RAC環境のチューニング

RAC環境では非RAC環境と比較してアーキテクチャの違いによりRAC固有のチューニングポイントがいくつかあります。
これらのチューニングポイントを考慮した設計になっていないとRACにすることのメリットの一つであるスケーラビリティはほぼ享受できず、 RACにしたことで逆に遅くなってしまう可能性が高くなります。

RAC固有のチューニングが必要な理由

基本的にはRACを構成する全ノード間で一貫性を保障するというアーキテクチャに起因するケースがほとんどです。 代表的な具体例としては以下のようなものがあります。

・ORACLEはブロック単位で読み書きを行うため、同じブロック内の別々の行に対して複数ノードから更新を行うとブロックに対する権限付与やブロックモードの変更、 ブロック転送(キャッシュフュージョン)のオーバーヘッドが必要になる
・全ノードで一つしか存在しないロックを獲得するには他ノードがロックをかけていないことをインターコネクト通信を利用した確認が必要になる。

キャッシュチューニング

・同じブロックに対して更新をかける可能性のあるセッションは全て一つのノードにまとめノード間で同一ブロックを触らないようにします。 ブロックの単位で更新ノードを振り分けるのはあまり現実的ではないため、更新する表やスキーマ別にサービス(接続に定義に指定するサービス)を分けておき、 優先接続インスタンスとフェイルオーバー時の接続先インスタンスを設定したサービス(srvctlコマンドで作成するサービスです)にそれぞれ接続する方法が一般的です。(アプリケーション・パーティショニング)。 なお、ノード間の読み取り同士(read×read)はあまり問題ありません。 (最初にキャッシュフュージョンは発生するものの、一般的にはDISK読み込みよりはキャッシュフュージョンのほうが一般的には早く一旦キャッシュに乗ってしまえば以降インターコネクト通信は発生しない)

・RACではブロックマスターという概念がありブロック毎に管理インスタンスが自動的に決まっています。 この仕組みによりブロックマスター以外のインスタンスがブロックをDISKから読み込む際にはDISK読み込みの権限を付与するためのクラスタ通信が発生します (gc cr grant 2-way、gc current grant 2-way、gc cr multi block request、gc current multi block request等の待機イベントで現れる)。 現時点までのバージョン(10gR1～12cR1)ではブロックマスターを動的に変更するDRMという機能がデフォルトで動作しています。

エンキューチューニング

・エンキューで最も問題になるケースが多いのがシーケンス用のエンキュー(SQエンキュー)です。SQエンキューを獲得する頻度はCACHEサイズを大きくすることで減少できるため RAC環境では可能な限りシーケンスのキャッシュは大きくとります。

・細かい更新が同時並行して大量に発生するオンライン系の処理ではTMエンキュー獲得のオーバーヘッドが劣化要因になる場合があります。 　TMエンキューは表の属性である table lock属性をdisableに変更することでDML文による通常の更新時にTMエンキューが獲得されなくなりパフォーマンスがアップする場合があります。 (ただし、disableにしている間はDDL文の発行等が不可能になります)

インターコネクト通信チューニング

・インターコネクト通信にUDPプロトコルが利用される環境ではOSのカーネルパラメータのUDPバッファを拡大することでクラスタ系の処理時間が減少する場合があります。

・cluster_interconnectsパラメータを利用してインターコネクト通信を多重化することでクラスタ系の処理時間が減少する場合があります。 　ただし、この多重化の仕組みはRAID0構成のようなものであるため可用性は低下します。(多重化した内のいずれか一つに障害が発生した場合インターコネクト障害になる)