ただし、キャッシュヒット率が激減し、一時的にパフォーマンスダウンが予想されるのでタイミングに注意。
RACの場合は、一度に全ノードクリアするのではなく、クリア後ある程度キャッシュがたまってきてからの方がベターです。
共有プールのサイズが大きすぎるとエージアウトした際のロック(ラッチ)の時間が長くなり、DBサーバの応答が遅くなります。
この例のようにsql area(SQL数)が多いことが根本原因なのでアプリを直すべきですが、障害対応として紹介します。
(とはいえ、リスクの方が大きいので僕はめったにクリアしません)
共有プールのラッチは、CPU使用率もI/O負荷も上昇しないので検知しづらく潜在リスクは非常に高いと思っています。
まず、現状の共有プールの状況を確認します。
例えば、次のようにsql areaが3.5GBほどあるインスタンスをクリアすることにします。set pages 10000 set lines 120 set time on col name for a40 select * from ( select name, bytes from v$sgastat where pool = 'shared pool' order by bytes desc ) where rownum <= 20;
共有プールのクリアはインスタンスごとにalter systemします。NAME BYTES ---------------------------------------- ---------- sql area 3690078544 free memory 957169136 PCursor 637214224 CCursor 623044928 library cache 499544096 sql area:PLSQL 268971096 gcs resources 233915744 gcs shadows 140065792 kglsim object batch 137342016 db_block_hash_buckets 94371840 kglsim heap 82446336 Cursor Stats 64968688 ASH buffers 30408704 transaction 19464072 ges enqueues 18813632 trace buffer 16891904 ges big msg buffers 15936168 KCL name table 12582912 event statistics per sess 12296000 FileOpenBlock 11575096
次のようにsql areaが消え、free memoryが増加します。$ sqlplus sys as sysdba SQL> alter system flush shared_pool;
NAME BYTES ---------------------------------------- ---------- free memory 6376176928 gcs resources 233915744 kglsim object batch 191237088 library cache 152614448 gcs shadows 140065792 kglsim heap 108622080 db_block_hash_buckets 94371840 Cursor Stats 85479368 sql area 44653328 ASH buffers 30408704 transaction 19490568 ges enqueues 18813632 trace buffer 16891904 ges big msg buffers 15936168 KCL name table 12582912 event statistics per sess 12296000 FileOpenBlock 11575096 CCursor 11276472 ges resource 11221136
0 件のコメント:
コメントを投稿