IT系统性能问题诊断方法论 | 第三课
2018-01-31
关于DB性能优化的一切|利用MaxGauge进行DB深度优化2
2018-05-02

Latch: redo waiting

 

目录

1 Basic Info. 2

2 Parameter & Wait Time. 2

2.1 Wait Paremeters 2

2.2 Wait Time. 2

3 Check Point & Solution. 2

3.1 Redo相关争用… 2

 

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!

Notify of
avatar
wpDiscuz