从GC 上的“顶级活动” 看,公司一套ADG环境发现备库的活动会话数比主库还要高,
备库的顶级活动
主库的顶级活动
在备库查看等待事件,发现很多的latch: row cache objects ,再细查v$rowcache ,发现很多的dc_rollback_segments 。
如果回滚段使用满了,那么所有使用回滚段的有可能产生等待回滚段的等待,最终导致了row cache lock上dc_rollback_segments 类型的等待。而如果row cache lock等待,这是一个和解析有关的等待,所有需要执行sql解析的会话都有可能需要等待。
大量的查询都放在了备库,由于读的一致性,肯定会导致undo 段的大量分配,这和上面 解释是吻合的。
SID SPID PID EVENT P1P2P3 SQL_ID SECON BLOCKING_SESSION
------- ---------- ---------- ------------------------- ------------------------- ------------------ ----- ----------------
3717 28726 519 SQL*Net message to client 1650815232\1\0 8zqdba64hxdav 0
102 103975 385 SQL*Net message to client 1413697536\1\0 9a4c54hbg70dy 0
2290 15887 504 buffer busy waits 103\577246\90 7v63ns0d1qhq6 0
1146 38676 108 buffer busy waits 3\1192\89 6u67x9u3dmq5p 0
2958 42552 511 latch: row cache objects 136586211008\280\0 3dfx9syby1c6d 0
2855 21231 366 latch: row cache objects 136586211008\280\0 7jrb7aqj65d0a 1
3809 30755 376 latch: row cache objects 136586211008\280\0 gsdqa446dz5xf 0
1051 30637 107 latch: row cache objects 136586211008\280\0 f58sjxwxfrb4u 1
679 32602 439 latch: row cache objects 136586211008\280\0 6jc8r0ck2m8gp 1
2292 34458 120 latch: row cache objects 136586211008\280\0 46wn35kfb0xn1 1
2946 143096 31 log file sequential read 0\197913\1811 27456
74
12:35:50 sys@wms>select PARAMETER,GETS from v$rowcache order by GETS desc;
PARAMETER GETS
-------------------------------- ----------
dc_rollback_segments 4244627126
dc_objects 2272530280
dc_users 1072341338
dc_tablespaces 925254872
dc_segments 372616310
dc_histogram_data 204239388
dc_histogram_defs 195818203
dc_histogram_data 191755202
global database name 2810177
dc_global_oids 1105448
dc_users 603450