Oracle Real Application Clusterの検証 その５
＜Oracle Real Application Clusterの検証 ～その５～＞
ペンネーム ダーリン
— RAC環境でのチューニング —
台風がやってまいりました。まもなく梅雨に入り暑かったり寒かったりする
とおもいます。皆さんお風邪を召しませんように。
さて、先週はRAC環境におけるデータベースバッファの管理を掌る機構として
“GCS”、グローバルキャッシュサービスのお話をしました。今週はその続きで
す。
Oracleでは、データなどの整合性を保証する手段としてロックを使います。
そこで、データベースバッファのロックに関する様子を見るために、先週
V$BHビューから情報を取得してみました。その結果は以下のとおりでした。
環境はRACです。
(先週の資料)
SQL> select status,count(*) from v$bh group by status ; STATUS COUNT(*) --------------- ---------- cr 453 free 11612 pi 11 scur 1335 xcur 232
この結果を少し説明すると、以下の様になります。
データベースバッファ上に占めるデータブロックの数：13643ブロック 読み取り一貫性ブロック(cr)：453ブロック 空きブロック(free)：11612ブロック PIブロック(pi)：11 共有モードブロック(scur)：1335ブロック 排他モードブロック(xcur)：232ブロック
実は、最後の2種類のブロックに関してはいわゆるロックがかかっているこ
とを現しています。
共有モード(scur) 任意のインスタンスで、検索した場合に取得するステータス。 このデータブロックがこのステータスの場合は、複数のインスタンスに同 一ブロックが存在する場合があります。 排他モード(xcur) 更新目的でデータブロックをバッファに読み込むと排他モードとなります。 当然ですね。更新するために読み込んだので、他のインスタンスで更新さ れては困ります。
また、排他モードでデータブロックを読み込むとき、すでに他のインスタン
スに読み込まれている可能性があり、(普通はこちらの可能性の方が多いで
しょうねぇ。) この場合、それらのインスタンスに通知する必要があります。
「俺が触るから、おまえたちは触れるな」って感じですね。
このとき、このもともとロックを取得していた方のインスタンスにあるデー
タブロックには、排他モードを解除した回数がカウントされます。
いわゆる”ロックダウン”です。
また、元のインスタンスにあるデータブロックが共有モードで読み込まれて
いた場合は、読み取り一貫性ブロック(CRブロック)としてそのままデータベ
ースバッファ上に残ります。排他モードの場合はすこし違って、”PI”ブロッ
クと呼ばれるステータスになります。(Performance Insightではありませ
んので念のため。)
RAC環境では全てのインスタンスにまたがって、このようにデータブロックレ
ベルのロック取得が行われ、このおかげでデータの整合性が保たれるんですね。
<>
さて、先週から”GCS”のお話をしてきましたが、これは、データベースバッファ
がひとつしかない（※）シングルインスタンス環境では、考慮する必要がな
かった、インスタンス間のロックに関する制御を掌るサービスで、RAC環境で
は、これが重要な役割を果たしていることをお話してきました。
では、”GCS”の稼動状態を調べる方法はないでしょうか。
RAC環境でロックなどのインスタンス間の処理に絡む統計情報を見るためには、
たとえば、”global”と言う単語がキーワードになります。
V$SYSSTATビューや、V$SESSTATとV$STATNAMEをジョインすると、このような
イベント名がたくさん出てきます。”global cache ・・・”は主に”GCS”が関
連する処理の統計値を表してくれます。
RACに影響しそうな”global lock ・・・” と言うイベントもあります。
SQL> select distinct name from v$sysstat where name like 'global%' NAME ------------------------------------------------ global cache blocks corrupt global cache blocks lost global cache claim blocks lost global cache convert time global cache convert timeouts global cache converts global cache cr block build time global cache cr block flush time global cache cr block receive time global cache cr block send time global cache cr blocks received global cache cr blocks served global cache current block flush time global cache current block pin time global cache current block receive time global cache current block send time global cache current blocks received global cache current blocks served global cache defers global cache freelist waits global cache get time global cache gets global cache prepare failures global cache skip prepare failures global lock async converts global lock async gets global lock convert time global lock get time global lock releases global lock sync converts global lock sync gets 31行が選択されました。 SQL>
(すこし戻って)CASE01とCASE02でこれらのイベントについて取得していた統
計値を見比べてみました。
すると、、
**********************************************************
CASE01 CASE02 (instance 1)
----------------------------------------------------------
global cache convert time(※1) 2.3 22.9 (ms)
global lock get time(※2) 1.3 38.6 (ms)
※1 global cache convert time/global cache converts
※2 global lock get time/(global lock async gets+global lock sync gets)
**********************************************************
どうも、上記の2つのイベントでCASE01の時と比較して、時間がかかっている
ようです。CASE01では、シングルインスタンス状態だったので、もとからイ
ンスタンス間の調整など不要だったので当たりまえのことですね。
CASE02では、この分がオーバーヘッドになった可能性があると言うことにな
るのでしょうか。
そこで、今回は各インスタンス間で頻繁に要求されるオブジェクトをチュー
ニングのターゲットにすることにしました。
(ふー。やっとここまで来た。先はながいぞ。)
ば、バ、バトンが。。。 茅ヶ崎にて