什么是WHO-IT 方法？
W (Waite Event)是等待事件
H (Hit rate) 是命中率
O (thrOughput)吞吐量
I (Inetractive) 交互式
T (Reponse Time) 响应时间
这次我们谈等待事件，好几年前的2011年等待事件非常火爆，凡谈ORACLE优化的DBA必说之，以展现自己很牛逼样子！不过IT就是如此，如同女人的衣服一样时尚而流行！ 差不多10年之后的今天似乎没有人再谈等待事件，一方面去IOE导致ORACLE 日薄西山，而如日中天的是MYSQL分表分库的各种中间件。另一方面当然大家对常用的等待事件优化早已熟知。
什么是等待事件，从中文字面来说等待某件事件发生。好家伙不是这样翻译的，它就是个名词，不是动名词，它就是等待某种事完成而已。好吧，还是动名词。算了不解释了，解释就是在掩饰！
当一个SQL 从发给数据库到返回数据为止，其实执行得超快，快过我们忽略了它必须走的路程。走一段路遇到了十字路口的红绿灯，等待了3分钟才通行。然后再走，再等红绿灯放行！
因此我们要做到手中无剑，而心中有剑！ 时刻记住ORACLE 内存结构和进程运行机制图。
主要3个进程运行机制
1 LGWR
2 DBWR
3 CKPT
DBWR进程是将DATA BUFFER中的数据写入，磁盘数据文件.
DBWR触发条件
1. 产生检查点
2. 脏数据缓冲区达到阀值 默认 10%
3.扫描整个data buffer没有空闲
4. timeout 超时，如果DBWR没事做 会被每三秒唤醒一次去巡检 写不写不一定
5. 表级别的truncate 或 drop 也会触发数据写
6. 修改表空间的 read only
7. 做表空间的offline (离线)
8. 热备份 begin backup 命令
LGWR触发条件：
· 提交时(commit)
·Redo log buffer 达到三分之一满时
· Redo log buffer 达到1M
· 每隔三秒写一次
· DBWn执行写入之前
CKPT
概括下来其实就是 DBWn 负责写检查点队列上的脏数据块，而CKPT 负责记录当前检查点队列的第一个数据库块所对应的重做日志条目在日志文件中的地址，将其写入到控制文件中去。检查点的用途就是标识联机重做日志文件开始进行实例恢复的位置
每隔三秒(或频率更高)，CKPT进程在 控制文件中存储一次数据。
由CKPT进程写入的检查点信息包含检查点位置、系统更改号、联机重做日志文件中开始恢复的位置、关于日志的信息等等
如果使用日志切换，CKPT 进程还会将这个检查点信息写入到数据文件头。
使用检查点信息更新数据文件头
使用检查点信息更新控制文件
查看等待事件总数：
SQL> select count(*) from v$event_name;
查看等待事件分类情况：
SQL> SELECT wait_class#, wait_class_id, wait_class,
COUNT ( * ) AS "count"
FROM v$event_name
GROUP BY wait_class#, wait_class_id, wait_class
ORDER BY wait_class#;
相关的几个视图：
V$SESSION：代表数据库活动的开始，视为源起。
V$SESSION_WAIT：视图用以实时记录活动SESSION的等待情况，是当前信息。
V$SESSION_WAIT_HISTORY：是对V$SESSION_WAIT的简单增强，记录活动SESSION的最近10次等待。
V$SQLTEXT：当数据库出现瓶颈时，通常可以从V$SESSION_WAIT找到那些正在等待资源的SESSION，通过SESSION的SID，联合V$SESSION和V$SQLTEXT视图就可以捕获这些SESSION正在执行的SQL语句。
V$ACTIVE_SESSION_HISTORY:是ASH的核心，用以记录活动SESSION的历史等待信息，每秒采样一次，这部分内容记录在内存中，期望值是记录一个小时的内容。
WRH#_ACTIVE_SESSION_HISTORY :是V$ACTIVE_SESSION_HISTORY在AWR的存储地。
V$ACTIVE_SESSION_HISTORY:中的信息会被定期(每小时一次)的刷新到负载库中，并缺省保留一个星期用于分析。
DBA_HIST_ACTIVE_SESS_HISTORY:视图是WRH#_ACTIVE_SESSION_HISTORY视图和其他几个视图的联合展现，通常通过这个视图进行历史数据的访问。
V$SYSTEM_EVENT由于V$SESSION记录的是动态信息，和SESSION的生命周期相关，而并不记录历史信息，所以ORACLE提供视图V$SYSTEM_EVENT来记录数据库自启动以来所有等待事件的汇总信息。通过这个视图，用户可以迅速获得数据库运行的总体概况。
其实等待事件不可怕，等待事件也不是可以消灭的，这本身是SQL语句执行必须经过的步骤。非常强调这点！
那等待事件优化在于，第一 消灭该等待事件！第二降低等待事件时间和次数。
你说等待事件是SQL执行必须的步骤啊，不可以消灭的，为啥这里又说反呢？
这里说正常情况下任何条SQL语句必须经过，执行+等待事件的必要步骤。一当SQL语句生成了执行计划，那么SQL语句必须按照执行计划每一步去做。要消灭该等待事件自然去优化执行计划，是不是该走全表的却走了索引呢？
第二降低等待事件的时间和次数，比如说一个按钮被用户重复点击N>100遍！ 这个次数自然比平常的次数高很多，另外等待事件的时间异常下会比正常时间高出很多。使用AWR对比报表可以分析得到。
AWR报表上TOP5等待事件，正常来说就这几个
1 DB CPU
2 Db file sequential read
3 Db file scattered read
4 Db file parallel read
5 Log file sync
这5个是正常系统常见的等待事件，并且每个等待事件都正常消耗时间内。
比如说LOG FILE SYNC 要低于10毫秒。如果它变慢了，平均每次达到20毫秒，
怎么办呢？ 自然最简单的办法就是把REDO LOG移植到独立的硬盘上，比如说SSD,
RAID 10. 避免其他IO请求抢了它的硬盘IO能力。
如果要深入优化则要分析LOG FILE SYNC每个步骤，挖掘是什么影响它。
AWR报表提供了多角度看等待事件
Top 10 Foreground Events by Total Wait Time
EventWaitsTotal Wait Time (sec)Wait Avg(ms)% DB timeWait Class
DB CPU803070.4
db file sequential read694,1951089.229.5User I/O
gc cr multi block request782,979426.213.7Cluster
log file sync224,929344.723.0Commit
gc current block 2-way836,105295.902.6Cluster
gc cr disk read434,77497.80.9Cluster
gc buffer busy acquire62,86224.80.2Cluster
control file sequential read12,31321.12.2System I/O
gc cr grant 2-way57,92514.40.1Cluster
gc current grant 2-way53,70414.10.1Cluster
这是一套RAC在负载正常情况下的！
Wait Classes by Total Wait Time
Wait ClassWaitsTotal Wait Time (sec)Avg Wait (ms)% DB timeAvg Active Sessions
DB CPU8,03070.41.1
User I/O709,0231,10429.70.2
Cluster2,252,51988107.70.1
System I/O650,74557715.10.1
Commit224,93334523.00.0
Other1,935,992310.30.0
Network3,278,733280.20.0
Concurrency432,745140.10.0
Application1,62411.00.0
Configuration2205.00.0
Wait Events StatisticsTime Model Statistics
Operating System Statistics
Operating System Statistics - Detail
Foreground Wait Class
Foreground Wait Events
Background Wait Events
Wait Event Histogram
Wait Event Histogram Detail (64 msec to 2 sec)
Wait Event Histogram Detail (4 sec to 2 min)
Wait Event Histogram Detail (4 min to 1 hr)
Service Statistics
Service Wait Class Stats
1570
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
