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

本連載では、大規模データベースでのパフォーマンス・チューニングの手法として、Oracleパーティショニングを解説する。単なる機能説明にとどまらず、実機による検証結果を加えて、より実践的な内容をお届けする。（編集部）

[岸和田隆，アシスト]

パラレルDDLの検証

　パラレルDDLでは副問い合わせを含む表の作成、索引の作成などをパラレル化できます。今回は、更新日列を月単位でレンジ・キーとしてレンジ・パーティション化した売上実績に対してパラレル索引作成を実施し、並列度を4、8、12、24と変化させて応答時間を計測しました。

　図7のように、パラレル索引作成では並列度4以降はあまり変化がなく、最大2.8倍のレスポンス向上を確認できました。パラレル・クエリとは異なった傾向を示しています。

図7　「MP」ごとのパラレル索引作成におけるレスポンス効果の傾向（表サイズ：100Gbytes）

　パラレル・クエリではCPUリソースをより多く利用することが処理時間の短縮につながっていましたが、パラレルDDLでのCPUリソースの利用状況を確認すると、図8〜11のように、処理をパラレル化することでCPU使用率は上昇しますが、同時にディスクI/Oがネックとなり、CPUリソースを使い切れない状態となることが確認できました。

図8　索引作成：非パラレル・CPU使用率の推移

図9　索引作成：並列度4・CPU使用率の推移

図10　索引作成：並列度12・CPU使用率の推移

図11　索引作成：並列度24・CPU使用率の推移

　また、図12のようにOracleの待機イベントでも「direct path read temp」「direct path read」「direct path write temp」が増加しており、ディスクへのI/O待ちが原因で処理が滞っていることが分かります。

　索引作成では既存の表からのデータの読み込み、ソート処理での一時表への読み込み書き込み、索引データの書き込み処理が実施されます。今回は15本のディスクをRAID0として1つのRAIDグループにまとめているため、索引作成時の読み込み、書き込みのI/O分散が実施できていないことが大きな原因だと思われます。

図12　「MP」ごとのパラレル索引作成時の待機イベントの傾向