oracle sql のパラレル実行...oracle sql のパラレル実行概要...

Oracle SQL のパラレル実行

Oracle ホワイト・ペーパー 2008 年 6 月


概要 ...................................................................................................................... 4 はじめに .............................................................................................................. 4 パラレル実行の利点 .......................................................................................... 6

最終的な目標：スケーラビリティ ............................................................. 6 シェアード・エブリシング - オラクルの利点........................................ 7

Oracle Database のパラレル実行に関する基本的な概念................................ 9 SQL 文のパラレル処理 ................................................................................ 9

問合せコーディネータ（QC）とパラレル・サーバー .................... 11 プロデューサ/コンシューマ・モデル ................................................ 12 グラニュル ............................................................................................. 14 データの再分散 ..................................................................................... 15

Oracle でのパラレル実行の有効化 ........................................................... 19 Oracle での SQL パラレル実行の制御...................................................... 22

ターゲット・ワークロードの理解 ..................................................... 22 並列度の制御 ......................................................................................... 23 並列処理の使用の制御 ......................................................................... 24

Oracle SQL のパラレル実行のベスト・プラクティス................................. 26 バランスのとれたシステムでの起動 ....................................................... 26

構成のキャリブレーション ................................................................. 27 Stripe And Mirror Everything（S.A.M.E.） - ASM の使用 ................. 27

優れたパフォーマンスを得るためのデータベース初期化パラメータの

設定............................................................................................................... 28 メモリの割当て ..................................................................................... 28 パラレル・サーバーの制御 ................................................................. 29 効率的な I/O スループットの有効化 .................................................. 31

一般的なパラレル実行の使用 ................................................................... 31 小さなオブジェクトに対して並列処理を有効にしない.................. 31 目標を大きく超えない並列処理を使用した目標の実現.................. 31 回避するヒントの使用 ......................................................................... 32

Oracle Partitioning とパラレル実行の組合せ............................................ 32 十分な統計情報........................................................................................... 32 パラレル実行アクティビティの監視 ....................................................... 33 Oracle RAC でパラレル実行を使用するかどうかの判断 ...................... 33 Database Resource Manager の使用 ............................................................ 34 ほかの機能を使用して、ハードウェア不足の解決を試みない ........... 34 ほかの機能を無視しない ........................................................................... 34

SQL のパラレル実行の監視 ............................................................................ 34 （G）V$パラレル実行ビュー ................................................................... 34 パラレル SQL 実行計画の実装 ................................................................. 35

パーティション化を伴わないパラレル計画 ..................................... 35 パーティション化とパーティションワイズ結合を伴うパラレル計

画 ............................................................................................................. 36 Oracle Enterprise Manager............................................................................ 39

待機イベント ......................................................................................... 39


2

Oracle Corporation 発行「Oracle SQL Parallel Execution」の翻訳版です。

入出力（I/O）の監視............................................................................ 40 パラレル実行の監視 ............................................................................. 41 SQL の監視 ............................................................................................ 42

Oracle9i Database からのアップグレードに関する考慮事項....................... 44 追加の並列処理........................................................................................... 44

Oracle9i Database で、SQL のパラレル実行を有効にするためにヒン

トを使用している場合 ......................................................................... 44 Oracle9i Database で、SQL のパラレル実行を有効にするためにセッ

ションの設定を使用している場合 ..................................................... 44 Oracle9i Database で、SQL のパラレル実行を有効にするためにオブ

ジェクト・レベルの設定を使用している場合.................................. 45 実行計画の変更点....................................................................................... 45 データベースのデフォルトの変更点 ....................................................... 45 Resource Manager の使用............................................................................ 46

結論 .................................................................................................................... 46


3



概要

パラレル実行は基本的なデータベース・テクノロジーの 1 つであり、数十（また

は数百）テラバイトのデータの管理とアクセスが可能になります。並列処理機能

がなければ、データウェアハウスで一般的に使用されているような運用システム

で広まりつつある大規模なデータベースは実現できません。

パラレル実行は、単一のデータベース操作の実行に複数の CPU および I/O リソー

スを利用するための機能です。今日の主要なデータベース・ベンダーは並列処理

機能を提供していますが、それらのベンダーが提供するアーキテクチャには決定

的な相違点があります。

SQLのパラレル実行がOracle Databaseに最初に導入されたのは、10 年1以上も前の

ことです。それ以来、パラレル実行には機能の拡張と改良が実施されてきました。

このホワイト・ペーパーでは、Oracle Database 11gのパラレル実行アーキテクチャ

について説明し、実世界のアプリケーションで使用するにあたり、このアーキテ

クチャがほかのアーキテクチャよりも優れている点を示します。また、パラレル

実行の制御および監視方法や、Oracle Database 11g以前のバージョンから移行する

際のアップグレードの考慮事項について説明します。

このホワイト・ペーパーでは、Oracle Database 11g に焦点を当てていますが、基本

的な概念は以前のバージョンにも適用できます。

はじめに

今日のデータベースには、それがデータウェアハウスや運用データ・ストア、ま

たは OLTP システムに限らず、大量の情報が格納されています。しかし、処理す

るデータが大量であるため、正しい情報をタイムリーに検索し、提示することは

容易ではありません。

パラレル実行は、この課題に対処するための機能です。並列処理を使用すること

で、テラバイトのデータを数時間や数日ではなく、数分または 1 分未満で処理で

きます。パラレル実行では、複数のプロセスを使用して、単一のタスク（SQL の

パラレル実行の場合は SQL 文）が実行されます。データベース・ソフトウェアに

よって、すべてのハードウェア・リソース（複数のコア、複数の I/O チャネル、

または 1 クラスタ内の複数のノード）を活用できることで、問合せやそのほかの

データベース処理がより効率的におこなわれます。

1 パラレル実行は、1996 年にOracle Version 7.3 で初めて導入されました。


4


リソース集約的なデータベース操作の例には以下のものがあります。

− 大量の（実行時間の長い）問合せ：データウェアハウスにおける、ある年の

結果と前年の結果を比較するための分析など

− 大きな表の索引の作成

− 大規模なデータベースの統計情報の収集

− データベースへの大量のデータのロード

− データベースのバックアップの実行

大規模なデータウェアハウスでは、優れたパフォーマンスを得るために、常にパ

ラレル実行を使用する必要があります。OLTP アプリケーションの特定の処理

（バッチ処理など）も、パラレル実行をおこなうことでパフォーマンスが大幅に向

上します。Oracle SQL のパラレル実行をおこなうには、Oracle Database 11g

Enterprise Edition が必要です。

このホワイト・ペーパーでは、以下の 4 つのメイン・トピックを取り上げます。

− 最初の項では、Oracleデータベースにおけるパラレル実行の基本的な概念につ

いて説明します。読者は、オラクルのパラレル・アーキテクチャ、パラレル

実行に関するOracle特有の用語、SQLのパラレル処理の制御および確認方法の

基礎が理解できるようになります。

− 2 番目の項では、ハードウェア・リソースをもっとも効率的に利用するための

パラレル実行に関するベスト・プラクティスについて説明します。

− 3 番目の項では、SQLまたはOracle Enterprise Manager Database/Grid Controlを活

用して、パラレル実行を使用している環境を監視する方法について説明しま

す。

− 4 番目の項では、Oracle to Oracle Database 11g以前のリリースから環境を移行

する際のアップグレードの考慮事項について説明します。


5


パラレル実行の利点

最終的な目標：スケーラビリティ

道路にある車の台数を数えるというタスクがあるとします。

− シナリオ 1：自分で道路まで行き、車の台数を数えます。

− シナリオ 2：友人がいる場合、2 人でそれぞれ道路の反対側から車の台数を数

え始め、2 人が落ち合った場所でそれぞれの台数を足します。

友人が車を数える速さがあなたと同じだとした場合、道路にあるすべての車の台

数を数えるタスクは、自分一人でおこなう場合と比べて半分の時間で終えること

ができます。このような場合、処理は直線的に測定できます。リソースの数を 2

倍にすると、全体の処理時間は半分になるのです。

データベースの場合も、上述の例とさほど変わりません。リソースの数を 2 倍に

することで、処理時間が最初の半分になれば、その処理は直線的に測定できます。

下の図 1は、直線的にスケーラブルな処理を実現する処理時間の減少についてグ

ラフで示したものです。

図 1：直線的なスケーラビリティを実現するリソース関数の処理時間

しかし、このグラフは直線的ではありません。もう一度見てください。このグラ

フは、スピードアップの相対的な要因ではなく、絶対的な処理時間を示していま

す。たとえば、リソースを 2 倍にすると処理時間は 360 から 180 に減ります。リ

ソースを 2 倍から 4 倍にすると、処理時間は 90 になります。いずれの場合も直線

的なスケーラビリティです。つまり、リソースの数が多くなるにつれ、パフォー

マンスの絶対的な伸び率は少なくなります。この点については、ベスト・プラク

ティスの項で説明します。


6


それでは、友人が疲れやすい人で、仕事の間中、定期的に休まなければならない

とします。この場合も、車を数えるのにかかる全体的な時間は減りますが、リソー

スを 2 倍にしても処理時間は半分にはなりません。タスクを完了するのに、1 人

でやる場合の 2/3 の時間がかかるかもしれません。この場合は、処理を同様には

測定できません。リソースを倍にしても、処理時間は期待どおり直線的には減少

しません。

データベースでは、問合せを処理するのに複数のコンポーネントが関与します。

各コンポーネントにはそれぞれ最大の処理能力があります。もっとも顕著な例は、

CPU、メモリ、入出力（I/O）です。すべて連携して能力を発揮します。データベー

ス処理の場合、さまざまなコンポーネント間に正しい量のリソースを割り当てな

いと、スケーラビリティを得られない場合があります。たとえば、CPU リソース

を追加して I/O リソースを追加しないと、CPU が快適に処理できる速度を保ちな

がらデータを取得することができない場合があります。

シェアード・エブリシング - オラクルの利点

これまでは、データベース・システムでのパラレル実行の実装には、2 つのアプ

ローチが使用されてきました。おもな違いは、作業を分割（並列処理）するため

に、ベースおよび静的な前提条件として、物理データのレイアウトを使用してい

るか、使用していないかという点です。

これらの基本的なアプローチは、シェアード・エブリシング型アーキテクチャお

よびシェアード・ナッシング型アーキテクチャとして知られています。

図 2：シェアード・エブリシングとシェアード・ナッシング

シェアード・ナッシング型のシステムでは、CPUのコアだけが個々のデータ・セッ

トに関与しており、特定のデータにアクセスするためには、そのデータのサブセッ

ト2を所有するCPUのコアを使用するしかありません。そのようなシステムは、

MPP（Massively Parallel Processing）システムとしても一般に知られています。最

良のワークロードの分散を実現するために、MPPシステムではハッシュ・アルゴ

リズムを使用して、使用可能なCPUのコアの間で（パーティション）データを均

一に配分します。結果として、MPPシステムでは、表のスキャンを伴う処理を実

行するために、そのシステムに必須の固定並列処理を導入することになります。 2一部の実装では、静的な少数のコアを最小の単位として設定できます。簡素化するために、それらを 1つのコアとして説明し、アーキテクチャ上のトレードオフは同一であるとします。


7


固定並列処理は、データベースまたはオブジェクトの作成時におこなわれる静的

データの固定パーティション化に全面的に依存しています。オラクル以外のベン

ダーが提供しているデータウェアハウス・システムの多くは、MPPシステムです。

Oracle Databaseでは、シェアード・エブリシング型アーキテクチャにより、並列処

理を有効にするために事前に定義されたデータのパーティション化をおこなう必

要がありません。Oracle Databaseでは、基礎となるデータ分散とは関係なく、ほぼ

すべての処理を並列処理できます。ただし、Oracle Partitioningを使用して、データ

が事前にパーティション化されている場合、Oracle Databaseでもシェアード・ナッ

シング型のベンダーが主張するのと同じ最適化機能とアルゴリズムを使用できま

す。

Oracle Databaseのシェアード・エブリシング型アーキテクチャでは、シェアード・

ナッシング型ベンダーのものより優れたパラレル実行機能を使用して、システム

に過負荷をかけることなく、柔軟なパラレル実行と高い同時実行性を実現でき

ます。


8


Oracle Database のパラレル実行に関する基本的な概念

Oracle Database には、人手を介さずに、複雑なタスクを並列で実行するための機

能があります。並列で実行できる処理には、以下のものがあります。

− SQL Loader と SQL ベースのデータ・ロード

− 問合せ

− RMAN バックアップ

− 索引の作成

− 統計情報の収集

− その他

このホワイト・ペーパーでは、SQL のパラレル実行のみを取り上げます。パラレ

ル実行には、パラレル問合せ、パラレル DML（データ操作言語）、およびパラレ

ル DDL（データ・ディクショナリ言語）が含まれます。Oracle Database 11g に焦

点を当てていますが、明示している場合を除き、このホワイト・ペーパーの情報

は Oracle Database 10g 以降のリリースにも当てはまります。

SQL 文のパラレル処理

Oracle DatabaseでSQL文を実行する場合、SQL文は、実行計画内で独立した行とし

て識別される個々のステップ（別名rowsources）に分解されます。以下は、単純な

シリアルSQL文とその実行計画の例です。この文は、CUSTOMERS表内の顧客の総

数を返します。

図 3：顧客のカウント、シリアル計画


9


すべての顧客の購買情報を表示するシリアル計画の例を次に示します。

図 4：顧客の購買情報、シリアル計画

後述のメカニズムを使用して、SQL 文を並列で実行すると、Oracle Database は実

行計画内の個々のステップを可能な限り多く並列化し、実行計画に反映させます。

上述の 2 つの計画は、次のように変わります。

図 5：顧客のカウント、パラレル計画

図 6：顧客の購買情報、パラレル計画


10


これらの計画は、以前のものとはかなり異なっています。そのおもな理由は、パ

ラレル処理のために、以前3は存在していなかった"ロジスティカル"な処理ステッ

プが追加されている点にあります。

Oracle データベースにおける SQL のパラレル実行は、いくつかの基本的な概念に

基づいています。次の項では、データベースでのパラレル実行の設定、および SQL

のパラレル実行計画の基本の理解に役立つ概念について説明します。

問合せコーディネータ（QC）とパラレル・サーバー

Oracle Database における SQL のパラレル実行は、コーディネータ（多くの場合、

問合せコーディネータ（QC）と呼ばれる）とパラレル・サーバーの原理に基づい

ています。QC はパラレル SQL 文を開始するセッションであり、パラレル・サー

バーは作業を並列で実行する個々のセッションです。QC は作業をパラレル・サー

バーに分散し、並列では実行できない作業のごくわずかな部分（ほとんどはロジ

スティカルな部分）を実行しなければならない場合があります。たとえば、SUM()

を使用するパラレル問合せ処理では、各パラレル・サーバーで計算されたそれぞ

れの小計を加算する必要があります。

QCは、パラレル実行計画内で簡単に識別できます。前述の図 6では、ID 1 の'PX

COORDINATOR'です。パラレルSQL処理のQCとして動作するプロセスは、それ自

体が実際のユーザー・セッション・プロセスです。

パラレル・サーバーは、全体で利用可能なパラレル・サーバー・プロセスのプー

ルから取得され、特定の処理に割り当てられます（設定については、後述します）。

サンプルのパラレル計画（図 5、図 6）のQC以下に表示されているすべての作業

は、パラレル・サーバーによって実行されています。

パラレル・サーバーのプロセスは、OS レベルで簡単に識別できます。たとえば、

Linux ではオラクル・プロセス ORA_P***となります。

図 7：'ps -ef'を使用した OS レベルで確認できるパラレル・サーバーのプロセス

3 Oracle Database 10g以前のバージョンでは、パラレル計画の見た目が異なります。


11


車の台数を数える例に戻ります。3 番目の人物（QC）が存在し、あなたと友人（2

つのパラレル・サーバー）に、道路に出て車の台数を数えるように指示するとし

ます。これは、図 5のID 2 の処理と同じです。図 8を参照してください。

− 図 8にあるように、SQLおよび実行計画を使用してデータベースの内部で実行

される処理とまったく同じことを道路上でおこなうことができます。あなた

と友人は、道路に出て自分の側にある車の台数だけを数えます。これは、ID 4、

ID 5、ID 6の処理と同じです。ここでID 5 は、あなたと友人に自分の側にある

車だけを数えるように告げるのと同じ働きをします（詳細は、グラニュルの

項を参照してください）。

− 最後に、あなたと友人は 3 番目の人物にそれぞれの小計（ID 3）を伝え、そ

の人物はそれらを加えて最終的な結果（ID 1）を算出します。この結果は、

結果の最終"アセンブリ"のために、パラレル・サーバー（実際の作業をおこな

うプロセス）からQCに渡され、ユーザー・プロセスに返されます。

図 8：QC とパラレル・サーバー

プロデューサ/コンシューマ・モデル

車の台数を数える例をここでも使用します。今回は車を色ごとにわけて数えます。

道路の両側にある車について、あなたと友人が片側をそれぞれ数えた場合、同じ

色の車も数えてしまい、その色の小計をそれぞれが計算することになります。た

だし、その数字は合計しないとその道路の最終結果にはなりません。2 人がただ

車を色ごとに数えて 3 番目の人物（"責任者"）に伝えるだけだと、責任者はすべ

ての結果を改めて合計しなければなりません。道路の車の色がすべて異なってい

たとしたらどうなるでしょうか。責任者は、あなたと友人がおこなった作業とまっ

たく同じことを繰り返す必要があるのです。ここで、さらに 2 人の友人の助けを

得て、このカウント作業を並列化してみます4。新しく加わった 2 人が道路の中央

4追加する友人の数は、車の色の数と関連性はありませんが、車を数えている人の数とは完全に一致しま

す。新たに協力してくれる友人の労力をもっとも効果的に利用したいので、すべての"カー・スキャナ"には継続的に増員の結果が平等に分散されていると想定し、彼らを常に忙しい状態にするだけの"カー・

カラー・カウンタ"があるとします。車の色を数える友人の数を増やせば、3 人は平均してそれぞれの仕

事時間の 30%は仕事がないことになります。


12


に行き、1 人は明色の車を、もう 1 人は暗色の車を担当します。あなたと最初の

友人は、車を数えるたびに、その情報を新しく加わった 2 人に報告します（この"

車の色の分離"により、情報が半分に分割されるとします）。あなたと友人が新し

い車を数えるときは、常に車の色を色の集計係（新しく加わった 2 人）に伝えま

す。つまり、情報を作成し、色の情報に基づいて再配分し、色の集計係がその情

報を使用します。最後に、集計係の 2 人がそれぞれの結果を責任者に伝えれば終

了です。つまり、2 人の友人とともに 2 組のタスクを連携して処理しています。

データベースでは、次のように処理がおこなわれます。1 つの文を並列で効率的

に実行するために、いくつかのパラレル・サーバーがペアで動作します。1 つの

組（プロデューサ）が行を生成し、もう 1 つの組（コンシューマ）がその行を使

用します。

SALES表とCUSTOMERS表のパラレル結合の例では、結合キーに基づいて行を再配

分し、両方の表で一致している結合キーを、結合している同じパラレル・サーバー

のプロセスに送信する必要があります。この例では、1 組のパラレル・サーバー

（プロデューサ）がCUSTOMERS表からデータを読み取って送信し、もう 1 組（コ

ンシューマ）がデータを受信してSALES表と結合します。図 9を参照してくださ

い。

図 9：プロデューサとコンシューマ

同じ組のパラレル・サーバーで処理された処理（rowsources）は、実行計画の'TQ'

列を見れば識別できます。図 9に示されているように、最初のスレーブ・セット

（Q1、00）は、CUSTOMERS表を並列で読み取り、行を生成してスレーブ・セット

2（Q1、01）に送信します。スレーブ・セット 2 は、それらのレコードを使用し

て、SALES表と結合します。プロデューサからコンシューマにデータが分散され

る際は、常に'NAME'列にTQxxxxx（Table Queue x）の形式のエントリも表示され

ます。今は、そのほかの列の内容は無視してください。


13


このことは、特定のパラレル処理のために起動されているパラレル・サーバーの

数に重大な影響を与えます。プロデューサ/コンシューマ・モデルでは、パラレル

処理のために 2 組のパラレル・サーバー（別名スレーブ・セット）が想定される

ため、パラレル・サーバーのプロセス数は、要求された並列度（DOP、個々のタ

スクを処理するパラレル・サーバーの数）の 2 倍になります。たとえば、図 9の

パラレル結合をDOP 4 で実行する場合、8 つのパラレル・サーバーのプロセスが

この文の処理に使用されます。

パラレル・サーバーがペアで動作しない唯一のケースは、文が非常に基本的なも

ので、1 組のパラレル・サーバーでその文全体を並列的に完了できるケースです。

たとえば、select count(*) from customers文に必要なのは、1 組のパラ

レル・サーバーだけです（図 5を参照）。

グラニュル

グラニュルは、データにアクセスする際の作業の最小単位です。Oracle Database

は、シェアード・エブリシング型アーキテクチャを使用します。このアーキテク

チャでは、ストレージの観点から、構成内のあらゆる CPU コアが任意のデータに

アクセスできます。これは、Oracle Database と市場にあるほかのすべての主要な

データベース製品との間にある、もっとも基本的なアーキテクチャの相違点です。

そのほかのシステムとは異なり、Oracle Database では、問合せの要件に応じて、

この最小の作業単位だけを選択できます。

図 10：顧客のカウント例におけるブロックベースのグラニュル

Oracle Databaseでパラレル実行用に作業を分散するために使用されている基本的

なメカニズムは、ディスク上のブロック範囲、いわゆるブロックベースのグラニュ

ルです。この手法はOracle Databaseに固有のもので、基礎となるオブジェクトが

パーティション化されているか、されていないかには左右されません。基礎とな

るオブジェクトへのアクセスは、大量のグラニュルに分割され、それぞれがパラ

レル・サーバーに渡されて処理されます（パラレル・サーバーが 1 つのグラニュ

ルの処理を終えると、次のグラニュルが渡されます）。グラニュルの数は、パラ

レル・サーバー間でのワークロードの分散を最適にするため、要求されたDOPよ

りも常に多くなります。パラレル処理の最初のパラレル・ステップである、'PX

BLOCK ITERATOR'処理（図 11参照）は、文字どおり、生成されたすべてのブロッ

ク範囲のグラニュルで繰り返されます。


14


ブロックベースのグラニュルは、ほぼすべての処理でパラレル実行を可能にする

ための基本ですが、いくつかの処理は、基礎となるデータ構造の利点を活かして、

個々のパーティションを作業のグラニュルとして利用できます。パーティション

ベースのグラニュルでは、1 つのパラレル・サーバーだけが単一パーティション

内の全データを処理します。Oracle Optimizerでは、処理でアクセスされる（サブ）

パーティションの数が少なくともDOPと等しい場合（個々の（サブ）パーティショ

ンのサイズに偏りがある場合は、DOPより多い方が理想的です）、パーティショ

ンベースのグラニュルが検討されます。パーティションベースのグラニュルを使

用するもっとも一般的な処理は、パーティションワイズ結合です。これについて

は後述します。

Oracle Databaseは、SQL文と並列度に基づき、ブロックベースのグラニュルとパー

ティションベースのグラニュルのどちらがより実行に適しているかを決定します。

ユーザーの決定には左右されません。

車を数える例では、道路の一方、または長い道路の 1 ブロックだけでも、ブロッ

クベースのグラニュルに相当すると考えることができます。既存のデータ・ボ

リューム（道路）は、物理的な単位に分割され、パラレル・サーバー（あなたと

友人）によって別々に処理されます。

データの再分散

基本的な処理を除き、並列処理では、一般的にデータの再分散をおこなう必要が

あります。データの再分散は、並列ソート、集計、結合などの処理を実行するた

めに必要になります。ブロックグラニュル・レベルでは、個々のグラニュルの実

データのコンテンツは認識されません。後続の処理が実コンテンツに依存する場

合は、すぐにデータを再分散する必要があります。車を数えるタスクの最後の例

を思い出してください。車の色が問題になっていますが、あなたは何色の車がど

こに停まっているかは把握していません。また、それらを管理することは不可能

です。あなたは、担当する色ごとの車の台数を、新たな 2 人の友人に再配分しま

す。これで、その 2 人は自分が担当する色の合計をカウントできます。

データの再分散は、単一のマシンにある個々のパラレル・サーバー間でおこなわ

れるか、または複数のマシンにあるパラレル・サーバー間でおこなわれます（Oracle

Real Application Clusters（Oracle RAC）データベースのマシンにまたがったパラレ

ル実行の場合）。前者の場合は共有メモリが使用され、後者はインターコネクト

通信を使用してデータの再分散がおこなわれます。

データの再分散は、Oracle Database に固有のものではありません。実際、これは

並列処理の基本的な原理の 1 つであり、並列処理機能を提供するすべての製品で

使用されています。Oracle の機能の基本的な相違点と利点は、パラレル・データ・

アクセス（前述のグラニュルの項を参照）にあります。そのため、必要なデータ

の再分散が、特定のハードウェア・アーキテクチャまたはデータベースの設定に

よって制約を受けることはありません。


15


シェアード・ナッシング（MPP）データベース・システムでも、処理でパーティ

ションワイズ結合（詳細はこの項で説明します）を利用している場合を除き、デー

タの再分散をおこなう必要があります。シェアード・ナッシング・システムでは、

パーティションワイズ結合を利用できない並列処理（2 つの異なる結合キーでの

単純な 3 方向の表結合）は、インターコネクト通信が頻繁に使用されます。Oracle

Database では、ノードのコンテキスト内でもパラレル実行が可能なため、並列処

理ではかならずしもインターコネクト通信を使用する必要はありません。そのた

め、インターコネクト・チャネルにおける潜在的なボトルネックを回避できます。

次の項では、索引やマテリアライズド・ビューなどの 2 次データ構造をもたない

単純な表結合の例を使用して、Oracle のデータの再分散機能について説明します。

シリアル結合

シリアル結合では、単一のセッションで両方の表が読み取られ、結合が実行され

ます。この例では、2 つの大規模な表、CUSTOMERS と SALES の結合をおこない

ます。

データベースは、全表スキャンを使用して両方の表にアクセスします。シリアル

結合では、単一のシリアル・セッション（赤い矢印）でフル結合を実行できます。

これは、CUSTOMERS表の一致するすべての値を 1 つのプロセスで読み取れるた

めです。図 11は、シリアル結合5を表しています。

図 11：2 つの全表スキャンに基づくシリアル結合

5 この項の図は、データの再分散を説明するための論理ダイアグラムを表しています。実際のデータベー

ス環境で、一般的にデータは複数の物理ディスクに分散されており、すべてのパラレル・サーバーからア

クセスできます。この図では、このような複雑な要素を意図的に排除してあります。


16


パラレル結合

同様の単純な結合を並列で実行するには、行の再分散をおこなう必要があります。

パラレル・サーバーは、ブロックの範囲に基づきどちらかの表の一部をスキャン

します。結合を完了するには、行をパラレル・サーバー間で再分散する必要があ

ります。図 12は、DOP 2（それぞれ緑と赤の矢印で示されています）におけるパ

ラレル結合のためのデータの再分散を表しています。両方の表は、赤と緑のプロ

セスによって並列で読み取られ（ブロック範囲のグラニュルを使用）、各パラレ

ル・サーバーは、結合キーに基づいてその結果セットを後続のパラレル結合演算

子に再分散する必要があります。

図 12：単純なパラレル結合用のデータの再分散

データの再分散の方式は多数存在します。次の 5 つがもっとも一般的な方式です。

− ハッシュ：ハッシュ再分散は、パラレル実行ではとくに一般的な方式です。

この方式ではハッシュ分散に基づいて、個々のパラレル・サーバーへ均等に

作業を分散します。ハッシュ（再）分散は、大部分のデータウェアハウスの

データベース・システム、とくにMPPシステムのためのパラレル実行を可能

にする基本的なメカニズムです。

− ブロードキャスト：ブロードキャスト再分散は、結合処理における 2 つの結

果セットのいずれかが他方の結果セットよりも極端に小さい場合におこなわ

れます。両方の結果セットの行を再分散する代わりに、データベースは小さ

い方の結果セットをすべてのパラレル・サーバーに送信して、個々のサーバー

がそれぞれの結合処理を完了できるようにします。小さい結果セットは、シ

リアルまたはパラレルで作成される場合があります。

− レンジ：レンジ再分散は、一般的に並列ソート処理で使用されます。個々の

パラレル・サーバーはデータの範囲に応じて処理をおこなうので、QCはソー

トを実行する必要がなく、個々のパラレル・サーバーの結果を正しい順序で

表示するだけで済みます。


17


− キー：キー再分散は、個々のキー値の結果セットを 1 つにまとめます。これ

は、おもにパーシャル・パーティションワイズ結合（後述の説明を参照）に

おいて使用される最適化方式で、結合する表の一方だけを再分散します。

− ラウンドロビン：ラウンドロビン・データ再分散は、データを要求元のプロ

セスに送信する前におこなわれる最後の再分散処理となります。また、再分

散に関する制約がまったくない場合は、問合せの早い段階でも使用できます。

データの再分散方式のバリエーションとして、Oracle Real Application Clustersデー

タベース上のパラレル実行計画に接尾辞LOCALが表示されることがあります。

LOCAL再分散は、Oracle RACでの最適化方式で、ノード内パラレル問合せのイン

ターコネクト・トラフィックを最小限に抑えます。たとえば、実行計画にHASH

LOCAL再分散が使用されることがあります。これは、行セットがローカル・ノー

ドで作成され、そのノードのパラレル・サーバーにのみ送信されたことを示して

います。

図 13：HASH 再分散を使用した、単純なパラレル結合用のデータの再分散

データの再分散は、SQL実行計画の'PQ Distrib'列に表示されています。図 13

には、単純なパラレル結合の実行計画が示されています。

パラレル・パーティションワイズ結合

結合でアクセスされる表の少なくとも 1 つが結合キーでパーティション化されて

いる場合、パーティションワイズ結合が使用されます。両方の表が結合キーで同

一レベル・パーティション化されている場合は、フル・パーティションワイズ結

合が使用されます。また、表のいずれかがメモリ内で動的にパーティション化さ

れている場合は、パーシャル・パーティションワイズ結合が使用され、そのあと、

フル・パーティションワイズ結合がおこなわれます。

パーティションワイズ結合では、データの再分散をおこなう必要はありません。

個々のパラレル・サーバーは、結合される両方の表のパーティションで均等に処

理をおこないます。


18


図 14：フル・パーティションワイズ結合では、データの再分散は必要ありません。

図 14に示されているとおり、赤いパラレル・プロセスはCUSTOMERS表の 1 パー

ティションのデータおよびSALES表の 1 パーティションのデータを読み取り、結

合キーで両方の表に対し同一レベル・パーティション化を実行して、これらの 2

つのパーティション外には結合に対して一致する行がないことを保証します。赤

いパラレル・プロセスは、一致するパーティションだけを読み取ることで、常に

フル結合を完成できます。この点は、緑のパラレル・サーバー・プロセス、およ

びこれら 2 つの表のパーティションの任意の組合せでも同様です。パーティショ

ンワイズ結合では、ブロックベースのグラニュルではなく、パーティションベー

スのグラニュルが使用されます。

パーティションワイズ結合は、シェアード・ナッシング・システムの基本的なイ

ネーブラです。シェアード・ナッシング・システムは、パーティションワイズ結

合を利用できる場合において、一般的に拡張性が高いシステムです。結果的に、

シェアード・ナッシング・システムでのパーティション化（分散）の選択は、表

へのアクセス・パスと同様に重要です。MPP システムでパーティションワイズ処

理を使用しない操作は、多くの場合、拡張性が低くなります。

Oracle でのパラレル実行の有効化

次の例を検討します。データベースに過去の販売データと顧客データが格納され

ているとします。以下は、関連する表の定義です。

SQL> desc customers Name Null? Type ID NOT NULL NUMBER(38) NAME NOT NULL VARCHAR2(60) YEAR_OF_BIRTH NUMBER(38) EMAIL_ADDRESS VARCHAR2(50) STREET_NUMBER VARCHAR2(10) STREET_NAME VARCHAR2(60) CITY VARCHAR2(60) STATE_PROVINCE VARCHAR2(40) ZIP_CODE VARCHAR2(10) COUNTRY NOT NULL VARCHAR2(40)


19


SQL> desc sales Name Null? Type PURCHASE_DATE NOT NULL DATE ITEM_ID NOT NULL NUMBER(38) CUSTOMER_ID NOT NULL NUMBER(38) STORE_ID NUMBER(38) QUANTITY NUMBER(38) AMOUNT NOT NULL NUMBER(7,2) TAX NUMBER(7,2)

表は、当初パーティション化されておらず、索引もありません。

米国における 2007年度の最後の 2か月の総収入を州ごとに知りたいと仮定します。

この結果は、次の問合せで得られます。

select c.state_province , sum(s.amount) revenue from customers c , sales s where s.customer_id = c.id and s.purchase_date

between to_date('01-NOV-2007','DD-MON-YYYY') and to_date('31-DEC-2007','DD-MON-YYYY')

and c.country = 'United States of America' group by c.state_province /

パラレル実行を有効にしないで問合せを実行した場合、問合せの実行に 10 分かか

るとします。

問合せを実行するエンドユーザーは、より速い応答時間（3 分未満）を期待して

います。これを実現する方法の 1 つは、パラレル実行です（使用可能なリソース

が余っていると仮定した場合）。

デフォルトで、Oracle Databaseは、パラレル実行をサポートするように設定され

ています。もっとも関連性の高いデータベースの初期化パラメータは、次のとお

りです。

− parallel_max_servers：データベース・インスタンスで起動可能なパラレ

ル・サーバーの最大数です。処理を並列で実行するためには、パラレル・サー

バーを利用できる必要があります（つまり、ほかの並列処理で使用されてい

ない必要があります）。デフォルトでは、parallel_max_serversの値は、

ほかのデータベースの設定から取得されます。この点については、このホワ

イト・ペーパーの後半で説明します。車を数える例で友人の助けを借りる場

合、parallel_max_serversは、助けてもらえる友人の最大数になります。

− parallel_min_servers：データベース・インスタンスが稼動しているとき

に、常に起動されるパラレル・サーバーの最小数です。parallel_min_servers

を指定することで、パラレル・サーバーの起動のために、並列処理の実行が

遅延するのを回避できます。車を数える例の場合、parallel_min_servers

は、車を数える仕事を始めるときに、呼ばなくてもそばにいる友人の数です。


20


データベース・インスタンスに対してパラレル実行が有効になっていることを確

認します（DBA または SYSDBA としてデータベースに接続します）。

SQL> show parameter parallel_max_servers NAME TYPE VALUE ------- parallel_max_servers integer 80

問合せのパラレル実行を有効にする方法は、3 つあります。

1) 表のパラレル実行を有効にする。

alter table sales parallel ; alter table customers parallel ;

通常、これらの表にアクセスする処理を並列で実行する場合は、この方

式を使用します。

2) パラレルのヒントを使用する。

select /*+ parallel(c) parallel(s) */ c.state_province

, sum(s.amount) revenue from customers c , sales s where s.customer_id = c.id and s.purchase_date between to_date('01-JAN-2007','DD-MON-YYYY') and to_date('31-DEC-2007','DD-MON-YYYY') and c.country = 'United States' group by c.state_province /

この方式は、おもにテストのために役立ちます。特定の文またはいくつ

かの文をパラレルで実行し、大部分の文はシリアルで実行する場合にも

役立ちます。

3) alter session force parallel queryを使用する。この方式は、

パラレルで実行したい特定のセッションを除き、アプリケーションを常

にシリアルで実行する場合に役立ちます。OLTPアプリケーションのバッ

チ処理は、このカテゴリに分類されます。


21


これら 3 つの方式はすべて、OracleデータベースがDOPを選択する、いわゆる

DEFAULTパラレル機能を有効にします。デフォルトでは、大部分のシステムで、

コアごとに 2 つのパラレル・サーバー・プロセスが起動されます。したがって、2

つのCPUコアがある環境で問合せを実行する場合、DOPは 4 になります。元々終

了するのに 10 分かかっていた問合せは、DOPが 4 の場合（使用可能なリソースが

十分であれば）、3 分未満で終了します。

Oracle での SQL パラレル実行の制御

ここまでで、パラレル実行を有効にする方法、およびオラクルのパラレル実行モ

デルの背後にある概念を理解できたと思います。では、並列処理に制限はあるの

でしょうか。より多くのリソースを使用すれば、応答時間を速くすることができ

ます。しかし、非常に多くの処理でこのアプローチをとった場合、システムのリ

ソースはすぐになくなってしまいます。実際に存在するリソース以上のリソース

を使用することはできません。

Oracle Databaseには制限と設定が組み込まれており、システムが過負荷になるのを

防ぎ、アプリケーションでデータベースを利用できる状態を維持します。データ

ベースの初期化パラメータ、parallel_max_serversは、これらの制限のよい

例です。データベースでの処理はすべて、メモリをはじめとしたリソースを必要

とし、アクティブな間はCPUやI/Oリソースも必要とします。システムは、この初

期化パラメータの設定より多いパラレル・サーバーをユーザーに割り当てること

はありません。

ターゲット・ワークロードの理解

パラレル実行では、単一の処理でシステムの全リソースを利用できます。このこ

とは、一定のシナリオでは問題にはなりませんが、多くの場合、望ましいもので

はありません。自分の要件を満たしながら、システムを最適に利用するためにパ

ラレル実行を適用するワークロードについて検討してみましょう。

シングルユーザー・ワークロード

シングルユーザー・ワークロードは、データベースで単一の処理を実行している

ワークロードで、この処理の目的は可能な限り速く終了することにあります。こ

のタイプのワークロードの例には、データベースの表を移入する夜間バッチの大

量ロードや、統計情報の収集があります。ベンチマークにおいても、多くの場合、

シングルユーザー・ワークロードの最大パフォーマンスが測定されます。

シングルユーザー・ワークロードでは、単一処理のパフォーマンスを向上するた

めに、すべてリソースを割り当てることができます。

マルチユーザーの同時ワークロード

ほとんどの本番環境には、マルチユーザー・ワークロードがあります。複数のユー

ザーが問合せ（多くは非定型の問合せ）を同時に実行したり、データのロード処

理を同時に実行したりします。

マルチユーザー環境では、ワークロード・リソースを同時に実行される処理間で

分割する必要があります。エンドユーザーは、自分の処理に公平な量のリソース

が割り当てられ、予想される応答時間が得られることを期待しています。


22


並列度の制御

Oracle のパラレル実行フレームワークでは、特定の並列度（DOP）を明示的に選

択または強制したり、並列度の制御を Oracle データベースにまかせたりできます。

DEFAULT並列処理

前述のパラレル問合せの例では、いわゆるDEFAULT並列処理を使用しています。

DEFAULT並列処理では、システム構成6（通常、DOPは[CPUのコア数]×2、クラ

スタ構成では、[CPUのコア数]×[ノード数]×2）に基づく式を使用してDOPが決

定されます。そのため、各ノードに 8 つのCPUコアがある 4 ノード・クラスタで

は、デフォルトのDOPは 64（2×8×4）となります。

DEFAULTアルゴリズムは、より多くのリソースを使用すれば処理が速く終了する

という想定のもとに、最大のリソースを使用するように設計されています。

DEFAULT並列処理は、シングルユーザー・ワークロードをターゲットにしていま

す。マルチユーザー環境では、DEFAULT並列処理は急速にシステム・リソースを

消費するため、ほかのユーザーがパラレル実行をおこなうために利用できるリ

ソースは残りません。

固定並列度（DOP）

DEFAULT 並列処理とは異なり、特定の DOP を Oracle データベースから要求でき

ます。たとえば、表または索引レベルで固定の DOP を設定できます。

alter table customers parallel 8 ; alter table sales parallel 16 ;

このケースでは、customer表だけにアクセスする問合せは要求した 8 のDOPを使用

し、sales表にアクセスする問合せは 16 のDOPを要求しています。sales表とcustomer

表の両方にアクセスする問合せは、16 のDOPで処理され、32 のパラレル・サーバー

（プロデューサ/コンシューマ）が割り当てられる可能性があります。異なるDOP

が指定されている場合、Oracleデータベースは常に大きい方のDOP7を使用します。

適応並行処理

Oracle の適応並列処理機能を使用する場合、データベースは SQL 実行時にアルゴ

リズムを使用して、並列処理が要求した DOP を受け取るべきか、DOP を下げる

べきかを決定します。

高い DOP を使用して、パラレル実行を積極的に利用するシステムでは、適応アル

ゴリズムにより、並列で実行している処理のごく一部の DOP だけが下げられます。

アルゴリズムによって、リソースの使用が最適な状態で保たれている間も、ユー

ザーは応答時間が一定していないと感じることがあります。絶対的な応答時間が

要求される環境で、適応並列処理機能だけを使用することは推奨されません。

6 ここでは、説明のためにかなり簡素化しています。倍率の 2 は、OS固有のパラメータであるinit.oraパラ

メータのparallel_threads_per_cpuから得ているもので、ほとんどのプラットフォームで 2 に設定されてい

ます。 7 パラレルのCREATE TABLE AS SELECT文など、一部の文はこのルールに該当しません。これらの例外

については、このホワイト・ペーパーでは取り上げていません。


23


適応並列処理は、データベースの初期化パラメータ、parallel_adaptive_

multi_userで制御されます。

最小 DOPの保証

SQL 文の実行が特定の DOP で開始されると、その実行中 DOP は変わりません。

ただし、適応パラレル実行の結果として、または使用可能なパラレル・サーバー

が少ないために、低い DOP で開始した場合は、SQL 文の実行が完了するまでかな

り時間がかかることがあります。文の実行完了がタイム・クリティカルである場

合は、最小の DOP が保証される必要があります。保証されない場合は実行せずに、

データベース管理者に連絡するか、システムの負荷が少ないときにプログラムに

より再度試行することになります。

最小のDOPを保証するには、初期化パラメータparallel_min_percentを使用

します。このパラメータは、処理の開始時に使用可能なパラレル・サーバー・プ

ロセスの最小の割合を制御します。デフォルト値は 0 で、使用可能なパラレル・

サーバー・プロセスの数とは関係なく、常に文が実行されます。

たとえば、ある文に対して要求したパラレル・サーバー・プロセスの 50%を最低

限確保したい場合は、次のように指定します。

SQL> alter session set parallel_min_percent=50 ; SQL> select /*+ parallel(s,128) */ count(*) from sales s ; select /*+ parallel(s,128) */ count(*) from sales s * ERROR at line 1: ORA-12827: insufficient parallel query slaves available

使用可能なパラレル問合せサーバーが足りない場合、この例では、単純なSQL文

に対して 64 パラレル・サーバー未満（または、プロデューサとコンシューマが関

与する、より複雑な処理に対して 128 スレーブ未満）の場合、ORA-12827エラー

が表示され、文は実行されません。このエラーは、コード内で取得してあとで再

試行できます。

並列処理の使用の制御

予想されるワークロード・パターンに応じ、Oracle のパラレル実行機能が自分の

環境でもっとも適切に使用されるように設定できます。これには、（a）並列処理

の使用の制御と（b）混在ワークロード環境の場合に、さまざまなユーザー・クラ

スに潜在的に異なる優先順位を適応する間、システムが過負荷にならないように

するという 2 つの基本的なタスクが関係します。


24


SQL 処理を並列で実行していてもいなくても、選択される DOP は、次のルールに

基づき、次の優先順位で決定されます。

− 並列処理がヒントで要求されている場合

select /*+ parallel(s,16) */ count(*) from sales s ; この問合せに要求した DOPは 16です。

− alter session コマンドで DOP が要求されている場合。次に例を示します。

alter session force parallel query parallel; そのセッション内のすべての処理に対して要求した DOPは、DEFAULT並列処

理になります。

− select文でアクセスした表および索引には、オブジェクト・レベルで並列度が

設定されます。オブジェクトにDEFAULT設定がある場合、データベースによっ

てDEFAULTに属しているDOP値が決定されます。異なるDOP設定でオブジェ

クトを処理する問合せの場合、問合せでアクセスされた並列度の設定がもっ

とも高いオブジェクトによって、要求したDOPが決まります。

Oracle Database Resource Manager の使用

Oracle Database Resource Manager（DBRM）を使用すると、特徴に基づいてユーザー

をグループ化し、一部ユーザーのパラレル実行を制限できます。DBRM は最大並

列度を決定するための最終的なインスタンスであり、（特定のリソース計画を使

用する）リソース・グループ内のユーザーは、リソース・グループの最大値より

高い DOP で実行することはできません。たとえば、リソース計画に最大 4 の DOP

を使用するポリシーがあり、ヒントを使用して 16 の DOP を要求した場合、SQL

は 4 の DOP で実行されます。

図 15：Oracle Database Control のパラレル実行の制限


25


図 15は、'DW_USERS'という名前のリソース計画におけるパラレル実行のDOPを 4

に制限したOracle Enterprise Manager Database Controlのスクリーンショットを示し

ています。

さらに、DBRM では、特定のリソース・グループのアクティブなセッションの最

大数を制御できます。表示されているリソース計画'DW_USERS'のアクティブにでき

る最大セッション数は 4 であり、最大のリソース消費の合計は、32 パラレル・サー

バー・プロセスとなります（4（セッション）×4（DOP）×2（スレーブ・セット））。

Oracle SQL のパラレル実行のベスト・プラクティス

この項では、SQL のパラレル実行の使用を検討する際に覚えておく必要があるベ

スト・プラクティスについて説明します。すでにパラレル実行を使用している場

合は、システムのパフォーマンスを最大限に活かしていることを確認するために

参照することもできます。

バランスのとれたシステムでの起動

優れた基盤を確立することが、SQL のパラレル実行を正常に使用するための基本

となります。SQL のパラレル実行の場合、この基盤はデータベースを実行するた

めに使用するハードウェア構成から成ります。すべてのシステム・リソース（CPU、

I/O、メモリ）で、SQL のパラレル実行の使用をサポートできる必要があります。

Real Application Clusters を使用する場合は、インターコネクトの設定も適切におこ

なう必要があります。パラレル実行は、本来、非常に I/O 集約的なものなので、

システム内に組み込まれた各インバランスは、I/O が少ないワークロードの場合よ

りも、ハードウェア・プラットフォームの全体的なスケーラビリティにより、目

に見えて大きな影響を与えることがあります。

たとえば、システムで I/O 集約的なワークロードを実行する予定の場合は、CPU

の各コアが約 200MB/秒を持続的に処理できると想定して、システムを設定します。

たとえば、そのような構成で CPU の 4 つのコアにおいてビジーな状態が継続する

場合、最適なパフォーマンスを得るために、I/O サブシステム全体で持続的に

800MB/秒をサポートできる必要があります。I/O スループットの要件は、次を含

むハードウェア・システム全体で保証される必要があります。計算ノード内の Host

Bus Adapter（HBA）、使用するすべてのスイッチ、およびストレージ・コントロー

ラや物理スピンドルを含む I/O サブシステムです。この構成では、もっとも弱い

リンクが処理のパフォーマンスおよびスケーラビリティを制限することになりま

す。そのほかのアプリケーションと共有するストレージに依存する場合は、デー

タベースのスループット・パフォーマンスは保証されず、並列処理において、応

答時間が安定しなくなる可能性があります。

SQL のパラレル実行では、メモリも大量に使用されます。CPU のコアごとに、最

低 4GB の RAM が必要です。

Oracle RAC を使用し、ノード内パラレル問合せ（複数のノードにまたがる並列処

理）を使用する場合は、インターコネクトの設定を適切におこなう必要がありま

す。一部のデータの再分散は、インターコネクトを介しておこなわれます。その

ため、インターコネクトの設定は、全体的な I./O 性能と同様に重要です。Oracle

には、従来のシェアード・ナッシング型アーキテクチャと同様に、ほかにもイン


26


ターコネクト・トラフィックを最小限に抑えるための最適化機能があります（並

列処理の実行の選択や単一ノード内の並列処理のサブセットなど）。しかし、最

悪の場合、優れたスケーラビリティを得るためにインターコネクトで要求される

スループットは、最低でもディスクに対するスループットと等しくなります。ノー

ド内パラレル問合せを使用する予定の場合は、（複数の）10 GigE または Infiniband

インターコネクトを使用してください。

ハードウェア・ベンダーおよびオラクルの担当者と協力して、望ましい基盤で開

始できるようにしてください。

構成のキャリブレーション

Oracle Database に期待するパフォーマンスのベースラインを設定する必要がありま

す。Oracle Database ソフトウェアは、ハードウェア構成で実現できる以上のパフォー

マンスを実現できません。したがって、オラクル・ソフトウェアを導入する前に、

オペレーティング・システムで実現可能なパフォーマンスを知っておく必要があ

ります。そして、パフォーマンスが十分ではないと考えられる場合は、オペレー

ティング・システムにおけるパフォーマンスをベースラインとして使用します。

SQLのパラレル実行は、一般的に非常I/O集約的なものなので、Oracle Databaseを使

用せずに実現できる最大のI/Oパフォーマンスを測定する必要があります。システ

ムのI/Oパフォーマンスは、OracleデータベースのI/Oワークロードをシミュレート

するために設計された、オラクルが無償で提供しているユーティリティのORION8

（ORacle I/O Number）キャリブレーション・ツール、またはオペレーティング・

システムの基本的なユーティリティ（Linux/Unixのddコマンドなど）を使用して測

定できます。構成はOracleデータベースが使用する方法（ストレージ・デバイス間

でデータがどのように配置されるか）でキャリブレーションし、SQL文を並列で

実行するときに、Oracle Databaseが実行するワークロードのタイプと似たキャリブ

レーション・ワークロードを使用します（通常、大量のランダムI/O）。

Stripe And Mirror Everything（S.A.M.E.） - ASM の使用

すべての物理ディスクは、20～30MB/秒で持続的に大量のデータをランダムに読

み取れます。1 つの CPU コアがビジーな状態を保つために約 200MB/秒の能力（つ

まり、8～10 台の物理ディスク）が必要な場合、並列で実行するデータベース処

理で優れたパフォーマンスを発揮するためには、多数の物理スピンドルが必要に

なります。800GB のデータベースに対して、1 台の 1TB ディスクを使用しないで

ください。この場合、データベースに対して並列で処理を実行しても優れたパ

フォーマンスは得られません。このような構成は、シングルユーザーがホーム・

ビデオをアーカイブするには有効かもしれませんが、複数のユーザーがパラレル

問合せをおこなうデータベースには適していません。

Oracle のシェアード・エブリシング型アーキテクチャで複数の物理スピンドルを

利用する方法は、複数のデバイス間でデータをストライプ化する方法です。高可

用性を得るには、RAID 構成（一般的に、ストレージベースの RAID1 または RAID5が使用されます）を使用して、1 台のディスクで障害が発生しても処理を続行で

きるようにします。オラクルでは、長年、Stripe And Mirror Everything（S.A.M.E.）方式（1MB のストライプ・サイズを使用）の使用をユーザーに推奨しています。

8 Orionは、Oracle Technology Networkからダウンロードできます。

http://www.oracle.com/technology/software/tech/orion/index.html


27


http://www.oracle.com/technology/software/tech/orion/index.html

このような構成は比較的設定が容易で、ほぼすべてのワークロード（OLTP、レポー

ト作成、データウェアハウス）に対して優れたパフォーマンスを提供します。

Oracle Database 10g 以降のバージョンでは、付属の Automatic Storage Manager を使

用できます。Automatic Storage Manager を使用して、Oracle Database ファイル（オ

ンラインの REDO ログ・ファイルやアーカイブ・ログ・ファイルを含む）を格納

できます。また、ユーザーがディスク・グループのコンテキストで提示するすべ

てのデバイス間でデータのストライプ化をおこないます。さらに重要なのは、構

成を拡張する場合、Automatic Storage Manager はすべてのデバイス間で自動的に

データを再バランス化（再ストライプ化）します。そのため、ストレージ構成内

でホット・スポットが生じることなく、構成内のすべてのストレージ・デバイス

を常に有効に活用できます。Automatic Storage Manager は、オラクルの S.A.M.E.方式を実装して、デバイスの追加または削除がおこなわれる際に自動的に維持し

ます。さらに、データをミラー化するためにも使用でき、ハードウェアの RAID構成でも使用できます

Oracle Database 10g 以降を使用している場合は、Automatic Storage Manager を使用

してください。

優れたパフォーマンスを得るためのデータベース初期化パラメータの

設定

バランスのとれたシステムを確立したら、Oracle Database ソフトウェアをインス

トールして、データベースを作成します。SQL のパラレル実行で優れたパフォー

マンスを得るには、考慮しなければならないパラメータがいくつかあります。

メモリの割当て

多数の並列処理をおこなうと、多くの実行メモリが使用されます。メモリをデータ

ベースに割り当てる際には、この点を考慮する必要があります。パラレルで実行

する処理の多くは、バッファ・キャッシュをバイパスすることも忘れないでくだ

さい。並列処理では、オブジェクトがCACHEオプションを指定して明示的に作成

されているか、オブジェクトのサイズがバッファ・キャッシュの 2%未満の場合に

のみバッファ・キャッシュが使用されます。オブジェクトのサイズがバッファ・

キャッシュの 2%未満の場合、直接読取りを開始するためのチェックポイントのコ

ストは、ブロックをキャッシュに読み取るだけの場合より高くなると考えられます。

shared_pool_size

パラレル・サーバーは、サーバー間で通信をおこない、メッセージを渡すことで

問合せコーディネータと通信します。メッセージは、共有プールから割り当てられ

ているメモリ・バッファを経由して渡されます。パラレル・サーバーは、起動する

と共有プールにバッファを割当て、通信できるようにします。共有プールにバッファ

を割り当てるための十分な空き領域がない場合、パラレル・サーバーの起動が失

敗します。共有プールのサイズを適切に設定するには、次の式を使用して、パラレ

ル・サーバーを追加することで共有プールに加わるオーバーヘッドを計算する必

要があります。ノード内並列処理を実行している場合は 1 つ目の式を、Oracle RAC

環境でクロス・インスタンス並列処理を使用する場合は 2 つ目の式を使用します。

(((2 + (cpu_count X parallel_threads_per_cpu)) X 2) X (cpu_count X parallel_threads_per_cpu)) X parallel_execution_message_size X # concurrent queries


28


(((2+ (cpu_count X 2)) X 4) X cpu_count X 2)) X parallel_execution_message_size X # concurrent queries

結果はバイト単位で表示されます。

parallel_min_serversに必要なメモリだけが、データベースの起動時に

shared_poolから事前に割り当てられます。追加のパラレル・サーバーが必要にな

ると、それらのメモリ・バッファが共有プールから"オン・ザ・フライ"で割り当

てられます。これらのルールは、shared_pool_sizeを直接使用するか、sga_

target（10g以降）またはmemory_target（11g以降）を使用するかに関係なく

適用されます。

pga_aggregate_target

pga_aggregate_targetパラメータは、Oracleデータベースで割り当てられる実

行メモリの総量を制御します。Oracleデータベースは、作業領域のサイズを合わせ

ることで、ユーザーが指定したターゲットよりプライベート・メモリの量を少な

い状態で維持しようと試みます。このパラメータの値を増やすと、間接的に作業

領域に割り当てられるメモリの量を増やすことになります。その結果、よりメモ

リ集約的な処理をメモリ内でフルに実行できるようになり、ディスクへのI/Oが減

ります。多数の並列処理を実行する環境では、pga_aggregate_targetは可能

な限り大きな値に設定する必要があります。目安としては、最低100MB×

parallel_max_serversが必要です。

parallel_execution_message_size

前述したように、パラレル・サーバーは、サーバー間で通信をおこない、メモリ・

バッファを使用してメッセージを渡すことで問合せコーディネータと通信します。

多数の処理を並列で実行する場合は、parallel_execution_message_size

（バッファのサイズ）を増やすことで、メッセージングの待機時間を短くすること

を推奨します。デフォルトでは、メッセージのサイズは 2KBです。理想的なサイ

ズは、16KB（16,384）です。ただし、parallel_execution_message_sizeに

大きな値を指定すると、shared_poolに必要なメモリの量が増えるので、2KBから

16KBに増やした場合、パラレル・サーバーに必要なメモリの量は 8 倍以上になり

ます。

パラレル・サーバーの制御

並列処理を最適な状態で実行するには、使用可能なパラレル・サーバーが十分に

ある必要があります。使用可能なパラレル・サーバーがない場合、処理は実際に

はシリアルに実行されます。

cpu_count

CPU カウントは Oracle システムのパラメータから自動的に取得され、デフォルト

のパラメータ・サーバー数およびオブジェクトのデフォルトの並列度を決めるた

めに使用されます。このパラメータの値は変更しないでください。


29


parallel_threads_per_cpu

このパラメータでは、パラレル実行中にCPUで処理できる並列処理プロセスまた

はスレッドの数を指定します。このパラメータは、インスタンスのデフォルトの

並列度を計算し、parallel_max_serversが設定されていない場合に最大のパ

ラレル・サーバー数を決めるために使用されます。デフォルト値は、プラット

フォームに依存し、ほとんどの場合適切なものです（大部分のプラットフォーム

で 2 です）。

parallel_min_servers

このパラメータで、データベースの起動時に起動されるパラレル・サーバーの数

が決まります。デフォルト値は 0 です。parallel_min_serversの値は、"同時

に実行する問合せの平均数×1 つの問合せで必要な最大並列度"に設定することを

推奨します。この設定により、システムで実行される問合せの大部分で使用でき

る十分なパラレル・サーバー・プロセスが用意され、追加のパラレル・サーバー

を起動することで加わるオーバーヘッドによって問合せのパフォーマンスが低下

することはありません。ただし、追加の問合せのために平均ワークロードよりも多

くのパラレル・サーバーが必要な場合は、最大parallel_max_serversの値ま

で"オン・ザ・フライ"で起動できます。parallel_min_serversの数より多く

起動された追加のパラレル・サーバー・プロセスは、非アクティブな状態が一定

時間続くと停止し、あとで再び必要になった場合は、再起動する必要があります。

parallel_max_servers

このパラメータで、データベース・インスタンスのために起動されるパラレル・

サーバーの最大数が決まります（そのような要求がある場合）。Oracle Database 10g

以降のデフォルト値は、10×cpu_count×parallel_threads_per_cpuです。

目安としては、parallel_max_serversisは、"同時に実行する問合せの最大数

×1 つの問合せで必要な最大の並列度"よりも大きい値に設定します。このように

設定することで、すべての問合せが適切な数のパラレル・サーバーを取得できま

す。

parallel_adaptive_multi_user

このパラメータは、システムへの過負荷を未然に防ぐために並列処理を自動的に

ダウングレードするかどうかを制御します。ワークロードおよびユーザーの期待

値に応じて、このパラメータを true または false に設定する必要があります。この

パラメータを true に設定して、並列処理がダウングレードされた場合、実行時間

が大幅に遅くなる点に注意してください。ビジーなサーバーにおいて予想される

応答時間を期待する場合は、このパラメータを falseに設定することを推奨します。


30


効率的な I/O スループットの有効化

db_file_multiblock_read_count

SQLのパラレル実行は、一般的に大量のデータにアクセスする問合せ（全表スキャ

ンを実行するときなど）に使用されます。パラレル実行はバッファ・キャッシュ

をバイパスし、ディスクから直接データをアクセスするので、待機時間を短くす

るために大きなI/O単位を使用し、各I/Oを可能な限り効率的におこなう必要があり

ます。db_file_multiblock_read_countに大きな値を設定すると、ブロッ

ク・サイズで掛けた場合、1MBになります。たとえば、ブロック・サイズが 8KB

の場合は、db_file_multiblock_read_count=128を使用します。

disk_async_io

最適なパフォーマンスを得るには、非同期の I/O を使用してください。これは、

大多数のプラットフォームのデフォルト値です。

一般的なパラレル実行の使用

パラレル実行では、非常に強力でスケーラブルなフレームワークが提供され、SQL

の処理が高速化されますが、次の一般的なルールに注意してください。パラレル

実行では、パフォーマンスが向上しますが、より多くのリソースが必要となり、

同じシステム内のほかのユーザーや処理に悪影響を及ぼすことがあります。実際

に利用可能なリソース以上のものを利用することはできません。

小さなオブジェクトに対して並列処理を有効にしない

小さな表や索引（最大で数千レコードまたは 10 のデータ・ブロック）では、パラ

レル実行を有効にしないでください。小さな表にのみアクセスする処理では、パ

ラレル実行によるパフォーマンスの向上はほとんど期待できません。また、大き

な表へのアクセスに割り当てたいパラレル・サーバーを使用することがあります。

特定の DOP で処理が開始されると、その処理の実行中は、DOP が変わらないこ

とに注意してください。並列処理の実行を決定する要素としてオブジェクト・サ

イズを利用している顧客へのベスト・プラクティスは、DOP を並列処理のための

ある種のステップ関数と関連づけることです。次に例を示します。

− 200MB より小さいオブジェクトでは並列処理を使用しない

− 200MB から 5GB のオブジェクトでは DOP 値を 4 にする

− 5GB 以上のオブジェクトには DOP 値を 32 にする

各ユーザーの最適なサイズの範囲や DOP の設定はそれぞれ異なり、ターゲットと

するワークロードやビジネス上の要件に強く依存します。

目標を大きく超えない並列処理を使用した目標の実現

並列処理を使用することでビジネス要件が実現可能な場合も、目標を大きく超え

ないでください。たとえば、特定の問合せを 2 分以内で実行する必要がある場合

も、30 秒で実行できるようにはDOPを設定しないでください。図 1をもう 1 度参

照してください。リニア・スケーラビリティが実現されていると仮定すると、こ

の例では 4 倍のパラレル・プロセスが必要になります。そのプロセスを処理でき


31


るリソースがあれば、同じクラスの問合せをさらに 3 つ実行でき、4 倍の作業を

実行してビジネス目標を達成できます（この例は簡素化されています。実際には、

ある程度の余裕をもたせて計画する必要があります）。

回避するヒントの使用

通常、パラレル実行を有効にするには、ヒントを使用しないでください。ヒント

は維持することが難しく、オブジェクトやビジネス要件の変化に伴い、適切に動

作しなくなることがあります。

Oracle Partitioning とパラレル実行の組合せ

Oracle Partitioning9は強力なデータベース機能であり、ラージ・データベース・オ

ブジェクトを管理できます。また、ラージ・データベース・オブジェクトへのア

クセス時に優れたパフォーマンスが得られます。Oracle Partitioningを使用すると、

1 つの論理オブジェクト（表または索引）を独立した複数の物理セグメントに透

過的に格納できます。データの配置は、オブジェクトに関する追加の情報（注文

データの範囲や顧客ID情報のハッシュ・バケットなど）でコントロールされます。

SQL のパラレル実行と Oracle Partitioning の間には固有の最適化機能があり、これ

らの機能を一緒に使用する場合には注意する必要があります。たとえば、パラレ

ル・パーシャル結合やフル・パーティションワイズ結合（18 ページを参照）が利

用可能な 2 つのパーティション化された大きな表は、パーティション化されてい

ない表よりも高速に結合できます。（サブ）パーティションのサイズは、ほぼ同

じであるのが理想的です。これは、2 の累乗の数のハッシュ（サブ）パーティショ

ンとともに、一意またはほぼ一意な列のハッシュ（サブ）パーティション化を使

用することで実現できます。

例として、2 つの大きな表、SALESとCUSTOMERSについて検討してみます。コン

ポジット・パーティション化RANGEをCUSTOMER_IDのORDER_DATE、HASHに使

用して、SALES表をパーティション化します。HASHパーティション化を

CUSTOMER_IDに使用して、CUSTOMERS表をパーティション化します。これで、

SALESおよびCUSTOMERS間のパラレル表結合で、フル・パーティションワイズ結

合を利用できます。

十分な統計情報

誤った実行計画で SQL文を実行すると、通常、実行パフォーマンスは低下します。

誤った実行計画を使用してパラレル実行した場合、パフォーマンスの問題はさら

に悪化することがあります。

Oracle Database では、すべての SQL 操作に対して最適な実行計画が計算されます。

優れた計算の基本となるのは、表のサイズ、データの分散などに関する有効な情

報です。統計情報をタイムリーに収集することが、正しい統計情報を取得するに

は重要であり、その結果、オプティマイザが優れた実行計画を生成できます。

9 Oracle Partitioningは、Oracle Database 11g Enterprise Editionの追加のライセンス・オプションです。


32


Oracle Database 10g からは、かならずシステム統計情報を収集してください。シス

テム統計情報には、問合せオプティマイザに渡す、I/O と CPU のパフォーマンス

や使用率などのシステムにおけるハードウェアの特徴が記録されます。システム

統計情報により、問合せオプティマイザはより正確に I/O および CPU のコストを

見積もることができ、より優れた実行計画の選択が可能になります。

パラレル実行アクティビティの監視

SQLのパラレル実行において問題があると考えている場合には、データベース・

ユーティリティを使用して、SQLのパラレル実行を中心にシステムのアクティビ

ティを監視します。Database ControlまたはGrid ControlにおいてEnterprise Manager

のパフォーマンス・ページを使用して、待機イベントを監視します。または、

statspackレポート（Oracle9i Database）やAWRレポート（Oracle Database 10g以降）

を使用して、システムのパフォーマンスを分析できます。パラレル実行の監視の

詳細について、次の項も参照してください。

Oracle RAC でパラレル実行を使用するかどうかの判断

Oracle RAC は優れたアーキテクチャを備えており、新たなシステム・リソースが

必要な際、ハードウェア構成を徐々に拡張できます。追加のリソースを使用して、

追加のユーザーをサポートし（したがって、ほかのサーバーの負荷を軽減できる）、

データベースで実行している処理のパフォーマンスを直接向上させることができ

ます。インターノード・パラレル実行では、大量のインターコネクト・トラフィッ

クが発生する可能性があるため、インターコネクトのサイズは適切に設定してく

ださい。Oracle データベースでは、（1 文のパラレル実行に複数のノードが関与す

る）インターノード・パラレル実行がデフォルトで有効になっています。

サーバーからストレージ構成への I/O 帯域幅と比較して、相対的に劣るインター

コネクトを使用する場合、パラレル実行は単一のノードまたは限られた数のノー

ドに限定することを推奨します。インターノード・パラレル実行は、標準以下の

インターコネクトでは拡張されません。一般的な目安としては、インターコネク

トがクラスタ内の全ノードの合計 I/O スループットを提供する必要があります（す

べてのノードは、ディスクからデータを読み取る速度で、時間内に同じポイント

にデータを分散できます）。そのため、4 つのノード・クラスタがある場合、各

ノードは I/O サブシステムから 1GB/秒でデータを読み取れるので、インターノー

ド・パラレル実行を伴う処理を直線的に拡張するには、インターコネクトは 4GB/

秒（4×1GB/秒）をサポートできる必要があります。インターコネクトがこの要件

を満たしている（または非常に近い）場合を除き、インターノード・パラレル実

行の使用は推奨されません。

インターノード・パラレル実行を制限するには、instance_groupsと

parallel_instance_groups、またはデータベース・サービス（Oracle Database

11g以降）を使用します。Oracle Database 11gからは、サービスの使用を推奨しま

す。instance_groupsパラメータの使用は推奨できず、下位互換性のためだけ

に残されることになります。


33


Database Resource Manager の使用

Database Resource Manager により、SQL の並列処理を実行する前に最終的な DOP

が決定されます。システムに過度の負荷がかからないように、ユーザーが無制限

に並列処理を使用するということを制限する場合は、Database Resource Manager

の使用を検討してください。Database Resource Manager は、一定の応答時間が要求

される処理のためのリソースを保証する優れたツールです。

ほかの機能を使用して、ハードウェア不足の解決を試みない

システムへの過負荷以外にある、パラレル実行のもっとも一般的な"問題"は、ユー

ザーがバランスのとれていないシステムでパラレル実行によりスケーラビリティ

を実現しようとすることです。これは明らかにうまくいきません。バランスのと

れたシステムを実装して、根本的な問題に対応するのではなく、ユーザーは多く

の場合、索引や新たなサマリー表などを作成して、さまざまな事象に対応しよう

とします。

そのような対応では、既存の欠陥を短期間は緩和できるかもしれませんが、問題

を解決することにはなりません。むしろ、複雑さが増し、問題の解決が遅れるこ

とになります。釘を打つにはハンマーを使用しますが、それをレンチで代用して

も 1、2 本打てるだけで、家を建てることはできないのと同様です。

ほかの機能を無視しない

一方、ハンマーがあっても、すべてが釘のように見えてしまい、ハンマーをもっ

ていない場合と同じくらい悪い状況に陥ることがあります。SQL のパラレル実行

は、費用のかかるデータベース処理に対して、より高いパフォーマンスを提供す

る優れた方法ですが、特定のビジネス要件に対しては、ある程度のパフォーマン

スを提供できる機能がほかにも存在するということを忘れないでください。たと

えば、キューブ化されているマテリアライズド・ビューを多次元レポートと多次

元分析に組み込んだ場合、非常に大規模なハードウェアを使用し、パラレル実行

と詳細なデータ・レコードにより同等の問合せを実行した場合と等しいパフォー

マンスを得られることがあります。Oracle のウェアハウス機能はすべて協調して

機能します。そのため、長所を活かせるように機能を選択し、ビジネス要件を解

決してください。1 組の機能だけを使用するというアプローチにはこだわらない

でください。

SQL のパラレル実行の監視

パラレル実行を監視する方法はいくつかあります。この項では、さまざまなオプ

ションについて説明します。

（G）V$パラレル実行ビュー

特定のパラレル実行のパフォーマンス・ビューは、（G）V$_PQおよび（G）V$_PX

で始まります。いわゆるV$ビューは、インスタンス固有のビューを提供し、GV$

ビューは、Real Application Clusters環境でクラスタ全体の情報を抽出するのに役立

ちます。GV$ビューには、V$ビューに相当する列に加えて、インスタンスIDが含


34


まれています（それ以外のものはありません）。たとえば、1 クラスタにおける

パラレル実行アクティビティの情報を得るには、次の文を実行します。

select inst_id , status , count(1) px_servers#

from gv$px_process group by inst_id, status order by inst_id, status ;

INST_ID STATUS PX_SERVERS#

1 AVAILABLE 4 1 IN USE 12 2 AVAILABLE 8 2 IN USE 8 3 AVAILABLE 6 3 IN USE 10 4 AVAILABLE 2 4 IN USE 14

パラレル SQL 実行計画の実装

Oracle Database 10g 以降で、問合せは、すべてのパラレル・サーバーで実行される

1 つのカーソルをもちます。パラレル実行のすべての情報は、すべてのパラレル・

サーバー・プロセスで使用される単一の実行計画内にあります。パラレル計画の

情報は、EXPLAIN PLAN ユーティリティの使用、カーソル・キャッシュからの選

択、または高度なワークロード・リポジトリの使用など、さまざまなメカニズム

により取得できます。計画の基本的な情報は、こうしたすべてのメカニズムで同

じです。それでは、もっとも基本的なパラレル実行の最適化機能、つまりパーティ

ションワイズ結合の識別および解釈方法について説明します。

パーティション化を伴わないパラレル計画

SALES表とCUSTOMERS表は、最初はパーティション化されていません。以下に実

行計画の一部を示します。

explain plan for select c.state_province , sum(s.amount) revenue from customers c, sales s where s.customer_id = c.id and s.purchase_date

between to_date('01-NOV-2007','DD-MON-YYYY') and to_date('31-DEC-2007','DD-MON-YYYY')

and c.country = 'United States of America' group by c.state_province; select * from table(dbms_xplan.display);10

10 この実行計画の例からは、わかりやすくするために一部の列が削除されています。


35


図 16：州ごとの顧客の購買情報、パラレル計画

このホワイト・ペーパーの概念の項で説明した情報をすべて活用することで、以

下の並列処理の手順を理解できます。

− CUSTOMERS 表は並列で読み取られ（ID 11）、SALES 表を読み取ったすべ

てのパラレル・サーバーにブロードキャストされます（ID 9）。

− 結合後、列ごとにグループで HASH 再分散（ID 5）を使用して、データが再

分散されます。

− 再分散をおこなうことなく、ハッシュ結合とハッシュのグループ化がパラレ

ル実行されます（ID 6 と ID 7）。各パラレル・サーバー・プロセスは、それ

ぞれの分離データ・セットの増分の集計をおこないます。

− SQL 文では order by が指定されていないため、結果はランダムに問合せコー

ディネータに返されます（ID 2）。パラレル・サーバーがその増分結果の計算

を終えると、結果は常に QC に返されます。

パーティション化とパーティションワイズ結合を伴うパラレル計画

大規模なデータベース、とくにデータウェアハウス（おもにパラレル実行を使用

するデータベースのタイプ）は、常に Oracle Partitioning を使用する必要がありま

す。パーティション化をおこなうと、パーティションの排除（プルーニング）機

能により、パフォーマンスが大幅に向上します。また、パラレル実行計画ではパー

ティション化を利用できることもパフォーマンスの向上につながっています。

SALES表とCUSTOMERS表を次のように作り直してみましょう。

− CUSTOMERS表のID列を 128 のパーティションを使用してHASHパーティショ

ン化します。

− これで、SALES表とCUSTOMERS表は、結合列で同一レベル・パーティション

化されます。


36


図 17：顧客の購買情報、パラレル計画、パーティションワイズ結合を使用したハッシュ・パーティション化

図 17は、ハッシュ・パーティション化された表を使用する同様の問合せの実行計

画を示しています。前述の例とは異なり、SALES表とCUSTOMERS表のグラニュル

を計画内ですぐに見かけることはありません。これはパーティションベースのグ

ラニュルを使用しているためであり、実行時に並列アクセスのためのデータを

パーティション化する必要がなく、データベースは単純に既存のパーティション

での処理を繰り返せば済みます。

さらに、パーティションワイズ結合を利用して、2 つの同一レベル・パーティショ

ン化された表を結合しています。パーティションベースのグラニュルは、両方の

表で等しいだけではなく、グラニュルの繰返し（処理）が、パーティションのペ

アの処理（結合も含む）もおこなっています。ある時点においては、1 つのパラ

レル・サーバー・プロセスが 1 つの等価パーティション・ペアの処理をおこない

ます。その結果、パーティションベースのグラニュル・イテレータは、実行計画

内でハッシュ結合処理の上にきます。

パラレル実行の既知の処理手順に加え、このパーティションワイズ結合の新しい

動作が図 17の実行計画に示されています。

− SALES表とCUSTOMERS表は並列的にアクセスされ、既存の同一レベル・パー

ティション化によるハッシュ・パーティションベースのグラニュルの処理を

繰り返します（ID 7）。この処理は、"すべてのハッシュ・パーティションの

ループ・オーバーおよび後続の操作の処理"と解釈できます。一連のパラレル・

サーバーがn個のパーティションで同時に処理をおこないます（nはDOPと同

値）。パーティションの数は 1～128 で、'Pstart'列と'Pstop'列で指定し

ます。

− 各HASHパーティション・ペアに対し、パラレル・サーバー・プロセスは、

CUSTOMERS表とSALES表を結合します。

SALES表とCUSTOMERS表を結合するためにデータの再分散はおこなわれません。

インターノード・パラレル問合せの場合、コンピュータ・ノード間でデータ転送

をおこなう必要はありません。Oracleデータベースは、組み込まれているシェアー

ド・エブリシング・パラダイムですが、この処理ではシェアード・ナッシング・

システムのように機能します。


37


図 18：顧客の購買情報、PWJ を使用したパラレル計画

フル・パーティションワイズ結合では、結合列を同等のものにするためのパーティショ

ン化戦略のみが必要です。レンジ・パーティション化のためのPURCHASE_DATEを

使用して、SALES表をコンポジットRANGE-HASHパーティション化表（月ごとに

パーティション化された 7 年間のデータ）に変更し、128 のサブパーティション

を使用して、CUSTOMER_IDをハッシュ・サブパーティションに変更します。それ

でも、フル・パーティションワイズ結合の条件は達成できるため、計画上の変更

点はわずかしかありません。上述の図 18を参照してください。

しかし、新しくパーティション化された表に対する問合せへの応答は以前よりも

速くなります。パラレル・フル・パーティションワイズ結合の利点のほか、パー

ティションの排除機能により大幅なパフォーマンスの向上が達成できます。Oracle

データベースは、問合せ内のすべての既存の条件を分析し、一部のパーティショ

ンにおいて処理から完全に排除できるかどうかを確認します。前述の例では、コ

ンポジットRANGE-HASHパーティション化表であるSALESには、合計で 10,752

（84×128）のサブパーティションがあります。purchase_dateのフィルタ条件

を分析すると、2 つの範囲パーティション（#72 と#73、ID 10 のpstart/pstop）が導

かれます。そのため、10,752 パーティションのうちの 256 パーティションにだけ

アクセスすればよく、パフォーマンスが約 40 倍向上します。

パーティションワイズ結合は、REF パーティション化表を結合する場合にも活用

できます。また、小さな表と非常に大きな表を結合するときに使用する、いわゆ

るパーシャル・パーティションワイズ結合では、大きな表のパーティション化戦

略と一致するようにデータの再分散がおこなわれます。パラレル実行だけに焦点

を絞るため、REF パーティション化表のパーティションワイズ結合やパーシャ

ル・パーティションワイズ結合の詳細については取り上げません。


38


Oracle Enterprise Manager

Oracle Enterprise Manager Database Control 11g は、パラレル実行の観点から、実用

的な新監視機能を提供します。この機能は、Oracle Enterprise Manager Grid Control

11g でも利用可能です。

待機イベント

Oracle Enterprise Manager Database Control または Grid Control（Oracle Database 10g

以降）のメインのパフォーマンス画面には、待機イベントが時間とともにグラフ

で表示されます。この画面は、任意の時点におけるシステムのワークロードを確

認する際に役立ちます。システムが大量の CPU リソースを使用しているか、特定

のリソースが空くのを待っているか、待っている場合リソースの種類は何かなど

を簡単に把握できます。パラレル実行のワークロードの大部分が SQL 文で構成さ

れている場合、一般的に CPU の使用率が高くなり、大量のユーザーI/O 待ちが発

生します。

図 19：Oracle Enterprise Manager Database Console 11g のパフォーマンス・ページ - 待機イ

ベント

図 19は、Oracle Enterprise Manager Database Controlの待機イベントのグラフを示し

ているパフォーマンス・ページのスクリーンショットです。パラレル実行のワー

クロードは、大量のI/O待ちを示していますが、システムのCPU使用率はそれほど

高くありません。

もっとも一般的なPXイベントは、プロデューサ/コンシューマ・モデルのメッセー

ジ（データ）交換を処理します。待機状態を緩和するために、パラレル実行イン

フラストラクチャはバッファを使用します。プロデューサがバッファに書き込み、

コンシューマがバッファを読み取ります。このメカニズムは、処理を効率的にお

こなうために、両方向で機能します。このモデルでは、データベース・インスタ

ンス内で待機イベントを確認できます。それらのイベントは、コンシューマがデー

タを受け取るのをプロデューサが待っているため（PX Deq Credit:send blkd）、

またはプロデューサがデータを作成するのをコンシューマが待っている（PX


39


DeqCredit：need buffer）ために発生します。プロデューサ/コンシューマ・

モデルにおける待機イベントの発生は、ほとんどの場合避けることができません

が、パフォーマンスにはほとんど影響しません（待機イベントは"アイドル"待機

クラスに分類されます）。ほかの待機イベントは、パラレル・サーバーの起動と

停止に関連するもので、コーディネータがパラレル・サーバーを取得するために

必要となります。これらの待機イベントは発生率を抑え、本番環境で多くの時間

を消費しないようにする必要があります。

statspack の出力または Analytic Workload Repository（AWR）レポートでは、すべ

てのパラレル実行の待機イベントを確認できます。前述のとおり、大部分のパラ

レル実行（PX）イベントは、アイドル待機イベント、または並列環境で追加のプ

ロセス通信が発生することによる調整と回避が不可能なイベントです。

一般的には、システムのパフォーマンス低下を引き起こすパラレル実行固有の待

機イベントではなく、パラレル実行のワークロード（I/O待ちまたはCPUの高い使

用率）によって発生する待ち状態です。アイドル・パラレル実行イベントの増加

は、多くの場合、パフォーマンスの問題の原因ではなく、その症状であると考え

られます。たとえば、プロデューサがデータ（PX Deq Credit：need buffer）

を生成するのを待機しているコンシューマの数が増えている場合は、I/Oパフォー

マンスの低下という問題を示している可能性が高くなります。たとえば、ディス

クのI/Oを伴うプロデューサの処理があるケース（並列全表スキャンなど）が考え

られます。

入出力（I/O）の監視

パラレル実行するほぼすべての SQL 文は、データをメモリからではなく、ディス

クから直接読み取ります。その結果、パラレル文の処理は非常に I/O 集約的なも

のになります。Oracle Enterprise Manager Database Control 11g では、メインのパ

フォーマンス・ページの"I/O タブ"と詳細な I/O ページに、I/O スループットの情

報が表示されます。

図 20：パラレル DML ワークロードを示す Oracle Enterprise Manager 11g Database Console の

詳細な I/O ページ


40


図 20の例は、パラレルDMLワークロードのI/Oページを示しています。データベー

ス・ライターに対して秒ごとに大量のI/Oが発生し、スループットの大部分が大量

の書込みになっています。圧倒的にパラレル問合せが多い環境では、大量の読取

りからスループット（MB/秒またはGB/秒）の大部分が生じます。I/Oが原因でSQL

の並列処理にボトルネックが生じる場合、通常は、毎秒のI/O動作回数（IOPS）の

最大値ではなく、スループット（MB/秒）の最大値に達しています。

パラレル実行の監視

Oracle Enterprise Manager Database Control 11gのパフォーマンス・ページには、パ

ラレル実行の監視機能も導入されています。この画面では、システムが大量の文

をパラレル実行しているかどうか、低いDOPで実行している多くの文に比べて、

高いDOPで実行しているわずかな文でリソースの大部分が使用されていないかど

うかを確認できます。図 21は、Oracle Enterprise Manager 11g Database Controlのパ

フォーマンス・ページのParallel Executionタブのスクリーンショットです。

図 21：Oracle Enterprise Manager 11g Database Console でのパラレル実行の監視


41


SQL の監視

Oracle Database 11gには、新しい動的ビュー、GV$SQL_MONITOR11が導入されてい

ます。このビューを使用すると、長時間実行しているSQL文やオーバーヘッドが

生じていないすべてのパラレルSQL文をリアルタイムに監視できます。

図 22：ほぼリアルタイムでのパラレル実行の問合せの監視

Oracle Database 11.1.0.6 では、ビューのテキスト形式の出力のみを使用できます。

Oracle Enterprise Manager Database Console 11.1.0.7 以降では、GV$SQL_MONITORの

グラフィカル・インタフェースを使用できます。Oracle Enterprise Manager Grid

Control 11gでは、グラフィカル・インタフェースも提供されます。

この項の例およびスクリーンショットは、単一インスタンスの 2 CPUデータベー

ス・サーバー12上での、Oracle Enterprise Manager 11.1.0.7 Database Consoleを示して

います。

SQL Monitoring画面には、実行時間が長い文またはパラレル実行している文の実行

計画が表示されます。ほぼリアルタイム（デフォルトの更新サイクルは 5 秒）で、

実行計画のどの手順が処理されているか、および待機状態のものがあるかどうか

を監視できます（図 22を参照）。パラレル文には、パラレル・サーバー・セット

が表示されます。SQL Monitorの出力は非常に有用で、実行計画のどの部分がSQL

文の実行全体においてもっとも費用がかかっているかを特定できます。

SQL Monitoring画面の"Parallel"タブには、パラレル・サーバー・セット、および個々

のパラレル・サーバー間に分散されている作業に関する情報が表示されます（図

23を参照）。

11（G）V$SQL_MONITORにアクセスするには、Oracle Database Enterprise Manager Tuning Packのライセン

スが必要です。 12このホワイト・ペーパーの公開時点では、Oracle Database 11.1.0.7 はまだ利用できません。例で表示して

いる以前のデータベース・コンソールのバージョンのスクリーンショットは、開発バージョンのものです。


42


図 23：SQL Monitoring のパラレル・サーバー・セットと作業の分散情報

作業はパラレル・サーバー間で均等に分散されているのが理想的です。1 つのパ

ラレル・サーバー・セット内のパラレル・サーバー間で、作業が偏って分散され

ている場合、最適なパフォーマンスを得ることはできません。文は、パラレル・

サーバーがほとんどの作業を完了するまで待機する必要があります。

SQL Monitoringインタフェースの 3 番目のタブには、ほぼリアルタイムで時間の経

過とともに、文のアクティビティが表示されます（図 24を参照）。この情報を使

用して、どのリソースがもっとも集中的に使用されているかを文のレベルで特定

できます。

図 24：SQL Monitoring の待機アクティビティ


43


Oracle9i Databaseからのアップグレードに関する考慮事項

Oracle Database 10gには、全面的に書き直された内部バラレル実行インフラストラ

クチャが導入されています。Oracle9i Databaseに存在したパラレル実行の多くの制

約が、Oracle Database 10gからは取り除かれています。

Oracle9i DatabaseでSQLのパラレル実行を使用していて、Oracle Database 10g以降に

アップグレードする予定がある場合は、SQLのパラレル実行インフラストラク

チャにおけるいくつかの変更点に注意する必要があります。これらの変更により、

さらに多くの文が並列化され、システムでさらに多くのパラレル・リソースが使

用されるといった予期せぬ変化が生じることがあります。そのため、並列処理の

実行時間が変わる、またはOracle9i Databaseとそれ以降のリリースではシステムの

使用状況が異なるという事態が発生します。

追加の並列処理

Oracle Database 10gでは、内部コードが書き直されており、Oracle9i Databaseに存在

していたパラレル実行数に関する制限が取り除かれています。その結果、表レベル

で並列設定を使用する場合、シリアルで実行していた処理の一部がパラレル実行

されることがあります。これにより、以前はパラレル実行していなかった処理の

実行時間は短縮されますが、システムは以前よりも多くのパラレル・リソースを

使用することになります。最悪の場合、Oracle9i Databaseではパラレル実行できてい

た処理を、パラレル・リソースが不足しているために、より低いDOPで実行する、

またはシリアルで実行することになります。この問題は、Oracle9i Databaseですでに

リソースの限界近くでシステムを稼動していた場合、さらに顕著になります。

Oracle9i Databaseからのアップグレードを計画する際には、SQLのパラレル実行の

設定を確認する必要があります。あらゆるケースにおいて、本番環境でワークロー

ドの代表的なテストをおこない、Oracle9i Databaseとほかのリリース間におけるパ

ラレル実行の動作を検証する必要があります。

Oracle9i Databaseで、SQLのパラレル実行を有効にするためにヒントを

使用している場合

常にヒントだけを使用して、Oracle9i DatabaseでSQLのパラレル実行を有効にして

いる場合、アップグレードに関する考慮事項はほとんどありません。パラレル・

ヒントを使用しているすべての処理が、Oracle9i Databaseにおいて実際にパラレル

実行されているかどうかを確認する必要があります。実行されている場合、Oracle

Database 10g以降でも同様にパラレル実行されます。

Oracle9i Databaseで、SQLのパラレル実行を有効にするためにセッショ

ンの設定を使用している場合

常にセッションの設定だけを使用してパラレル実行を有効にしている場合、パラ

レル実行が有効になっている、または強制されているセッションで実行されてい

る処理を確認する必要があります。Oracle Database 10g以降にアップグレードすれ

ば、さらに多くの処理がパラレル実行されることが予想されます。Oracle9i

Databaseでパラレル実行が有効になっているセッションに並列処理だけ存在する

場合は、アップグレード後の変化はあるとしても最小限のものになります。


44


Oracle9i Databaseで、SQLのパラレル実行を有効にするためにオブジェ

クト・レベルの設定を使用している場合

パラレル実行を有効にするために、表または索引レベルでパラレル・プロパティ

を設定している場合、変化を実感する可能性がもっとも高くなります。オブジェク

トへの並列アクセスが有効になっていて、Oracle9i Databaseではパラレル実行され

ない処理の一部は、アップグレード後にパラレル実行される可能性があります。

表レベルでのパラレル設定を慎重に確認して、小さなデータベース・オブジェク

トの並列処理の設定を noparallel にリセットします（レコード数が数千未満のデー

タベース・オブジェクト、およびデータベース・ブロックのサイズが小さいもの

を対象におこないます）。シリアルで実行した場合に数秒未満で終了する処理で

は、パラレル実行によるメリットはほとんどありません。シリアルで実行した場

合に数分または数時間かかる処理の方が、パラレル実行のメリットを得ることが

できます。

実行計画の変更点

前述したように、Oracle Database 10g 以降のすべてのパラレル・サーバーで使用さ

れるパラレル文には、1 つの実行計画しか表示されません。その結果、実行計画

はさらにわかりやすくなっています。しかし、古いデータベース・リリースと新

しいデータベース・リリース間での実行計画の比較を自動化した場合、変更され

ている点が見つかります。そのため、それらの変更点が何によってもたらされた

のかを知る必要があります。場合によっては、悪い方向に変わっていないことを

確認するために実行計画を手動で比較する必要があります。

さらに、単一のカーソル・モデルに変更されているため、パラレル計画の一部

（Oracle Database 10g 以前のバージョンのスレーブ SQL）を表すさまざまな SQL 文

が表示される代わりに、パラレル実行計画のために、複数のパラレル・サーバー

が単一の実カーソルを実行している点しか表示されません。つまり、パラレル実

行を監視および分析する方法が変わります。単一のカーソル・モデルへの変更自

体は、システムの処理に何の影響も及ぼしません。影響するとしても、それは、

Oracle Database 10g 以降で増したパラレル機能に関連するものだけです。

データベースのデフォルトの変更点

SQLのパラレル実行に関するデータベースの初期化パラメータのデフォルト値の

一部は、Oracle9i Databaseから変更されています。もっとも注目すべきものは、次

のとおりです。

parallel_max_servers

Oracle9i Databaseのデフォルト値は、10 でした。Oracle Database 10g以降では、実

行メモリに自動メモリ管理機能を使用すると仮定した場合（つまり、pga_

aggregate_targetまたはOracle Database 11g以降のmemory_targetを使用す

る場合）、デフォルト値は10×cpu_countの値になります。10×cpu_countの

結果は、通常 10 以上になります。つまり、SQLのパラレル実行で、さらに多くの

システム・リソースが使用されることになります。Oracle9i Databaseでのシステム

の負荷がかなり高く、一部の処理をパラレル実行している場合、Oracle Database

10g以降にアップグレードしたときにシステム全体のスループットが低下するこ


45


とがあります。この変化に対処するには、データベースの初期化ファイルpfileま

たはspfileでparallel_max_serversを手動で 10 に設定します。

parallel_adaptive_multi_user

Oracle9i Databaseのparallel_adaptive_multi_userは、parallel_

automatic_tuningからデフォルトで取得され、デフォルト値はfalseになっていま

す。Oracle Database 10g以降では、parallel_adaptive_multi_user equatesはtrue

に設定されます。その結果、ほかの文ですでにSQLパラレル・サーバーが使用さ

れている場合、SQLの並列処理のDOPが強制的に減らされます。Oracle9i Database

で、parallel_automatic_tuningまたはparallel_adaptive_

multi_userを明示的に変更していない場合は、Oracle Database 10g以降にアップグ

レードしたあとに、parallel_adaptive_multi_userを明示的にfalseへ設定す

る必要があります。

Resource Manager の使用

Oracle9i Database以降では、処理が必要なときに必要なリソースを取得できるよう

にするために、Resource Managerの使用を検討してください。絶対に並列処理をお

こなわないユーザーのクラスまたはアプリケーションのタイプがある場合は、

Resource Managerで特定のコンシューマ・グループおよび適切なリソース計画を使

用して、該当するアプリケーションをパラレル実行しないようにします。これに

より、該当するアプリケーションがパラレル・リソースを予定外に消費すること

がなくなり、時間内に処理を完了するためにパラレル実行が必要な処理で、リソー

スを使用できないということがなくなります。

結論

パラレル実行の目的は、複数のリソースを同時に使用することで、処理全体の実

行時間を短くすることにあります。スケーラブルなパラレル実行には、リソース

の可用性がもっとも重要な前提条件となります。

Oracle Databaseは、強力なSQLのパラレル実行エンジンを備えており、Oracle Database

のほぼすべての SQL ベースの処理（DDL、DML、および問合せ）をパラレル実行

できます。このホワイト・ペーパーでは、SQL のパラレル実行を有効にする方法、

およびパラレル実行を正常に使用するためのいくつかのベスト・プラクティスに

ついて説明しました。


46


Oracle SQL のパラレル実行 2008 年 6 月著者：Mark Van de Wiel、Hermann Baer 共著者：Thierry Cruanes、Maria Colgan Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. 海外からのお問い合わせ窓口：電話：+1.650.506.7000 ファクシミリ：+1.650.506.7200 www.oracle.com Copyright © 2008, Oracle. All rights reserved. 本文書は情報提供のみを目的として提供されており、ここに記載される内容

は予告なく変更されることがあります。本文書は一切間違いがないことを保

証するものではなく、さらに、口述による明示または法律による黙示を問わ

ず、特定の目的に対する商品性もしくは適合性についての黙示的な保証を含

み、いかなる他の保証や条件も提供するものではありません。オラクル社は

本文書に関するいかなる法的責任も明確に否認し、本文書によって直接的ま

たは間接的に確立される契約義務はないものとします。本文書はオラクル社

の書面による許可を前もって得ることなく、いかなる目的のためにも、電子

または印刷を含むいかなる形式や手段によっても再作成または送信すること

はできません。Oracle、JD Edwards、PeopleSoft、および Siebel は、米国

Oracle Corporation およびその子会社、関連会社の登録商標です。その他の名

称はそれぞれの会社の商標です。

oracle sql のパラレル実行...oracle sql のパラレル実行 概要...

Documents

oracle sql のパラレル実行...oracle sql のパラレル実行概要...