Ges resources引起的library cache pin
作者 ：OoNiceDream【转载时请务必以超链接形式标明文章原始出处和作者信息】
链接：http://www.dbaroad.me/archives/2009/08/ges_resources_cause_library_cache_pin.html
链接：http://www.dbaroad.me/archives/2009/08/ges_resources_cause_library_cache_pin.html
RAC环境，9208,节点2上library cache pin非常严重，以下是Statspack报告中Top 5等待事件：
Top 5 Timed Events ~~~~~~~~~~~~~~~~~~ % Total Event Waits Time (s) Ela Time -------------------------------- ------------ ----------- -------- library cache pin 105,664 224,526 61.59 latch free 31,566,620 110,585 30.33 CPU time 16,591 4.55 db file sequential read 1,308,510 6,532 1.79 enqueue 36,749 4,587 1.26 ------------------------------------------------- |
数据库有监控DDL操作的trigger，未发现DDL操作。另外查询dba_ddl_locks及根据v$session字段command判断，未发现异常会话。
检查v$sgastat发现ges resources占用了相当大的部份，达到了近5个G的大小，整个shared pool也就6G，sql area被压榨得只有800M：
SQL> select * 2 from perfstat.stats$sgastat 3 where snap_id = 153106 4 and name in ('sql area', 'ges resources'); SNAP_ID DBID INSTANCE_NUMBER NAME POOL BYTES ------- ---------- --------------- --------------- ------------ ---------- 153106 1906744064 2 ges resources shared pool 5288077032 153106 1906744064 2 sql area shared pool 811700904 SQL> show parameter shared_pool NAME TYPE VALUE -------------------------------- ---------------- ------------ shared_pool_reserved_size big integer 322122547 shared_pool_size big integer 6442450944 |
正常情况下ges resources一般也就使用80M左右：
SQL> select * 2 from perfstat.stats$sgastat 3 where snap_id = 152831 4 and name in ('sql area', 'ges resources'); SNAP_ID DBID INSTANCE_NUMBER NAME POOL BYTES ------- ---------- --------------- --------------- ------------ ---------- 152831 1906744064 2 ges resources shared pool 83175352 152831 1906744064 2 sql area shared pool 5538146368 |
所以，原因很可能就是shared pool中ges resources占用过大，导致sql area太小，从而使SQL被频繁地刷入刷出shared pool，引起了library cache pin 。这与Bug 3046725 ORA-4031 due to shared_pool fragmented with high ges resources & enqueues有些类似。我们可以设置_lm_locks / _lm_ress 参数，为ges资源先预分配一些内存，从而避免类似情况发生。但预分配了，不等于不会再占shared pool，超过部份还是要从shared pool中分配的，所以这里5G的大小，还是太大了。
要注意的是，flush shared pool是无法回收shared pool中的ges resources的，最终还是通过重启实例来释放的。
附一个设置了_lm_locks / _lm_ress的生产数据库参数设置情况：
SQL> @getpar 输入 par 的值: lm_lock NAME VALUE ISDEFAULT ISMOD ISADJ ----------------------- ---------------- --------- ------- ------ _lm_locks 120000 FALSE FALSE FALSE SQL> @getpar 输入 par 的值: lm_ress NAME VALUE ISDEFAULT ISMOD ISADJ ----------------------- ---------------- --------- ------- ------ _lm_ress 14000000 FALSE FALSE FALSE SQL> select * from v$resource_limit where resource_name like 'ges%'; RESOURCE_NAME CURRENT_ MAX_UTILIZATION INITIAL_ALLOCATION LIMIT_VALUE --------------- --------- --------------- ------------------ ----------- ges_procs 1818 2839 3549 3549 ges_ress 255919 258037 14000000 UNLIMITED ges_locks 40321 201349 120000 UNLIMITED ges_cache_ress 72720 74108 0 UNLIMITED ges_reg_msgs 1993 4353 7326 UNLIMITED ges_big_msgs 150 379 7326 UNLIMITED ges_rsv_msgs 0 0 1000 1000 |
最后还有一个问题，是什么原因导致ges resources激增呢？估计原因比较复杂，这次是因为数据加载导致的。
— The End —
关键字: 故障案例
以前我也遇到过ges resources占用了大量内存的问题，我也很想知道ges resources里都是啥东东？
我是这么想的，既然ges resources你这么大，我那就拿刀剖开你的肚皮，看看里面都是啥？不知道哪位高人可以指点迷津。
Reply