パラレル実行の概念

8.1 パラレル実行の概念

パラレル実行では、複数のCPUリソースおよびI/Oリソースを1つのSQL文の実行に適用できます。

パラレル実行を使用すると、通常ディシジョン・サポート・システム(DSS)およびデータ・ウェアハウスに関連付けられているサイズの大きなデータベース上で、データ集中型の操作のレスポンス時間を大幅に削減できます。オンライン・トランザクション処理(OLTP)システム上で、索引の作成などのバッチ処理またはスキーマ・メンテナンス操作のためにパラレル実行を実装することもできます。

パラレル実行はパラレル化とも呼ばれます。パラレル化の概念は、タスクへの分解であり、これにより1つのプロセスで問合せに関するすべての処理を実行するのではなく、多くのプロセスが同時に各処理を実行します。たとえば、1年の合計売上げを4つのプロセスで計算するのに、1つのプロセスですべての四半期を処理するのではなく、各プロセスが1年の四半期それぞれを処理する場合です。これを使用するとパフォーマンスの大幅な向上が見込めます。

パラレル実行では、次のプロセスのパフォーマンスを向上できます。

大規模な表のスキャン、結合またはパーティション索引スキャンを必要とする問合せ
大規模な索引の作成
マテリアライズド・ビューを含む大規模な表の作成
バルク挿入、更新、マージおよび削除

この項では、次の項目について説明します。

8.1.1 パラレル実行を実装する場合

パラレル実行は、ハードウェア内のCPU機能およびI/O機能を活用することで、問合せの実行時間を短縮するために使用されます。

パラレル実行は、次の場合に、シリアル実行よりも適切な選択となります。

問合せで大きなデータ・セットが参照される。
同時並行性が低い。
経過時間が重要である。

パラレル実行では、多数のプロセスを一緒に処理して、SQL問合せなどの単一操作を実行できます。パラレル実行は、次のすべての特性を持つシステム上で有効です。

対称型マルチプロセッサ(SMP)、クラスタ、または大規模なパラレル・システム
十分なI/Oバンド幅
稼働中でないCPUまたは断続的に使用されているCPU(CPUの使用率が通常30%未満のシステムなど)
ソート、ハッシュおよびI/Oバッファなどの追加のメモリー集中処理をサポートする十分なメモリー

システムでこれらの特徴が1つでも欠けていると、パラレル実行を使用してもパフォーマンスが大幅には改善されないことがあります。実際に、使用率の高すぎるシステムまたはI/O帯域幅が小さいシステムでは、パラレル実行によりシステム・パフォーマンスが低下する場合もあります。

パラレル実行のメリットは、DSSおよびデータ・ウェアハウス環境でわかります。OLTPシステムでも、バッチ処理やスキーマ・メンテナンス操作(索引の作成など)の際にはパラレル実行の利点が得られます。OLTPアプリケーションを特徴づける通常の単純なDMLまたはSELECT文では、パラレルで実行することによるメリットはありません。

8.1.2 パラレル実行を実装しない場合

シリアル実行は、1つのプロセスのみでSQL問合せなどの単一のデータベース操作を実行するという点で、パラレル実行とは異なります。

シリアル実行は、次の場合に、パラレル実行よりも適切な選択となります。

問合せで小さいデータ・セットが参照される。
同時並行性が高い。
効率が重要である。

通常、次のような場合にはパラレル実行は適していません。

標準的な問合せまたはトランザクションが非常に短い(数秒またはそれ以下)環境。

これには、ほとんどのオンライン・トランザクション・システムが含まれます。パラレル実行はこのような環境では役立ちません。パラレル実行サーバーの調整に関連するコストが発生するためです。短時間のトランザクションの場合、この調整のコストが並列処理のメリットを上回ります。
CPU、メモリーまたはI/Oリソースが大量に使用されている環境。

パラレル実行は追加の使用可能なハードウェア・リソースを利用するように設計されています。そのようなリソースが使用できない場合、パラレル実行はなんのメリットももたらさず、パフォーマンスに悪影響を及ぼす可能性があります。

8.1.3 ハードウェアの基本要件

パラレル実行は、問合せに迅速に応じるために複数のCPUおよびディスクを効率よく使用するように設計されています。

本質的に高度なI/O集中型処理です。最適なパフォーマンスを達成するには、同一レベルのスループットを維持するように、ハードウェア構成の各コンポーネント(CPUや計算ノードのホスト・バス・アダプタ(HBA)からスイッチまで、また記憶域コントローラや物理ディスクなどのI/Oサブシステム)をサイズ設定する必要があります。システムがOracle Real Application Cluster (Oracle RAC)システムの場合、インターコネクトのサイズも適切に設定する必要があります。最も弱いリンクのために、構成における処理のパフォーマンスとスケーラビリティが制限されるためです。

Oracle Databaseを除いて、ハードウェア構成によって実現できる最大のI/Oパフォーマンスを測定することをお薦めします。将来のシステム・パフォーマンス評価の基礎としてこの測定結果を使用できます。パラレル実行で達成できるI/Oスループットが、基礎となるハードウェアによって実現可能なスループットを上回ることはありません。Oracle Databaseには、フリーの測定ツール、Orionが用意されています。このツールは、Oracle I/OワークロードをシミュレーションしてシステムのI/Oパフォーマンスを測定します。通常、パラレル実行では大容量のランダムI/Oを行います。

関連項目:

I/O構成および設計の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください

8.1.4 パラレル実行の仕組み

パラレル実行では、1つのプロセスで1つの問合せに関する処理のすべてを実行するのではなく、多数のプロセスで処理の部分部分を同時に実行するように、タスクが分割されます。

この項では、次の項目について説明します。

8.1.4.1 SQL文のパラレル実行

各SQL文では、解析の際に最適化およびパラレル化のプロセスが行われます。

文がパラレルで実行されることが決定された場合は、実行計画で次のステップが行われます。

ユーザー・セッションまたはシャドウ・プロセスが、コーディネータの役割を引き受けます。これは、問合せコーディネータ(QC)またはパラレル実行(PX)コーディネータと呼ばれることもあります。QCは、パラレルSQL文を開始するセッションです。
PXコーディネータは、パラレル実行(PX)サーバーというプロセスを必要な数だけ取得します。PXサーバーは、セッションを開始するかわりにパラレルで処理を実行する個々のプロセスです。
SQL文は、全表スキャンまたはORDER BY句などの、一連の操作として実行されます。各操作は、可能な場合はパラレルで実行されます。
PXサーバーで文の実行が完了すると、PXコーディネータで、パラレルで実行できない処理の部分が実行されます。たとえば、SUM()演算を含むパラレル問合せでは、各PXサーバーで計算された小計それぞれを合計する必要があります。
最後に、PXコーディネータによって結果がユーザーに返されます。

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

パラレル実行では、プロデューサ/コンシューマ・モデルが使用されます。

パラレル実行計画は、一連のプロデューサ/コンシューマ操作として実行されます。後続操作のためにデータを生成するパラレル実行(PX)サーバーはプロデューサと呼ばれ、他の操作の出力を必要とするPXサーバーはコンシューマと呼ばれます。プロデューサまたはコンシューマ・パラレル操作はそれぞれ、PXサーバー・セットという一連のPXサーバーによって実行されます。PXサーバー・セット内のPXサーバーの数は、並列度(DOP)と呼ばれます。PXサーバー・セットの基本処理単位は、データ・フロー操作(DFO)と呼ばれます。

1つのPXコーディネータで複数のレベルのプロデューサ/コンシューマ操作(複数のDFO)が可能ですが、1つのPXコーディネータのためのPXサーバー・セットの数は、2つまでに制限されています。そのため、同時に2つのPXサーバー・セットのみを1つのPXコーディネータのためにアクティブにできます。結果として、1つのDFO内および複数DFO間の操作の両方に、並列処理が存在します。個々のDFOの並列処理はイントラ・オペレーション並列処理と呼ばれ、複数DFO間の並列処理はインター・オペレーション並列処理と呼ばれます。次の文に関して、イントラ・オペレーション並列化とインター・オペレーション並列化を説明します。

SELECT * FROM employees ORDER BY last_name;

実行計画により、employees表の全体スキャンが実装されます。この操作の後で、取得された行がlast_name列の値に基づいてソートされます。この例では、last_name列には索引がないとします。また、問合せのDOPが4に設定されているとします。これは、どの操作に対しても4つのパラレル実行サーバーが使用できることを意味します。

図8-1は、この例の問合せのパラレル実行を示しています。

図8-1 インター・オペレーション並列化と動的パーティション化

「図8-1 インター・オペレーション並列化と動的パーティション化」の説明

図8-1に示すように、この問合せのDOPは4ですが、実際は8つのPXサーバーが関係しています。これは、プロデューサ演算子とコンシューマ演算子が同時に実行できるためです(インター・オペレーション並列化)。

また、スキャン操作に関係するすべてのPXサーバーが、SORT操作を実行する適切なPXサーバーに行を送信します。PXサーバーでスキャンされる行のlast_name列の値がAからGの場合、その行は最初のORDER BYパラレル実行サーバーに送信されます。スキャン操作が完了すると、ソート・プロセスはソート結果を問合せコーディネータに返し、コーディネータが完全な問合せ結果をユーザーに返します。

8.1.4.3 並列処理のグラニュル

並列処理の基本作業ユニットはグラニュルと呼ばれます。

Oracle Databaseによって、表のスキャンや索引の作成などのパラレル化対象の操作がグラニュル単位に分割されます。パラレル実行(PX)サーバーは操作を1回に1グラニュルずつ実行します。グラニュルの数とサイズは並列度(DOP)と相関関係があります。グラニュルの数は、PXサーバー間で処理を適切に均衡できるかどうかにも影響します。

8.1.4.3.1 ブロック・レンジ・グラニュル

ブロック・レンジ・グラニュルは、ほとんどのパラレル操作の基本ユニットです。パーティション表の場合でも同様です。Oracle Databaseの観点では、並列度はパーティション数に関係しません。

ブロック・レンジ・グラニュルは、表の物理ブロックのレンジです。グラニュルの数とサイズは、関連するすべてのパラレル実行(PX)サーバーで処理の配分を最適化して均衡させるように、実行時にOracle Databaseによって計算されます。グラニュルの数とサイズは、オブジェクトのサイズとDOPによって決まります。ブロック・レンジ・グラニュルは、表または索引の静的な事前割当てには影響を受けません。グラニュルの計算の際に、Oracle DatabaseはDOPを考慮に入れて、可能な場合には競合を避けるために、グラニュルをさまざまなデータ・ファイルから各PXサーバーに割り当てようとします。また、Oracle Databaseは、PXサーバーとディスクの物理的な近接性を利用するために、超並列処理(MPP)システム上のグラニュルのディスク・アフィニティを考慮します。

8.1.4.3.2 パーティション・グラニュル

パーティション・グラニュルが使用される場合、パラレル実行(PX)サーバーは、表または索引のパーティションまたはサブパーティション全体を処理します。

パーティション・グラニュルは表または索引の作成時の構造によって静的に決まるため、パーティション・グラニュルではブロック・グラニュルのように操作を柔軟にパラレル実行することはできません。使用可能な最大の並列度(DOP)はパーティション数です。このため、システムの使用率とPXサーバー間のロード・バランシングが制限されることがあります。

表または索引に対するパラレル・アクセスにパーティション・グラニュルが使用される場合は、比較的多数のパーティション(理想的にはDOPの3倍)を使用することをお薦めします。これによって、Oracle Databaseで複数のPXサーバーにわたり処理を効率よく均衡化できます。

パーティション・グラニュルは、パラレル索引レンジ・スキャン、2つの同一レベル・パーティション表の結合(問合せオプティマイザがパーティション・ワイズ結合を選択した場合)、およびパーティション・オブジェクトの複数パーティションを変更するパラレル操作の基本ユニットです。これらの操作には、パーティション索引のパラレル作成やパーティション表のパラレル作成も含まれます。

文の実行計画を調べることによって、どのタイプのグラニュルが使用されたかがわかります。表または索引アクセスの上の行PX BLOCK ITERATORは、ブロック・レンジ・グラニュルが使用されたことを示しています。次の例では、SALES表のTABLE FULL ACCESSのすぐ上の実行計画出力の7行目に示されています。

-------------------------------------------------------------------------------------------------
|Id|      Operation          |  Name  |Rows|Bytes|Cost%CPU|  Time  |Pst|Pst|  TQ |INOUT|PQDistri|
-------------------------------------------------------------------------------------------------
| 0|SELECT STATEMENT         |        |  17| 153 |565(100)|00:00:07|   |   |     |     |        |
| 1| PX COORDINATOR          |        |    |     |        |        |   |   |     |     |        |
| 2|  PX SEND QC(RANDOM)     |:TQ10001|  17| 153 |565(100)|00:00:07|   |   |Q1,01|P->S |QC(RAND)|
| 3|   HASH GROUP BY         |        |  17| 153 |565(100)|00:00:07|   |   |Q1,01|PCWP |        |
| 4|    PX RECEIVE           |        |  17| 153 |565(100)|00:00:07|   |   |Q1,01|PCWP |        |
| 5|     PX SEND HASH        |:TQ10000|  17| 153 |565(100)|00:00:07|   |   |Q1,00|P->P | HASH   |
| 6|      HASH GROUP BY      |        |  17| 153 |565(100)|00:00:07|   |   |Q1,00|PCWP |        |
| 7|       PX BLOCK ITERATOR |        | 10M| 85M | 60(97) |00:00:01| 1 | 16|Q1,00|PCWC |        |
|*8|        TABLE ACCESS FULL|  SALES | 10M| 85M | 60(97) |00:00:01| 1 | 16|Q1,00|PCWP |        |
-------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------
8 - filter("CUST_ID"<=22810 AND "CUST_ID">=22300)

パーティション・グラニュルが使用された場合、実行計画出力の表または索引アクセスの上に行PX PARTITION RANGEが表示されます。次の例では、この文が表内の16個のパーティションすべてにアクセスするため、計画の6行目にPX PARTITION RANGE ALLと示されています。すべてのパーティションにアクセスするのでない場合は、単にPX PARTITION RANGEと表示されます。

---------------------------------------------------------------------------------------------------------
|Id|      Operation                    |  Name    |Rows|Byte|Cost%CPU|  Time  |Ps|Ps|  TQ |INOU|PQDistri|
---------------------------------------------------------------------------------------------------------
| 0|SELECT STATEMENT                   |          |  17| 153|   2(50)|00:00:01|  |  |     |    |        |
| 1| PX COORDINATOR                    |          |    |    |        |        |  |  |     |    |        |
| 2|  PX SEND QC(RANDOM)               |:TQ10001  |  17| 153|   2(50)|00:00:01|  |  |Q1,01|P->S|QC(RAND)|
| 3|   HASH GROUP BY                   |          |  17| 153|   2(50)|00:00:01|  |  |Q1,01|PCWP|        |
| 4|    PX RECEIVE                     |          |  26| 234|    1(0)|00:00:01|  |  |Q1,01|PCWP|        |
| 5|     PX SEND HASH                  |:TQ10000  |  26| 234|    1(0)|00:00:01|  |  |Q1,00|P->P| HASH   |
| 6|      PX PARTITION RANGE ALL       |          |  26| 234|    1(0)|00:00:01|  |  |Q1,00|PCWP|        |
| 7|       TABLEACCESSLOCAL INDEX ROWID|SALES     |  26| 234|    1(0)|00:00:01| 1|16|Q1,00|PCWC|        |
|*8|        INDEX RANGE SCAN           |SALES_CUST|  26|    |    1(0)|00:00:01| 1|16|Q1,00|PCWP|        |
---------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------
8 - access("CUST_ID"<=22810 AND "CUST_ID">=22300)

8.1.4.4 プロデューサとコンシューマの間の配分方法

配分方法とは、一方のパラレル実行(PX)サーバー・セットから他方へデータが送信(または再配分)される方法です。

次に、パラレル実行で最も一般的に使用される配分方法を示します。

ハッシュ配分

ハッシュ配分方法では、行内の1つ以上の列でハッシュ関数が使用され、それによってその後、プロデューサがその行を送信するコンシューマが決定されます。この配分では、ハッシュ値に基づいて複数コンシューマ間で等しく処理が分割されるよう試みられます。
ブロードキャスト配分

ブロードキャスト配分方法では、各プロデューサがすべての行をすべてのコンシューマに送信します。この方法は、ジョイン演算の左側の結果セットが小さく、すべての行をブロードキャストするコストが高くない場合に使用されます。この場合は、ジョインの右側の結果セットを配分する必要はありません。ジョイン演算に割り当てられたコンシューマPXサーバーで、右側のスキャンおよびジョインの実行が可能です。
レンジ配分

レンジ配分は、主にパラレル・ソート操作で使用されます。この方法では、各プロデューサが、ある範囲の値を含む行を同じコンシューマに送信します。これは、図8-1で使用されている方法です。
ハイブリッド・ハッシュ配分

ハイブリッド・ハッシュは、ジョイン演算で使用される適応配分方法です。実際の配分方法は、オプティマイザによって、実行時にジョインの左側の結果セットのサイズに応じて決定されます。左側から返される行の数はカウントされ、しきい値と照合されます。行の数がしきい値以下の場合は、ジョインの左側に対してブロードキャスト配分が使用されます。また、ジョイン演算に割り当てられた同じコンシューマPXサーバーが右側をスキャンしジョインを実行するため、右側は配分されません。左側から返された行の数がしきい値より大きい場合は、ジョインの両側にハッシュ配分が使用されます。

配分方法を決定するには、パラレル実行(PX)コーディネータでSQL文の実行計画内の各操作を検証してから、その操作によって影響を受ける行をPXサーバー間で再配分する方法を決定します。パラレル問合せの例として、例8-1の問合せを想定します。図8-2では、例8-1の問合せのデータ・フローおよび問合せ計画を示し、例8-2では、同じ問合せについて実行計画出力を示します。

問合せ計画には、PXコーディネータによって適応配分方法が選択されたことが示されています。実行時にオプティマイザでハッシュ配分が選択されるとすると、実行は次のように進行します。SS1およびSS2という、PXサーバーの2つのセットが問合せのために割り当てられ、文のDOPを指定するPARALLELヒントにより、各サーバー・セットに4つのPXサーバーがあります。

PXセットSS1は、最初に表customersをスキャンし、行をSS2に送信します。それにより、それらの行に対してハッシュ表が作成されます。つまり、SS2のコンシューマとSS1のプロデューサは同時に働きます。一方はcustomersをパラレルでスキャンし、もう一方は行を受け取って、パラレルでハッシュ結合を実行できるようにハッシュ表を構築します。インター・オペレーション並列処理の例を次に示します。

SS1内のPXサーバー・プロセスでcustomers表の行がスキャンされた後、SS2内のどのPXサーバー・プロセスにそれが送信されるでしょうか。この例では、customersのパラレル・スキャンを実行するSS1から、パラレル・ハッシュ結合を実行するSS2に送られる行の再配分は、結合列に対するハッシュ配分によって行われます。つまり、customersをスキャンしているPXサーバー・プロセスが、列customers.cust_idの値でハッシュ関数を計算して、送り先となるSS2内のPXサーバー・プロセスを決定します。使用される再配分方法は、問合せのEXPLAIN PLANのDistrib列に明示的に示されます。図8-2では、これはEXPLAIN PLANの5、9および14行目に示されています。

SS1はcustomers表全体のスキャンを終了すると、sales表をパラレルでスキャンします。その行をSS2内のPXサーバーに送り、それがその後プローブを実行してハッシュ結合をパラレルで完了します。これらのPXサーバーは、結合後にGROUP BY操作も実行します。SS1は、パラレルでsales表をスキャンし、行をSS2に送信すると、パラレルでの最後のgroup by操作の実行に切り替わります。この時点で、SS2内のPXサーバーは、group by操作のために、ハッシュ配分を使用してそれらの行をSS1内のPXサーバーに送信します。これは、2つのサーバー・セットを同時に実行して、問合せツリーの様々な演算子に対してインター・オペレーション並列化を実現する方法です。

図8-2 表結合のためのデータ・フロー図

「図8-2 表結合のためのデータ・フロー図」の説明

例8-1 CustomersおよびSalesに対する問合せの実行計画の実行

EXPLAIN PLAN FOR
SELECT /*+ PARALLEL(4) */ customers.cust_first_name, customers.cust_last_name, 
  MAX(QUANTITY_SOLD), AVG(QUANTITY_SOLD)
  FROM sales, customers
  WHERE sales.cust_id=customers.cust_id
  GROUP BY customers.cust_first_name, customers.cust_last_name;

Explained.

例8-2 CustomersおよびSalesに対する問合せの実行計画出力

PLAN_TABLE_OUTPUT
---------------------------------------------------------------------------------------------------------------------------------------
Plan hash value: 3260900439
---------------------------------------------------------------------------------------------------------------------------------------
|Id  |Operation                      |Name     |Rows  | Bytes |TempSpc|Cost (%CPU)| Time     |Pstart|Pstop |   TQ  |IN-OUT|PQ Distrib |
---------------------------------------------------------------------------------------------------------------------------------------
|  0 |SELECT STATEMENT               |         |  960 | 26880 |       |    6  (34)| 00:00:01 |      |      |       |      |           |
|  1 | PX COORDINATOR                |         |      |       |       |           |          |      |      |       |      |           |
|  2 |  PX SEND QC (RANDOM)          |:TQ10003 |  960 | 26880 |       |    6  (34)| 00:00:01 |      |      | Q1,03 | P->S |QC (RAND)  |
|  3 |   HASH GROUP BY               |         |  960 | 26880 | 50000 |    6  (34)| 00:00:01 |      |      | Q1,03 | PCWP |           |
|  4 |    PX RECEIVE                 |         |  960 | 26880 |       |    6  (34)| 00:00:01 |      |      | Q1,03 | PCWP |           |
|  5 |     PX SEND HASH              |:TQ10002 |  960 | 26880 |       |    6  (34)| 00:00:01 |      |      | Q1,02 | P->P |HASH       |
|  6 |      HASH GROUP BY            |         |  960 | 26880 | 50000 |    6  (34)| 00:00:01 |      |      | Q1,02 | PCWP |           |
|* 7 |       HASH JOIN               |         |  960 | 26880 |       |    5  (20)| 00:00:01 |      |      | Q1,02 | PCWP |           |
|  8 |        PX RECEIVE             |         |  630 | 12600 |       |    2   (0)| 00:00:01 |      |      | Q1,02 | PCWP |           |
|  9 |         PX SEND HYBRID HASH   |:TQ10000 |  630 | 12600 |       |    2   (0)| 00:00:01 |      |      | Q1,00 | P->P |HYBRID HASH|
| 10 |          STATISTICS COLLECTOR |         |      |       |       |           |          |      |      | Q1,00 | PCWC |           |
| 11 |           PX BLOCK ITERATOR   |         |  630 | 12600 |       |    2   (0)| 00:00:01 |      |      | Q1,00 | PCWC |           |
| 12 |            TABLE ACCESS FULL  |CUSTOMERS|  630 | 12600 |       |    2   (0)| 00:00:01 |      |      | Q1,00 | PCWP |           |
| 13 |        PX RECEIVE             |         |  960 |  7680 |       |    2   (0)| 00:00:01 |      |      | Q1,02 | PCWP |           |
| 14 |         PX SEND HYBRID HASH   |:TQ10001 |  960 |  7680 |       |    2   (0)| 00:00:01 |      |      | Q1,01 | P->P |HYBRID HASH|
| 15 |          PX BLOCK ITERATOR    |         |  960 |  7680 |       |    2   (0)| 00:00:01 |    1 |   16 | Q1,01 | PCWC |           |
| 16 |           TABLE ACCESS FULL   |SALES    |  960 |  7680 |       |    2   (0)| 00:00:01 |    1 |   16 | Q1,01 | PCWP |           |
---------------------------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
7 - access("SALES"."CUST_ID"="CUSTOMERS"."CUST_ID")
Note
-----
   - Degree of Parallelism is 4 because of hint

8.1.4.5 パラレル実行サーバーの通信方法

問合せをパラレルで実行するために、通常、Oracle Databaseはプロデューサ・パラレル実行サーバー・セットとコンシューマ・パラレル実行サーバー・セットを作成します。

プロデューサ・サーバーは表から行を取得し、コンシューマ・サーバーはそれらの行に対して結合、ソート、DML、DDLなどの操作を実行します。プロデューサ・セットの各サーバーは、コンシューマ・セットの各サーバーに接続しています。パラレル実行サーバー間の仮想接続数は並列度の2乗で増加します。

各通信チャネルには、少なくとも1つ、最大で4つのメモリー・バッファがあり、共有プールから割り当てられます。複数のメモリー・バッファを使用すると、パラレル実行サーバー間の非同期通信が促進されます。

シングル・インスタンス環境では、各通信チャネルで最大3つのバッファを使用します。Oracle Real Application Clusters環境では、各チャネルで最大4つのバッファを使用します。図8-3は、メッセージ・バッファと、プロデューサ・パラレル実行サーバーがコンシューマ・パラレル実行サーバーにどのように接続するかを示します。

図8-3 パラレル実行サーバーの接続とバッファ

「図8-3 パラレル実行サーバーの接続とバッファ」の説明

同一インスタンスで2つのプロセス間に接続が存在するとき、サーバーはメモリー内で(共有プールで)バッファを受け渡すことにより通信を行います。異なるインスタンスのプロセス間に接続が存在するとき、メッセージはインターコネクトを介して外部の高速ネットワーク・プロトコルを使用して送信されます。図8-3では、DOPはパラレル実行サーバーの数と同じです(この場合はn)。図8-3にはパラレル実行コーディネータは示されていません。実際には各パラレル実行サーバーはパラレル実行コーディネータとも接続しています。パラレル実行を使用する際は、共有プールのサイズを適切に設定することが重要です。共有プールに、パラレル・サーバーに必要なメモリー・バッファを割り当てるための十分な空き領域がない場合、開始することができません。

8.1.5 パラレル実行サーバーのプール

インスタンスが起動すると、Oracle Databaseによって、パラレル操作に使用可能なパラレル実行サーバーのプールが作成されます。

初期化パラメータPARALLEL_MIN_SERVERSによって、Oracle Databaseがインスタンス起動時に作成するパラレル実行サーバーの数が指定されます。

パラレル操作を実行するとき、パラレル実行コーディネータは、パラレル実行サーバーをプールから獲得して操作に割り当てます。必要であれば、Oracle Databaseは操作のためにパラレル実行サーバーを追加作成することもできます。これらのパラレル実行サーバーは、実行の間は操作とともにあります。文が処理されると、パラレル実行サーバーはプールに戻ります。

パラレル操作の数が増えると、着信リクエストを扱うためにOracle Databaseによって追加のパラレル実行サーバーが作成されます。ただし、初期化パラメータPARALLEL_MAX_SERVERSで指定された値を超えるパラレル実行サーバーが、1つのインスタンスに対して作成されることはありません。

パラレル操作の数が減ると、一定期間アイドル状態になっていたパラレル実行サーバーがOracle Databaseによって停止されます。パラレル実行サーバーのアイドル状態が長く続いても、プールのサイズがPARALLEL_MIN_SERVERSの値よりも小さくなることはありません。

8.1.5.1 十分なパラレル実行サーバーなしでの処理

Oracle Databaseでは、リクエストよりも少ないプロセス数でパラレル操作を処理することができます。

プールのすべてのパラレル実行サーバーが占有され、最大数のパラレル実行サーバーが起動されている場合、パラレル実行コーディネータはシリアル処理に切り替えます。

関連項目:

PARALLEL_MIN_PERCENTおよびPARALLEL_MAX_SERVERSの詳細は、「パラレル実行のための一般的なパラメータのチューニング」を参照してください
初期化パラメータPARALLEL_MIN_PERCENTの使用の詳細は、『Oracle Databaseリファレンス』を参照してください

8.1.6 パフォーマンスを最適化するためのワークロードのバランシング

パフォーマンスを最適化するには、すべてのパラレル実行サーバーのワークロードを均等にする必要があります。

ブロック・レンジまたはパラレル実行サーバーによってパラレルで実行されるSQL文では、ワークロードはパラレル実行サーバー間で動的に分割されます。この方法では、一部のパラレル実行サーバーで実行する作業が他のプロセスよりも大幅に多くなる、ワークロードの偏りが最小限に抑えられます。

パーティション単位でパラレル実行される比較的少数のSQL文では、ワークロードがパーティションで均等に分散されていれば、パラレル実行サーバーの数とパーティションの数を一致させるか、パーティション数がプロセス数の倍数になるようにDOPを選択することで、パフォーマンスを最適化できます。これは、Oracle9iよりも前に作成された表に対するパーティション・ワイズ結合とパラレルDMLに適用されます。詳細は、「並列度の制限」を参照してください。

たとえば、表に16個のパーティションがあり、パラレル操作の処理がそれらのパーティション間で均等に分割されるとします。16個のパラレル実行サーバー(DOPが16)を使用すると、1プロセスの場合のおよそ10分の1の時間で作業を行うことができます。また、5プロセスを使用すると5分の1の時間、2プロセスを使用すると2分の1の時間になります。

ただし、16個のパーティションで作業を行うために15個のプロセスを使用した場合は、1つのパーティションの作業を最初に終了したプロセスが16番目のパーティションの作業を開始し、それ以外のプロセスは作業を終了してアイドルになります。この構成では、作業をパーティション間で均等に分割しても、優れたパフォーマンスは得られません。作業の分割が不均等な場合、最後に残ったパーティションの作業が他のパーティションに比べて多いか少ないかによってパフォーマンスが変わります。

同様に、6個のプロセスを使用して16個のパーティションを処理し、作業を均等に分割するとします。この場合、各プロセスは最初のパーティションを終了してから2番目のパーティションを処理しますが、3番目のパーティションを処理するのは4つのプロセスのみで、残りの2つはアイドルになります。

一般的に、P個のパラレル実行サーバーを使用したN個のパーティションに対するパラレル操作の実行時間がN/Pになると想定することはできません。この計算式は、最後のパーティションを処理する間に待機する必要のあるプロセスが存在する可能性を考慮に入れていません。ただし、適切なDOPを選択すると、ワークロードの偏りを最小にしてパフォーマンスを最適化することができます。

8.1.7 複数のパラレライザ

実行計画内の各パラレル実行(PX)コーディネータは、パラレライザと呼ばれます。

SQL文によって使用されるPXサーバーの数は、文の並列度(DOP)、およびパラレライザの数によって決定されます。1つのパラレライザのためのPXサーバー・セットの数は2つまでに制限されているため、ほとんどの文のPXサーバーの数はDOP*2となります。一部の文では、複数のパラレライザを使用できます。各パラレライザで2つのPXサーバー・セットを使用できるため、これらの文のためのPXサーバーの数はDOP*2より多くできます。EXPLAIN PLANを調べることで、これらの文を識別できます。計画に複数のPXコーディネータがある場合は、文に複数のパラレライザがあることを意味します。

SQL文で複数のパラレライザが使用される数少ない例としては、副問合せファクタ、グルーピング・セット、スター・クエリー、インメモリー集計、および無相関な副問合せがあります。

1つのSQL文の複数のパラレライザは、同時に、または実行計画に従って順々にアクティブにできます。

パラレライザが1つある文は、必要な数のPXサーバーを実行の開始時に割り当て、これらの割り当てられたPXサーバーを、文の完了まで解放することなく保持します。これにより、実行の間のPXサーバーの数が必ず一定になります。パラレライザが複数ある文は、各パラレライザの開始時にPXサーバーを割り当てるため異なります。パラレライザは実行中の様々な時点で開始できるため、システム内の使用可能プロセスの数に基づいて異なる数のPXサーバーを使用して各パラレライザを実行できます。

複数のパラレライザが同時に実行される場合は、文でDOP*2より多くのPXサーバーを使用できます。

ビューV$PQ_SESSTATでは、STATISTIC列にパラレライザの数が示されます。データ・フロー操作統計DFO Treesには、パラレライザの数が示されます。Server Threads統計には、1つのSQL文のために同時に使用されたPXサーバーの最大数が示されます。

関連項目:

V$PQ_SESSTATおよびその他の動的ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

8.1.8 Oracle RACでのパラレル実行

デフォルトでは、Oracle RAC環境で、パラレルで実行されるSQL文はクラスタ内のすべてのノードで実行できます。

このクロスノードまたはノード間パラレル実行を実現するには、ノード間パラレル実行によってインターコネクト・トラフィックが増大する可能性があるため、Oracle RAC環境でのインターコネクトのサイズが適切である必要があります。ノード間パラレル実行は、インターコネクトのサイズが小さいと対応できません。

使用可能なインスタンス数の制限

Oracle RAC環境では、サービスを使用して、パラレルSQL文の実行に参加するインスタンスの数を制限できます。デフォルトのサービスには使用可能なすべてのインスタンスが含まれます。それぞれが1つ以上のインスタンスを含むサービスを必要な数のみ作成できます。ユーザーがサービスを使用してデータベースに接続する場合は、そのサービスのメンバーであるインスタンス上のPXサーバーのみがパラレル文の実行に参加できます。

パラレル実行を単一ノードに限定するには、PARALLEL_FORCE_LOCAL初期化パラメータをTRUEに設定します。この場合は、セッションが接続するインスタンス上のPXサーバーのみが、そのセッションからのパラレル文の実行に使用されます。このパラメータがTRUEに設定されている場合は、セッションがインスタンスに直接接続するかサービスを使用して接続するかに関係なく、そのインスタンス上で実行されているすべてのパラレル文がローカルで実行されることに注意してください。

フレックス・クラスタでのパラレル実行

フレックス・クラスタ上で実行されるパラレル文は、ハブおよびリーフ・ノードの両方で使用できます。ユーザー・セッションではハブ・ノードへの接続のみが許可されているため、コーディネータ・プロセス(問合せコーディネータまたはPXコーディネータ)はハブ・ノード上に存在し、クラスタ内の任意のノードからPXサーバー・プロセスを使用できます。パラレル問合せでは、任意のノード上の任意のPXサーバーが文の実行に参加できます。パラレルDML操作では、ハブ・ノードのみがDML操作の実行を許可されているため、ハブ・ノード上のPXサーバーのみが文のDML部分の実行に参加できます。

DML操作のためにリーフ・ノードからハブ・ノードへのデータ配分が存在する場合は、実行計画がこの配分を示します。次の例では、行Id 3にあるロード操作がハブ・ノード上でのみ実行されることを示し、行Id 5でデータがハブ・ノードに配分されます。

--------------------------------------------------------
| Id  | Operation                          | Name      |
--------------------------------------------------------
|   0 | CREATE TABLE STATEMENT             |           |
|   1 |  PX COORDINATOR                    |           |
|   2 |   PX SEND QC (RANDOM)              | :TQ10001  |
|   3 |    LOAD AS SELECT (HYBRID TSM/HWMB)| SALESTEMP |
|   4 |     PX RECEIVE                     |           |
|   5 |      PX SEND ROUND-ROBIN (HUB)     | :TQ10000  |
|   6 |       PX BLOCK ITERATOR            |           |
|   7 |        TABLE ACCESS FULL           | SALES     |
--------------------------------------------------------

関連項目:

ハブ、リーフおよびフレックス・クラスタ・アーキテクチャの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください
Grid Infrastructureのクラスタ・インストール・オプションの詳細は、『Oracle Grid Infrastructureインストレーションおよびアップグレード・ガイドfor Linux』を参照してください
インスタンス・グループの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください