Oracle Real Application Clusterの検証 その5

<Oracle Real Application Clusterの検証 ~その5~>
ペンネーム ダーリン

— 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では、この分がオーバーヘッドになった可能性があると言うことにな
るのでしょうか。

そこで、今回は各インスタンス間で頻繁に要求されるオブジェクトをチュー
ニングのターゲットにすることにしました。

(ふー。やっとここまで来た。先はながいぞ。)

ば、バ、バトンが。。。 茅ヶ崎にて