Oracle Real Application Clusterの検証 その１１
＜Oracle Real Application Clusterの検証 ～その１１～＞
ペンネーム ダーリン
— RAC環境でのチューニング —
今回のシリーズでは、Oracle Real Application Clusterについて、実際の
環境で発生したケースを題材に、その時のチューニング作業をトレースして
きました。
すこし振り返ってみましょう。
1.まず、開発環境(シングルインスタンス)で動作確認を行ったアプリケーシ
ョンを、本番環境(もちろんRAC)に導入し、取り敢えずテストを行うと、
あらまーびっくり、シングルインスタンス状態の方が、RAC構成の時より
処理が高速に行われています。
スケーラビリティーで言うところの、”0.67″でした。
2.さて、ボトルネックの洗い出しです。
V$SEGMENT_STATISTICSビューや、V$SYSTEM_EVENTビューなどから、どうも
ログテーブルのインデックスが特に大きな”待ち”を起こしていることがわ
かりました。また、これらは、”ITL waits”を伴っていることから、少な
くともインサート時の”待ち”が発生していることも推測できました。
これらは、RACをシングルインスタンス状態で使用しているときには、現
れてはいません。RACの複数インスタンスが並行稼動しているときに現れ
るようです。
つまり、インスタンス間をまたがった時の処理が問題であることが考えら
れます。
3.では、このインデックスをチューニング対象とする場合どのような方法が
考えられるでしょうか。
今回は、インデックスのキーの先頭項目にインスタンス番号を付与してみ
ました。これで、インサート時の競合は防げるはずです。なぜなら、B-Tree
インデックスでは昇順に値が並ぶため、先頭にインスタンス番号を付与す
ることで、各インスタンスごとでのリーフブロックの取り合いは発生して
も、インスタンス間でのリーフブロックの取り合いはほとんど起こらなく
なるためです。(もちろん、INSERT時のお話です。)
その他にも方法はあります。例えば、”リバースインデックス”です。
これは、日付など、末尾が適度にバラバラになるようなキー項目に対して
有効になります。
もちろんいずれの方法を選択するにしても、インデックスの本来の目的を
忘れてはいけません。検索用途に適した方法を選択することをお忘れなく。
4.そして、最後に検証です。
当初、スケーラビリティが”1″を下回っていた処理性能が、約”1.4″まで上
昇しました。まずは、一安心というところでした。
振り返ってみると、キーになるポイントは、それほど多くは無い様に見えま
す。しかしながら、それらの組み合わせが重要な判断材料になります。
組み合わせを誤ると、チューニング方向を間違えるかもしれません。
例えば、”buffer busy waits”。今回はたまたま（？）、インデックスが報
告されていました。もちろん環境によっては、テーブルが報告されることも
あります。このような環境ではどうしたらよいのでしょうか。
もちろん、インデックスは関係ないので、今回の手順とはまったく異なりま
す。
ローカル管理表領域のテーブルであれば、自動セグメント領域管理がつかえ
ます。一応Oracleの推奨です。（一応・・・）
ディクショナリ管理表領域のテーブルの場合は、”free lists”や、”freelist
groups”を定義することで、データブロックの競合を回避することが出来る
でしょう。ただし、データのインサート時の競合です。
大量の全件検索が発生している場合にも、その対象テーブルが「”buffer busy
waits”の発生しているオブジェクト」として報告されることがあります。
この場合には、そもそもその全件検索が必要かどうかを見極める必要があり
ます。必要ないのであれば、RACとしてと言うよりは、むしろ、通常のアプ
リケーションとしての見直しが必要になります。
さて、この時点で、スケーラビリティ≒”1.4″までたどり着きました。
実は、この環境ではさらにチューニングを続けて、最終的には、1.9程度まで
持っていくことができました。ただし、すでにお分かりとおもいますが、ア
プリケーションのチューニングなしでは、難しいのが現状ではないでしょう
か。
いま、RACで稼動している環境をお持ちの皆さんは、いまどのくらいのスケー
ラビリティでそのシステムが稼動しているかご存知ですか？
おそらく、問題なく業務をこなしておられるでしょうから、ことさら騒ぐこ
とではないでしょう。スケーラビリティよりなにより、通常の業務を問題な
くこなすことのほうが重要ですから。（そういう意味ではダウンタイムがほ
とんど無い”高可用性”の方がメリットとして大きいでしょう。）
でも、もしかしたら、スケーラビリティーが”1″を下回っているかもしれませ
ん。インスタンス障害が発生した時のほうが処理性能が上がるなんてあまり
笑えない状況になっていないでしょうか？
実稼動が始まると、スケーラビリティーなど、あまり意味の無いことかもし
れません。しかしながら、せっかくのリソースを有効活用したいのは世の常
です。同じ処理をこなすなら、速いに越したことはありませんから。
また、CPUの使用率が下がれば、電気消費量も抑えられることでしょう。
今年の夏は、特に電気メータの回転率も監視項目に入れたほうがよいかもし
れません。
RACのチューニングに関しては、これから、もっともっと突き詰めて行きた
いとおもっています。また、今回は取り上げなかった高可用性を実現するた
めのノウハウなどもいずれご紹介できればとおもっています。
ひょっとするとこちらの方に興味があるかたがたも多いかもしれませんね。
今回のシリーズは今週で終わりますが、来週は読者よりいくつかいただいた
「RAC環境でのインデックスチューニングの検証」を行います。是非お楽し
みにしてください。
それでは、また来週。
妻よ、娘よパパは元気にしているぞー へっくしゅん! 茅ヶ崎にて