« oramon如何收集V$SYSTEM_EVENT数据? »
Tools » http://www.anysql.net/tools/oramon-system-event.html 2009-06-25基于等待事件的性能调优方法, 自从提出来后就一直很管用, 很快就替换掉了根据命中率来调优的老方法. 当然oramon也同样关于等待事件的数据, 同样以10秒钟的频率计算出10秒内发生的等待事件数据, 并用如下格式保存.
06/25-15:23:44 206-49792:416125:83, 203-18279:89351:48, 157-8436:47502:56, 21-153:1438:93, 4-397:1360:34, 195-10382:906:0, 209-128:726:56, 210-26:514:197, 372-1409:24:0, 233-111:15:1, 207-1:10:100, 234-50:0:0, 152-2:0:0,
06/25-15:23:54 206-49756:414376:83, 203-18221:90461:49, 157-10301:52368:50, 4-448:1543:34, 209-161:1007:62, 21-180:973:54, 195-10376:926:0, 210-36:566:157, 372-1343:21:0, 207-2:13:65, 233-61:0:0, 234-50:0:0, 152-3:0:0,
每一个时间点一行, 按总等待时间降序排列各个事件的数据, 单个事件的格式为”事件号-等待次数:等待时间:平均时长”, 需要注意的是平均时长的单位是万分之一秒, 而不是千分之一秒(毫秒). 可以从目标库(不同版本会有差异)中根据事件号来查询等待事件名称.
SQL> select name from v$event_name where event#=206;
NAME
——————————————–
db file sequential read
象上面的例子中, 可以看到平均单块读的时间为8毫秒, 这个值可以用来评价OLTP系统的存贮响应时间. 利用10秒钟的等待事件数据, 帮我们发现了Oracle中超长log file sync等待的问题, 并成功绕过这个Bug, 有利于保持数据库系统的稳定运行.
Tags: DBA, Oracle, Tools, Tuning


好工具啊!
超长log file sync等待?log file sync正常情况下应该是1秒timeout吧,
但是即使timeout了,commit应该还是要等的,是怎么绕过去呢?
是好工具, 我一直在用, 是我确定数据库性能问题的依据呢.
可因为没有界面, 也没有报表, 没有人关注啊.
呵呵,因为对那些关键statistics清楚的人大多都可以有script简单采集下,不清楚的看了也还是不清楚,谁都喜欢简单直观的东西.
还是比较疑问:
超长log file sync等待?log file sync正常情况下应该是1秒timeout吧,
但是即使timeout了,commit应该还是要等的,是怎么绕过去呢?