Oracle Event详解| 第4集 Enq:TX-index contention
2018-05-02
IT系统性能问题诊断方法论 | 第三课
2018-01-31
Latch: redo waiting
目录
1 Basic Info
为了节省重做缓冲区的空间，向LGWR请求写入的进程需要获取redo writing的锁存器。因为根据LGWR写的操作不能同时进行，所以这个latch在整个实例中只存在一个。redo writing的锁存器是独立的锁存器(solitary latch)，所以可以通过V$LATCH_PARENT来观察它的活动性。
| SQL> select name, gets, misses, immediate_gets, immediate_misses,
wait_time from v$latch_parent where name = ‘redo writing’;
NAME GETS MISSES IMMEDIATE_GETS IMMEDIATE_MISSES WAIT_TIME ———- ———- ———- —————- —————- ——— redo writing 829715 20 0 0 0 |
redo writing的锁存器以Willing-to-wait方式来获取。在获取redo writing锁存器的过程中若发生争用，会等待latch：redo writing事件。
2 Parameter & Wait Time
2.1 Wait Paremeters
与latch free事件相同。
2.2 Wait Time
与latch free事件相同。
3 Check Point & Solution
3.1 Redo相关争用
一般环境下不会发生相关重做的锁存器争用。如果在整个系统的等待事件目录中相关重做的锁存器占据着前几位，那么可以解释为发生了对重做的严重的争用。根据metalink文件编号码14747.1，misses / gets在1%以上或者immediate_misses / ( immediate_gets + immediate_misses)为1%以上的时候，视为获取重做锁存器过程中发生了争用。但是比起次数，将重做锁存器的等待时间作为争用发生的证据来使用是更为恰当。
重做缓冲池大小可能会成为引起重做锁存器争用的原因。重做日志区过小的时候，LGWR的后台记录工作(Background write)会频繁的发生。特别是有长时间生成数据的事务处理时，LGWR需要频繁的执行后台记录工作。LGWR为了执行记录的操作，需要获得关联重做的锁存器，所以会引起锁存器争用的增加。所以重做锁存器争用经常发生的时候，需要查看重做日志区的大小是否太小。
在系统整体上产生过多不必要的重做数据时，利用Nologging功能减少重做数据，也是减少锁存器争用的方法。但是，需要注意Nologging操作是不可恢复的。幸好大部分关于重做性能问题不是锁存器争用，而是跟应用程序的运行方式或者I/O的性能有关。用“幸好”来表示的原因是因为很多时候对重做锁存器发生争用时，没有什么特别有效的解决方法。从Oracle升到9i、10g开始，因为对关于重做日志区的的oracle内部的算法有了重大的改进，所以大部分的锁存器争用已经不是问题了。
实际上，生成许多重做数据时，通过模拟看看产生多少重做锁存器的争用。测试方案如下。
同时从30多个会话执行DML，产生大量的重做数据。
确认在这个过程中产生的重做锁存器。
| SQL> ed redo_test.sql
— 如下，执行数百次的update和commit，增加重做区域的负载的SQL语句。 update redo_test set id = id, name = name where id = &1; commit; update redo_test set id = id, name = name where id = &1; commit; update redo_test set id = id, name = name where id = &1; ….
SQL> ed redo_test.bat — 如下，同时从30多个会话执行redo_test.sql。 start sqlplus maxgauge/maxgauge@ora10gr2 @redo_test 1 start sqlplus maxgauge/maxgauge@ora10gr2 @redo_test 2 … start sqlplus maxgauge/maxgauge@ora10gr2 @redo_test 30
cmd> redo_test.bat |
执行以上脚本后，查看会话的等待状况可以得到以下结果。
| SQL> select event, total_waits, time_waited
from v$session_event where sid = (select sid from v$mystat where rownum = 1) order by 3 desc;
EVENT TOTAL_WAITS TIME_WAITED —————————— ————– ———– SQL*Net message from client 515 5458 buffer busy waits 106 503 log file sync 129 231 latch: cache buffers chains 86 84 latch: In memory undo latch 27 17 events in waitclass Other 18 15 latch: library cache 22 14 SQL*Net message to client 516 3 latch: redo copy 2 3 latch: library cache pin 4 1 SQL*Net break/reset to client 2 0 cursor: mutex S 193 0 |
可以看到log file sync等待和latch：redo copy等待是一起发生的。但是可以确认在整个等待中占据的比重较低。
Leave a Reply
Be the First to Comment!