Clusterについて、実際の環境で発生したケースを題材に、その時のチューニング作業をトレースしてきました。振り返ってみましょう。1.まず、開発環境(シングルインスタンス)で動作確認を行ったアプリケーションを、本番環境(もちろんRAC)に導入し、取り敢えずテストを行うと、あらまーびっくり、シングルインスタンス状態の方が、RAC構成の時より処理が高速に行われています。スケーラビリティーで言うところの、”0.67′′でした。2.さて、ボトルネックの洗い出しです。V$SEGMENT_STATISTICSビューや、V$SYSTEM_EVENTビューなどから、どうもログテーブルのインデックスが特に大きな”待ち”を起こしていることがわかりました。waits”を伴っていることから、少なくともインサート時の”待ち”が発生していることも推測できました。これらは、RACをシングルインスタンス状態で使用しているときには、現れてはいません。RACの複数インスタンスが並行稼動しているときに現れるようです。インスタンス間をまたがった時の処理が問題であることが考えられます。3.では、このインデックスをチューニング対象とする場合どのような方法が考えられるでしょうか。今回は、インデックスのキーの先頭項目にインスタンス番号を付与してみました。これで、インサート時の競合は防げるはずです。B-Treeインデックスでは昇順に値が並ぶため、先頭にインスタンス番号を付与することで、各インスタンスごとでのリーフブロックの取り合いは発生しても、インスタンス間でのリーフブロックの取り合いはほとんど起こらなくなるためです。(もちろん、INSERT時のお話です。)その他にも方法はあります。”リバースインデックス”です。これは、日付など、末尾が適度にバラバラになるようなキー項目に対して有効になります。いずれの方法を選択するにしても、インデックスの本来の目的を忘れてはいけません。検索用途に適した方法を選択することをお忘れなく。4.そして、最後に検証です。一安心というところでした。振り返ってみると、キーになるポイントは、それほど多くは無い様に見えます。それらの組み合わせが重要な判断材料になります。組み合わせを誤ると、チューニング方向を間違えるかもしれません。