Oracle Real Application Clusters は複数のコンピュータのOracleデータベースをあたかも1つの大きなOracleデータベースとして利用できるようにする仕組み。このような仕組みを「クラスター」とか「クラスタリング」とか言う。「クラスター」とはブドウなどの「ふさ」という意味。クラスターの分類の中で RAC は以下の位置づけになる。
- 利用目的からのクラスターの分類（RAC は両方を兼ねる）
- スケーラビリティ（並列処理するので処理速度が速くなる）
- アベイラビリティ（複数のコンピュータがあるので、一部のコンピュータが逝っても止まらない）
要するに RAC は並列化の仕組み。並列的な仕組みでボトルネックになるのは分岐／合流点。全ての処理を並列化できるわけではなく、並列化できるところは並列化し、並列化できないところは合流して直列化し、また並列化できるところは分岐して並列化する。したがって、RAC という並列的な仕組みのボトルネックを最小限にする（パフォーマンス・チューニング）方法は主に以下の2種類に分類されると思う。
- 直列処理を減らして、できるだけ並列化する
- どうしても直列化する必要がある箇所は、直列処理をできるだけ高速化する
RAC じゃなくてもシングルインスタンスでも並列処理はたくさんある。直列化しないといけないところはいろいろな種類のロック機構が使われている（Oracle のロックの種類 - ablog）。複数ノードで並列処理を行う RAC の場合、シングルインスタンスほど細分化した並列処理ができないため、ボトルネックになりやすいポイントが多い。
RAC でのチューニングポイントをリストアップしてみる。
- 採番用テーブルを使った採番処理
- 同じテーブルの同じ行を更新するような処理になるので、同一ブロック競合過多になりやすい。
- 対策はSequenceを使って、キャッシュ単位を100以上程度にすると良いらしい。
- 監査AuditTrail
- 全ノードから同一表に書込まれ、セグメントヘッダーがノード間でやりとりされボトルネックになる。
- 対策は監査AuditTrailを使わなければよいw
- SQL*Loaderによる大量データローディング
- 未ソートデータを多ノードでロードしてもパフォーマンスが出ない。PK/UKの索引作成が並列処理されないため？
- 対策はソート済みデータをパーティショニングテーブルにロードする。
- 複数ノードで同じマスタデータを更新するバッチの実行
- 同一マスタのマスタ更新処理を複数ノードで同時に行う場合、同一ブロック競合過多になりやすい。
- 対策は同一マスタの更新は1ノードに集めるとか、同時に同一マスタを更新しないようJOB実行順を制御するとか。
- commit間隔が大きい
- commit間隔が長いと、CR（読取一貫性）ブロックがキャッシュ・フュージョンで大量に転送される。
- 対策はcommit間隔を短くする。
- ブロックサイズが大きい
- ブロックサイズが大きいとブロック競合過多になりやすい。
- 4k、8k程度が適切？
- 初期化パラメータ FAST_START_MTTR_TARGET
- 小さめの値にしてチェックポイント発生頻度を高めにしたほうがパストイメージが解放されバッファキャッシュ使用率が向上する。
- 初期化パラメータ DB_CACHE_SIZE
- シングルインスタンスよりもパストイメージ用に10%程度多めにする。
- 初期化パラメータ MAX_COMMIT_PROPAGATION_DELAY
- 10gR1まではデフォルト設定では問題あり？
- LMSプロセス数、優先順が適切でない
- 様々な理由によるブロック競合過多
- UDP転送バッファの設定が適切でない
（とりあえず書いてみた。随時更新予定。）
[参考]
wikipedia:並列コンピューティング
wikipedia:コンピュータ・クラスター
http://ext.dictionary.goo.ne.jp/leaf/ej/cluster/m0u/cluster/
http://www.oracle.co.jp/onoracle/members/doc/ISV_RAC_Design.pdf
シーケンスについての FAQ - オラクル・Oracleをマスターするための基本と仕組み
小飼弾の 「仕組み」進化論
http://www.oracle.com/technetwork/jp/ondemand/b-10-ractuning-1448392-ja.pdf
