一次大量latch:library cache,latch free,latch:row cache objects,latch:shared pool故障一例

早上出现故障的时候,我们登陆到服务器非常的缓慢。登陆上之后执行操作系统topas命令发现大系统cpu 100%,同时出现大量的page space使用的情况。

 
如图所示,当前的cpu使用率为100%,而系统正在发生page交换,通过lsps –a查看page所在的磁盘。

oracle@[/oracle]$lsps -a
Page Space      Physical Volume   Volume Group    Size %Used Active  Auto  Type
paging00        hdisk0            rootvg        8192MB     9   yes   yes    lv
hd6             hdisk0            rootvg        8192MB     9   yes   yes    lv

这里可以看到paging所有的盘是hdisk0,而在topas中可以看到hdisk0的磁盘使用率正好是100%。
由于使用了交换分区,此时主机非常的卡顿,DBA得到授权将数据库连上来的进程kill,并重启了数据库,释放了page的使用,恢复了业务。
由于当时使用交换,导致主机非常卡顿,通过当时执行的命令,可以看到数据库存在下列异常等待事件。

 
异常等待事件主要集中在latch:library cache,latch free,latch:row cache objects,latch:shared pool等等。
而通过当时的hanganalyze文件,可以发现下列问题

Open chains found:
Chain 1 : <cnode/sid/sess_srno/ospid/wait_event> :
    <0/1238/48822/7065650/No Wait>
 -- <0/2001/39972/5091404/latch: cache buffers chains>
Chain 2 : <cnode/sid/sess_srno/ospid/wait_event> :
    <0/1368/30056/6525120/No Wait>
 -- <0/2135/34699/7209246/enq: US - contention>
 -- <0/3719/45790/1593804/enq: US - contention>
 -- <0/1181/19814/4796780/enq: US - contention>
 -- <0/2084/34256/5067152/enq: US - contention>
 -- <0/1289/43797/3043610/enq: US - contention>
Chain 3 : <cnode/sid/sess_srno/ospid/wait_event> :
    <0/2018/59725/839906/No Wait> -- <0/1216/52471/946238/latch: shared pool>
 -- <0/1125/22284/700568/latch: library cache>
Chain 4 : <cnode/sid/sess_srno/ospid/wait_event> :
    <0/2416/7593/717294/No Wait> -- <0/1093/58083/4329904/latch: shared pool>
 -- <0/1183/11571/6033794/latch free>
Chain 5 : <cnode/sid/sess_srno/ospid/wait_event> :
    <0/2828/27676/2760914/No Wait> -- <0/2873/17499/7344436/latch: shared pool>
 -- <0/4089/21626/1098142/enq: SQ - contention>
 -- <0/2037/20966/1593434/enq: SQ - contention>
 -- <0/1144/63358/938388/enq: SQ - contention>
 -- <0/1417/28837/5980514/enq: SQ - contention>
 -- <0/2266/53190/5656926/enq: SQ - contention>
 -- <0/3263/18056/5071068/enq: SQ - contention>
 -- <0/2942/37833/2859166/enq: SQ - contention>
 -- <0/2128/2570/528474/enq: SQ - contention>
 -- <0/3306/48374/1610236/enq: SQ - contention>
 -- <0/3566/27572/1212630/enq: SQ - contention>
 -- <0/1694/7066/5398642/enq: SQ - contention>
 -- <0/1571/14643/3207368/enq: SQ - contention>
 -- <0/3178/63446/676180/enq: SQ - contention>
 -- <0/2645/26248/909592/enq: SQ - contention>
 -- <0/1309/45338/1179948/enq: SQ - contention>
 -- <0/3601/5173/585802/enq: SQ - contention>
 -- <0/4105/13466/3019110/enq: SQ - contention>
 -- <0/4260/8280/4534328/enq: SQ - contention>
 -- <0/3501/31240/3219628/enq: SQ - contention>
 -- <0/3495/59861/4043206/enq: SQ - contention>
 -- <0/2967/54472/2662708/enq: SQ - contention>
 -- <0/3602/24026/4624628/enq: SQ - contention>
 -- <0/3870/34387/1401144/enq: SQ - contention>
 -- <0/2038/19862/3366974/enq: SQ - contention>
 -- <0/2074/64236/6262996/enq: SQ - contention>
 -- <0/3009/50866/4735076/enq: SQ - contention>
 -- <0/1157/62270/987524/enq: SQ - contention>
 -- <0/4307/15391/6500818/enq: SQ - contention>
 -- <0/3327/5325/327982/enq: SQ - contention>
 -- <0/4177/18769/1323248/enq: SQ - contention>
 -- <0/2024/48829/2150588/enq: SQ - contention>
 -- <0/4267/56291/1917232/enq: SQ - contention>
 -- <0/3243/43651/6197554/enq: SQ - contention>
 -- <0/1365/28689/3137584/enq: SQ - contention>
 -- <0/3970/7235/3469734/enq: SQ - contention>
 -- <0/3439/56494/6680960/enq: SQ - contention>
 -- <0/2858/1694/1437882/enq: SQ - contention>
 -- <0/1509/47049/5816734/enq: SQ - contention>
 -- <0/4133/633/3236212/enq: SQ - contention>
 -- <0/2360/62359/803142/enq: SQ - contention>
可以发现多数的会话当时都在等待latch:shared pool,而产生latch:shared pool的主要原因如下:

Shared pool latch
Possible Causes :
The shared pool latch is used to protect critical operations when allocating and freeing memory in the shared pool
共享池锁存器用于在共享池中分配和释放内存时保护关键操作
Contentions for the shared pool and library cache latches are mainly due to intense hard parsing. A hard parse applies to new cursors and cursors that are aged out and must be re-executed
共享池和库高速缓存锁存器的争用主要是由于很多的硬解析。硬解析适用于老化的游标和游标执行失败,必须重新执行

这里可以看到可能的产生latch:shared pool和latch: library cache都可能是硬解析导致的。
而基于上述判断,咨询了昨晚做的变更操作,执行了修改密码的操作,而修改了密码之后并没有修改相关的db_link密码,导致早上db_link的操作一直持续不断的执行。最终导致了系统硬解析严重,引起了相关的latch争用,从而导致出现数据库和主机hang住。
这一点可以从后台日志看到,当时的db link产生了大量的2pc_pending的事务。

 
所以当修改密码的时候,一定要梳理与之相关的db link的密码。

分享到: 更多

Post a Comment

Your email is never published nor shared. Required fields are marked *