Oracle Real Application Clusterの検証 その4

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

— 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に分散しましょうね。
茅ヶ崎にて