端午放假之后,从6月7日开始,DB 就不太稳定,alert log 出现了:checkpoint not complete, cannot allocate new log 的警告。 所以加了一个online redo log group。 不过警告并没有因此消失,第二天又加了一组。 原来是4组,加了2组之后就有6组。 而且每天的归档也比以前增加了1G多。 CPU 也上升到了50%,高的时候,能波动到80%。
通过AWR 报告查看,等待事件排名前2的是:log file sync和 log file parallel write。 这2个等待事件更写log的速度和用户commit的频率有关。
查看Trace 文件,有一些警告信息:
WARNING:Could not increase the asynch I/O limit to 160 for SQL direct I/O. It is set to 128
WARNING:Could not increase the asynch I/O limit to 160 for SQL direct I/O. It is set to 128
WARNING:Could not increase the asynch I/O limit to 160 for SQL direct I/O. It is set to 128
WARNING:Could not increase the asynch I/O limit to 160 for SQL direct I/O. It is set to 128
WARNING:Could not increase the asynch I/O limit to 192 for SQL direct I/O. It is set to 128
看到WARNING:Could not increase the asynch I/O limit to 160 for SQL direct I/O. It is set to 128 的警告,怀疑是Oracle的bug。 在MOS上搜了半天,只找到一个类似的信息。 不过这个bug 的版本只争对 oracle 10.2.0.4 的版本,在10.2.0.5 的版本已经修复过了。 我的DB 去年做过升级。 现在的版本是10.2.0.5,所以不太可能是这个bug。
lgwr的trace 也有警告:
[oracle@qs-xezf-db1 bdump]$ tail -50 xezf_lgwr_11189.trc.bak
*** 2011-06-09 06:02:48.846
Warning: log write time 610ms, size 6KB
*** 2011-06-09 06:02:54.119
Warning: log write time 800ms, size 18KB
*** 2011-06-09 06:02:54.821
Warning: log write time 700ms, size 25KB
......
*** 2011-06-09 22:43:21.961
Warning: log write time 670ms, size 1KB
*** 2011-06-09 23:20:03.613
Warning: log write time 670ms, size 5KB
*** 2011-06-10 00:16:34.240
Warning: log write time 730ms, size 13KB
根据Oracle 的说法:
Warning: log write time 730ms, size 13KB 这个警告是在10.2.0.4 之后才有的,当log write 超过500ms,就会出现这个警告。
LGWR Is Generating Trace file with 'Warning Log Write Time 540ms, Size 5444kb' In 10.2.0.4 Database
http://blog.csdn.net/tianlesoftware/archive/2011/06/10/6537196.aspx
昨天晚上收到的报警短信CPU 更是超过了90%,有时还是100%。 今天早上到公司收了下监控邮件。 发现归档比昨天又增加了2G。 这个明显不太正常。就是业务增长,也不应该是这个长法。 在CPU 超过90%的时候,根据Linux pid 抓到了SQL 语句。 然后查看了对应的表。 有400多万的记录。
然后从6月1号到6月10号的记录就有370w。 数据很不正常,问同事这几天可有做什么修改,有做大事务的操作没。同事说没有,查看了中间件的log,发现了问题,从昨天晚上0点到今天早上8 点,同一个IP 地址刷了12w的记录到这张表。前面几天的log 没有查看,肯定和这个IP 也有关系。很明显是用程序在刷,人工刷不了这么多的记录, 和同事商量了下业务流程,想在流程上杜绝这种狂刷的做法。 这个需要点时间。
先从这几张表入手, 将这张400w的表进行了手工转历史。 转移了300w的数据,然后就log表。 这个也是重灾区。 一共1700w的记录,其中有900万的记录是6月份以后的。 转历史之后log表还有900w的记录。
从AWR 报告上看到这个log表上的索引有较严重的等待。因为这个表是更新多,查询很少,所有的交易都会写这个log表,更新相当频繁,维护索引的成本明显要大于查询的成本,所以drop 掉了这个索引。
数据转历史之后,收集了一下表的统计信息,因为删除了大量的数据,此时的统计信息很明显有变化,不手动更新,CBO 还是会使用以前的统计信息。那样执行计划就会有偏差。
在查看了一下CPU,已经降到了20%左右。恢复正常。根据AWR ,对占用资源较多的几个SQL语句,做了小修改,建了联合索引。 在看CPU 已经降到15%左右。CPU 这块已经差不多了。
IO 这块还是瓶颈。 不过lgwr trace出现Warning: log write time 660ms, size 1KB 这种警告的周期变长。 如果业务流程不改,还是有大量的业务数据刷进来的话, 写log 还是个大问题。
-------------------------------------------------------------------------------------------------------
Blog: http://blog.csdn.net/tianlesoftware
Email: dvd.dba@gmail.com
DBA1 群:62697716(满); DBA2 群:62697977(满) DBA3 群:62697850(满)
DBA 超级群:63306533(满); DBA4 群: 83829929 DBA5群: 142216823
DBA6 群:158654907 聊天 群:40132017 聊天2群:69087192
--加群需要在备注说明Oracle表空间和数据文件的关系,否则拒绝申请
分享到:
相关推荐
CPU使用率 = 1- 空闲时间/CPU总时间 用户态占用过多的CPU,应着重排查用户进程的性能问题。 系统态占用过多的CPU,应着重排查系统调用,内核进程的问题。 IO等待时机过长,应着重排查系统存储的IO问题。 软中断硬...
操作系统性能监控优化不外乎对CPU、Memory、IO、Network这四个方面,下面分别介绍使用工具和指标 一、CPU 1、良好状态指标 CPU利用率:User Time <= 70%,System Time <= 35%,User Time + System...
我认为性能优化是很重要的一项工作,比如服务器CPU使用率过高,top命令之后怎么快速定位问题,又比如系统没有跑什么占用内存的程序,但是用free一看,内存已经不多了,应该怎么处理,或者一大早起来,zabbix收到报警...
而问题定位分析通常情况下,最优先排查的是监控服务器资源利用率,例如先用TOP 或者nmon等查看CPU、内存使用情况,然后在排查IO问题,例如网络IO、磁盘IO的问题。 如果是磁盘IO问题,一般问题是SQL语法问题、MYSQL...
服务器系统健康监控体系 硬件监控项 CPU使用率 内存使用率 硬盘使用率 内网网卡使用率 外网网卡使用率 磁盘IO 服务器监控及性能优化全文共27页,当前为第6页。 服务器系统健康监控体系 服务器监控及性能优化全文共...
dj及xh_bz的比较,而在进行第二条SQL的时候0.5%条记录都进行dy_dj及xh_bz的比较,以此可以得出第二条SQL的CPU占用率明显比第一条低。 查询表顺序的影响 在FROM后面的表中的列表顺序会对SQL执行性能影响,在...
第一部分 ORACLE系统优化基本知识 23 第1章 ORACLE结构回顾 23 §1.1 Oracle数据库结构 23 §1.1.1 Oracle数据字典 23 §1.1.2 表空间与数据文件 24 §1.1.3 Oracle实例(Instance) 24 §1.2 Oracle文件 26 §1.2.1...
CPU占用率很高(CPU占用超过了100%) 主线程Runloop执行了很久(抢锁或大量IO)(主线程Runloop执行了超过2秒) 工具及方法: 采取的措施: 现网用户的卡顿状况通过接收bugly卡顿监控,通过下发配置,对现网用户...
HBase是一个庞大的体系,涉及到很多方面,很多因素都会影响到系统性能和系统资源使用率,根据场景对这些配置进行优化会很大程度上提升系统的性能。笔者总结至少有如下几个方面:HDFS相关配置优化,HBase服务器端优化...
使用Toad,我们可以通过一个图形化的用户界面快速访问数据库,完成复杂的SQL和PL/SQL代码编辑和测试工作。Toad由Oracle开发专家专门为开发人员而设计,是一个功能强大、结构紧凑的专业化PL/SQL开发环境。 Toad 主要...
CPU的执行时间、IO等待的时间和锁等待时间。 平均I/O响应时间。 支持峰值IOPS数和MPS数。 物理读和逻辑读的百分比。 有效索引读的百分比。 有效行读的百分比。 数据库设计准则及方法论全文共5页,当前为第3页。...
服务器性能监控,系统资源(cpu使用率、内存使用率、磁盘、网络 IO)监控图形化界面展现,在图形中可设定“危险警戒线”,当出现异常情况时,图形界面一目了然。 ③用户管理账号防护 云锁可双向保障账号安全,一...
可以显示磁盘系统的最大IO能力、磁盘系统的最大吞吐量、CPU使用率、错误信息等。用户可以通过设置不同的测试的参数,有存取类型(如sequential ,random)、读写块大小(如64K、256K),队列深度等,来模拟实际应用的读写...
可以用该用户登录系统, 使用命令“ulimit -f”和“ulimit -Hf”可分别显示其fsize,fsize_hard的大小. //如何查看小型机适配器卡及硬盘的微码级别microcode level lscfg -vl device_name //查询SSA卡的微码级别 #...
同时CPU占用率更低。 HttpUploader4更加注重对硬盘的保护,在HttpUploader4中不再直接对文件进行I/O操作,而是在内存中对文件进行操作,所以不仅极大的减少了对硬盘的读写次数,同时速度却变的更快了。 借助于...
同时CPU占用率更低。 HttpUploader4更加注重对硬盘的保护,在HttpUploader4中不再直接对文件进行I/O操作,而是在内存中对文件进行操作,所以不仅极大的减少了对硬盘的读写次数,同时速度却变的更快了。 借助于...
同时CPU占用率更低。 HttpUploader4更加注重对硬盘的保护,在HttpUploader4中不再直接对文件进行I/O操作,而是在内存中对文件进行操作,所以不仅极大的减少了对硬盘的读写次数,同时速度却变的更快了。 借助于...
同时CPU占用率更低。 HttpUploader4更加注重对硬盘的保护,在HttpUploader4中不再直接对文件进行I/O操作,而是在内存中对文件进行操作,所以不仅极大的减少了对硬盘的读写次数,同时速度却变的更快了。 借助于...