パラレル処理の有効性と落とし穴を検証する：Oracleパーティショニング実践講座（4）（4/4 ページ）

» 2007年03月05日 00時00分公開

パラレルロードの検証

　パラレルロードの検証では、SQL*Loaderのパラレルダイレクトロードを利用し、バッファ・キャッシュを経由せずに直接データファイルに書き込むダイレクトロードの並列度を2、4、6、8、10、12、14、16と変化させて応答時間を計測しました。図13のように、並列度4以降は大きな変化はありませんが、最大2.0倍程度の効果を確認できました。

図13　「MP」ごとのSQL*Loaderにおけるパラレルロードのレスポンス効果の傾向（表サイズ：100Gbytes）
p：パラレル・ダイレクト・パス・ロードの並列度

　図14〜16から、CPUリソースはI/O待ちになることなく利用されていることが確認できます。SQL*Loaderのパラレルダイレクトロードによる書き込み処理だけであるため、読み込み処理との競合が発生していないためだと思われます。

図14　SQL*Loader_非パラレル・CPU使用率の推移

図15　SQL*Loader_並列度2・CPU使用率の推移

図16　SQL*Loader_並列度14・CPU使用率の推移

　ただ、図17の待機イベントが示すように、Oracleの「buffer busy waits」や「row cache lock」などOracle側のリソース競合による待機が増加しています。「buffer busy waits」はSQL*Loaderによるパラレルロード処理によって、ブロックの競合が発生していることを意味しています。

　本検証では更新日列を月単位でレンジ・キーとしてレンジ・パーティション化した売上実績表を使用しているため、ローディングするCSVデータの順番を変更したり、ハッシュ・キーを加えたコンポジット・パーティションとすることで「buffer busy waits」の待機を回避できる可能性はあります。

図17　SQL*Loaderのパラレルロード実行時における待機イベントの傾向

まとめ

　パラレルクエリ、パラレルDDL、パラレルロードの各検証で確認したように、パラレル処理ではハードウェア・リソース（CPU、メモリ、ディスクI/O）だけではなく、Oracleの内部的なリソースも含めた各リソースがバランスよく利用できる条件が整わないと、最大の効果は発揮できないことが分かりました。

　どのような処理を高速化させたいのかによって、パーティショニングする手法、パーティション・キーとする列なども異なりますし、ストレージの設定の仕方、各ストレージへのデータの配置の仕方も変化します。パーティショニングとパラレル処理の特性、Oracleのリソース競合の特性もふまえて設計を行うことが大切なのではないでしょうか。

　次回は、パーティショニングの最終回としてデータ圧縮の効果と、パーティショニングと組み合わせの活用方法を紹介します。（次回へ続く）

「次回」へ

「Oracleパーティショニング実践講座」バックナンバー