今回は、シングルノードの時はあまり気にしなくても良いこともRACになると無視できなくなることがあるので、それについてRACとバッチ処理で説明しようと思います。
■１．RAC(Real Application Clusters)について
RACを知らない方はもういないと思いますが、念のために簡単に説明しておきます。 RACは、Oracleの高可用性とスケールアウトを実現する共有ディスク型クラスターデータベースシステムです。全ノード（インスタンス）が全データベースに直接アクセスできるため、どのノードからも意識せずにデータベースにアクセスすることが可能です。各ノードのキャッシュの一貫性はキャッシュ・フュージョン技術を使用して実施しています。
キャッシュ・フュージョン
クラスタ・ノード間のデータの一貫性を保持する機能です。読込み/読込み、読込み/書込み、書込み/書込みの競合するデータ・アクセスにおいて、高速なノード間通信を使用したデータベース・ブロック転送を行うことで、ディスクI/Oのコストを抑えます。
■２．RACのときのバッチ処理
RAC環境ではシングルノード環境で無視できたレベルでもパフォーマンス問題になる場合があります。特にバッチ処理は大量のデータ更新を行いますから、何も考えないで実行させるとキャッシュ・フュージョンが多発することになります。OLTPなどの処理ではキャッシュ・フュージョンのレベルは気にしなくても問題ないようになってきましたが、バッチ処理のように大量に更新を行う処理ではキャッシュフュージョンのオーバーヘッドは無視できません。かえって遅くなったりします。何も考えないで行うと1ノードに寄せて実行しなくてはいけなくなり（RACの方が1ノードで実行するより遅くなる）、性能要件に対応できないケースもありますので注意が必要です。非RAC環境と同じように、OracleのパラレルDMLを使用すれば内部的にデータを分割するので、キャッシュ・フュージョンは発生しませんので気にする必要はありません。
もしプログラムで分割して並列化する場合は、キャッシュ・フュージョンが発生してしまいますので、データ分割がより重要になりますので、パーティション機能の必要性が増します。ここからは、3つの事例を使用して説明しようと思います。それぞれ異なる改善方法を採用した事例になります。
事例１．アクセスログ管理システムのデータ削除処理
複数の端末からログ情報を順次受信してリアルタイムにアクセスログ・テーブルに追加して、履歴データとして管理しているシステムです。一定期間（12ヶ月間）が経過したログ情報を定期的（月単位）にテーブルから削除する必要があります。このときにDELETE文で対象データの削除を並列実行しているが、2ノードRAC環境なので2ノードから削除を実行したらキャッシュ・フュージョンが多発して性能が低下してしまったケース。仕方なく1ノードに寄せて実行することにした例です。
改善方法としては、月単位（2010年01月～2010年12月）のレンジ・パーティションにして、削除対象のパーティション（2010年01月）をDROP PARTITIONする（新たな挿入先として2011年01月もADD PARTITIONする）ことで、瞬時に削除することができます。このようにデータを大量に削除するような場合はDELETE文ではなくDROP PARTITION の利用を検討して下さい。
事例２．名寄せ処理
50音順に格納されている複数の名簿テーブル（名簿X、名簿Y、名簿Z）を名寄せして、結果テーブルに差分更新（存在しないものは挿入）する処理です。このときに分割キー（名前の範囲）を元に並列実行しているが、2ノードRAC環境なので2ノードから並列実行したらキャッシュ・フュージョンが多発して性能が低下してしまったケース。仕方なく1ノードに寄せて実行することにした例です。
改善方法としては、並列実行する単位（名前の範囲）でレンジ・パーティションにして、2ノードから並列実行してもキャッシュ・フュージョンが発生しないようにします（それぞれのプロセスで更新するデータが同一ブロックにならないようにする）。パラレルDMLを使用することも改善方法になる場合もありますが、この例の名寄せ処理が複雑であったので使用しないことにしました。
事例３．外部ファイルの取り込み処理
外部ファイルのデータをマスタ・テーブル（マスタX、マスタY、マスタZ）と整合性のチェックをしてから格納先テーブルに差分更新（存在しないものは挿入）する処理です。このときに並列処理を行うために外部ファイルを属性に応じて複数ファイルに分割して並列実行しているが、2ノードRAC環境なので2ノードから並列実行したら格納先テーブルでキャッシュ・フュージョンが多発して性能が低下してしまったケース。仕方なく1ノードに寄せて実行することにした例です。
改善方法としては、外部ファイルを外部表（外部ファイルをテーブルとしてSQL文で扱うことができる機能）にしてパラレルDML（MERGE文）で整合性をチェックしながら行う（パラレルDMLを2ノード上で実行する）ことで、キャッシュ・フュージョンが発生しないようにします（整合性チェック等の処理が複雑で1つのSQL文にするのが難しいような場合は、一時テーブルを作成して複数のSQL文で実行すると処理しやすくなると思います）。格納先テーブルへの処理が挿入だけであれば自動セグメント領域管理を使用することでフリーリスト／フリーリストグループ管理をしてくれるのでキャッシュ・フュージョンが発生しないことも知っておいて下さい。この例には含まれませんでしたが、格納先テーブルの対象データを絞り込む場合は、パーティション化してアクセスするデータを削減することも忘れないようにして下さい。
このようにRAC環境だとシングル環境以上に競合（キャッシュ・フュージョン）が発生してしまいますので、何も考えずに処理をすると性能が低下してしまって、事例のように1ノードだけで処理することになってしまいます。実際に、そのような運用方法をされているケースを眼にすることがあります。スケールアウトのためにノードを追加した訳ですから、バッチ処理だけ1ノードで実行するというのはリソース的に勿体ない話です。そのような事が無いように、この事例を参考にしていただければと思います。
■３．おわりに
前回と今回で、大規模データのバッチ処理という観点でみると、シングルでもRACでも パラレル処理やパーティショニングといった機能を有効に活用することで、パフォーマンスを向上、維持することができることを説明しました。
それでは、次回まで、ごきげんよう。