Oracle Real Application Clusterの検証 その４
＜Oracle Real Application Clusterの検証 ～その４～＞
ペンネーム ダーリン
— RAC環境でのチューニング —
先週はV$SYSTEM_EVENTから待機イベント、V$SEGMENT_STATISTICSビューから
オブジェクトの情報を探ってみました。
これらの情報から、シングルインスタンス状態では見られなかった”enqueue”
や、”buffer busy waits”という待機イベントが、RAC環境下ではかなり大き
な値になっていました。また、各オブジェクト単位では、ログ系のインデッ
クスが”buffer busy waits”や、”ITL waits”の多い対象オブジェクトとして
統計情報にあがってきました。
では、CASE02ではなぜ”buffer busy waits”や、”ITL waits”が多くなるので
しょうか。
先週みたV$SEGMENT_STATISTICSの情報のなかで、RAC環境下におけるWAIT時間
の大きいイベントとして、 “enqueue”、”buffer busy waits”、”buffer busy
global cache”があることをお話しました。
*********************************************************
V$SYSTEM_EVENTの情報
(先週の資料)
CASE INSTANCE NO EVENT WAIT数 WAIT時間(sec)
=================================================================
01 1 log file sync 1,763,899 422,800
latch free 456,638 38,245
buffer busy waits 244,583 16,821
enqueue 122,109 12,221
-----------------------------------------------------------------
02 1 enqueue 2,367,703 410,303 << (1)
buffer busy waits 3,025,078 314,120 << (2)
buffer busy global
cache 1,736,016 206,586 << (3)
global cache busy 1,042,919 95,160
latch free 4,551,655 75,086
--------------------------------------------------------
2 enqueue 2,341,917 408,503
buffer busy waits 3,034,419 321,680
buffer busy global
cache 1,748,311 213,001
global cache busy 968,529 85,302
latch free 4,638,862 73,170
-----------------------------------------------------------------
*********************************************************
<>
先週は、”enqueue”と”buffer busy waits”について調べてました。
では、”buffer busy global cache” は何を表しているのでしょうか。
文字通り解釈すると、”グローバル・キャッシュに関連するバッファー・ビジ
ー”ですね。では、”グローバル・キャッシュに関する・・”とは？？
ここからは、すこし、概念的なお話に入ります。数字が好きな皆さんには、
少し苦痛になるかもしれませんがお付き合いください。
シングルインスタンス環境では、自分のインスタンスにデータブロックがな
ければDISKから読み込むのですが、RACの場合はそのデータブロックを他のイ
ンスタンスが持っている可能性があります。この場合、InterConnectを利用
して該当するデータブロックを転送してもらいます。
そのメリットは？
もちろんOracleのボトルネックとなるDISK I/Oを減らすためですね。つまり、
RAC環境ではデータベースバッファがまるで3倍も、4倍も(インスタンスの数
分)あるような計算になります。ただし、ここで考慮しなくてはいけない点が
でてきます。
それぞれのインスタンスで好き勝手にデータブロックを扱えないことは、皆
さんご理解いただけるでしょう。全てのインスタンスでクエリーだけが実行
されているわけではないので、データブロックを取得する際に、自分が使い
たいデータブロックが、「他のインスタンスに存在するか」、「更新されて
いるか」、というような確認をした上で転送してもらいます。
このあたりの管理機構を掌っているのが、”GCS”です。皆さんも名前は聞いた
（見た）ことがあるでしょう。”GCS”は、グローバル・キャッシュ・サービス
の略称で、RACを構成するインスタンス全体に渡ってデータブロックの情報を
管理します。
実体はLMSと言うプロセスで、RAC環境下では、psコマンドを実行すると、そ
の存在を知ることが出来ます。目に見える形で存在すると少しほっとします
ね。
$ ps -ef | grep ora_lms
bora920 17535 1 0 May16 ? 00:00:36 ora_lms0_RACDB2 bora920 17537 1 0 May16 ? 00:00:33 ora_lms1_RACDB2 bora920 15286 15109 0 18:11 pts/4 00:00:00 grep ora_lms $
通常LMSプロセスは各インスタンスごとに2つ起動しています。
データの整合性を保つため、Oracleでは、よくロックと言う機構を利用しま
す。”GCS”も例外ではなく、インスタンス間のデータの整合性を保つために、
やはり、ロックを使います。
ちょっとデータブロックに関する情報を見てみましょう。
社内のRAC環境で見てみると、こんな感じです。
SQL> select status,count(*) from v$bh group by status ; STATUS COUNT(*) --------------- ---------- cr 453 free 11612 pi 11 scur 1335 xcur 232
データベースバッファにいくつかの状態で、データブロックが存在している
ことがわかります。なにやら見覚えのあるもの、ないものがあるのではあり
ませんか。
実は、ここにロックに関する情報が見えています。例えば、、、
続きは又来週。
オンラインREDOログファイルのメンバは、複数の物理DISKに分散しましょうね。
茅ヶ崎にて