RAC環境のチューニングwww.doppo1.netRAC環境のチューニングRAC環境では非RAC環境と比較してアーキテクチャの違いによりRAC固有のチューニングポイントがいくつかあります。RACにしたことで逆に遅くなってしまう可能性が高くなります。基本的にはRACを構成する全ノード間で一貫性を保障するというアーキテクチャに起因するケースがほとんどです。代表的な具体例としては以下のようなものがあります。ブロック転送(キャッシュフュージョン)のオーバーヘッドが必要になる・全ノードで一つしか存在しないロックを獲得するには他ノードがロックをかけていないことをインターコネクト通信を利用した確認が必要になる。キャッシュチューニング・同じブロックに対して更新をかける可能性のあるセッションは全て一つのノードにまとめノード間で同一ブロックを触らないようにします。優先接続インスタンスとフェイルオーバー時の接続先インスタンスを設定したサービス(srvctlコマンドで作成するサービスです)にそれぞれ接続する方法が一般的です。(アプリケーション・パーティショニング)。ノード間の読み取り同士(read×read)はあまり問題ありません。(最初にキャッシュフュージョンは発生するものの、一般的にはDISK読み込みよりはキャッシュフュージョンのほうが一般的には早く一旦キャッシュに乗ってしまえば以降インターコネクト通信は発生しない)・RACではブロックマスターという概念がありブロック毎に管理インスタンスが自動的に決まっています。request等の待機イベントで現れる)。現時点までのバージョン(10gR1~12cR1)ではブロックマスターを動的に変更するDRMという機能がデフォルトで動作しています。エンキューチューニング・エンキューで最も問題になるケースが多いのがシーケンス用のエンキュー(SQエンキュー)です。RAC環境では可能な限りシーケンスのキャッシュは大きくとります。・細かい更新が同時並行して大量に発生するオンライン系の処理ではTMエンキュー獲得のオーバーヘッドが劣化要因になる場合があります。lock属性をdisableに変更することでDML文による通常の更新時にTMエンキューが獲得されなくなりパフォーマンスがアップする場合があります。(ただし、disableにしている間はDDL文の発行等が不可能になります)インターコネクト通信チューニング・インターコネクト通信にUDPプロトコルが利用される環境ではOSのカーネルパラメータのUDPバッファを拡大することでクラスタ系の処理時間が減少する場合があります。・cluster_interconnectsパラメータを利用してインターコネクト通信を多重化することでクラスタ系の処理時間が減少する場合があります。この多重化の仕組みはRAID0構成のようなものであるため可用性は低下します。本サイトはリンクフリーです。本サイトの情報により発生した問題等については一切責任を負えません。管理人への連絡はftpsaba0123@hotmail.comまでどうぞ。