パラレル処理の有効性と落とし穴を検証する：Oracleパーティショニング実践講座（4）（4/4 ページ）
本連載では、大規模データベースでのパフォーマンス・チューニングの手法として、Oracleパーティショニングを解説する。単なる機能説明にとどまらず、実機による検証結果を加えて、より実践的な内容をお届けする。（編集部）
パラレルロードの検証
パラレルロードの検証では、SQL*Loaderのパラレルダイレクトロードを利用し、バッファ・キャッシュを経由せずに直接データファイルに書き込むダイレクトロードの並列度を2、4、6、8、10、12、14、16と変化させて応答時間を計測しました。図13のように、並列度4以降は大きな変化はありませんが、最大2.0倍程度の効果を確認できました。
図14〜16から、CPUリソースはI/O待ちになることなく利用されていることが確認できます。SQL*Loaderのパラレルダイレクトロードによる書き込み処理だけであるため、読み込み処理との競合が発生していないためだと思われます。
ただ、図17の待機イベントが示すように、Oracleの「buffer busy waits」や「row cache lock」などOracle側のリソース競合による待機が増加しています。「buffer busy waits」はSQL*Loaderによるパラレルロード処理によって、ブロックの競合が発生していることを意味しています。
本検証では更新日列を月単位でレンジ・キーとしてレンジ・パーティション化した売上実績表を使用しているため、ローディングするCSVデータの順番を変更したり、ハッシュ・キーを加えたコンポジット・パーティションとすることで「buffer busy waits」の待機を回避できる可能性はあります。
まとめ
パラレルクエリ、パラレルDDL、パラレルロードの各検証で確認したように、パラレル処理ではハードウェア・リソース（CPU、メモリ、ディスクI/O）だけではなく、Oracleの内部的なリソースも含めた各リソースがバランスよく利用できる条件が整わないと、最大の効果は発揮できないことが分かりました。
どのような処理を高速化させたいのかによって、パーティショニングする手法、パーティション・キーとする列なども異なりますし、ストレージの設定の仕方、各ストレージへのデータの配置の仕方も変化します。パーティショニングとパラレル処理の特性、Oracleのリソース競合の特性もふまえて設計を行うことが大切なのではないでしょうか。
次回は、パーティショニングの最終回としてデータ圧縮の効果と、パーティショニングと組み合わせの活用方法を紹介します。（次回へ続く）
Copyright © ITmedia, Inc. All Rights Reserved.