8 パラレル実行の使用

パラレル実行とは、複数のプロセスの使用により、複数のCPUリソースおよびI/Oリソースを単一SQL文の実行に適用する機能です。

この章では、パラレル実行がどのように機能するかと、Oracle Databaseでのパラレル実行の制御、管理および監視の方法を説明します。

この章の構成は、次のとおりです。

関連項目:

Oracle Databaseでのパラレル実行の詳細は、http://www.oracle.com/technetwork/database/database-technologies/parallel-execution/overview/index.htmlを参照してください

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文では、解析の際に最適化およびパラレル化のプロセスが行われます。

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

  1. ユーザー・セッションまたはシャドウ・プロセスが、コーディネータの役割を引き受けます。これは、問合せコーディネータ(QC)またはパラレル実行(PX)コーディネータと呼ばれることもあります。QCは、パラレルSQL文を開始するセッションです。

  2. PXコーディネータは、パラレル実行(PX)サーバーというプロセスを必要な数だけ取得します。PXサーバーは、セッションを開始するかわりにパラレルで処理を実行する個々のプロセスです。

  3. SQL文は、全表スキャンまたはORDER BY句などの、一連の操作として実行されます。各操作は、可能な場合はパラレルで実行されます。

  4. PXサーバーで文の実行が完了すると、PXコーディネータで、パラレルで実行できない処理の部分が実行されます。たとえば、SUM()演算を含むパラレル問合せでは、各PXサーバーで計算された小計それぞれを合計する必要があります。

  5. 最後に、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 インター・オペレーション並列化と動的パーティション化」の説明

図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-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の説明が続きます
「図8-3 パラレル実行サーバーの接続とバッファ」の説明

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

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

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

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

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

ノート:

パラレル化を使用する個々の文が終了する前に、パラレル処理を事前に解放できます。たとえば、コミットされていないパラレルDML操作または2つのパラレル・サーバー・セット(Producer-Consumer)を持つ、部分的にフェッチされたパラレルSELECT文は、作業が終了するとすぐにパラレル・サーバー・セットの1つをサーバー・プールに解放し、他の文で使用するためにパラレル処理の半分を解放します。V$PQ_SESSTATビューを使用すると、この方法で事前に解放されたサーバーの数を監視できます。

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

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

関連項目:

Oracle DatabaseリファレンスのV$PQ_SESSTAT。
8.1.5.1 十分なパラレル実行サーバーなしでの処理

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     |
--------------------------------------------------------

関連項目:

8.2 並列度の設定

並列度(DOP)は、単一の処理に対応付けられるパラレル実行サーバーの数で表されます。

パラレル実行は複数のCPUを効率よく使用するためのものです。Oracle Databaseのパラレル実行フレームワークでは、特定の並列度をユーザーが明示的に選択することも、Oracle Databaseによって自動的に並列度を制御することもできます。

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

8.2.1 手動での並列度の指定

表および索引に対して、Oracle Databaseで特定の並列度(DOP)をリクエストできます。

たとえば、次のように表レベルで固定DOPを設定できます。

ALTER TABLE sales PARALLEL 8;
ALTER TABLE customers PARALLEL 4;

この例では、sales表のみにアクセスする問合せはDOPである8をリクエストし、customers表にアクセスする問合せはDOPとして4をリクエストします。sales表とcustomers表の両方にアクセスする問合せは、DOPが8として処理され、16個のパラレル実行サーバーを割り当てる可能性があります(プロデューサ/コンシューマ・モデルのため)。Oracle Databaseでは、異なるDOPが指定されるときは必ず、高いほうのDOPが使用されます。

文レベルまたはオブジェクト・レベルのパラレル・ヒントを使用することで、特定のDOPをリクエストすることもできます。

表または索引のPARALLEL句で指定されたDOPは、PARALLEL_DEGREE_POLICYがMANUALまたはLIMITEDに設定されている場合のみ有効となります。

文の実際の実行時のDOPは、Oracle Database Resource Managerで制限できます。

関連項目:

8.2.2 デフォルトの並列度

PARALLEL句が指定されているが並列度(DOP)の指定がない場合、オブジェクトのDOPはデフォルトになります。

たとえば、次のSQL文により、表をデフォルトのDOPに設定できます。

ALTER TABLE sales PARALLEL;

デフォルトの並列処理では、次に示すように、計算式が使用され、システム構成に基づいてDOPが決定されます。

  • シングル・インスタンスの場合、DOP = PARALLEL_THREADS_PER_CPU x CPU_COUNT

  • Oracle RAC構成の場合、DOP = PARALLEL_THREADS_PER_CPU x sum(CPU_COUNT)

デフォルトでは、sum(CPU_COUNT)は、クラスタ内のCPUの合計数です。ただし、Oracle RACサービスを使用して1つのパラレル操作で実行可能なノードの数を制限している場合は、sum(CPU_COUNT)は、そのサービスに属するすべてのノードにわたるCPUの合計数になります。たとえば、ノード4つのOracle RACクラスタで、各ノードに8個のCPUコアがあり、Oracle RACサービスがない場合、デフォルトのDOPは2 x (8+8+8+8) = 64になります。

文レベルまたはオブジェクト・レベルのパラレル・ヒントを使用することで、デフォルトのDOPをリクエストすることもできます。

表または索引のPARALLEL句で指定されたデフォルトDOPは、PARALLEL_DEGREE_POLICYがMANUALに設定されている場合のみ有効となります。

デフォルトのDOPアルゴリズムは、最大限のリソースを使用するように設計されており、操作で使用できるリソースが多いほど、操作は速く終了すると想定しています。デフォルトDOPは、単一ユーザーのワークロードが対象となるため、複数ユーザーの環境ではお薦めできません。

SQL文の実際の実行時のDOPは、Oracle Database Resource Managerで制限できます。

関連項目:

8.2.3 自動並列度

自動並列度(自動DOP)により、Oracle Databaseで、文をパラレルで実行する必要があるかどうかと、使用する必要があるDOPを自動的に決定できます。

次に、自動DOPが有効になっている場合のパラレル文処理の概要を示します。

  1. SQL文が発行されます。

  2. 文が解析され、オプティマイザが実行計画を決定します。

  3. 初期化パラメータPARALLEL_MIN_TIME_THRESHOLDによって指定されたしきい値がチェックされます。

    1. 予想される実行時間がしきい値より短い場合は、SQL文はシリアルで実行されます。

    2. 予想される実行時間がしきい値より長い場合は、定義されたリソース制限の考慮を含むオプティマイザが計算するDOPに基づいて文はパラレルで実行されます。

8.2.4 自動DOPでの並列度の決定

自動並列度(DOP)の使用時は、オプティマイザは、文のリソース要件に基づいて文のDOPを自動的に決定します。

オプティマイザは、全表スキャンや索引の高速全スキャンなど、実行計画内のすべてのスキャン操作のコスト、およびすべての操作のCPU操作のコストを使用して、必要なDOPを決定します。

ただし、オプティマイザは、実際の最大DOPの上限を設定して、多数のパラレル実行サーバーによってシステムの障害が発生しないようにします。この上限値は、パラメータPARALLEL_DEGREE_LIMITで設定されます。このパラメータのデフォルト値はCPUです。これは、デフォルトDOPとも呼ばれ、DOPがシステム上のCPUの数(PARALLEL_THREADS_PER_CPU * sum(CPU_COUNT))によって制限されることを意味します。このデフォルトのDOPにより、1つのユーザー操作でシステムの障害が発生しないようにします。このパラメータの設定を調整することによって、オプティマイザがSQL文に対して選択できるDOPの最大値を制御できます。オプティマイザでは、DOPの制限にOracle Database Resource Managerが使用される場合に選択できる最大DOPを、さらに制限できます。

ノート:

PARALLEL_DEGREE_LIMITの値AUTOには、値CPUと同じ機能があります。

SQL文の処理のコストを計算するために、自動DOPでは、システムのハードウェア特性に関する情報が使用されます。ハードウェア特性にはI/Oキャリブレーション統計が含まれるため、これらの統計を収集する必要があります。

必要な統計を収集するようI/Oキャリブレーションが実行されていない場合、デフォルトのキャリブレーション値を使用して操作コストおよびDOPが計算されます。

I/Oキャリブレーション統計は、PL/SQL DBMS_RESOURCE_MANAGER.CALIBRATE_IOプロシージャを使用して収集できます。I/Oキャリブレーションは、ハードウェアの物理的な交換を行わないかぎり、1回のみの処理です。

オプティマイザによって決定されたDOPは、次の実行計画出力で示すように、実行計画出力のNoteセクションに示され、実行計画文またはV$SQL_PLANのどちらかを使用して表示できます。 

EXPLAIN PLAN FOR
SELECT SUM(AMOUNT_SOLD) FROM SH.SALES;

PLAN TABLE OUTPUT
Plan hash value: 1763145153

----------------------------------------------------------------------------------------------------------------------
|Id| Operation              | Name     | Rows | Bytes| Cost (%CPU)| Time     | Pstart| Pstop|    TQ |IN-OUT| PQ Distrib |
------------------------------------------------------------------------------------------------------------------------
| 0| SELECT STATEMENT       |          |     1|     4|     2   (0)| 00:00:01 |       |       |      |      |           |
| 1|  SORT AGGREGATE        |          |     1|     4|            |          |       |      |       |      |           |
| 2|   PX COORDINATOR       |          |      |      |            |          |       |      |       |      |           |
| 3|    PX SEND QC (RANDOM) | :TQ10000 |     1|     4|            |          |       |      |  Q1,00| P->S | QC (RAND) |
| 4|     SORT AGGREGATE     |          |     1|     4|            |          |       |      |  Q1,00| PCWP |           |
| 5|      PX BLOCK ITERATOR |          |   960|  3840|     2   (0)| 00:00:01 |     1 |    16|  Q1,00| PCWC |           |
| 6|       TABLE ACCESS FULL| SALES    |   960|  3840|     2   (0)| 00:00:01 |     1 |    16|  Q1,00| PCWP |           |
------------------------------------------------------------------------------------------------------------------------
Note
-----
   - automatic DOP: Computed Degree of Parallelism is 4

関連項目:

DBMS_RESOURCE_MANAGERパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください

8.2.5 自動並列度の制御

自動並列度(自動DOP)を制御する初期化パラメータがあります。これらの初期化パラメータには、PARALLEL_DEGREE_POLICY、PARALLEL_DEGREE_LIMIT、PARALLEL_MIN_TIME_THRESHOLD、PARALLEL_MIN_DEGREEなどがあります。

初期化パラメータPARALLEL_DEGREE_POLICYは、自動DOP、パラレル文のキューイング、およびインメモリー・パラレル実行を有効にするかどうかを制御します。このパラメータには、次の値を指定できます。

  • MANUAL

    この設定では、自動DOP、パラレル文のキューイング、およびインメモリー・パラレル実行が無効になります。パラレル実行の動作をOracle Database 11gリリース2 (11.2)よりも前の設定に戻します。これがデフォルトです。

    PARALLEL_DEGREE_POLICYのデフォルト設定MANUALの使用時は、DOPがオブジェクトに明示的に設定されている場合、またはパラレル・ヒントがSQL文に指定されている場合にかぎり、パラレル実行が使用されます。使用されるDOPは、指定されたとおりのものになります。パラレル文のキューイング、およびインメモリー・パラレル実行は起こりません。

  • LIMITED

    この設定では、一部の文については自動DOPが有効になりますが、パラレル文のキューイングおよびインメモリー・パラレル実行は無効になります。自動DOPは、明示的にDOPを指定することなく、PARALLEL句で明示的に宣言されている表または索引にアクセスする文に対してのみ適用されます。特定のDOPが指定された表および索引は、その明示的なDOP設定を使用します。

    Oracle Databaseでオブジェクトの特定のサブセットにアクセスするSQL文のサブセットに対してのみDOPを自動的に決定するようにする場合は、PARALLEL_DEGREE_POLICYをLIMITEDに設定し、明示的なDOPを指定せずに、そのオブジェクト・サブセットにパラレル・プロパティを設定します。

  • AUTO

    この設定では、すべての文について自動DOPが有効になり、パラレル文のキューイングおよびインメモリー・パラレル実行も有効になります。

    Oracle DatabaseですべてのSQL文のDOPを自動的に決定するようにする場合は、PARALLEL_DEGREE_POLICYをAUTOに設定します。

  • ADAPTIVE

    この設定では、AUTO値と同様に、自動DOP、パラレル文のキューイング、およびインメモリー・パラレル実行が有効になります。さらに、パフォーマンス・フィードバックを使用可能にします。

PARALLEL_DEGREE_LIMIT初期化パラメータは、システム全体にわたり自動DOPで使用できる、最大DOPを指定します。最大DOPの非常に細かい制御には、Oracle Database Resource Managerを使用できます。

PARALLEL_MIN_TIME_THRESHOLD初期化パラメータは、文を自動DOPの対象とするための最小推定実行時間を指定します。最初に、オプティマイザで、SQL文のシリアル実行計画が計算されます。推定された実行時間がPARALLEL_MIN_TIME_THRESHOLDの値より長い場合、その文は自動DOPの候補となります。

PARALLEL_MIN_ DEGREE初期化パラメータは、自動並列度によって計算された最小並列度を制御します。ただし、PARALLEL_MIN_DEGREEの値がCPU_COUNTの値より大きい場合、またはオブジェクトがOracle所有のもの(ディクショナリ表やディクショナリ表に対して作成されたビューなど)である場合、PARALLEL_MIN_DEGREEの影響はありません。

文レベルまたはオブジェクト・レベルの適切なSQLヒントを指定することで、自動DOPをリクエストすることもできます。

関連項目:

8.2.6 問合せ調整並列処理

マルチユーザー問合せ調整アルゴリズムでは、システムの負荷が増加すると並列度が低下します。

Oracle Databaseの問合せ調整並列処理を使用すると、データベースはSQL実行時にアルゴリズムを使用して、パラレル操作がリクエストどおりのDOPを受け取るか、低いDOPに下げてシステムのオーバーロードを回避するかを決定します。

高いDOPを使用してパラレル実行を積極的に利用するシステムでは、問合せ調整アルゴリズムによってDOPが下がるのは、ごく少数の操作がパラレルで実行する場合のみです。このアルゴリズムでは最適なリソース使用率が保証されますが、ユーザーによってレスポンス時間が一定しないことがあります。確定したレスポンス時間を必要とする環境では問合せ調整並列処理のみを使用することはお薦めしません。問合せ調整並列処理は、データベース初期化パラメータPARALLEL_ADAPTIVE_MULTI_USERを介して制御されます。

ノート:

初期化パラメータPARALLEL_ADAPTIVE_MULTI_USERは、Oracle Database 12cリリース2 (12.2.0.1)で非推奨となり、将来のリリースではサポートされなくなるため、かわりにパラレル文のキューイングを使用することをお薦めします。

8.3 インメモリー・パラレル実行

インメモリー機能には、パラレル実行のための技法が用意されています。

この項では、インメモリー・パラレル実行について説明します。

8.3.1 パラレル実行でのバッファ・キャッシュの使用

デフォルトでは、オブジェクトが非常に小さいかCACHEとして宣言されている場合を除き、パラレル実行ではスキャン済ブロックをキャッシュするためにSGA (バッファ・キャッシュ)は使用されません。

インメモリー・パラレル実行では、パラメータPARALLEL_DEGREE_POLICYをAUTOに設定することで有効になっている場合、パラレル文でSGAを使用してオブジェクト・ブロックをキャッシュできます。Oracle Databaseでは、パラレル実行を使用してアクセスされるオブジェクトにとって、SGAにキャッシュされることが有益かどうかが判断されます。オブジェクトをキャッシュするかどうかの決定は、サイズやアクセス頻度などの明確な経験則に基づいて行われます。Oracle Real Applications Cluster (Oracle RAC)環境では、Oracle Databaseにより、オブジェクトのピースがアクティブ・インスタンスの各バッファ・キャッシュにマップされます。このマッピングを作成することで、オブジェクトの様々な部分もしくはピースを見つけるためにアクセスするバッファ・キャッシュが自動的にわかります。この情報を使用すると、複数のインスタンスが、ディスクから同じ情報を何度も繰り返して読み取ることがなくなり、オブジェクトをキャッシュできるメモリー容量を最大化することができます。これは、ブロックがキャッシュされるインスタンス上でPXサーバーを使用することで実行されます。

オブジェクトのサイズが、バッファ・キャッシュ(単一インスタンス)の合計サイズに基づくか、バッファ・キャッシュのサイズにOracle RACクラスタ内のアクティブ・インスタンスの数を乗算した値に基づく、特定のしきい値より大きい場合、オブジェクトはダイレクト・パス読取りを使用して読み取られ、SGAにキャッシュされません。

8.3.2 自動ビッグ・テーブル・キャッシング

自動ビッグ・テーブル・キャッシングでは、問合せをバッファ・キャッシュと統合して、単一インスタンス環境とOracle RAC環境の両方で、Oracle Databaseのインメモリー問合せ機能を拡張します。

Oracle Real Application Clusters (Oracle RAC)環境では、この機能はパラレル問合せでのみサポートされます。単一インスタンス環境では、この機能はパラレル問合せとシリアル問合せの両方でサポートされます。

大きな表のキャッシュに予約されているキャッシュ・セクションが、表スキャンのためのデータのキャッシュに使用されます。大きな表のキャッシュは主としてデータ・ウェアハウスのワークロードのパフォーマンスを高めるために設計されていますが、混在するワークロードを実行するOracle Databaseのパフォーマンスも向上します。

自動ビッグ表キャッシュでは、温度およびオブジェクト・ベースのアルゴリズムを使用して中間表およびビッグ表を追跡します。Oracleではかなり小規模の表をキャッシュしますが、自動ビッグ表キャッシュではこれらの表は追跡されません。

シリアル問合せで自動ビッグ・テーブル・キャッシングを有効化するには、DB_BIG_TABLE_CACHE_PERCENT_TARGET初期化パラメータの値(パーセント)を設定する必要があります。さらに、パラレル問合せで自動ビッグ・テーブル・キャッシングの使用を有効化するには、PARALLEL_DEGREE_POLICY初期化パラメータをAUTOまたはADAPTIVEに設定する必要があります。Oracle RAC環境では、自動ビッグ・テーブル・キャッシングはパラレル問合せでのみサポートされるため、両方の設定が必要です。

大きい表のサイズがほぼ、すべてのインスタンスの大きい表のキャッシュを合計したサイズである場合、すべてのインスタンスで、表はパーティション化されてキャッシュされます(または大部分がキャッシュされます)。インメモリー問合せで表の問合せのほとんどのディスク読取りが排除されるか、データベースで大きい表のキャッシュに入らない表の部分についてのみディスク読取りが行われます。大きい表のキャッシュでスキャン対象のすべての表をキャッシュできない場合、最も頻繁にアクセスされる表のみがキャッシュされ、残りは直接読取りで自動的に読み取られます。

DB_BIG_TABLE_CACHE_PERCENT_TARGETパラメータは、スキャンに使用するバッファ・キャッシュ・サイズのパーセントを決定します。DB_BIG_TABLE_CACHE_PERCENT_TARGETを80 (%)に設定した場合、バッファ・キャッシュの80 (%)がスキャンに使用され、残りの20 (%)がOLTPワークロードに使用されます。

PARALLEL_DEGREE_POLICYがAUTOまたはADAPTIVEに設定されている場合、DB_BIG_TABLE_CACHE_PERCENT_TARGETパラメータはOracle RAC環境でのみ有効化されます。DB_BIG_TABLE_CACHE_PERCENT_TARGETのデフォルトは0 (無効)で、上限は90 (%)で、少なくとも10%のバッファ・キャッシュを表スキャン以外の使用のために予約しています。値が0の場合、インメモリー問合せは既存のLeast Recently Used (LRU)メカニズムで実行されます。DB_BIG_TABLE_CACHE_PERCENT_TARGETパラメータは動的に調整できます。

DB_BIG_TABLE_CACHE_PERCENT_TARGETパラメータの設定時には、次のガイドラインを使用してください。

  • Oracle RAC環境で自動並列度(DOP)を有効にしない場合は、このパラメータを設定しないでください。このような場合、大きい表のキャッシュ・セクションは使用されないためです。

  • このパラメータを設定する際は、ワークロードの混在を検討する必要があります(OLTPにどれだけのワークロードを要するか; 挿入、更新、ランダム・アクセス; 表スキャンにどれだけのワークロードを要するか)。データ・ウェアハウスのワークロードではしばしば、大きい表のスキャンが実行されるため、大きい表のキャッシュ・セクションに、データ・ウェアハウス用に大きい割合のバッファ・キャッシュ領域を付与することを検討できます。

  • このパラメータは、ワークロードが変わると、動的に変わる可能性があります。その時にバッファ・キャッシュ・メモリーがアクティブに使用されている可能性があるため、目標を達成する現在のワークロードによっては、変更に多少時間がかかることがあります。

PARALLEL_DEGREE_POLICYがAUTOまたはADAPTIVEに設定されている場合、データ・ウェアハウスのロードおよびスキャン・バッファのオブジェクトレベルの統計が追加され、特定(ヘルパー)インスタンスのオブジェクトのパラレル(PQ)スキャン数が示されます。

V$BT_SCAN_CACHEおよびV$BT_SCAN_OBJ_TEMPSビューには、大きい表のキャッシュに関する情報が表示されます。

関連項目:

8.4 パラレル文のキューイング

状況によっては、パラレル文はリソースの待機中にキューに入れられます。

パラメータPARALLEL_DEGREE_POLICYをAUTOに設定すると、必要な数のパラレル実行サーバー・プロセスが使用可能でない場合、パラレル実行を必要とするSQL文はキューに入ります。必要なリソースが使用可能になると、SQL文はデキューされ、実行が許可されます。デフォルトのデキュー順序は、文が発行された時刻に基づく単純な先入先出キューです。

次に、パラレル文処理のサマリーを示します。

  1. SQL文が発行されます。

  2. 文が解析され、DOPが自動的に決定されます。

  3. 使用可能なパラレル・リソースがチェックされます。

    1. 十分なパラレル実行サーバーが使用でき、キューにリソース待ちの文がない場合は、そのSQL文が実行されます。

    2. 十分なパラレル実行サーバーが使用できない場合、SQL文は指定された条件に基づいてキューに入れられ、指定された条件が満たされたときにキューの先頭からデキューされます。

文を実行するとアクティブなパラレル・サーバーの数が初期化パラメータPARALLEL_SERVERS_TARGETの値を超える場合、そのパラレル文はキューに入れられます。たとえば、PARALLEL_SERVERS_TARGETが64に設定されており、現在アクティブなサーバーの数が60で、新しいパラレル文が16のパラレル・サーバーを必要とする場合、60に16を加えるとPARALLEL_SERVERS_TARGETの値である64より大きくなるため、そのパラレル文はキューに入れられます。

これはシステムで使用可能なパラレル・サーバー・プロセスの最大数ではなく、パラレル文のキューイングが使用されるまでにパラレル文の実行に使用できるパラレル・サーバー・プロセスの数です。各パラレル文に必要なパラレル・サーバー・プロセスをすべて確保するとともに、パラレル・サーバー・プロセスによるシステムのオーバーロードを回避するため、システムで許容されるパラレル・サーバー・プロセスの最大数(PARALLEL_MAX_SERVERS)未満に設定されます。ただし、文のキューイングがアクティブになっている場合でも、すべてのシリアル(非パラレル)文はただちに実行されます。

文がキューに入っているかどうかを確認するには、resmgr:pq queued待機イベントを使用します。

この項の内容は次のとおりです。

関連項目:

8.4.1 Oracle Database Resource Managerによるパラレル文のキューイングの管理について

デフォルトでは、パラレル文のキューは先入先出キューとして動作しますが、リソース・プランを使用して、デフォルトの動作を変更できます。

ノート:

マルチテナント・コンテナ・データベースは、Oracle Database 21cにおいてサポートされている唯一のアーキテクチャです。ドキュメントの改訂中は、従来の用語が残っている可能性があります。ほとんどの場合、「データベース」と「非CDB」は、コンテキストに応じて、CDBまたはPDBを意味します。アップグレードなど、一部のコンテキストでは、「非CDB」は以前のリリースの非CDBを意味します。

リソース・プランを構成および設定して、パラレル文をデキューする順序と、各ワークロードまたはコンシューマ・グループが使用するパラレル実行サーバーの数を管理できます。

Oracle Database Resource Managerは、コンシューマ・グループおよびリソース・プランの概念に基づいて動作します。コンシューマ・グループは、同じリソース権限および要件を使用したユーザーのグループを識別します。リソース・プランは、各コンシューマ・グループに対するディレクティブのコレクションから構成され、パラレル・サーバーなどの各種データベース・リソースの管理と割当てを指定します。マルチテナント・コンテナ・データベース(CDB)およびプラガブル・データベース(PDB)では、パラレル文キューの順序はsharesと呼ばれるディレクティブによって管理されます。

リソース・プランは、RESOURCE_MANAGER_PLANパラメータをリソース・プランの名前に設定すると有効になります。

並列度ポリシーがAUTOに設定されている場合、次の項で説明するディレクティブを使用して、コンシューマ・グループのパラレル文の処理を管理できます。

どのような場合でも、指定されたコンシューマ・グループのパラレル文のキューはOracle RACデータベース上の単一キューとして管理されます。各コンシューマ・グループに対する制限は、そのコンシューマ・グループに属するOracle RACデータベースのすべてのセッションに適用されます。パラレル文のキューイングは、データベース・インスタンス全体での初期化パラメータPARALLEL_SERVERS_TARGETの合計値に基づいて発生します。

マルチテナント・コンテナ・データベース(CDB)およびプラガブル・データベース(PDB)のパラレル文のキューイングも管理できます。

関連項目:

8.4.1.1 パラレル文キューの順序の管理について

Oracle Database Resource Managerを使用して、複数のコンシューマ・グループ間のパラレル文のキューからパラレル文をデキューする優先順位を管理できます。

特定のコンシューマ・グループのパラレル文は、デフォルトで先入先出の順序でデキューされます。ディレクティブsharesを使用すると、コンシューマ・グループのパラレル文がデキューされる順序を決定できます。これらのディレクティブをDBMS_RESOURCE_MANAGER PL/SQLパッケージのCREATE_PLAN_DIRECTIVEまたはUPDATE_PLAN_DIRECTIVEプロシージャを使用して構成します。また、PDB間のパラレル文の順序を管理するために、CDBリソース・プランでsharesを設定できます。

たとえば、コンシューマ・グループPQ_HIGH、PQ_MEDIUMおよびPQ_LOWを作成し、優先順位に基づいてパラレル文セッションをこれらのコンシューマ・グループにマップします。次にリソース・プランを作成し、PQ_HIGHにshares=14、PQ_MEDIUMにshares=5、PQ_LOWにshares=1を設定します。これは、PQ_HIGHの文がデキューされる確率は70% (14/(14+5+1)=.70)、PQ_MEDIUMがデキューされる確率は25% (5/(14+5+1)=.25)、そしてPQ_LOWがデキューされる確率は5% (1/(14+5+1)=.05)であることを示しています。

パラレル文がキューに入っており、そのパラレル文をただちに実行する必要があると判断した場合は、DBMS_RESOURCE_MANAGER.DEQUEUE_PARALLEL_STATEMENT PL/SQLプロシージャを実行して、そのパラレル文をデキューできます。

関連項目:

8.4.1.2 コンシューマ・グループに対するパラレル・サーバー・リソースの制限について

Oracle Database Resource Managerを使用して、優先順位の低いコンシューマ・グループのパラレル文がパラレル文処理に使用できるパラレル・サーバーの数を制限できます。

Oracle Database Resource Managerを使用してパラレル文セッションを異なるコンシューマ・グループにマップし、それぞれに使用できるパラレル・サーバーの数に特定の制限を持たせることができます。各コンシューマ・グループには、独自の個々のパラレル文キューがあります。コンシューマ・グループのこの制限を指定した場合、コンシューマ・グループのパラレル文は、その制限を超えるとキューに入れられます。

この制限は、データベースにコンシューマ・グループの優先順位が高いものと低いものがある場合に役立ちます。制限を設けないと、優先順位の低いコンシューマ・グループから大量のパラレル文が発行されて、すべてのパラレル・サーバーが使用される可能性があります。優先順位の高いコンシューマ・グループからパラレル文が発行されたときに、リソース割当てディレクティブにより、その優先順位の高いパラレル文を確実に最初にデキューすることができます。優先順位の低いコンシューマ・グループが使用できるパラレル・サーバーの数を制限することにより、優先順位の高いコンシューマ・グループが使用できるパラレル・サーバーを常に確保しておくことができます。

コンシューマ・グループが使用するパラレル・サーバーを制限するには、DBMS_RESOURCE_MANAGERパッケージで、CREATE_PLAN_DIRECTIVEプロシージャのparallel_server_limitパラメータを使用するか、UPDATE_PLAN_DIRECTIVEプロシージャのnew_parallel_server_limitパラメータを使用します。parallel_server_limitパラメータは、PARALLEL_SERVERS_TARGETで指定されるOracle RAC全体のパラレル・サーバー・プールのうち、コンシューマ・グループが使用できる最大パーセンテージを指定します。

マルチテナント・コンテナ・データベース(CDB)のリソース・プランでは、プラガブル・データベース(PDB)にパラレル・サーバー制限が適用されます。PDBリソース・プランまたはCDB以外のリソース・プランの場合、この制限がコンシューマ・グループに適用されます。

たとえば、非マルチテナント構成のOracle RACデータベースでは、初期化パラメータPARALLEL_SERVERS_TARGETが2つのノードで32に設定されているため、キューイングが開始されるまでに使用できるパラレル・サーバーの合計数は32 x 2 = 64です。使用可能なパラレル・サーバーのうち50%をコンシューマ・グループPQ_LOWが使用するように設定し(parallel_server_limit = 50)、優先順位の低い文をPQ_LOWコンシューマ・グループにマップできます。このシナリオでは、コンシューマ・グループPQ_LOWのパラレル文は、64 x 50% = 32のパラレル・サーバーに制限されます。これは、たとえ非アクティブなまたは未使用のパラレル・サーバーがこれより多くあったとしても同じです。このシナリオでは、コンシューマ・グループPQ_LOWの文は、32のパラレル・サーバーをすべて使用すると、キューに入れられます。

1つのデータベース内に並列度ポリシーをMANUALに設定したセッションとAUTOに設定したセッションを混在させることが可能です。このシナリオでは、並列度ポリシーをAUTOに設定したセッションのみキューに入れることができます。ただし、並列度ポリシーをMANUALに設定したセッションで使用されるパラレル・サーバーは、コンシューマ・グループで使用されるパラレル・サーバーの合計数に含まれます。

関連項目:

ユーザーに対するパラレル・リソースの制限の詳細は、PARALLEL_SERVERS_TARGETを参照してください

8.4.1.3 各コンシューマ・グループに対するパラレル文キューのタイムアウトの指定

Oracle Database Resource Managerを使用して、コンシューマ・グループに対して特定のキュー・タイムアウト最大値を設定し、パラレル文がキューに長時間入ったままにならないようにすることができます。

キューのタイムアウトを管理するには、DBMS_RESOURCE_MANAGERパッケージで、CREATE_PLAN_DIRECTIVEプロシージャのparallel_queue_timeoutパラメータを使用するか、UPDATE_PLAN_DIRECTIVEプロシージャのnew_parallel_queue_timeoutパラメータを使用します。parallel_queue_timeoutおよびnew_parallel_queue_timeoutパラメータは、文がコンシューマ・グループのパラレル文のキューに留まることのできる時間を秒単位で指定します。タイムアウト時間が経過すると、文はエラーORA-7454で終了するか、パラレル文のキューから削除され、リソース・マネージャ計画のPQ_TIMEOUT_ACTIONディレクティブの値に基づいて実行するように有効化されます。

PQ_TIMEOUT_ACTIONリソース・マネージャ・ディレクティブを使用してパラレル文のキュー・タイムアウト・アクションを指定できます。このディレクティブをCANCELに設定すると、エラーORA-7454で文が終了します。このディレクティブをRUNに設定すると、文は実行可能になります。

8.4.1.4 コンシューマ・グループに対する並列度制限の指定

Oracle Database Resource Managerを使用して、特定のコンシューマ・グループに対する並列度を制限できます。

Oracle Database Resource Managerを使用して、リソース・プランでパラレル文セッションをそれぞれ特定の並列度制限を持つ異なるコンシューマ・グループにマップできます。

コンシューマ・グループの並列度制限を管理するには、DBMS_RESOURCE_MANAGERパッケージでCREATE_PLAN_DIRECTIVEプロシージャのparallel_degree_limit_p1パラメータを使用するか、DBMS_RESOURCE_MANAGERパッケージでUPDATE_PLAN_DIRECTIVEプロシージャのnew_parallel_degree_limit_p1パラメータを使用します。parallel_degree_limit_p1およびnew_parallel_degree_limit_p1パラメータは、任意の操作について並列度の制限を指定します。

たとえば、コンシューマ・グループPQ_HIGH、PQ_MEDIUMおよびPQ_LOWを作成し、優先順位に基づいてパラレル文セッションをこれらのコンシューマ・グループにマップします。それから並列度の制限を指定するリソース・プランを作成し、PQ_HIGHの制限値を16、PQ_MEDIUMの制限値を8、PQ_LOWの制限値を2に設定します。

PARALLEL_DEGREE_POLICYがAUTOに設定されていない場合でも、並列度の制限が強制されます。

8.4.1.5 クリティカルなパラレル文の優先順位

PARALLEL_STMT_CRITICALパラメータの設定は、パラレル文のキューに関連するプラン・ディレクティブのパラレル文のクリティカル指定に影響します。

  • PARALLEL_STMT_CRITICALパラメータがQUEUEに設定されている場合、PARALLEL_DEGREE_POLICYがMANUALに設定されているパラレル文はキューに入れられます。

  • PARALLEL_STMT_CRITICALパラメータがBYPASS_QUEUEに設定されている場合、パラレル文はパラレル文のキューを回避し、即座に実行されます。

  • PARALLEL_STMT_CRITICALがFALSEに設定されている場合は、デフォルトの動作が指定され、クリティカルとして指定される文はありません。

クリティカルなパラレル文はパラレル文のキューを回避するため、システムは、PARALLEL_SERVERS_TARGETパラメータの指定より多くのアクティブなパラレル・サーバーを検出する場合があります。パラレル・サーバーの数がPARALLEL_MAX_SERVERSに達した後にクリティカルなパラレル文を実行できるため、一部のクリティカルなパラレル文がダウングレードされる場合があります。

DBA_RSRC_PLAN_DIRECTIVESビューのPARALLEL_STMT_CRITICAL列は、パラレル文がクリティカルとマークされたコンシューマ・グループかどうかを示します。

8.4.1.6 パラレル・キュー内の文を管理するシナリオ例

このシナリオでは、Oracle Database Resource Managerを使用してコンシューマ・グループを設定してパラレル・キュー内の文を管理する方法について説明します。

このシナリオでは、3種類のSQL文で構成されるデータ・ウェアハウスのワークロードについて考えます。

  • 実行時間の短いSQL文

    実行時間が短い文とは、実行時間が1分以内の文を指します。このような文はレスポンスが非常によいことが予想されます。

  • 実行時間が中程度のSQL文

    実行時間が中程度の文とは、実行時間が1分より長く15分以内の短い文を指します。このような文はレスポンスがある程度よいことが予想されます。

  • 実行時間の長いSQL文

    実行時間の長い文とは、実行時間が15分より長い非定型の問合せや複雑な問合せを指します。このような文は長時間かかると予想されます。

このデータ・ウェアハウス・ワークロードでは、実行時間の短い文でよりよいレスポンスが求められています。この目標を達成するには、次の点について確認する必要があります。

  • 実行時間の長い文がパラレル・サーバー・リソースをすべて使用して、実行時間のより短い文がパラレル文のキューで待機させられることがないようにします。

  • 実行時間の短い文と長い文の両方がキューに入っている場合は、実行時間の短い文を長い文よりも先にデキューするようにします。

  • 実行時間の短い問合せのDOPを制限します。これはDOPを高くすることで得られる高速化は、多数のパラレル・サーバーの使用を正当化するほど重要ではないためです。

例8-3に、Oracle Database Resource Managerを使用してコンシューマ・グループを設定して、パラレル文キュー内の文に優先順位を設定する方法を示します。この例については、次の内容に注意してください。

  • デフォルトでは、ユーザーはコンシューマ・グループOTHER_GROUPSに割り当てられています。SQL文の推定実行時間が1分(60秒)より長い場合は、ユーザーはMEDIUM_SQL_GROUPに切り替わります。switch_for_callがTRUEに設定されている場合、その文の完了後、ユーザーはOTHER_GROUPSに戻ります。ユーザーがMEDIUM_SQL_GROUPにあり、文の推定実行時間が15分(900秒)より長い場合は、ユーザーはLONG_SQL_GROUPに切り替わります。同様に、switch_for_callがTRUEに設定されている場合は、問合せの完了後、ユーザーはOTHER_GROUPSに戻ります。切替え処理の実行に使用されるディレクティブは、switch_time、switch_estimate、switch_for_callおよびswitch_groupです。

  • アクティブなパラレル・サーバーの数が初期化パラメータPARALLEL_SERVERS_TARGETの値に達すると、それ以降のパラレル文はキューに入れられます。sharesディレクティブは、パラレル・サーバーが使用可能になったときにパラレル文をデキューする順番を制御します。この例では、SYS_GROUPのsharesが100%に設定されているため、SYS_GROUPのパラレル文は常に最初にデキューされます。SYS_GROUPのパラレル文がキューにない場合、OTHER_GROUPSのパラレル文は70%、MEDIUM_SQL_GROUPの文は20%、LONG_SQL_GROUPの文は10%の確率でデキューされます。

  • OTHER_GROUPSから発行されるパラレル文は、parallel_degree_limit_p1ディレクティブの設定により、DOPが4に制限されます。

  • LONG_SQL_GROUPグループのパラレル文がパラレル・サーバーをすべて使用して、OTHER_GROUPSやMEDIUM_SQL_GROUPのパラレル文を長時間待機させることのないようにするには、そのparallel_server_limitディレクティブを50%に設定します。つまり、LONG_SQL_GROUPが初期化パラメータPARALLEL_SERVERS_TARGETで設定したパラレル・サーバーの50%まで使用すると、それ以降はそのグループのパラレル文を強制的にキューで待機させます。

  • LONG_SQL_GROUPグループのパラレル文はかなり長い時間キューに留まる可能性があるため、14400秒(4時間)のタイムアウトが設定されます。LONG_SQL_GROUPのパラレル文は、キューで4時間待機すると、エラーORA-7454により停止されます。

例8-3 コンシューマ・グループを使用したパラレル文キュー内の優先順位の設定

BEGIN
  DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();
 
  /* Create consumer groups.
   * By default, users start in OTHER_GROUPS, which is automatically
   * created for every database.
   */
  DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(
    'MEDIUM_SQL_GROUP',
    'Medium-running SQL statements, between 1 and 15 minutes.  Medium priority.');

  DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(
    'LONG_SQL_GROUP',
    'Long-running SQL statements of over 15 minutes.  Low priority.');
 
  /* Create a plan to manage these consumer groups */
  DBMS_RESOURCE_MANAGER.CREATE_PLAN(
    'REPORTS_PLAN',
    'Plan for daytime that prioritizes short-running queries');
 
  DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
    'REPORTS_PLAN', 'SYS_GROUP', 'Directive for sys activity',
    shares => 100);
 
  DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
    'REPORTS_PLAN', 'OTHER_GROUPS', 'Directive for short-running queries',
    shares => 70,
    parallel_degree_limit_p1 => 4,
    switch_time => 60, switch_estimate => TRUE, switch_for_call => TRUE,
    switch_group => 'MEDIUM_SQL_GROUP');
 
  DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
    'REPORTS_PLAN', 'MEDIUM_SQL_GROUP', 'Directive for medium-running queries',
    shares => 20,
    parallel_server_limit => 80,
    switch_time => 900, switch_estimate => TRUE, switch_for_call => TRUE,
    switch_group => 'LONG_SQL_GROUP');
 
  DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
    'REPORTS_PLAN', 'LONG_SQL_GROUP', 'Directive for medium-running queries',
    shares => 10,
    parallel_server_limit => 50,
    parallel_queue_timeout => 14400);
 
  DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
END;
/

/* Allow all users to run in these consumer groups */
EXEC DBMS_RESOURCE_MANAGER_PRIVS.GRANT_SWITCH_CONSUMER_GROUP(
  'public', 'MEDIUM_SQL_GROUP', FALSE);
 
EXEC DBMS_RESOURCE_MANAGER_PRIVS.GRANT_SWITCH_CONSUMER_GROUP(
  'public', 'LONG_SQL_GROUP', FALSE);

8.4.2 パラレル文のグループ化: BEGIN_SQL_BLOCK END_SQL_BLOCK

複数のパラレル文からなるレポートやバッチ・ジョブをできるだけ高速に完了することが重要な場合がよくあります。

たとえば、多数のレポートを同時に開始した場合、すべてのレポートをできるだけすばやく完了させる必要があります。ただし、すべてのレポートを同時に終わらせるのではなく、特定のレポートを最初に完了させたい場合もあります。

レポートに複数のパラレル文が含まれており、PARALLEL_DEGREE_POLICYがAUTOに設定されている場合、それぞれのパラレル文がビジー状態のデータベース上でキューに待機する可能性があります。たとえば、次のステップでは、SQL文の処理でのシナリオについて説明します。 

serial statement
parallel query - dop 8
  -> wait in queue
serial statement
parallel query - dop 32
  -> wait in queue
parallel query - dop 4
  -> wait in queue

レポートをすばやく完了させるには、パラレル文が次のように動作するようグループ化する必要があります。

start SQL block
serial statement
parallel query - dop 8
  -> first parallel query: ok to wait in queue
serial statement
parallel query - dop 32
  -> avoid or minimize wait
parallel query - dop 4
  -> avoid or minimize wait
end SQL block

パラレル文をグループ化するには、DBMS_RESOURCE_MANAGER PL/SQLパッケージでBEGIN_SQL_BLOCKおよびEND_SQL_BLOCKプロシージャを使用します。各コンシューマ・グループに対して、コンシューマ・グループの各パラレル文に関連付けられた時間によってパラレル文キューの順序付けを行います。通常は、パラレル文に関連付けられた時間は、その文がエンキューされた時間で、つまりキューは先入先出(FIFO)であることを意味します。BEGIN_SQL_BLOCKおよびEND_SQL_BLOCKプロシージャを使用してパラレル文をSQLブロックにグループ化する場合、最初にキューイングされたパラレル文は同様にエンキューされた時間を使用します。ただし、2番目とその後続のパラレル文はすべて特別な扱いを受け、SQLブロック内の最初にキューイングされたパラレル文のエンキュー時間を使用してエンキューされます。この機能により、文がパラレル文キューの前方に移動することがよくあります。この優先的な扱いにより、待機時間を最小限に抑えられます。

関連項目:

DBMS_RESOURCE_MANAGERパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください

8.4.3 ヒントによるパラレル文のキューイングの管理について

SQL文のNO_STATEMENT_QUEUINGおよびSTATEMENT_QUEUINGヒントを使用して、文がパラレル文のキューイングでキューに入れられるかどうかに影響を与えることができます。

  • NO_STATEMENT_QUEUING

    PARALLEL_DEGREE_POLICYをAUTOに設定すると、このヒントにより文がパラレル文キューに入らないようにすることができます。ただし、文のキューを回避する文は、パラレル文のキューイングを開始する制限を決定するPARALLEL_SERVERS_TARGET初期化パラメータの値で定義されるパラレル実行サーバーの最大数を超える可能性があります。

    システムで使用できるパラレル実行サーバーの数がPARALLEL_MAX_SERVERS初期化パラメータの値までに制限されるため、パラレル文のキューイングを回避する文がリクエストされたパラレル実行サーバーの数を受け取る保証はありません。

    たとえば:

    SELECT /*+ NO_STATEMENT_QUEUING */ last_name, department_name 
  FROM employees e, departments d 
  WHERE e.department_id = d.department_id;

  • STATEMENT_QUEUING

    PARALLEL_DEGREE_POLICYをAUTOに設定しない場合は、このヒントにより文をパラレル文のキューイングに考慮し、リクエストされたDOPで十分なパラレル処理を実行できる場合にのみ実行させることができます。キューイングを有効にする前の使用できるパラレル実行サーバーの数は、使用するパラレル実行サーバーの数とPARALLEL_SERVERS_TARGET初期化パラメータで定義されるシステムで許可される最大数の違いと同じです。

    たとえば:

    SELECT /*+ STATEMENT_QUEUING */ last_name, department_name 
  FROM employees e, departments d 
  WHERE e.department_id = d.department_id;

8.5 並列処理の種類

並列処理には複数のタイプがあります。

ここでは、次の項目で並行処理の種類について説明します。

8.5.1 パラレル問合せについて

SELECT文でパラレル問合せとパラレル副問合せを使用できます。DDL文とDML文(INSERT、UPDATEおよびDELETE)の問合せ部分もパラレルで実行できます。

また、外部表をパラレルで問い合せることもできます。

SQL問合せのパラレル化決定には、パラレル化の決定と並列度(DOP)という2つの要素があります。これらの要素の決定方法は、問合せ、DDL操作およびDML操作で異なります。DOPを決定するときに、Oracle Databaseは次の参照オブジェクトを調べます。

  • パラレル問合せは、パラレルで実行される問合せの部分で、それぞれの表および索引を調べて、どれが参照表かを決定します。原則として、最大のDOPが設定された表または索引を選択します。

  • パラレルDML(INSERT、UPDATE、MERGEおよびDELETE)では、DOPを決定する参照オブジェクトは、挿入、更新または削除操作によって変更される表です。パラレルDMLではデッドロックを防ぐためにDOPに制限が課せられます。パラレルDML文に副問合せが含まれる場合、副問合せのDOPはDML操作のDOPと同じになります。

  • パラレルDDLでは、DOPを決定する参照オブジェクトは、作成、再構築、分割または移動される表、索引またはパーティションです。パラレルDDL文に副問合せが含まれる場合、副問合せのDOPはDDL操作と同じになります。

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

関連項目:

8.5.1.1 索引構成表のパラレル問合せ

索引構成表ではいくつかのパラレル・スキャン方法がサポートされています。

パラレル・スキャン方法には、次が含まれます。

  • 非パーティション索引構成表のパラレル高速全スキャン

  • パーティション索引構成表のパラレル高速全スキャン

  • パーティション索引構成表のパラレル索引レンジ・スキャン

オーバーフロー領域を含む索引構成表およびLOBを含む索引構成表に対して、これらのスキャン方法を使用できます。

非パーティション索引構成表

非パーティション索引構成表に対するパラレル問合せでは、パラレル高速全スキャンが使用されます。作業の割当ては、索引セグメントを十分な数のブロック・レンジに分割し、ブロック・レンジをデマンドドリブン方式でパラレル実行サーバーに割り当てることで行われます。任意の行に対応するオーバーフロー・ブロックは、その行を所有するプロセスによってのみデマンドドリブン方式でアクセスされます。

パーティション索引構成表

索引レンジ・スキャンと高速全スキャンの両方をパラレルで実行できます。パラレル高速全スキャンでは、パラレル化は非パーティション索引構成表の場合と同じです。DOPによって異なりますが、各パラレル実行サーバーは、1つ以上のパーティションを取得します。各パーティションは、主キー索引セグメントと関連するオーバーフロー・セグメント(ある場合)を含みます。

8.5.1.2 オブジェクト型のパラレル問合せ

パラレル問合せを、オブジェクト型の表およびオブジェクト型の列を含む表に実行することができます。

オブジェクト型に対するパラレル問合せでは、オブジェクト型に対する順次問合せで使用できるすべての機能がサポートされます。

  • オブジェクト型に対するメソッド

  • オブジェクト型の属性アクセス

  • オブジェクト型インスタンスを作成するためのコンストラクタ

  • オブジェクト・ビュー

  • オブジェクト型に対するPL/SQLおよびOracle Call Interface (OCI)問合せ

パラレル問合せではオブジェクト型のサイズの制限はありません。

オブジェクト型に対してパラレル問合せを使用する際には次の制限が適用されます。

  • 結合とソート(ORDER BY、GROUP BYまたは集合操作による)を含む問合せをパラレルで実行するにはMAP関数が必要です。MAP関数がない場合、問合せは自動的にシリアルで実行されます。

  • パラレルDMLおよびパラレルDDLはオブジェクト型に対してはサポートされず、そのような文は常にシリアルで実行されます。

これらいずれかの制限のために問合せをパラレルで実行できない場合は、常に問合せ全体がシリアルで実行されエラー・メッセージは返されません。

8.5.1.3 問合せのパラレル化のルール

SQL問合せは、特定の条件下でのみパラレルで実行できます。

SELECT文をパラレルで実行できるのは、次の条件のいずれかが満たされている場合のみです。

  • 問合せに、文レベルまたはオブジェクト・レベルのパラレル・ヒント仕様(PARALLELまたはPARALLEL_INDEX)が含まれている。

  • 問合せ内で参照されるスキーマ・オブジェクトに、PARALLEL宣言が関連付けられている。

  • 自動並列度(自動DOP)が有効になっている。

  • ALTER SESSION FORCE PARALLEL QUERY文を使用してパラレル問合せが強制されている。

また、実行計画には、少なくとも次のいずれかが必要となります。

  • 全表スキャン

  • 複数パーティションに及ぶ索引レンジ・スキャン

  • 索引高速全体スキャン

  • パラレル表関数

関連項目:

8.5.2 パラレルDDL文について

このトピックでは、DDL文の並列処理について説明します。

DDL文の並列処理に関するこの項には、次のトピックが含まれます。

8.5.2.1 パラレル化できるDDL文

表および索引(パーティションまたは非パーティション)に対するDDL文をパラレルで実行できます。

非パーティション表および非パーティション索引のパラレルDDL文は次のとおりです。

  • CREATE INDEX

  • CREATE TABLE AS SELECT

  • ALTER TABLE MOVE

  • ALTER INDEX REBUILD

  • ALTER TABLE MODIFY

パーティション表およびパーティション索引のパラレルDDL文は次のとおりです。

  • CREATE INDEX

  • CREATE TABLE AS SELECT

  • ALTER TABLE {MOVE|SPLIT|COALESCE} PARTITION

  • ALTER INDEX {REBUILD|SPLIT} PARTITION

    • この文をパラレルで実行できるのは、分割対象の(グローバル)索引パーティションが使用可能な場合のみです。

このようなDDL操作はすべて、パラレル実行でもシリアル実行でもNOLOGGINGモードで実行できます。

索引構成表のCREATE TABLE文は、AS SELECT句の有無にかかわらずパラレルで実行できます。

パラレルDDLは、オブジェクト列を含む表では実行できません。パラレルDDLは、LOB列を含む非パーティション表では実行できません。

8.5.2.2 パラレルでのCREATE TABLE AS SELECTの使用について

パラレル実行により、問合せをパラレルで実行でき、別の表または表セットから副問合せとして表を作成する操作を作成できます。

このパラレル機能は、サマリーまたはロールアップ表の作成で非常に役に立ちます。

クラスタ表の作成と移入は、パラレルで行えないことに注意してください。

図8-4に、パラレルでの副問合せを使用したサマリー表の作成を示します。

図8-4 パラレルでのサマリー表の作成

図8-4の説明が続きます
「図8-4 パラレルでのサマリー表の作成」の説明
8.5.2.3 リカバリ可能性とパラレルDDL

パラレルDDLは、サマリー表の作成や、スタンドアロン・トランザクションである大量データ・ロードの実行(必ずしもリカバリ可能でなくてもよい)によく使用されます。

Oracle DatabaseロギングをオフにするとUNDOログまたはREDOログは生成されないため、パラレルDML操作のパフォーマンスは多くの場合向上しますがオールオアナッシング操作になります。つまり、操作がなんらかの理由で失敗した場合、操作をやりなおす必要があります。再開することはできません。

パラレル表作成(またはその他のパラレルDDL操作)時にロギングを無効化する場合は、メディア障害による表の損失を防ぐために、表が作成されてからその表を含む表領域をバックアップする必要があります。

UNDOログおよびREDOログの生成を無効にするには、CREATE TABLE、CREATE INDEX、ALTER TABLEおよびALTER INDEX文でNOLOGGING句を使用します。

8.5.2.4 パラレルDDLの領域管理

表または索引のパラレルでの作成は、領域管理と密接に関連します。

これらの領域管理は、パラレル操作時に必要な記憶領域、および表または索引が作成された後に使用可能な空き領域の両方に影響します。

8.5.2.5 ディクショナリ管理表領域使用時の記憶領域

表または索引をパラレルで作成するとき、各パラレル実行サーバーはCREATE文のSTORAGE句の値を使用して、行を格納するための一時セグメントを作成します。

NEXT設定が4MB、PARALLEL DEGREEが16で作成される表は、作成時に少なくとも64MBの記憶域を消費します。各パラレル・サーバー・プロセスが4MBのエクステントで開始するためです。パラレル実行コーディネータがセグメントを結合するときに、セグメントの一部が切り捨てられ、生成される表はリクエストの64MBよりも小さくなることがあります。

8.5.2.6 空き領域とパラレルDDL

索引と表をパラレルで作成するとき、各パラレル実行サーバーが新しいエクステントを割り当て、エクステントに表または索引のデータを格納します。

たとえば、DOPを4として索引を作成する場合、索引には最初の時点で少なくとも4つのエクステントがあります。このエクステントの割当ては、パラレルでの索引再構築の場合や、パラレルでのパーティションの移動、分割または再構築の場合と同様に行われます。

シリアル操作では、スキーマ・オブジェクトに少なくとも1つのエクステントが必要です。パラレル作成では、表または索引に、スキーマ・オブジェクトを作成するパラレル実行サーバーと同数のエクステントがあることが必要です。

表または索引をパラレルで作成するとき、空き領域が作成されることがあります。これは、パラレル実行サーバーで使用される一時セグメントが、行の格納に必要なサイズよりも大きい場合に発生します。

  • 各一時セグメント内の未使用領域が、表領域レベルで設定されたMINIMUM EXTENTパラメータの値よりも大きい場合、Oracle Databaseがすべての一時セグメントの行を表または索引にマージするときに未使用領域を切り捨てます。未使用領域はシステムの空き領域に戻され、新しいエクステント用に割り当てることができます。ただし、連続した領域ではないため、結合してより大きいセグメントにすることはできません(外部断片化)。

  • 各一時セグメントの未使用領域がMINIMUM EXTENTパラメータの値よりも小さい場合は、一時セグメントの行をマージするときに未使用領域を切り捨てることはできません。この未使用領域はシステムの空き領域に戻されません。表または索引の一部として残り(内部断片化)、後から行われる挿入や追加領域を必要とする更新のためにのみ使用されます。

たとえば、CREATE TABLE AS SELECT文でDOPを3と指定したが、表領域には1つしかデータファイルがない場合、図8-5に示すように内部断片化が発生することがあります。データファイルの内部表エクステント内の空き領域を他の空き領域と結合して、エクステントとして割り当てることはできません。

図8-5 使用できない空き領域(内部断片化)

図8-5の説明が続きます
「図8-5 使用できない空き領域(内部断片化)」の説明

関連項目:

パラレルでの表および索引作成の詳細は、『Oracle Database SQLチューニング・ガイド』を参照してください

8.5.2.7 DDL文のルール

DDL操作は、特定の条件下でパラレルで実行できます。

DDL操作をパラレルで実行できるのは、次の条件のうち少なくとも1つが満たされている場合のみです。

  • 構文でPARALLEL句(宣言)が指定されている。CREATE TABLE、CREATE INDEX、ALTER INDEX REBUILDおよびALTER INDEX REBUILD PARTITIONの場合、パラレル宣言はデータ・ディクショナリに格納されます。

  • 自動並列度(自動DOP)が有効になっている。

  • ALTER SESSION FORCE PARALLEL DDL文を使用してパラレルDDLが強制されている。

関連項目:

8.5.2.8 CREATE TABLE AS SELECTのルール

CREATE TABLE AS SELECT文のCREATE操作は、パラレル化DDL文のルールに基づいてパラレル化されます。

また、文のSELECT部分で指定されている文レベルPARALLELヒントでも、DDL操作をパラレル化できます。パラレル化DDL文のルールの詳細は、DDL文のルールを参照してください。

CREATE TABLE AS SELECTのCREATE操作がパラレル化されるとき、可能であればスキャン操作もパラレル化されます。

DDL部分がパラレル化されない場合でも、問合せのパラレル化のルールに基づいて、SELECT部分をパラレル化できます。

自動並列度(自動DOP)では、文のDDL部分と問合せ部分の両方がパラレル化されます。

並列度(DOP)を決定するためのルールの詳細は、SQL文の並列度ルールを参照してください。

8.5.3 パラレルDML操作について

このトピックでは、パラレルDML操作について説明します。

パラレルDML(PARALLEL INSERT、UPDATE、DELETEおよびMERGE)は、パラレル実行メカニズムを使用して、大規模なデータベース表や索引に対する大規模なDML操作を高速化または拡張します。

ノート:

同じセッションで同じオブジェクトを複数のDML操作またはパラレルDML操作によって変更できます。各操作を個別にコミットする必要がなくなりました。これにより、パラレルDMLのコミットのオーバーヘッドが削減されます。

通常、DMLには問合せが含まれますが、この章ではDMLという語はINSERT、UPDATE、MERGEおよびDELETE操作のみを指すものとして使用しています。

ここでは、パラレルDMLの次の項目について説明します。

8.5.3.1 パラレルDMLを使用する場合

パラレルDMLが役立つのは、大容量オブジェクトにアクセスする際のパフォーマンスとスケーラビリティが重要になる意思決定支援システム(DSS)環境です。パラレルDMLは、DSSデータベースのための問合せ機能と更新機能の両方を提供し、パラレル問合せを補います。

並列処理の設定に伴うオーバーヘッドのため、パラレルDML操作は短時間のOLTPトランザクションでの実行には適していません。ただし、パラレルDML操作を使用してOLTPデータベースでのバッチ・ジョブの実行を高速処理することができます。

パラレルDMLが使用されるシナリオの一部を次に示します。

8.5.3.1.1 データ・ウェアハウス・システムでの表のリフレッシュ

データ・ウェアハウス・システムでは、大容量の表を本番システムの新規データまたは変更データで定期的にリフレッシュ(更新)する必要があります。

MERGE文を使用すると、これを効率よく実行できます。

8.5.3.1.2 中間サマリー表の作成

DSS環境では、多くのアプリケーションで、多数の大容量中間サマリー表の作成や操作を行う複雑な計算が必要です。

このようなサマリー表は多くの場合は一時的に使用され、ロギングする必要がないものが大半です。パラレルDMLを使用すると、このような大容量中間表に対する操作が高速化されます。メリットの1つは、増分結果を中間表に格納して、パラレル更新を実行できることです。

また、サマリー表には、アプリケーション・セッションが終了しても保存する必要がある累積情報または比較情報が含まれる場合もあります。つまり、一時表は使用できません。パラレルDML操作を使用すると、このような大容量サマリー表に対する変更が高速化されます。

8.5.3.1.3 スコアリング・テーブルの使用

多くのDSSアプリケーションは、一連の基準に基づいて定期的に顧客をスコアリングしています。

通常、スコアは大容量のDSS表に格納されます。その後、スコア情報は意思決定(たとえばメーリング・リストへの指定)で使用されます。

このようなスコアリング・アクティビティでは、表の多数の行の問合せと更新が行われます。パラレルDMLを使用すると、このような大容量表に対する操作が高速化されます。

8.5.3.1.4 履歴表の更新

履歴表は、最新の時間間隔における企業のビジネス・トランザクションを示します。

DBAは定期的に、この表から最も古い行セットを削除し、新しい行セットを挿入します。パラレルINSERT SELECTおよびパラレルDELETE操作を使用すると、このロールオーバー・タスクが高速化されます。

パーティションの削除を使用して古い行を削除することもできます。ただし、表を日付でパーティション化して、適切な時間間隔を設定する必要があります。

8.5.3.1.5 バッチ・ジョブの実行

業務時間外にOLTPデータベースで実行されるバッチ・ジョブは、ジョブを完了する必要のある時間枠が決まっています。時間どおりに確実にジョブを完了するための最適な手段が、パラレルでの操作の実行です。

ワーク・ロードが増えると、コンピュータ・リソースを追加できます。パラレル操作のスケールアップ・プロパティにより時間制限を守ることができます。

8.5.3.2 パラレルDMLモードの有効化

DML文をパラレル化できるのは、セッションまたはSQL文におけるパラレルDMLを明示的に有効化した場合のみです。

セッションでこのモード有効にするには、次のSQL文を実行します。

ALTER SESSION ENABLE PARALLEL DML;

特定のSQL文でパラレルDMLモードを有効にするには、ENABLE_PARALLEL_DML SQLヒントを含めます。たとえば: 

INSERT /*+ ENABLE_PARALLEL_DML */ …

パラレルDMLとシリアルDMLでは、ロック、トランザクションおよびディスク領域の要件が異なるため、このモードが必要になり、パラレルDMLはデフォルト設定によりセッションに対して無効化されています。

パラレルDMLが無効になっていると、PARALLELヒントが使用されてもDMLはパラレルで実行されません。

パラレルDMLがセッションで有効化されていると、そのセッションのすべてのDML文がパラレル実行の対象とみなされます。ENABLE_PARALLEL_DMLヒントを使用してパラレルDMLがSQL文で有効になっている場合、その特定の文のみがパラレル実行の対象として考慮されます。ただし、パラレルDMLが有効になっていても、パラレル・ヒントがない場合や表にパラレル属性がない場合、またはパラレル操作の制限に違反している場合、DML操作はシリアルで実行されます。

セッションのPARALLEL DMLモードはSELECT文、DDL文、およびDML文の問合せ部分の並列処理には影響しません。このモードが設定されていない場合、DML操作はパラレル化されませんが、DML文内のスキャン操作または結合操作はパラレル化されることがあります。

セッションに対してパラレルDMLモードが有効になっている場合、DISABLE_PARALLEL_DML SQLヒントを使用して、特定のSQL文のモードを無効にできます。

ノート:

Oracle Database 23aiでは、ALTER SESSION ENABLE PARALLEL DMLによって、セッション内のパラレルDMLが有効になるのみでなく、操作ごとに個別のトランザクション・コミットを必要とせずに、同じオブジェクトに対する複数のDML/PDML/QUERY操作が可能です。これにより、パラレルDMLでのコミットのオーバーヘッドを削減できます。

詳細は、「パラレルDMLの領域に関する考慮事項」および「パラレルDMLの制限」を参照してください。

8.5.3.3 UPDATE、MERGEおよびDELETEのルール

更新、マージまたは削除操作は、特定の条件下でのみパラレル化されます。

UPDATE、MERGEおよびDELETE操作は、次の条件のうち少なくとも1つが満たされている場合のみパラレル化されます。

  • 前のCREATE TABLEまたはALTER TABLE文によって、更新、マージまたは削除の対象となる表にPARALLEL宣言が設定されている。

  • DML文で文レベルまたはオブジェクト・レベルのPARALLELヒントが指定されている。

  • 自動並列度(自動DOP)が有効になっている。

  • ALTER SESSION FORCE PARALLEL DML文を使用してパラレルDMLが強制されている。

文に副問合せまたは更新可能なビューが含まれている場合は、問合せのパラレル化のルールに基づいて、それらもパラレルで実行される可能性があります。UPDATE、MERGEおよびDELETE部分のパラレル化の決定は、問合せ部分から独立しており、逆もまた同様です。文レベルのPARALLELヒントまたは自動DOPでは、DML部分と問合せ部分の両方がパラレル化されます。

関連項目:

8.5.3.4 INSERT SELECTのルール

挿入操作は、特定の条件下でのみパラレルで実行されます。

INSERT操作がパラレルで実行されるのは、次の条件のうち少なくとも1つが満たされている場合のみです。

  • 前のCREATE TABLEまたはALTER TABLE文によって、挿入の対象となる表(参照オブジェクト)にPARALLEL宣言が設定されている。

  • DML文でINSERTの後に文レベルまたはオブジェクト・レベルのPARALLELヒントが指定されている。

  • 自動並列度(自動DOP)が有効になっている。

  • ALTER SESSION FORCE PARALLEL DML文を使用してパラレルDMLが強制されている。

INSERT操作のパラレル化の決定は、SELECT操作とは別に行われます。逆の場合も同様です。問合せのパラレル化のルールに基づいて、SELECT操作をパラレル化できます。文レベルのPARALLELヒントまたは自動DOPでは、INSERT操作とSELECT操作の両方がパラレル化されます。

関連項目:

8.5.3.5 パラレルDMLのトランザクション制限

DML操作をパラレルで実行するには、パラレル実行コーディネータがパラレル実行サーバーを取得し、パラレル実行サーバーがそれぞれのパラレル・プロセス・トランザクションで作業の一部を実行します。

次の条件に注意してください。

  • 各パラレル実行サーバーは異なるパラレル・プロセス・トランザクションを生成します。

  • 自動UNDO管理のかわりにロールバック・セグメントを使用する際は、同じロールバック・セグメントに存在するパラレル・プロセス・トランザクションの数を制限することによって、ロールバック・セグメントに対する競合を減らした方がよい場合があります。詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

コーディネータにも独自のコーディネータ・トランザクションがあり、独自のロールバック・セグメントが対応しています。ユーザーレベルのトランザクション原子性を確保するには、コーディネータは2フェーズのコミット・プロトコルを使用して、パラレル・プロセス・トランザクションで実行される変更をコミットします。

パラレルDMLが有効になっているセッションでPL/SQLプロシージャまたはブロックが実行される場合、プロシージャまたはブロックの文にはこのルールが適用されます。

8.5.3.6 ロールバック・セグメント

自動UNDO管理のかわりにロールバック・セグメントを使用する場合、パラレルDMLを使用するときにいくつかの制限があります。

関連項目:

パラレルDMLおよびロールバック・セグメントの制限の詳細は、『Oracle Database SQL言語リファレンス』を参照してください

8.5.3.7 パラレルDMLのリカバリ

パラレルDML操作をロールバックするために必要な時間は、フォワード操作の実行にかかる時間とほぼ同じです。

Oracle Databaseでは、トランザクションとプロセスが失敗した後、およびインスタンスとシステムで障害が発生した後のパラレル・ロールバックをサポートしています。Oracle Databaseでは、トランザクション・リカバリのロールフォワード・ステージとロールバック・ステージの両方をパラレル化できます。

関連項目:

パラレル・ロールバックの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください

8.5.3.7.1 ユーザー発行のロールバックでのトランザクション・リカバリ

文のエラーのためにトランザクションが失敗した際のユーザー発行のロールバックは、パラレル実行コーディネータとパラレル実行サーバーによってパラレルで実行されます。

このロールバックには、フォワード・トランザクションとほぼ同じ時間がかかります。

8.5.3.7.2 プロセス・リカバリ

パラレル実行コーディネータまたはパラレル実行サーバーの障害からのリカバリは、PMONプロセスによって実行されます。

パラレル実行サーバーまたはパラレル実行コーディネータで障害が発生すると、PMONによってそのプロセスの作業がロールバックされ、トランザクションの他のすべてのプロセスによってその変更内容がロールバックされます。

8.5.3.7.3 システム・リカバリ

システム障害のリカバリでは新規起動が必要です。

リカバリは、SMONプロセスとSMONで生成されるすべてのリカバリ・サーバー・プロセスによって実行されます。パラレルDML文はパラレル・ロールバックを使用してリカバリできます。初期化パラメータCOMPATIBLEが8.1.3以上に設定されている場合は、ファスト・スタート・オン・デマンド・ロールバックによって、中止されたトランザクションを1回に1ブロックずつオンデマンドでリカバリできます。

8.5.3.8 パラレルDMLの領域に関する考慮事項

パラレルUPDATEではオブジェクト内の既存の空き領域が使用されますが、ダイレクト・パスINSERTではデータのために新しいエクステントが取得されます。

パラレル実行では複数の同時子トランザクションがオブジェクトを変更するため、領域使用の特徴がシリアル実行と異なることがあります。

8.5.3.9 パラレルDMLの制限

パラレルDMLに適用されるいくつかの制限事項があります。

パラレルDML(ダイレクト・パスINSERTを含む)には次の制限が適用されます。

  • UPDATE、MERGEおよびDELETE操作のイントラ・パーティション並列化を実行するには、COMPATIBLE初期化パラメータを23.0以上に設定する必要があります。

  • パラレルDML操作は、トリガーを含む表に対しては実行できません。

  • レプリケーション機能はパラレルDMLに対してはサポートされません。

  • オブジェクト列を含む表に対してパラレルDMLを実行できますが、それはオブジェクト列にアクセスしない場合です。

  • LOB列を含む表に対してパラレルDMLを実行できますが、それは表がパーティション化されている場合です。ただし、イントラ・パーティション並列処理はサポートされません。

    LOB列を含む非パーティション化表では、LOB列がSecureFiles LOBとして宣言される場合に、パラレルのINSERT操作がサポートされます。パラレルのUPDATE、DELETEおよびMERGE操作は、そのような表に対してはサポートされません。

  • DML操作が分散トランザクションに含まれる場合、またはDMLまたは問合せ操作の対象がリモート・オブジェクトである場合、そのDML操作はパラレルで実行できません。

  • クラスタ化表がサポートされていません。

  • パラレルでのUPDATE、DELETEおよびMERGE操作は、プライベート一時表に対してはサポートされていません。

  • 表がパーティション化されていない場合、パラレルDMLは、ビットマップ索引を使用した表でサポートされません。

ノート:

Oracle Database 23ai以降では、ダイレクト・パス・インサート後のDMLおよびPDMLに関して、以前の制限事項がいくつかなくなりました。ダイレクト・パス・インサートの直後に次のことを実行できるようになりました。
  • セッション内の同じ表に対する1つ以上のPDMLの後に表を複数回問い合せます。
  • 同じセッション内で同じ表に対して従来型のDML (シリアルおよびパラレル)を実行する。
  • 同じセッション内で同じ表に対して複数のダイレクト・ロード(シリアルおよびパラレル)を実行する。
なお、次の条件を満たす場合は、前述の制限事項がなくなります:
  • 表がヒープ表である。
  • 表が、SEGMENT SPACE MANAGEMENT AUTOおよびAUTOALLOCATEで作成された表領域にある。
  • 初期化パラメータCOMPATIBLEが23.0以上に設定されている。
8.5.3.9.1 パーティション化キーの制限

パーティション表のパーティション化キーを新しい値に更新できるのは、更新によってその行が新しいパーティションに移動されない場合のみです。

表定義で行移動の句が有効になっている場合は更新が可能です。

8.5.3.9.2 関数の制限

パラレルDMLの関数の制限は、パラレルDDLおよびパラレル問合せの関数の制限と同じです。

詳細は、「関数のパラレル実行について」を参照してください。

8.5.3.10 データ整合性の制限

このトピックでは、整合性制約とパラレルDML文の相互作用について説明します。

この項の内容は次のとおりです。

8.5.3.10.1 NOT NULLおよびCHECK

このトピックでは、NOT NULLおよびCHECKの整合性制約について説明します。

NOT NULLおよびCHECKの整合性制約は許可されます。列レベルおよび行レベルそれぞれで施行されるため、パラレルDMLでは問題になりません。

8.5.3.10.2 UNIQUEおよびPRIMARY KEY

このトピックでは、UNIQUEおよびPRIMARY KEYの整合性制約について説明します。

UNIQUEおよびPRIMARY KEYの整合性制約は許可されます。

8.5.3.10.3 FOREIGN KEY(参照整合性)

参照整合性の制限が発生するのは、ある表に対するDML操作が別の表に対して再帰的なDML操作を引き起こす可能性があるときです。

整合性チェックを実行するために、変更対象のオブジェクトに行われるすべての変更を同時に確認する必要がある場合にも、この制限が適用されます。

表8-1に、参照整合性制約に関連する表に対して実行可能なすべての操作を示します。

表8-1 参照整合性の制限

DML文 親での発行 子での発行 自己参照型

INSERT

(該当せず)

パラレル化なし

パラレル化なし

MERGE

(該当せず)

パラレル化なし

パラレル化なし

UPDATE No Action

サポートされている

サポートされている

パラレル化なし

DELETE No Action

サポートされている

サポートされている

パラレル化なし

DELETE Cascade

パラレル化なし

(該当せず)

パラレル化なし
8.5.3.10.4 削除カスケード

このトピックでは、削除カスケード・データ整合性制限について説明します。

外部キーを含む表に対する削除カスケードを使用した削除はパラレル化されません。パラレル実行サーバーが、複数のパーティション(親表および子表)から行を削除しようとするためです。

8.5.3.10.5 自己参照型整合性

自己参照型整合性制約のある表に対するDMLは、参照されるキー(主キー)に関係する場合はパラレル化されません。

その他すべての列に対するDMLでは並列処理が可能です。

8.5.3.10.6 遅延可能整合性制約

このトピックでは、遅延可能整合性制約について説明します。

操作対象の表に遅延可能制約が適用される場合、DML操作はパラレルで実行されません。

8.5.3.11 トリガーの制限

影響する表に有効なトリガーが含まれており、DML文の結果によってトリガーが起動される可能性がある場合、そのDML操作はパラレルで実行されません。

つまり、レプリケート中の表に対するDML文はパラレル化されません。

表に対するDMLをパラレル化するには関連するトリガーを無効にしておく必要があります。トリガーを有効または無効にすると、従属する共有カーソルが無効化されます。

8.5.3.12 分散トランザクションの制限

このトピックでは、分散トランザクションの制限について説明します。

DML操作が分散トランザクションに含まれる場合、またはDMLまたは問合せ操作の対象がリモート・オブジェクトである場合、そのDML操作はパラレルで実行できません。

8.5.3.13 分散トランザクション並列処理の例

このトピックでは、分散トランザクション処理の例をいくつか説明します。

最初の例では、DML文がリモート・オブジェクトを問い合せます。DML操作はリモート・オブジェクトを参照しているため、通知なくシリアルで実行されます。

INSERT /*+ APPEND PARALLEL (t3,2) */ INTO t3 SELECT * FROM t4@dblink;

次の例では、DML操作がリモート・オブジェクトに適用されます。DELETE操作はリモート・オブジェクトを参照しているため、パラレル化されません。 

DELETE /*+ PARALLEL (t1, 2) */ FROM t1@dblink;

最後の例では、DML操作が分散トランザクションに含まれます。DELETE操作は分散トランザクション(SELECT文によって開始される)で実行されるため、パラレルで実行されません。 

SELECT * FROM t1@dblink; 
 DELETE /*+ PARALLEL (t2,2) */ FROM t2;
 COMMIT;
8.5.3.14 UNION ALLの同時実行

UNIONやUNION ALLなどの集合演算子は、単一のSQL文に結合される複数の問合せ(分岐)で構成されます。

従来、集合演算子は順に処理されます。個々の分岐をシリアルまたはパラレルで処理できますが、一度に1つの分岐のみで順に処理されます。この方法は多くのユースケースを満たしますが、UNIONまたはUNION ALL文の複数の分岐の処理を同時に実行する状況があります。ほとんどの一般的な状況は、複数またはすべての分岐がリモートのSQL文である場合です。この状況では、すべての参加するリモート・システムの同時処理は、参加するシステムのワークロードを増やさずに処理時間全体の処理速度を上げるよう求められます。

UNIONまたはUNION ALL文の同時実行のデフォルト動作は、OPTIMIZER_FEATURES_ENABLE初期化パラメータの設定によって制御されます。12.1.0.1以上に設定すると、同時実行がデフォルトで有効になります。少なくとも1つの分岐の文がローカルでパラレルの処理が考慮される文は、UNIONまたはUNION ALL文全体も同時に処理されます。システムは個々のローカル分岐の文のDOPを計算し、UNIONまたはUNION ALL文全体の実行のDOPの最大値を選択します。次に、システムは、パラレルで処理される分岐のパラレル化およびシリアルおよびリモート文の同時ワーカーに選択されたDOPを使用して、できるだけ多くの分岐を同時に処理します。

OPTIMIZER_FEATURES_ENABLE初期化パラメータが12.1.0.1より小さい値に設定されている場合、UNIONまたはUNION ALL文の同時実行は、PQ_CONCURRENT_UNIONヒントを使用して明示的に有効にする必要があります。

ただし、1つずつの分岐の連続処理とは異なり、同時処理は個々の分岐の結果の順序付けられた戻りを保証しません。1つずつの分岐の順序付けられた戻りが必要な場合、NO_PQ_CONCURRENT_UNIONヒントを使用して同時処理を無効にするか、SQL文を拡張して個々の分岐の文を一意に識別してその指定された識別子でソートする必要があります。

特にPQ_CONCURRENT_UNIONヒントを使用しないかぎり、シリアルまたはリモート分岐のみで構成されるUNIONまたはUNION ALL文は同時に処理されません。このSQL文のDOPは、最大でシリアルおよびリモート入力の数です。

UNIONまたはUNION ALL文の同時処理が発生するかどうかは、SQL文の実行計画で簡単に識別できます。パラレルで実行される場合、シリアルおよびリモート分岐の実行は、PX SELECTORとして識別可能な行ソースで管理されます。同時に処理されない文は、シリアルおよびリモート分岐のコーディネータとして問合せコーディネータ(QC)を示します。

例8-4では、SQL文はローカルおよびリモート分岐で構成されています。SQL文は、ローカル・データベースのゴールドおよびプラチナ顧客の情報およびリモート・データベースの3つの主要都市の顧客の情報をロードします。ローカルSELECT文がパラレルで発生するため、この処理はパラレルで自動的に実行されます。各シリアル分岐は、1つのパラレル実行サーバー・プロセスのみによって実行されます。各パラレル実行サーバーは1つのシリアル分岐を実行できるため、同時に実行されます。

例8-4 UNION ALLの実行計画

SQL> EXPLAIN PLAN FOR INSERT INTO all_customer 
  SELECT * FROM GOLD_customer UNION ALL 
  SELECT * FROM PLATINUM_customer UNION ALL 
  SELECT * FROM SF_customer@san_francisco UNION ALL 
  SELECT * FROM LA_customer@los_angeles UNION ALL 
  SELECT * FROM LV_customer@las_vegas;
-------------------------------------------------------------------------------
| Id | Operation              | Name          | TQ/Ins |IN-OUT | PQ Distrib|
-------------------------------------------------------------------------------
| 0 | INSERT STATEMENT         |              |        |       |           |
| 1 |  LOAD TABLE CONVENTIONAL | ALL_CUSTOMER |        |       |           |
| 2 |   PX COORDINATOR         |              |        |       |           |
| 3 |    PX SEND QC (RANDOM)   | :TQ10003     |        | P->S  | QC (RAND) |
| 4 |     UNION-ALL            |              |        | PCWP  |           |
| 5 |      PX BLOCK ITERATOR   |              |        | PCWC  |           |
| 6 |       TABLE ACCESS FULL  | GOLD_CUSTOMER|        | PCWP  |           |
| 7 |      PX BLOCK ITERATOR   |              |        | PCWC  |           |
| 8 |       TABLE ACCESS FULL  | PLATINUM_CUST|        | PCWP  |           |
| 9 |      PX SELECTOR         |              |        | PCWP  |           |
|10 |       REMOTE             | SF_CUSTOMER  |        | PCWP  |           |
|11 |      PX SELECTOR         |              |        | PCWP  |           |
|12 |       REMOTE             | LA_CUSTOMER  |        | PCWP  |           |
|13 |      PX SELECTOR         |              |        | PCWP  |           |
|14 |       REMOTE             | LV_CUSTOMER  |        | PCWP  |           |
-------------------------------------------------------------------------------

8.5.4 関数のパラレル実行について

SQL文には、PL/SQLまたはJavaで作成したユーザー定義関数、あるいはCで作成した外部プロシージャとしてのユーザー定義関数を含めることができます。これらは、SELECTリスト、SET句またはWHERE句に指定できます。

SQL文がパラレル化されると、このような関数はパラレル実行サーバー・プロセスによって1行ずつ実行されます。関数で使用されるPL/SQLパッケージ変数またはJava静的属性は、完全に個々のパラレル実行プロセスのみで使用され、元のセッションからコピーされるのではなく各行が処理されるたびに新たに初期化されます。この処理のため、パラレルで実行した場合、すべての関数によって正しい結果が生成されるとはかぎりません。

ユーザーが作成した表関数を文のFROMリストに指定できます。このような関数は、行出力を生成するためソース・テーブルのように機能します。表関数はその文で1回、各パラレル実行プロセスの開始時に初期化されます。すべての変数は、対応するパラレル実行プロセスでしか使用されません。

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

8.5.4.1 パラレル問合せでの関数

ユーザー関数は、SQL問合せ文またはDMLまたはDDL文の副問合せでパラレルで実行できます。

SELECT文、あるいはDMLまたはDDL文の副問合せでは、次の場合にユーザー作成関数がパラレルで実行されることがあります。

  • PARALLEL_ENABLEキーワードで宣言された場合。

  • パッケージまたはタイプで宣言され、PRAGMA RESTRICT_REFERENCES句にWNDS、RNPSおよびWNPSのすべてが指定された場合。

  • CREATE FUNCTIONで宣言され、システムがPL/SQLコードの本体を分析して、コードがデータベースに書き込まず、パッケージ変数の読取りや変更も行わないことを判別できた場合。

関数の実行をシリアルで行うことが必要な場合でも、問合せまたは副問合せの他の部分はパラレルで実行されることがあります。

関連項目:

8.5.4.2 パラレルDMLおよびDDL文での関数

ユーザー関数は、特定の条件下でDMLまたはDDL文で実行できます。

パラレルDMLまたはDDL文においても、パラレル問合せと同じく、次の場合にユーザー作成関数がパラレルで実行されることがあります。

  • PARALLEL_ENABLEキーワードで宣言された場合。

  • パッケージまたはタイプで宣言され、PRAGMA RESTRICT_REFERENCES句にRNDS、WNDS、RNPSおよびWNPSのすべてが指定された場合。

  • CREATE FUNCTION文で宣言され、システムがPL/SQLコードの本体を分析して、コードがデータベースに読取りや書込みを行わず、パッケージ変数の読取りや変更も行わないことを判別できた場合。

パラレルDML文の場合、パラレルで実行できない関数コールが含まれていると、そのDML文全体がシリアルで実行されます。INSERT SELECT文またはCREATE TABLE AS SELECT文の場合は、ここで説明したパラレル問合せルールに従って、問合せ部分の関数コールはパラレル化されます。文のその他の部分をシリアルで実行する必要があっても、問合せはパラレル化できます。または、その逆の場合もあります。

8.5.5 その他の並列処理の種類について

Oracle Databaseは、複数の操作タイプでパラレル処理を使用できます。

パラレルSQL実行の他に、Oracle Databaseは次の操作について並列処理を使用できます。

  • パラレル・リカバリ

  • パラレル伝播(レプリケーション)

  • パラレル・ロード(外部表およびSQL*Loaderユーティリティ)

パラレルSQLと同じく、 パラレル・リカバリ、パラレル伝播およびパラレル外部表ロードは、パラレル実行コーディネータと複数のパラレル実行サーバーによって実行されます。ただし、SQL*Loaderを使用したパラレル・ロードでは異なるメカニズムが使用されます。

パラレル実行コーディネータとパラレル実行サーバーの動作は、実行する操作の種類(SQL、リカバリまたは伝播)に応じて変わることがあります。たとえば、プールのすべてのパラレル実行サーバーが占有されており、最大数のパラレル実行サーバーが起動されている場合は、次のようになります。

  • パラレルSQLおよび外部表ロードでは、パラレル実行コーディネータがシリアル処理に切り替えます。

  • パラレル伝播では、パラレル実行コーディネータがエラーを返します。

1つのセッションで、パラレル実行コーディネータは1種類の操作のみを調整します。たとえば、パラレル実行コーディネータは、パラレルSQLとパラレル・リカバリまたはパラレル伝播を同時に調整することはできません。

関連項目:

8.5.6 SQL文の並列度ルール

SQL文のパラレル化決定には、パラレル化の決定と並列度(DOP)という2つの要素があります。

これらの要素の決定方法は、問合せ、DDL操作およびDML操作で異なります。

次の各項で、並列度について説明します。

各種SQL文の並列度は、文レベルまたはオブジェクト・レベルのPARALLELヒント、PARALLEL句、ALTER SESSION FORCE PARALLEL文、自動並列度(自動DOP)、または表や索引のPARALLEL宣言によって決定できます。これらの方法のうち複数を使用する場合、Oracle Databaseでは、優先順位ルールを使用して、DOPの決定に使用する方法が決定されます。

表8-2には、各種SQL文の並列度(DOP)を決定するための優先順位ルールを示します。この表では、方法の優先順位番号が小さいほうが、大きい番号よりも優先されます。たとえば、優先度(1)は、優先度(2)、優先度(3)、優先度(4)および優先度(5)よりも優先されます。

表8-2 パラレル化の優先順位

パラレル操作 文レベルのPARALLELヒント オブジェクト・レベルのPARALLELヒント PARALLEL句 ALTER SESSION 自動DOP パラレル宣言

パラレル問合せ表/索引スキャン。詳細は、問合せのパラレル化のルールを参照してください。

優先度(1)

優先度(2)

N/A

優先度(3) FORCE PARALLEL QUERY

優先度(4)

優先度(5)

パラレルUPDATE、DELETEまたはMERGE。詳細は、UPDATE、MERGEおよびDELETEのルールを参照してください。

優先度(1)

優先度(2)

N/A

優先度(3) FORCE PARALLEL DML

優先度(4)

優先度(5)のターゲット表

パラレルINSERT... SELECTのINSERT操作。詳細は、INSERT SELECTのルールを参照してください。

優先度(1)

優先度(2)

N/A

優先度(3) FORCE PARALLEL DML

優先度(4)

挿入対象となる優先度(5)の表

INSERTがシリアルの場合の、INSERT SELECTのSELECT操作。詳細は、INSERT SELECTのルールを参照してください。

優先度(1)

優先度(2)

N/A

優先度(3) FORCE PARALLEL QUERY

優先度(4)

選択対象となる優先度(5)の表

パラレルCREATE TABLE AS SELECTのCREATE操作(パーティション表または非パーティション表)詳細は、CREATE TABLE AS SELECTのルールを参照してください。

優先度(1)

N/A

優先度(4)

優先度(2) FORCE PARALLEL DDL

優先度(3)

N/A

CREATEがシリアルの場合の、CREATE TABLE AS SELECTのSELECT操作。詳細は、CREATE TABLE AS SELECTのルールを参照してください。

優先度(1)

優先度(2)

N/A

優先度(3) FORCE PARALLEL QUERY

優先度(4)

優先度(5)

その他のDDL操作。詳細は、DDL文のルールを参照してください。

N/A

N/A

優先度(3)

優先度(1) FORCE PARALLEL DDL

優先度(2)

N/A

関連項目:

8.6 パラレル実行のためのパラメータの初期化とチューニングについて

パラメータを使用して、パラレル実行を初期設定およびチューニングできます。

Oracle Databaseでは、データベース起動時のCPU_COUNTとPARALLEL_THREADS_PER_CPUの値に基づいて、パラレル実行パラメータのデフォルトを計算します。パラメータを手動でチューニングして、特定のシステム構成またはパフォーマンス目標に合うように値を増減することもできます。たとえば、パラレル実行がまったく使用されないシステムではPARALLEL_MAX_SERVERSを0に設定できます。

パラレル実行パラメータを手動でチューニングすることもできます。パラレル実行はデフォルトで有効になっています。

パラレル実行の初期設定およびチューニングについては、次のトピックで説明します。

8.6.1 デフォルトのパラメータ設定

Oracle Databaseでは、パラレル実行パラメータがデフォルトで自動設定されます。

パラレル実行のパラメータを表8-3に示します。

表8-3パラメータとデフォルト値

パラメータ デフォルト コメント

PARALLEL_ADAPTIVE_MULTI_USER

FALSE

パラレル実行によりSQLの並列度(DOP)リクエストの数を制限し、システムのオーバーロードを回避します。

PARALLEL_ADAPTIVE_MULTI_USERは、Oracle Database 12cリリース2 (12.2.0.1)で非推奨となり、将来のリリースではサポートされなくなります。かわりに、パラレル文のキューイングを使用することをお薦めします。

PARALLEL_DEGREE_LIMIT

CPU

自動DOPが使用された場合に、文に許可されるDOPの最大値を制御します。最大DOPは、次のとおりです。 

SUM(CPU_COUNT)*PARALLEL_THREADS_PER_CPU

PARALLEL_DEGREE_LIMITの値AUTOには、値CPUと同じ機能があります。

PARALLEL_DEGREE_POLICY

MANUAL

自動DOP、パラレル文のキューイングおよびインメモリー・パラレル実行を使用するかどうかを制御します。デフォルトでは、これらの機能はすべて無効化されています。

PARALLEL_EXECUTION_MESSAGE_SIZE

16 KB

パラレル実行サーバー、およびパラレル実行サーバーと問合せコーディネータの通信に使用されるバッファのサイズを指定します。これらのバッファは、共有プールの中から割り当てられます。

PARALLEL_FORCE_LOCAL

FALSE

パラレル実行を現在のOracle RACインスタンスに制限します。
PARALLEL_INSTANCE_GROUP なし。デフォルトでは、現在アクティブなすべてのインスタンスでパラレル実行が有効になっています。 パラレル問合せ操作をインスタンスの制限数に制限できます。サービスおよび非推奨のパラメータINSTANCE_GROUPSとともに使用します。

PARALLEL_MAX_ SERVERS

PARALLEL_MAX_SERVERSを参照してください。

1インスタンスに対するパラレル実行プロセスとパラレル・リカバリ・プロセスの最大数が指定されます。需要が増加するにつれて、インスタンスの起動時に作成された数からこの値までプロセス数が増加します。

このパラメータの設定が低すぎると、問合せが処理中に十分なパラレル実行プロセスを得られない場合があります。設定が高すぎると、ピーク時にメモリー・リソース不足が発生してパフォーマンスが低下する可能性があります。
PARALLEL_MIN_DEGREE 1 自動並列度によって計算される最小並列度を制御します。

PARALLEL_MIN_SERVERS

CPU_COUNT * PARALLEL_THREADS_PER_CPU * 2

Oracle Databaseの起動時に、パラレル実行のために起動および予約するパラレル実行プロセス数を指定します。この設定の値を大きくすると、パラレル文の起動コストを均衡化するのに役立ちますが、パラレル実行プロセスはデータベースが停止されるまで削除されないため、必要なメモリー使用量は増大します。

PARALLEL_MIN_PERCENT

0

パラレル実行に必要なリクエストされたパラレル実行プロセスの最小パーセンテージを指定します。デフォルト値は0で、使用可能なパラレル・サーバー・プロセスがない場合、パラレル文はシリアルで実行されます。

PARALLEL_MIN_TIME_THRESHOLD

AUTO

オプティマイザによって見積もられた実行時間を指定します。これより大きい値の場合、文は自動パラレル問合せおよび自動DOP導出の候補となります。AUTOの解釈は、データベース・インメモリーが使用されているかどうかによって異なります。

PARALLEL_SERVERS_TARGET

PARALLEL_SERVERS_TARGETを参照してください。

パラレル文のキューイングが使用されるまでに問合せを実行するのに使用可能なパラレル実行サーバー・プロセスの数を指定します。文のキューイングは、PARALLEL_DEGREE_POLICYがAUTOに設定されている場合にのみアクティブ化されることに注意してください。

PARALLEL_THREADS_PER_CPU

1

パラレル実行中にCPUが処理できるパラレル実行プロセスまたはスレッドの数を示します。

一部のパラメータの設定方法によってはOracle Databaseが制約を受けます。たとえば、PROCESSESを20に設定すると、25個の子プロセスを取得できなくなります。

関連項目:

初期化パラメータの詳細は、Oracle Databaseリファレンスを参照

8.6.2 セッションでのパラレル実行の強制

セッションでのパラレル実行を強制できます。

パラレルで実行する必要があるが、表に対するDOPの設定または関連する問合せの変更を避けたい場合は、次の文を使用して並列処理を強制できます。

ALTER SESSION FORCE PARALLEL QUERY;

この後のすべての問合せは、制限に違反しないかぎりパラレルで実行されます。DML文およびDDL文も強制できます。この句は、セッションの後続の文に指定されるすべてのパラレル句よりも優先されますが、パラレル・ヒントに対しては優先されません。

たとえば、一般的なOLTP環境では表にはパラレルの設定がありませんが、毎晩バッチ・スクリプトを使用してこのような表からデータをパラレルで収集する場合があります。セッション中にDOPを設定することで、ユーザーは、各表をパラレルで変更してから、終了時にシリアルに戻す必要がなくなります。

8.6.3 パラレル実行のための一般的なパラメータのチューニング

このトピックでは、パラレル実行の一般的なパラメータのチューニングについて説明します。

この項の内容は次のとおりです。

8.6.3.1 パラレル操作のリソース制限を設定するパラメータ

リソース制限を決定するための初期化パラメータを設定できます。

リソース制限を設定するパラメータを次で説明します。

関連項目:

初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください

8.6.3.1.1 PARALLEL_FORCE_LOCAL

PARALLEL_FORCE_LOCALパラメータは、パラレルで実行されるSQL文がOracle RAC環境のシングル・インスタンスに制限されるかどうかを示します。

このパラメータをTRUEに設定することにより、問合せコーディネータが実行しているシングルOracle RACインスタンスのために処理されるパラレル・スレーブのスコープを制限できます。

PARALLEL_FORCE_LOCALパラメータの推奨値はFALSEです。

関連項目:

PARALLEL_FORCE_LOCAL初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください

8.6.3.1.2 PARALLEL_MAX_SERVERS

PARALLEL_MAX_SERVERSパラメータには、1つのインスタンスに対するパラレル実行プロセスおよびパラレル・リカバリ・プロセスの最大数を指定します。

需要が増加するにつれて、インスタンスの起動時に作成された数からこの値までプロセス数が増加します。

たとえば、この値を64に設定した場合、各問合せが2つのワーカー・セットを使用し、各セットのDOPが8とすると、4つのパラレル問合せを同時に実行できるようになります。

ユーザーのプロセスが多すぎる場合

同時ユーザーの問合せサーバー・プロセスが多すぎると、メモリー競合(ページング)、I/O競合または過剰なコンテキストのスイッチングが発生することがあります。

この競合により、パラレル実行が使用されなかった場合のレベルよりもシステム・スループットが低下する可能性があります。PARALLEL_MAX_SERVERS値を増やすのは、それによって生成されるロードのための十分なメモリーおよびI/O帯域幅がシステムにある場合のみにしてください。

オペレーティング・システムのパフォーマンス・モニタリング・ツールを使用すると、メモリー、スワップ領域およびI/O帯域幅の空き状況を判別できます。CPUとディスク両方の実行キューの長さ、およびシステムのI/O処理のサービス時間を調べます。プロセスを追加する場合は、システムに十分なスワップ領域があることを確認します。問合せサーバー・プロセスの総数を制限すると、パラレル操作を実行できる同時ユーザー数が制限されることがありますが、システム・スループットは安定するようになります。

コンシューマ・グループを使用したユーザーに対するリソース数の制限時期

必要な場合、ユーザーに対してリソース・コンシューマ・グループを設定することで、所定のユーザーが使用可能な並列処理の量を制限できます。

これは、1ユーザーまたは1ユーザー・グループが使用できる、セッション数、同時ログオンおよびパラレル・プロセス数を制限するために行います。

パラレル実行文を処理する各問合せサーバー・プロセスは、セッションIDを使用してログオンしています。各プロセスは、ユーザーの同時セッションの制限に対してカウントされます。たとえば、あるユーザーが使用できるパラレル実行プロセスを10個に制限するには、ユーザーの制限を11に設定します。1プロセスがパラレル実行コーディネータ用、その他の10プロセスが2セットの問合せサーバーを構成します。こうすると、パラレル実行コーディネータが1セッション、パラレル実行プロセスが10セッションを使用できます。

関連項目:

8.6.3.1.3 PARALLEL_MIN_PERCENT

PARALLEL_MIN_PERCENTパラメータにより、使用中のアプリケーションに応じて、許容できるDOPを待機できます。

PARALLEL_MIN_PERCENTパラメータの推奨値は0です。このパラメータを0以外の値に設定すると、リクエストされたDOPがその時点でシステムによって実現されない場合、Oracle Databaseがエラーを返します。たとえば、PARALLEL_MIN_PERCENTを50(50パーセント)に設定したときに、マルチユーザー問合せ調整アルゴリズムまたはリソース制限によってDOPが50パーセントを超えて低減されると、Oracle DatabaseによってORA-12827が返されます。たとえば: 

SELECT /*+ FULL(e) PARALLEL(e, 8) */ d.department_id, SUM(SALARY)
  FROM employees e, departments d WHERE e.department_id = d.department_id
  GROUP BY d.department_id ORDER BY d.department_id;

Oracle Databaseから次のメッセージが返されます。

ORA-12827: insufficient number of parallel execution servers

関連項目:

PARALLEL_MIN_PERCENT初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください

8.6.3.1.4 PARALLEL_MIN_SERVERS

PARALLEL_MIN_SERVERSパラメータは、1つのインスタンスで、パラレル操作のために起動および予約するプロセス数を指定します。

PARALLEL_MIN_SERVERSの設定により、メモリー使用量と起動コストのバランスを保つことができます。PARALLEL_MIN_SERVERSを使用して起動されるプロセスは、データベースが停止されるまで終了しません。これによって、問合せが発行されるときには、多くの場合、プロセスが使用可能になっています。

関連項目:

PARALLEL_MIN_SERVERS初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください

8.6.3.1.5 PARALLEL_MIN_TIME_THRESHOLD

PARALLEL_MIN_TIME_THRESHOLDパラメータには、文が自動並列度の対象とみなされるまでの最小実行時間を指定します。

関連項目:

PARALLEL_MIN_TIME_THRESHOLD初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください

8.6.3.1.6 PARALLEL_SERVERS_TARGET

PARALLEL_DEGREE_POLICYパラメータは、パラレル文のキューイングが使用されるまでにパラレル文を実行できるパラレル・サーバー・プロセスの数を指定します。

PARALLEL_DEGREE_POLICYがAUTOに設定されていると、システムで現在使用されているパラレル・プロセスの数がPARALLEL_SERVERS_TARGET以上の場合、パラレル実行の必要な文はキューに入れられます。これはシステムで許可されているパラレル・サーバー・プロセスの最大数ではありません(それはPARALLEL_MAX_SERVERSによって制御されます)。ただし、PARALLEL_SERVERS_TARGETおよびパラレル文のキューイングを使用すると、パラレル実行の必要なそれぞれの文が必要なパラレル・サーバー・リソースに割り当てられ、パラレル・サーバー・プロセスの過多によるフラッドを防止できます。

関連項目:

PARALLEL_SERVERS_TARGET初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください

8.6.3.1.7 SHARED_POOL_SIZE

SHARED_POOL_SIZEパラメータは、共有プールのメモリー・サイズを指定します。

パラレル実行では、シリアルSQL実行で必要なメモリー・リソースに加えてさらにメモリー・リソースが必要です。追加のメモリーは、問合せサーバー・プロセスと問合せコーディネータ間での通信とデータの受渡しに使用されます。

Oracle Databaseによって、共有プールから問合せサーバー・プロセスにメモリーが割り当てられます。次のように共有プールをチューニングします。

  • 共有プールの他のクライアント(共有カーソルやストアド・プロシージャなど)を考慮します。

  • 大きな値ではマルチユーザー・システムでのパフォーマンスが向上しますが、小さな値ではメモリー使用量が減ることに注意します。

  • その後、パラレル実行で使用されるバッファ数を監視し、shared pool PX msg poolと、ビューV$PX_PROCESS_SYSSTATの出力に示されている現在の最高水位標を比較します。

    ノート:

    使用可能な十分なメモリーがない場合は、エラー・メッセージ12853(「PXバッファのメモリーが不足しています: 現在はstringKBですが、最大stringKBが必要です」)が生成されます。これは、PXバッファのためのSGAメモリーが十分でない場合に発生します。少なくとも(MAX - CURRENT)バイトを追加するようにSGAメモリーを再構成する必要があります。

デフォルトでは、Oracle Databaseはパラレル実行バッファを共有プールから割り当てます。

Oracle Databaseで起動時に次のエラーが表示された場合、SHARED_POOL_SIZEの値を、データベースが起動できるように十分に下げる必要があります。 

ORA-27102: out of memory 
SVR4 Error: 12: Not enough space

SHARED_POOL_SIZEの値を下げた後で、次のエラーが発生する場合があります。 

ORA-04031: unable to allocate 16084 bytes of shared memory 
   ("SHARED pool","unknown object","SHARED pool heap","PX msg pool")

その場合は、次の問合せを実行して、Oracle Databaseが16,084バイトを割り当てられなかった理由を判別します。

SELECT NAME, SUM(BYTES) FROM V$SGASTAT WHERE UPPER(POOL)='SHARED POOL' 
  GROUP BY ROLLUP (NAME);

出力は次のようになります。

NAME                       SUM(BYTES) 
-------------------------- ---------- 
PX msg pool                   1474572 
free memory                    562132
                              2036704

SHARED_POOL_SIZEを指定したときに、保持するよう指定したメモリー容量がプールよりも大きい場合、Oracle Databaseでは、取得できるメモリーのすべてを割り当てません。一部の領域が残されます。問合せが実行されるとき、Oracle Databaseは必要なメモリーを取得しようとします。Oracle Databaseは560KBを使用し、失敗するとさらに16KBが必要になります。このエラーでは、必要とされた容量の累積は報告されません。必要な追加メモリー容量を判別する最適な方法としては、「メッセージ・バッファの追加メモリー要件」の式を使用します。

この例の問題を解決するには、SHARED_POOL_SIZEの値を増やします。サンプル出力に表示されるように、SHARED_POOL_SIZEは約2MBです。使用可能なメモリー容量によって異なりますが、SHARED_POOL_SIZEの値を4MBに増やしてから、データベースの起動を試行してください。Oracle Databaseで引き続きORA-4031メッセージが表示される場合は、起動が成功するまでSHARED_POOL_SIZEの値を次第に増やします。

関連項目:

SHARED_POOL_SIZE初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください

8.6.3.1.8 メッセージ・バッファの追加メモリー要件

このトピックでは、パラレル実行計画を使用する際のメッセージ・バッファおよびカーソル用の追加メモリー要件について説明します。

共有プールの初期設定を決定したら、メッセージ・バッファの追加メモリー要件を計算し、カーソル用に必要な追加領域の容量を決定する必要があります。

メッセージ・バッファに必要なメモリー

メッセージ・バッファを収容できるようにSHARED_POOL_SIZEパラメータの値を増やす必要があります。メッセージ・バッファによって、問合せサーバー・プロセスが相互に通信できます。

Oracle Databaseでは、プロデューサ問合せサーバーとコンシューマ問合せサーバーの間の仮想接続ごとに一定数のバッファが使用されます。接続数は、DOPの増加に合せてその2乗の数に増加します。この理由から、パラレル実行で使用されるメモリーの最大容量は、システムで許可されるDOPの最大値によって制限されます。この値を制御するには、PARALLEL_MAX_SERVERSパラメータを使用するか、ポリシーとプロファイルを使用します。

必要なメモリー容量を計算するには、次のいずれかの計算式を使用します。

  • SMPシステム:

    mem in bytes = (3 x size x users x groups x connections)

  • Oracle Real Application ClustersおよびMPPシステム:

    mem in bytes = ((3 x local) + (2 x remote)) x (size x users x groups) 
  / instances

各インスタンスで、この式で計算されたメモリーが使用されます。

用語の意味は次のとおりです:

  • SIZE = PARALLEL_EXECUTION_MESSAGE_SIZE

  • USERS = DOPが最適な場合に実行が予想される同時パラレル実行ユーザー数

  • GROUPS = 各問合せで使用される問合せサーバー・プロセス・グループ数

    単純なSQL文で必要になるのは1グループのみです。ただし、問合せに関連する副問合せがパラレルで処理される場合、Oracle Databaseはもう1つの問合せサーバー・プロセス・グループを使用します。

  • CONNECTIONS = (DOP2 + 2 x DOP)

    システムがクラスタまたはMPPの場合は、インスタンス数を考慮する必要があります。インスタンス数によってDOPが増加するためです。つまり、2つのインスタンス・クラスタでDOPを4にすると、結果としてDOPが8になります。控えめな見積りとして、初期値にはPARALLEL_MAX_SERVERSとインスタンス数を掛けて4で割った値を使用することをお薦めします。

  • LOCAL = CONNECTIONS/INSTANCES

  • REMOTE = CONNECTIONS - LOCAL

共有プールの元の設定にこの容量を追加します。ただし、これらのメモリー構造体いずれかの値を設定する前に、次の項で説明するカーソル用の追加メモリーも考慮する必要があります。

カーソルの追加メモリー

パラレル実行計画は、シリアル実行計画よりもSQL領域を多く消費します。共有プール・リソース使用状況を定期的に監視して、メッセージとカーソルの両方で使用されるメモリーがシステムの処理要件を満たすことを確認します。

8.6.3.1.9 処理開始後のメモリー使用状況の監視

自動チューニングと手動チューニングのどちらを使用するにしても、実行時の使用状況を監視して、メモリーのサイズが大きすぎないか、小さすぎないかを確認する必要があります。

この項の計算式はあくまで開始値を設定するためのものです。正しいメモリー・サイズを確認するため、次の問合せを使用して共有プールをチューニングします。 

SELECT POOL, NAME, SUM(BYTES) FROM V$SGASTAT WHERE POOL LIKE '%pool%'
  GROUP BY ROLLUP (POOL, NAME);

出力は次のようになります。 

POOL        NAME                       SUM(BYTES) 
----------- -------------------------- ---------- 
shared pool Checkpoint queue                38496 
shared pool KGFF heap                        1964 
shared pool KGK heap                         4372 
shared pool KQLS heap                     1134432 
shared pool LRMPD SGA Table                 23856 
shared pool PLS non-lib hp                   2096 
shared pool PX subheap                     186828 
shared pool SYSTEM PARAMETERS               55756 
shared pool State objects                 3907808 
shared pool character set memory            30260 
shared pool db_block_buffers               200000 
shared pool db_block_hash_buckets           33132 
shared pool db_files                       122984 
shared pool db_handles                      52416 
shared pool dictionary cache               198216 
shared pool dlm shared memory             5387924 
shared pool event statistics per sess      264768 
shared pool fixed allocation callback        1376 
shared pool free memory                  26329104 
shared pool gc_*                            64000 
shared pool latch nowait fails or sle       34944 
shared pool library cache                 2176808 
shared pool log_buffer                      24576 
shared pool log_checkpoint_timeout          24700 
shared pool long op statistics array        30240 
shared pool message pool freequeue         116232 
shared pool miscellaneous                  267624 
shared pool processes                       76896 
shared pool session param values            41424 
shared pool sessions                       170016 
shared pool sql area                      9549116 
shared pool table columns                  148104 
shared pool trace_buffers_per_process     1476320 
shared pool transactions                    18480 
shared pool trigger inform                  24684 
shared pool                              52248968 
                                         90641768

出力に表示されたメモリー使用量を評価し、処理ニーズに基づいてSHARED_POOL_SIZEの設定を変更します。

メモリー使用量の統計をさらに取得するには、次の問合せを実行します。

SELECT * FROM V$PX_PROCESS_SYSSTAT WHERE STATISTIC LIKE 'Buffers%';

出力は次のようになります。

STATISTIC                           VALUE 
-------------------                 ----- 
Buffers Allocated                   23225 
Buffers Freed                       23225 
Buffers Current                         0 
Buffers HWM                          3620

使用されたメモリー容量は、Buffers CurrentとBuffers HWMの統計に表示されます。バッファ数にPARALLEL_EXECUTION_MESSAGE_SIZEの値を掛けた値(バイト数)を計算します。この最高水位標をパラレル実行メッセージ・プール・サイズと比較して、割当てメモリーが多すぎないかを判別します。たとえば、最初の出力で、px msg poolに示されるラージ・プールの値は38,092,812すなわち38MBです。2番目の出力のBuffers HWMは3,620です。これにパラレル実行メッセージ・サイズの4,096を掛けると、14,827,520すなわち約15MBになります。この場合、最高水位標は容量の約40パーセントに達しています。

8.6.3.2 リソース消費に影響するパラメータ

このトピックでは、リソース消費に影響するパラメータについて説明します。

ノート:

次の項を検討する前に、詳細についてMEMORY_TARGETおよびMEMORY_MAX_TARGET初期化パラメータの説明を参照してください。MEMORY_TARGETによってSGAコンポーネントおよびPGAコンポーネントが自動チューニングされるため、PGA_AGGREGATE_TARGET初期化パラメータを設定する必要はありません。

ここで説明するパラメータの最初のグループは、すべてのパラレル操作(特にパラレル実行)のメモリーとリソースの消費に影響します。これらのパラメータは次のとおりです:

パラメータの2つ目のサブセットについては、「パラレルDMLおよびパラレルDDLのリソース消費に影響するパラメータ」で説明しています。

リソース消費を制御するには、次の2つのレベルでメモリーを構成する必要があります。

  • データベース・レベル。データベース・システムがオペレーティング・システムの適切な容量のメモリーを使用できるようにします。

  • オペレーティング・システム・レベル(一貫性のため)。

    プラットフォームによっては、使用可能な仮想メモリーの合計容量(全プロセスの合計)を制御するオペレーティング・システム・パラメータを設定する必要があります。

データ・ウェアハウス操作で使用されるメモリーの大きな部分は(OLTPと比べて)動的に使用されます。このメモリーはプロセス・グローバル領域(PGA)から割り当てられ、プロセス・メモリーのサイズとプロセスの数はどちらも幅広い範囲で変化する可能性があります。そのような場合は、PGA_AGGREGATE_TARGET初期化パラメータを使用して、プロセス・メモリーとプロセス数の両方を制御します。PGA_AGGREGATE_TARGETとMEMORY_TARGETを合せて明示的に設定すると、自動チューニングは行われますが、PGA_AGGREGATE_TARGETが指定値未満になるようにチューニングされることはありません。

関連項目:

8.6.3.2.1 PGA_AGGREGATE_TARGET

PGA_AGGREGATE_TARGETなどの初期化パラメータの設定により、自動PGAメモリー管理を有効にできます。

自動PGAメモリー管理を有効にすると、PGAメモリーの割当て方法が単純化されて強化されます。このモードでは、DBAによって明示的に設定されたPGAメモリー全体の目標に基づいて、Oracle DatabaseがPGAメモリーの作業領域専用部分のサイズを動的に調整します。自動PGAメモリー管理を有効にするには、PGA_AGGREGATE_TARGET初期化パラメータを設定する必要があります。新しいインストールでは、PGA_AGGREGATE_TARGETおよびSGA_TARGETは自動的にDatabase Configuration Assistant (DBCA)によって設定されます。MEMORY_TARGETは0です。つまり、自動メモリー管理は無効になっています。したがって、集計PGAの自動チューニングはデフォルトで有効になっています。ただし、集計PGAは、MEMORY_TARGETを0以外の値に設定して自動メモリー管理を有効にしないかぎり、増えることはありません。

関連項目:

8.6.3.2.1.1 HASH_AREA_SIZE

このパラメータは現在非推奨になっています。

HASH_AREA_SIZEは非推奨です。かわりにPGA_AGGREGATE_TARGETを使用してください。詳細は、PGA_AGGREGATE_TARGETを参照してください。

8.6.3.2.1.2 SORT_AREA_SIZE

このパラメータは現在非推奨になっています。

SORT_AREA_SIZEは非推奨です。かわりにPGA_AGGREGATE_TARGETを使用してください。詳細は、PGA_AGGREGATE_TARGETを参照してください。

8.6.3.2.2 PARALLEL_EXECUTION_MESSAGE_SIZE

PARALLEL_EXECUTION_MESSAGE_SIZEパラメータでは、パラレル実行メッセージで使用されるバッファのサイズを指定します。

PARALLEL_EXECUTION_MESSAGE_SIZEのデフォルト値は、オペレーティング・システム固有ですが、通常、16Kです。この値はほとんどのアプリケーションで適切です。

関連項目:

PARALLEL_EXECUTION_MESSAGE_TIME初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください

8.6.3.2.3 パラレルDMLおよびパラレルDDLのリソース消費に影響するパラメータ

このトピックでは、パラレルDMLおよびパラレルDDL操作のリソース消費に影響するパラメータについて説明します。

パラレルDMLおよびパラレルDDLのリソース消費に影響するパラメータを次に示します。

パラレルの挿入、更新および削除操作では、シリアルDML操作よりも多くのリソースが必要です。同じく、PARALLEL CREATE TABLE AS SELECTおよびPARALLEL CREATE INDEXでも、より多くのリソースが必要となることがあります。このため、場合によっては、さらにいくつかの初期化パラメータの値を増やす必要があります。これらのパラメータは問合せのためのリソースには影響しません。

関連項目:

初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください

8.6.3.2.3.1 TRANSACTIONS

TRANSACTIONSパラメータは、パラレルDMLおよびDDLでのトランザクション数に影響します。

パラレルのDMLおよびDDLでは、各問合せサーバー・プロセスがトランザクションを開始します。パラレル実行コーディネータは2フェーズのコミット・プロトコルを使用してトランザクションをコミットします。このため、処理されるトランザクション数はDOPに応じて増加します。この結果、TRANSACTIONS初期化パラメータの値を増やす必要が生じることがあります。

TRANSACTIONSパラメータでは、同時トランザクションの最大数を指定します。TRANSACTIONSのデフォルト値は、並列なしを想定しています。たとえば、DOPが20の場合は、追加の新しいサーバー・トランザクション20(サーバー・セットが2つの場合は40)とコーディネータ・トランザクション1が生成されます。この場合、トランザクションが同一インスタンスで実行されているときは、TRANSACTIONSに21(または41)を加えた値に増やします。このパラメータを設定しない場合は、Oracle Databaseによって値が1.1 x SESSIONSになるように設定されます。サーバー管理のUNDOを使用している場合、この説明は適用されません。

8.6.3.2.3.2 FAST_START_PARALLEL_ROLLBACK

コミットされていないパラレルDMLまたはパラレルDDLトランザクションがあるときにシステムで障害が発生した場合に、FAST_START_PARALLEL_ROLLBACKパラメータを使用して、起動時のトランザクションのリカバリを高速化できます。

FAST_START_PARALLEL_ROLLBACKパラメータは、終了したトランザクションをリカバリするときに使用するDOPを制御します。異常終了したトランザクションとは、システム障害の前にアクティブだったトランザクションです。デフォルトでは、最大でCPU_COUNTパラメータ値の2倍になるようにDOPが選択されます。

このデフォルトDOPが不十分な場合は、パラメータをHIGHに設定します。これにより、最大DOPがCPU_COUNTパラメータの4倍になります。この機能はデフォルトで使用できます。

8.6.3.2.3.3 DML_LOCKS

DML_LOCKSパラメータは、パラレルDML操作によって保持されるロック数を含むように設定する必要があります。

DML_LOCKSパラメータは、DMLロックの最大数を指定します。この値は、すべてのユーザーが参照するすべての表でのロック数の合計と等しくなるように指定する必要があります。パラレルDML操作のロック要件は、シリアルDMLの要件と大きく異なります。パラレルDMLで保持されるブロックはかなり多いため、DML_LOCKSパラメータの値を倍量に増やす必要があります。

ノート:

ターゲット表の表ロックが使用禁止の場合、パラレルDML操作は実行されません。

表8-4に、様々なパラレルDML文ごとにコーディネータとパラレル実行サーバー・プロセスによって取得されるロックの種類を示します。この情報を使用して、このようなパラメータで必要な値を決定することができます。

表8-4 パラレルDML文で取得されるロック

文のタイプ コーディネータ・プロセスが取得するロック: 各パラレル実行サーバーが取得するロック

パーティション表に対するパラレルUPDATEまたはDELETE(WHERE句によりパーティションまたはサブパーティションのサブセットにプルーニング)

1つの表ロックSX

プルーニングされたパーティションまたはサブパーティション当たり1つのパーティション・ロックX

1つの表ロックSX

問合せサーバー・プロセスが所有するプルーニングされたパーティションまたはサブパーティション当たり1つのパーティション・ロックNULL

問合せサーバー・プロセスが所有するプルーニングされたパーティションまたはサブパーティション当たり1つのパーティション待機ロックS

パーティション表に対するパラレル行移行UPDATE(WHERE句によりパーティションまたはサブパーティションのサブセットにプルーニング)

1つの表ロックSX

プルーニングされたパーティションまたはサブパーティション当たり1つのパーティション・ロックX

他のすべてのパーティションまたはサブパーティションの1つのパーティション・ロックSX

1つの表ロックSX

問合せサーバー・プロセスが所有するプルーニングされたパーティションまたはサブパーティション当たり1つのパーティション・ロックNULL

問合せサーバー・プロセスが所有するプルーニングされたパーティション当たり1つのパーティション待機ロックS

他のすべてのパーティションまたはサブパーティションの1つのパーティション・ロックSX

パーティション表に対するパラレルUPDATE、MERGE、DELETEまたはINSERT

1つの表ロックSX

すべてのパーティションまたはサブパーティションのパーティション・ロックX

1つの表ロックSX

パーティションまたはサブパーティション当たり1つのパーティション・ロックNULL

パーティションまたはサブパーティション当たり1つのパーティション待機ロックS

パーティション表に対するパラレルINSERT(目的の表はパーティション句またはサブパーティション句を含む)

1つの表ロックSX

指定されたパーティションまたはサブパーティション当たり1つのパーティション・ロックX

1つの表ロックSX

指定されたパーティションまたはサブパーティション当たり1つのパーティション・ロックNULL

指定されたパーティションまたはサブパーティション当たり1つのパーティション待機ロックS

非パーティション表に対するパラレルINSERT

1つの表ロックX

なし

ノート:

表、パーティションおよびパーティション待機のDMLロックはすべて、TMロックとしてV$LOCKビューに表示されます。

DOPを100として実行する600のパーティションを含む表について検討します。すべてのパーティションが、行移行のないパラレルUPDATE文またはDELETE文に関連するとします。

コーディネータでは次のロックが取得されます:

  • 1つの表ロックSX

  • 600のパーティション・ロックX

サーバー・プロセス全体では次のロックが取得されます。

  • 100の表ロックSX

  • 600のパーティション・ロックNULL

  • 600のパーティション待機ロックS

8.6.3.3 I/Oに関連するパラメータ

このトピックでは、I/Oに影響するパラメータについて説明します。

I/Oに影響するパラメータを次に示します。

これらのパラメータは、パラレル実行I/O操作の最適なパフォーマンスを確保するオプティマイザにも影響します。

関連項目:

初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください

8.6.3.3.1 DB_CACHE_SIZE

DB_CACHE_SIZEパラメータは、バッファのDEFAULTバッファ・プールのサイズをプライマリ・ブロック・サイズで設定します。

パラレルの更新、マージおよび削除操作を実行するとき、バッファ・キャッシュの動作は、大容量の更新を実行するOLTPシステムと非常によく似ています。

8.6.3.3.2 DB_BLOCK_SIZE

DB_BLOCK_SIZEパラメータは、Oracleデータベース・ブロックを設定します。

このパラメータの推奨値は8KBまたは16KBです。

データベース・ブロック・サイズはデータベースを作成するときに設定します。新しいデータベースを作成する場合は、8KBまたは16KBの大きなブロック・サイズを使用します。

8.6.3.3.3 DB_FILE_MULTIBLOCK_READ_COUNT

DB_FILE_MULTIBLOCK_READ_COUNTパラメータでは、オペレーティング・システムのREADコール1回で読み取られるデータベース・ブロック数を決定します。

このパラメータのデフォルト値は効率よく実行できる最大I/Oサイズに対応する値です。最大I/Oサイズの値はプラットフォームによって異なり、ほとんどのプラットフォームで1MBです。DB_FILE_MULTIBLOCK_READ_COUNTに設定した値が高すぎる場合、データベースの起動時に、オペレーティング・システムによって許容範囲内の最高レベルまで値が下げられます。

8.6.3.3.4 DISK_ASYNCH_IOおよびTAPE_ASYNCH_IO

DISK_ASYNCH_IOおよびTAPE_ASYNCH_IOパラメータにより、オペレーティング・システムの非同期I/O機能を有効化または無効化できます。

DISK_ASYNCH_IOとTAPE_ASYNCH_IOパラメータの両方の推奨値はTRUEです。これらのパラメータによって、問合せサーバー・プロセスが、表スキャンを実行するときにI/Oリクエストと処理を同時に行うことができます。オペレーティング・システムで非同期I/Oがサポートされる場合は、これらのパラメータをデフォルト値のTRUEにしておきます。図8-6に、非同期読取りの仕組みを示します。

図8-6 非同期読取り

図8-6の説明が続きます
「図8-6 非同期読取り」の説明

非同期操作が現在サポートされているのは、パラレル表スキャン、ハッシュ結合、ソートおよびシリアル表スキャンです。ただし、この機能にはオペレーティング・システム固有の構成が必要となることがあり、すべてのプラットフォームでサポートされるとはかぎりません。

8.7 パラレル実行のパフォーマンスの監視

パラレル実行のパフォーマンスに関する問題を診断するときは、次の種類の監視を行う必要があります。

これらの監視の種類を、次に示します。

関連項目:

動的ビューの詳細は、『Oracle Databaseリファレンス』を参照してください

8.7.1 動的パフォーマンス・ビューを使用したパラレル実行パフォーマンスの監視

動的パフォーマンス・ビューを使用してパラレル実行パフォーマンスを監視できます。

Oracle Databaseのリアルタイム監視機能を使用すると、SQL文の実行中にパフォーマンスを監視することができます。SQLの監視が自動的に開始するのは、SQL文がパラレルで実行されたとき、または1回の実行でCPUまたはI/O時間を5秒以上消費したときです。

システムが数日間稼働した後に、パラレル実行パフォーマンスの統計を監視して、並列処理が最適かどうかを判別する必要があります。これには、ここで説明するいずれかのビューを使用します。

Oracle Real Application Clustersでは、ここで説明するビューのグローバル・バージョンによって、複数インスタンスの統計が集計されます。グローバル・ビューの名前はGで開始します。たとえば、V$FILESTATに対してはGV$FILESTATとなります。

関連項目:

パフォーマンス監視の詳細は、『Oracle Database SQLチューニング・ガイド』を参照してください

8.7.1.1 V$PX_BUFFER_ADVICE

V$PX_BUFFER_ADVICE動的パフォーマンス・ビューを使用してパラレル実行のパフォーマンスを監視できます。

V$PX_BUFFER_ADVICEビューは、すべてのパラレル問合せによる最大バッファ使用量の履歴と見積りに関する統計を示します。このビューを調べて、パラレル問合せのメモリー不足の問題に応じてSGAサイズを再構成できます。

8.7.1.2 V$PX_SESSION

V$PX_SESSION動的パフォーマンス・ビューを使用してパラレル実行のパフォーマンスを監視できます。

V$PX_SESSIONビューは、問合せサーバーのセッション、グループ、セットおよびサーバー数のデータを示します。パラレル実行のために稼働しているプロセスのリアルタイム・データも示します。この表には、リクエストされた並列度(DOP)と操作に与えられた実際のDOPの情報も含まれます。

8.7.1.3 V$PX_SESSTAT

V$PX_SESSTAT動的パフォーマンス・ビューを使用してパラレル実行のパフォーマンスを監視できます。

V$PX_SESSTATビューは、V$PX_SESSION表とV$SESSTAT表のセッション情報を結合したものです。つまり、通常のセッションで得られるすべてのセッション統計は、パラレル実行を使用して実行されるすべてのセッションでも利用できます。

8.7.1.4 V$PX_PROCESS

V$PX_PROCESS動的パフォーマンス・ビューを使用してパラレル実行のパフォーマンスを監視できます。

V$PX_PROCESSビューには、パラレル・プロセスの情報が含まれます。ステータス、セッションID、プロセスID、その他の情報があります。

8.7.1.5 V$PX_PROCESS_DETAIL

V$PX_PROCESS_DETAILは、インスタンス上のアクティブなPX (パラレル実行)サーバーごとの統計情報を示します。

この動的パフォーマンス・ビューはV$PX_PROCESSと似ていますが、より詳細な情報が表示されます。データベース内のPXプロセス管理に関する付加的なインサイトが提供されるため、実際のワークロードに対して環境をより適切に調整するのに役立ちます。

関連項目:

V$PX_PROCESS_DETAIL
8.7.1.6 V$PX_PROCESS_SYSSTAT

V$PX_PROCESS_SYSSTAT動的パフォーマンス・ビューを使用してパラレル実行のパフォーマンスを監視できます。

V$PX_PROCESS_SYSSTATビューは、問合せサーバーのステータスとバッファ割当て統計を示します。

8.7.1.7 V$PQ_SESSTAT

V$PQ_SESSTAT動的パフォーマンス・ビューを使用してパラレル実行のパフォーマンスを監視できます。

V$PQ_SESSTATビューは、システムの現在のサーバー・グループすべてのステータスを示します。問合せによってどのようにプロセスが割り当てられたか、またマルチユーザー問合せ調整アルゴリズムやロード・バランシング・アルゴリズムにより、デフォルト値やヒント指定された値がどのように影響されたかといったデータが含まれます。

場合によっては、これらのビューのデータを確認した後で、パフォーマンスを改善するために一部のパラメータの設定を調整する必要があります。その場合は、「パラレル実行のための一般的なパラメータのチューニング」の説明を参照してください。実行時間の長いパラレル操作の進捗を監視するには、これらのビューを定期的に問い合せます。

多くの動的パフォーマンス・ビューでは、Oracle Databaseが各ビューの統計を収集するためには、パラメータTIMED_STATISTICSをTRUEに設定する必要があります。ALTER SYSTEMまたはALTER SESSION文を使用して、TIMED_STATISTICSの設定を切り替えることができます。

8.7.1.8 V$PQ_TQSTAT

V$PQ_TQSTAT動的パフォーマンス・ビューを使用してパラレル実行のパフォーマンスを監視できます。

単純な例として、固有値が2種類のみの1つの列の結合による、2つの表のハッシュ結合について考えます。このハッシュ関数は、最大でも、パラレル実行サーバーAに対して1つのハッシュ値、パラレル実行サーバーBに対してもう1つのハッシュ値を生成します。DOPは2で問題ありません。4とすると少なくとも2つのパラレル実行サーバーの作業がなくなります。このような偏りを検出するには、次の例のような問合せを使用します。

SELECT dfo_number, tq_id, server_type, process, num_rows
FROM V$PQ_TQSTAT ORDER BY dfo_number DESC, tq_id, server_type, process;

この問題を解決する最適な方法は、別の結合方法の選択です。ネステッド・ループ結合が最適であると予想されます。または、結合表の一方が他方よりも小さい場合は、PQ_DISTRIBUTEヒントを使用してBROADCAST分散方法を指定できます。オプティマイザによってBROADCAST分散方法が考慮されるためには、OPTIMIZER_FEATURES_ENABLEを9.0.2以上に設定する必要があります。

ここで、カーディナリティの高い結合キーがあるが、値の1つにほとんどのデータが含まれると仮定します。このような例としては、ラーバ・ランプの年次売上があります。大きな売上があったのは1968年のみで、1968年のレコードに対応するパラレル実行サーバーの負荷が高くなります。前述したものと同じ修正処理を使用する必要があります。

V$PQ_TQSTATビューは、表キュー・レベルのメッセージ・トラフィックの詳細なレポートを示します。V$PQ_TQSTATデータが有効なのは、パラレルSQL文を実行しているセッションから問い合せた場合のみです。 表キューは、問合せサーバー・グループ間、パラレル実行コーディネータと問合せサーバー・グループ間、または問合せサーバー・グループとコーディネータ間のパイプラインです。表キューは、PX SEND <partitioning type> (たとえば、PX SEND HASH)およびPX RECEIVEによって操作列に明示的に示されます。

V$PQ_TQSTATには、各表キューに対して読取りまたは書込みを行う問合せサーバー・プロセスごとに1行があります。10のコンシューマ・プロセスと10のプロデューサ・プロセスを接続する表キューの場合、このビューに20の行があります。バイト列を合計し、TQ_ID (表キュー識別子)によってグループ化すると、各表キューを介して送信された合計バイト数を求めることができます。この値をオプティマイザの見積りと比較します。差が大きいときは、より大きなサンプルを使用したデータの分析が必要な可能性があります。

TQ_IDでグループ化したバイト数の平方偏差を計算します。平方偏差が大きい場合はワークロードの不均衡を意味します。大きな平方偏差について調べて、プロデューサの起動時にデータ分散が不均等だったのか、分散そのものに偏りがあるのかを判別する必要があります。データそのものに偏りがある場合は、カーディナリティが低い、あるいは固有値が少ないことを意味します。

8.7.1.9 V$RSRC_CONS_GROUP_HISTORY

V$RSRC_CONS_GROUP_HISTORY動的パフォーマンス・ビューを使用してパラレル実行のパフォーマンスを監視できます。

V$RSRC_CONS_GROUP_HISTORYビューは、非NULLプランのあるV$RSRC_PLAN_HISTORYに、パラレル文のキューイングの情報など、各エントリに対するコンシューマ・グループ統計の履歴を表示します。

8.7.1.10 V$RSRC_CONSUMER_GROUP

V$RSRC_CONSUMER_GROUP動的パフォーマンス・ビューを使用してパラレル実行のパフォーマンスを監視できます。

V$RSRC_CONSUMER_GROUPビューは、パラレル文の情報など、現在アクティブなリソース・コンシューマ・グループに関連するデータを表示します。

8.7.1.11 V$RSRC_PLAN

V$RSRC_PLAN動的パフォーマンス・ビューを使用してパラレル実行のパフォーマンスを監視できます。

V$RSRC_PLANビューは、パラレル文のキューイングの状態など、現在アクティブなリソース・プランすべての名前を表示します。

8.7.1.12 V$RSRC_PLAN_HISTORY

V$RSRC_PLAN_HISTORY動的パフォーマンス・ビューを使用してパラレル実行のパフォーマンスを監視できます。

V$RSRC_PLAN_HISTORYは、リソース・プランがインスタンスで有効化、無効化または変更された場合の履歴を表示します。履歴にはパラレル文のキューイングの状態を含みます。

8.7.1.13 V$RSRC_SESSION_INFO

V$RSRC_SESSION_INFO動的パフォーマンス・ビューを使用してパラレル実行のパフォーマンスを監視できます。

V$RSRC_SESSION_INFOビューは、パラレル文のキュー統計など、リソース・マネージャ統計をセッション単位で表示します。列には、PQ_SERVERSおよびPQ_STATUSが含まれます。

セッションがアクティブでパラレル問合せを実行している場合、V$RSRC_SESSION_INFOビューのPQ_SERVERS列には、アクティブなパラレル・サーバーの数が含まれます。問合せがキューに入れられると、この問合せで実行するパラレル・サーバーの数が表示されます。

PQ_STATUS列は、パラレル文がキューに入れられる理由を保持します。

関連項目:

V$RSRC_SESSION_INFOビューの詳細は、『Oracle Databaseリファレンス』を参照してください

8.7.1.14 V$RSRCMGRMETRIC

V$RSRCMGRMETRIC動的パフォーマンス・ビューを使用してパラレル実行のパフォーマンスを監視できます。

V$RSRCMGRMETRICビューは、パラレル文のキューイングに関連する統計を表示します。

パラレル文のキューイングに関連する統計は、指定された1分間の統計を取得して約1時間保持するリソース・マネージャ・メトリックに追加されます。

列には、AVG_ACTIVE_PARALLEL_STMTS、AVG_QUEUED_PARALLEL_STMTS、AVG_ACTIVE_PARALLEL_SERVERS、AVG_QUEUED_PARALLEL_SERVERSおよびPARALLEL_SERVERS_LIMITが含まれます。

関連項目:

V$RSRCMGRMETRICビューの詳細は、『Oracle Databaseリファレンス』を参照してください

8.7.2 セッション統計の監視

動的パフォーマンス・ビューを使用してセッション統計を監視し、パラレル実行のパフォーマンスを診断できます。

GV$PX_SESSIONを使用して、パラレルで実行するサーバー・グループの構成を判別します。この例では、セッション9が問合せコーディネータ、セッション7および21が最初のセットの最初のグループにあります。セッション18および20は2番目のセットの最初のグループです。この問合せでリクエストされたOPと与えられたDOPはどちらも2です。これは、次の問合せによる出力に示されます。 

SELECT QCSID, SID, INST_ID "Inst", SERVER_GROUP "Group", SERVER_SET "Set",
  DEGREE "Degree", REQ_DEGREE "Req Degree"
FROM GV$PX_SESSION ORDER BY QCSID, QCINST_ID, SERVER_GROUP, SERVER_SET;

出力は次のようになります。

QCSID      SID        Inst       Group      Set        Degree     Req Degree 
---------- ---------- ---------- ---------- ---------- ---------- ---------- 
         9          9          1 
         9          7          1          1          1          2          2 
         9         21          1          1          1          2          2 
         9         18          1          1          2          2          2 
         9         20          1          1          2          2          2

シングル・インスタンスの場合、SELECT FROM V$PX_SESSIONを使用します。列名Instance IDは含めません。

GV$PX_SESSIONを使用した前の例の出力に表示されるプロセスが、同じタスクを完了するために連携します。次の例は、物理読取りに関してこれらのプロセスの進捗を判別するための、結合問合せの実行を示します。次の問合せを使用して特定の統計を追跡できます。 

SELECT QCSID, SID, INST_ID "Inst", SERVER_GROUP "Group", SERVER_SET "Set",
  NAME "Stat Name", VALUE
FROM GV$PX_SESSTAT A, V$STATNAME B
WHERE A.STATISTIC# = B.STATISTIC# AND NAME LIKE 'PHYSICAL READS'
  AND VALUE > 0 ORDER BY QCSID, QCINST_ID, SERVER_GROUP, SERVER_SET;

出力は次のようになります。

QCSID  SID   Inst   Group  Set    Stat Name          VALUE      
------ ----- ------ ------ ------ ------------------ ---------- 
     9     9      1               physical reads           3863 
     9     7      1      1      1 physical reads              2 
     9    21      1      1      1 physical reads              2 
     9    18      1      1      2 physical reads              2 
     9    20      1      1      2 physical reads              2

このタイプの問合せを使用して、V$STATNAMEの統計を追跡します。問合せサーバー・プロセスの進捗を確認するには、この問合せを必要な回数繰り返します。

次の問合せは、V$PX_PROCESSを使用して問合せサーバーのステータスを調べます。 

SELECT * FROM V$PX_PROCESS;

出力は次のようになります。

SERV STATUS    PID    SPID      SID    SERIAL# IS_GV   CON_ID
---- --------- ------ --------- ------ ------- -----  -------
P002 IN USE        16     16955     21   7729  FALSE        0
P003 IN USE        17     16957     20   2921  FALSE        0
P004 AVAILABLE     18     16959                FALSE        0
P005 AVAILABLE     19     16962                FALSE        0
P000 IN USE        12      6999     18   4720  FALSE        0
P001 IN USE        13      7004      7    234  FALSE        0

関連項目:

例で使用される動的パフォーマンス・ビューの詳細は、「動的パフォーマンス・ビューを使用したパラレル実行パフォーマンスの監視」を参照してください

8.7.3 システム統計の監視

動的パフォーマンス・ビューを使用してシステム統計を監視し、パラレル実行のパフォーマンスを診断できます。

V$SYSSTATビューおよびV$SESSTATビューには、パラレル実行を監視するためのいくつかの統計が含まれます。これらの統計を使用して、パラレル問合せ、DML、DDL、データ・フロー演算子(DFO)および操作の数を追跡します。問合せ、DMLまたはDDLそれぞれが、複数のパラレル操作および複数のDFOを含むことがあります。

さらに、統計では、マルチユーザー問合せ調整アルゴリズムまたは使用可能なパラレル実行サーバーの不足のために、DOPが減らされた(ダウングレードされた)問合せ操作の数もカウントされます。

また、これらのビューの統計では、パラレル実行のために送信されたメッセージ数もカウントされます。次の構文は、これらの統計を表示する方法の例です。

SELECT NAME, VALUE FROM GV$SYSSTAT
  WHERE UPPER (NAME) LIKE '%PARALLEL OPERATIONS%'
  OR UPPER (NAME) LIKE '%PARALLELIZED%' OR UPPER (NAME) LIKE '%PX%';

出力は次のようになります。

NAME                                               VALUE      
-------------------------------------------------- ---------- 
queries parallelized                                      347 
DML statements parallelized                                 0 
DDL statements parallelized                                 0 
DFO trees parallelized                                    463 
Parallel operations not downgraded                         28 
Parallel operations downgraded to serial                   31 
Parallel operations downgraded 75 to 99 pct               252 
Parallel operations downgraded 50 to 75 pct               128 
Parallel operations downgraded 25 to 50 pct                43 
Parallel operations downgraded 1 to 25 pct                 12 
PX local messages sent                                  74548 
PX local messages recv'd                                74128 
PX remote messages sent                                     0 
PX remote messages recv'd                                   0

次の問合せは、システムの各ワーカー(子プロセス)および問合せコーディネータ・プロセスの現在の待機状態を示します。

SELECT px.SID "SID", p.PID, p.SPID "SPID", px.INST_ID "Inst",
       px.SERVER_GROUP "Group", px.SERVER_SET "Set",
       px.DEGREE "Degree", px.REQ_DEGREE "Req Degree", w.event "Wait Event"
FROM GV$SESSION s, GV$PX_SESSION px, GV$PROCESS p, GV$SESSION_WAIT w
WHERE s.sid (+) = px.sid AND s.inst_id (+) = px.inst_id AND
      s.sid = w.sid (+) AND s.inst_id = w.inst_id (+) AND
      s.paddr = p.addr (+) AND s.inst_id = p.inst_id (+)
ORDER BY DECODE(px.QCINST_ID,  NULL, px.INST_ID,  px.QCINST_ID), px.QCSID, 
DECODE(px.SERVER_GROUP, NULL, 0, px.SERVER_GROUP), px.SERVER_SET, px.INST_ID;

8.7.4 オペレーティング・システム統計の監視

Oracle Databaseで得られる情報とオペレーティング・システムのユーティリティ(UNIXベース・システムでのsarやvmstatなど)で得られる情報はかなり重複しています。

オペレーティング・システムでは、I/O、通信、CPU、メモリーとページング、スケジューリング、同期プリミティブに関するパフォーマンス統計が提供されます。V$SESSTATビューにも、オペレーティング・システム統計の主なカテゴリが示されます。

通常、I/Oデバイスやセマフォ操作に関するオペレーティング・システム情報を、データベースのオブジェクトや操作にマップするのは、Oracle Databaseの情報に比べて困難です。ただし、オペレーティング・システムによっては、優れたビジュアル化ツールが備えられており、データを収集する効率のよい手段があります。

CPUやメモリーの使用量に関するオペレーティング・システム情報は、パフォーマンスを調査するために大変重要です。おそらく最も重要な統計はCPU使用率です。下位レベルのパフォーマンス・チューニングの目標は、すべてのCPUでCPUバウンドになることです。これが達成されると、SQLレベルで作業して、CPUの使用率は低いがI/Oの使用率が高い代替計画を見つけることができます。

オペレーティング・システムのメモリーとページングの情報は、メモリー集中型データ・ウェアハウス・サブシステム(パラレルの通信、ソート、ハッシュ結合など)の間でメモリーをどのように分割するかを制御する、多数のシステム・パラメータのチューニングに役立ちます。

8.8 パラレル実行のチューニングのヒント

この項では、パラレル実行環境でのパフォーマンスを向上させるための様々な方法を説明します。

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

8.8.1 パラレル実行計画の実装

優れたパラレル実行計画の実装は、高いパフォーマンスを確実にするために重要となります。

優れた計画のための推奨事項を次に示します。

  • システム内で起こっていることを理解するために、単純な設定を実装します。

  • リソース・マネージャを使用して、システムに負担をかけることなく一定量の処理リソースを各グループに割り当てるよう、コンシューマ・グループの最大並列度(DOP)を指定します。リソース・マネージャ・ポリシーは、パラレル実行を使用してシステムを統御する場合、およびSQL文を必ずパラレルで実行できるようにするために必要となります。

  • パラレル実行に使用できるようにするシステム・リソースの量を計画の基礎とします。パラメータPARALLEL_MAX_SERVERSおよびPARALLEL_SERVERS_TARGETの値を調整して、システム内で実行されるパラレル実行(PX)サーバーの数を制限します。

  • ETL (抽出、変換およびロード)計画ではなくELT (抽出、ロードおよび変換)計画の採用を検討します。

  • より高速なデータ・ロードのために、CTASやIASなど、パラレルSQL文で外部表を使用します。

8.8.2 パラレルでの表の作成および移入によるパフォーマンスの最適化

大量の結果セットを取得するパラレル実行パフォーマンスを最適化するには、パラレルで表を作成および移入します。

Oracle Databaseは、結果をユーザー・プロセスにパラレルで返すことはできません。問合せが多数の行を返す場合、問合せの実行は実際に速くなることもあります。ただし、ユーザー・プロセスは行の受取りをシリアルでしか実行できません。大量の結果セットを取得する問合せのパラレル実行パフォーマンスを最適化するには、PARALLEL CREATE TABLE AS SELECTまたはダイレクト・パスINSERTを使用して結果セットをデータベースに格納します。ユーザーは結果セットを後からシリアルで確認できます。

SELECTをパラレルで実行してもCREATE文には影響しません。ただし、CREATE文がパラレルで実行される場合、オプティマイザはSELECTもパラレルで実行しようとします。

パラレルのCREATE TABLE AS SELECTをNOLOGGINGオプションと組み合せると、大変効率のよい中間表機能が提供されます。たとえば: 

CREATE TABLE summary PARALLEL NOLOGGING AS SELECT dim_1, dim_2 ..., 
SUM (meas_1)
FROM facts GROUP BY dim_1, dim_2;

これらの表も、パラレルINSERTを使用して増分的にロードできます。中間表を活用するには、次の方法を使用します。

  • 通常の副問合せは、1回計算すると、何度でも参照できます。これを利用すると、スター・スキーマに対する一部の問合せ(特に、選択のためのWHERE句を含む述語のない問合せ)をより適切にパラレル化できるようになります。スター型変換を使用する、選択のためのWHERE句を含む述語のあるスター問合せは、SQLを変更しなくても自動的に効率よくパラレル化できます。

  • アプリケーションレベルのチェックポイントまたは再起動を実現するために、複雑な問合せを単純なステップに分解します。たとえば、1TBのデータベースに対して複雑な複数表の結合を実行すると、数十時間に及ぶ可能性があります。この問合せの最中に障害が発生すると、最初からやりなおすことになります。CREATE TABLE AS SELECTまたはPARALLEL INSERT AS SELECTを使用してこの問合せを再作成し、数時間ずつ実行される単純な問合せの順序を作成します。システム障害が発生しても、最後に完了したステップの次から問合せを再起動できます。

  • 元の表の不要な行を省いた新しい表を作成してから、元の表を削除することにより、手動パラレル削除操作を効率よく実装します。または、元の表から行を直接削除する、便利なパラレル削除機能を使用することもできます。

  • 効率のよいマルチディメンション・ドリルダウン分析のためにサマリー表を作成します。たとえば、サマリー表には、月、種類、地域、販売担当者ごとにグループ化された収益の合計を含めることができます。

  • 行チェーンの消去や空き領域の圧縮などを行い、古い表を新しい表にコピーして、表を再編成します。この方法はエクスポートとインポートよりも速く、再ロードよりも容易です。

新たに作成した表でオプティマイザ統計を収集するにはDBMS_STATSパッケージを使用してください。I/Oボトルネックを回避するために、少なくともCPUと同数の物理ディスクに対してストライプ化された表領域を指定します。領域を割り当てるときに断片化を回避するために、表領域のファイル数はCPU数の倍数にする必要があります。

関連項目:

データ・ウェアハウスのパラレル実行の詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください

8.8.3 EXPLAIN PLANを使用したパラレル操作計画の表示

EXPLAIN PLAN文を使用して、パラレル問合せの実行計画を表示します。

EXPLAIN PLANの出力で、COST、BYTESおよびCARDINALITY列にオプティマイザの情報が表示されます。utlxplp.sqlスクリプトを使用して、関連するすべてのパラレル情報と一緒にEXPLAIN PLAN出力を表示することもできます。

結合文のパラレル実行を最適化する方法がいくつかあります。システム構成を変更するか、この章で前に説明したようにパラメータを調整するか、DISTRIBUTIONヒントなどのヒントを使用します。

EXPLAIN PLANを使用する際の重要なポイントは次のとおりです。

  • オプティマイザの選択性見積りを確認します。問合せで1行しか生成されないとオプティマイザが予測する場合、ネステッド・ループを使用する傾向が高くなります。このとき、表が分析されていない可能性や、同一の表に対する複数の述語の相関関係についてオプティマイザの見積りが誤っている可能性があります。オプティマイザに正しい選択性を提供したり、オプティマイザに別の結合方法を使用させるために、統計やヒントを拡張することが必要な場合があります。

  • 低カーディナリティの結合キーに対するハッシュ結合を使用します。結合キーに固有の値が少ない場合、ハッシュ結合は最適ではない可能性があります。固有値の数が並列度(DOP)を下回る場合は、一部のパラレル問合せサーバーが特定の問合せの処理を行えないことがあります。

  • データの偏りを考慮します。結合キーに過度のデータの偏りがある場合、ハッシュ結合を行うと、一部のパラレル問合せサーバーに多くの作業が偏る可能性があります。オプティマイザによってBROADCAST分散方法が選択されなかった場合は、そのためのヒントの使用を検討してください。オプティマイザによってBROADCAST分散方法が考慮されるのは、OPTIMIZER_FEATURES_ENABLEを9.0.2以上に設定した場合のみです。詳細は、「V$PQ_TQSTAT」を参照してください。

8.8.3.1 例: EXPLAIN PLANを使用したパラレル操作の表示

EXPLAIN PLANを使用してパラレル操作を表示できます。

次の例は、オプティマイザがパラレル問合せを実行しようとする場合を示しています。

explain plan for 
  SELECT /*+ PARALLEL */ cust_first_name, cust_last_name 
   FROM customers c, sales s WHERE c.cust_id = s.cust_id;

----------------------------------------------------------
| Id  | Operation                       |  Name          |
----------------------------------------------------------
|   0 | SELECT STATEMENT                |                |
|   1 |  PX COORDINATOR                 |                |
|   2 |   PX SEND QC (RANDOM)           | :TQ10000       |
|   3 |    NESTED LOOPS                 |                |
|   4 |     PX BLOCK ITERATOR           |                |
|   5 |      TABLE ACCESS FULL          | CUSTOMERS      |
|   6 |     PARTITION RANGE ALL         |                |
|   7 |      BITMAP CONVERSION TO ROWIDS|                |
|   8 |       BITMAP INDEX SINGLE VALUE | SALES_CUST_BIX |
----------------------------------------------------------

Note
-----
   - automatic DOP: Computed Degree of Parallelism is 2

8.8.4 パラレルDMLのその他の考慮事項

このトピックでは、パラレルDML操作の使用に関するその他の考慮事項について説明します。

データ・ウェアハウスに対してパラレルの挿入、更新または削除操作を使用して、データ・ウェアハウス・データベースをリフレッシュする予定があるときは、物理データベースを設計する際にさらに考慮すべき項目があります。これらの考慮事項はパラレル実行操作には影響しません。これらの問題は次のとおりです:

8.8.4.1 パラレルDMLおよびダイレクト・パス制限

このトピックでは、パラレルおよびダイレクト・パス操作の制限について説明します。

パラレル制限に違反すると、操作はシリアルで実行されるだけです。ダイレクト・パスINSERT制限に違反すると、APPENDヒントが無視され、従来の挿入操作が実行されます。エラー・メッセージは返されません。

8.8.4.2 並列度の制限

使用しているOracle Databaseのソフトウェア・レベルに基づいて、並列度(DOP)には一定の制限があります。

パラレルDML ITL不変プロパティを持たない表の場合、たとえば:
  • Oracle9iリリース2 (9.2)より前に作成された表、または
  • COMPATIBLE初期化パラメータを9.2より小さい値に設定して作成された表
最大DOPは、パーティションまたはサブパーティションの数に制限されます。表がパーティション化されていない場合、パラレル実行は使用されず、問合せはシリアルで実行されます。

この制限が表に適用されているかどうかを確認する方法:

表がこの制限の影響を受けている疑いがある場合は、次の問合せを実行して確認できます:

SELECT u.name, o.name 
FROM obj$ o, tab$ t, user$ u
WHERE o.obj# = t.obj# 
AND o.owner# = u.user#
AND bitand(t.property,536870912) != 536870912;

ノート:

この制限は、すべての表に適用されるわけではありません。表がOracle 9.2以降で作成された場合、またはCOMPATIBLEパラメータが9.2以上に設定されている場合、この制限は適用されず、パラレル実行が想定どおりに機能します。表がすでにパラレルで実行されている場合、この制限は適用されません。

関連項目:

トランザクション表とも呼ばれるInterested Transaction List (ITL)の詳細は、『Oracle Database概要』を参照してください

8.8.4.3 INITRANSを増加するタイミング

特定の状況では、INITRANSの値を増やす必要があります。

グローバル索引がある場合、グローバル索引セグメントとグローバル索引ブロックは同じパラレルDML文のサーバー・プロセスによって共有されます。操作が同じ行に対して実行されなくても、サーバー・プロセスは同じ索引ブロックを共有できます。各サーバー・トランザクションは、索引ブロックに変更を行う前に、索引ブロック・ヘッダーの1つのトランザクション・エントリを必要とします。

この状況では、CREATE INDEX文またはALTER INDEX文を使用する際、INITRANS(各データ・ブロックに割り当てられるトランザクションの初期値)を、その索引に対する最大DOPなどの大きな値に設定する必要があります。

8.8.4.4 セグメントで使用可能なトランザクション空きリスト数の制限

ディクショナリ管理表領域のセグメントで使用可能なトランザクション空きリスト数には制限があります。

セグメントが作成されると、プロセス空きリストとトランザクション空きリストの数は固定され、変更できません。セグメント・ヘッダーでプロセス空きリストの数として大きな値を指定すると、それによって使用可能なトランザクション空きリストの数が制限されることがあります。この制限を避けるには、次にセグメント・ヘッダーを再作成するときに、プロセス空きリストの数を減らします。こうすると、セグメント・ヘッダーでトランザクション空きリストのための余裕ができます。

UPDATEおよびDELETE操作では、各サーバー・プロセスが独自のトランザクション空きリストを必要とする場合があります。このため、パラレルDMLのDOPは、表とDML文でメンテナンスする必要があるすべてのグローバル索引に対して使用可能な、トランザクション空きリストの最小数によって事実上制限されます。たとえば、表に25のトランザクション空きリストがあるとき、その表に2つのグローバル索引があり、1つの索引に50のトランザクション空きリスト、もう1つの索引に30のトランザクション空きリストがあるとすると、DOPの制限は25になります。この表のトランザクション空きリストが40であれば、DOPの制限は30になります。

STORAGE句のFREELISTSパラメータは、プロセス空きリストの数を設定するために使用されます。デフォルトではプロセス空きリストは作成されません。

トランザクション空きリストのデフォルト数はブロック・サイズによって異なります。たとえば、プロセス空きリストの数が明示的に設定されない場合、デフォルトでは4KBのブロックに対して約80のトランザクション空きリストになります。トランザクション空きリストの最小数は25です。

8.8.4.5 多数のREDOログの複数のアーカイバ

多数のREDOログをアーカイブするには、複数のアーカイバ・プロセスが必要です。

パラレルDDLおよびパラレルDML操作は、多数のREDOログを生成する場合があります。これらのREDOログのアーカイブは、1つのARCHプロセスでは間に合わない可能性があります。この問題を回避するため、複数のアーカイバ・プロセスを生成できます。これは、手動で行うこともジョブ・キューを使用して行うこともできます。

8.8.4.6 データベース・ライター・プロセス(DBWn)のワークロード

データベース・ライター・プロセスの数を増やす必要がある場合があります。

パラレルDML操作により、短時間でバッファ・キャッシュ内の多数のデータ、索引およびUNDOブロックの内容が使用されます。たとえば、次の構文でV$SYSTEM_EVENTビューを問い合せると、free_buffer_waitsの値が高く示されると想定します。 

SELECT TOTAL_WAITS FROM V$SYSTEM_EVENT WHERE EVENT = 'FREE BUFFER WAITS';

この場合は、DBWnプロセスを増やすことの検討が必要です。空きバッファの待機時間がない場合、問合せによって行が返されません。

8.8.4.7 [NO]LOGGING句

[NO]LOGGING句を設定する際の考慮事項を理解してください。

[NO]LOGGING句は、表、パーティション、表領域および索引に適用されます。NOLOGGING句を使用すると、事実上、特定の操作(ダイレクト・パスINSERTなど)に対してログが生成されません。NOLOGGING属性はINSERT文のレベルでは指定されませんが、表、パーティション、索引または表領域に対してALTER文またはCREATE文を使用して指定されます。

表または索引にNOLOGGINGが設定されると、パラレルまたはシリアルのダイレクト・パスINSERT操作ではREDOログが生成されません。NOLOGGINGオプションが設定されて実行しているプロセスは、REDOが生成されないため、処理が速くなります。ただし、表、パーティションまたは索引に対するNOLOGGING操作の後、バックアップを実行する前にメディア障害が発生すると、変更されたすべての表、パーティションおよび索引が破損することがあります。

NOLOGGING句が使用されている場合、ダイレクト・パスINSERT操作(ディクショナリ更新以外)では、REDOログは常に生成されません。NOLOGGING属性はUNDOには影響せず、REDOのみに影響します。正確には、NOLOGGINGを使用すると、ダイレクト・パスINSERT操作ではごくわずかのREDO(フル・イメージREDOとは逆のレンジ無効REDO)が生成されます。

下位互換性のため、CREATE TABLE文での代替キーワードとして[UN]RECOVERABLEも引き続きサポートされています。ただし、この代替キーワードは今後のリリースでサポートが終了する可能性があります。

表領域レベルでは、LOGGING句によって、その表領域に作成されるすべての表、索引およびパーティションのデフォルト・ロギング属性が指定されます。既存の表領域のロギング属性がALTER TABLESPACE文によって変更されると、ALTER文の後で作成されたすべての表、索引およびパーティションには新しいロギング属性が適用されます。既存の表、索引、パーティションのロギング属性は変化しません。表領域レベルのロギング属性は、表、索引またはパーティション・レベルの指定で上書きできます。

デフォルトのロギング属性はLOGGINGです。ただし、ALTER DATABASE NOARCHIVELOGを発行してデータベースをNOARCHIVELOGモードにした場合、ロギング属性の指定にかかわらず、ロギングなしで実行できるすべての操作ではログが生成されなくなります。

8.8.5 パラレルでの索引の作成によるパフォーマンスの最適化

パラレルで索引を作成してパフォーマンスを最適化できます。

複数のプロセスが同時に作動して、1つの索引を作成できます。索引を作成するために必要な処理を複数のサーバー・プロセスに分割することで、Oracle Databaseでは、1つのサーバー・プロセスによって索引をシリアルで作成した場合に比べて速く索引を作成できます。

パラレル索引作成では、ORDER BY句での表スキャンとほぼ同様の処理が行われます。表がランダムにサンプリングされ、索引をDOPと同数に均等に分割するための索引キーのセットが検出されます。問合せプロセスの第1セットが表をスキャンしてキーと行IDのペアを抽出し、問合せプロセスの第2セットのプロセスに対してキーに基づいて各ペアを送ります。第2セットの各プロセスは、キーをソートし、通常の方法で索引を構築します。索引のすべての部分が構築されると、パラレル実行コーディネータが各部(ソート済)を連結して、最終的に索引を形成します。

パラレルのローカル索引作成では、1つのサーバー・セットが使用されます。セットの各サーバー・プロセスは、割り当てられた表パーティションをスキャンし、そのパーティションに対して索引パーティションを構築します。所定のDOPに対して半数のサーバー・プロセスが使用されるため、パラレルのローカル索引作成が可能になるのはDOPが高い場合です。ただし、DOPは作成する索引パーティション数以内に制限されます。この制限を回避するには、DBMS_PCLXUTILパッケージを使用できます。

索引作成時にREDOおよびUNDOのロギングを行わないことをオプションで指定できます。こうすると、パフォーマンスが大きく向上する可能性がありますが、索引が一時的にリカバリ不可の状態になります。新しい索引のバックアップを取得すると、リカバリは可能になります。アプリケーションで、索引のリカバリ時に索引を再作成するNOLOGGING句の使用を検討してください。

CREATE INDEX文のPARALLEL句のみが、索引作成のDOPを指定するただ1つの方法です。DOPがCREATE INDEX文のPARALLEL句に指定されないと、CPUの数がDOPとして使用されます。PARALLEL句がない場合、索引作成はシリアルで行われます。

索引をパラレルで作成するとき、STORAGE句には、問合せサーバー・プロセスで作成される各副索引の記憶域を指定します。このため、INITIAL値が5MB、DOPが12で作成される索引は、索引作成時に少なくとも60MBの記憶域を消費します。各プロセスが5MBのエクステントで開始するためです。問合せコーディネータ・プロセスがソート済の副索引を結合するときに、エクステントの一部が切り捨てられ、生成される索引はリクエストの60MBよりも小さくなることがあります。

UNIQUEまたはPRIMARY KEY制約を表に追加するか、有効にすると、必要な索引をパラレルで自動的に作成できなくなります。かわりに、CREATE INDEX文と適切なPARALLEL句を使用して、必要な列に対して手動で索引を作成します。こうすることで、制約を有効にするか追加するときに、Oracle Databaseが既存の索引を使用します。

同じ表の複数の制約を同時にパラレルで有効にできるのは、すべての制約がすでにENABLE NOVALIDATE状態になっている場合です。次の例では、ALTER TABLE ENABLE CONSTRAINT文が、制約をパラレルでチェックする表スキャンを実行します。 

CREATE TABLE a (a1 NUMBER CONSTRAINT ach CHECK (a1 > 0) ENABLE NOVALIDATE)
PARALLEL; 
INSERT INTO a values (1);
COMMIT;
ALTER TABLE a ENABLE CONSTRAINT ach;

8.8.6 パラレルDMLのヒント

このトピックでは、パラレルDML機能のヒントについて説明します。

内容は次のとおりです。

関連項目:

8.8.6.1 パラレルDMLのヒント1: INSERT

このトピックでは、SQL INSERT文を使用した場合のパラレルDMLについて説明します。

INSERT文を使用して実行できる機能は表8-5にまとめられます。

表8-5 INSERT機能のまとめ

挿入タイプ パラレル シリアル NOLOGGING

従来型

不可

パラレルDMLを有効にしてNOAPPENDヒントを使用して、従来型のパラレル挿入を実行する方法の詳細は、この項の説明を参照してください。

可

不可

ダイレクト・パス

INSERT

(APPEND)

可能(次の指定が必要)

PARALLEL DMLモードを有効にするためのALTER SESSION ENABLE PARALLEL DMLまたはENABLE_PARALLEL_DML SQLヒント

さらに、次のいずれか1つの指定

  • 並列処理を明示的に設定する表のPARALLEL属性またはPARALLELヒント

  • モードを明示的に設定するAPPENDヒント

または次の指定

強制的にPARALLEL DMLモードにするALTER SESSION FORCE PARALLEL DML

可能(次の指定が必要):

APPENDヒント

可能(次の指定が必要):

パーティションまたは表に対するNOLOGGING属性の設定

パラレルDMLが有効で、PARALLELヒントがあるか PARALLEL属性がデータ・ディクショナリの表に設定されている場合、制限が適用されないかぎり挿入操作はパラレルで行われ追加されます。PARALLELヒントまたはPARALLEL属性のいずれかがない場合、挿入操作はシリアルで行われます。自動DOPでは、パラレルDMLが有効化または強制される場合にかぎり、SQL文のDML部分のみがパラレル化されます。

パラレルDMLが有効化される場合は、NOAPPENDヒントを使用してパラレルの従来型挿入操作を実行できます。たとえば、/*+ noappend parallel */をSQL INSERT文で使用して、パラレルの従来型挿入を実行できます。 

SQL> INSERT /*+ NOAPPEND PARALLEL */ INTO sales_hist SELECT * FROM sales;

パラレルの従来型挿入操作の利点は、ダイレクト・パスINSERTの制約なしにオンライン操作を実行できることです。パラレルの従来型挿入操作のデメリットは、ダイレクト・パスINSERTよりもプロセスの速度が遅いことです。

8.8.6.2 パラレルDMLのヒント2: ダイレクト・パスINSERT

このトピックでは、ダイレクト・パスINSERT操作を使用した場合のパラレルDMLについて説明します。

追加モードは、パラレルの挿入操作時のデフォルトです。データは、表に割り当てられる新規ブロックに常に挿入されます。APPENDヒントの使用はオプションです。追加モードは、INSERT操作の速度を速める場合には使用しますが、領域の使用率の最適化が必要な場合は使用しないでください。NOAPPENDを使用すると追加モードを上書きできます。

APPENDヒントは、シリアルとパラレルの両方の挿入操作に適用されます。このヒントを使用すると、シリアル挿入もより高速になります。ただし、APPENDは多くの領域を使用する必要があり、ロックのオーバーヘッドも増加します。

NOLOGGINGとAPPENDを一緒に使用すると、プロセスはさらに速くなります。NOLOGGINGは操作のREDOログが生成されないことを意味します。NOLOGGINGはデフォルトではありません。パフォーマンスを最適化するときに使用します。表またはパーティションのリカバリが必要となる通常の場合には使用しないでください。リカバリが必要な場合は、操作の直後にバックアップを取得するようにします。ALTER TABLE [NO]LOGGING文を使用して、適切な値を設定します。

8.8.6.3 パラレルDMLのヒント3: INSERT、MERGE、UPDATEおよびDELETEのパラレル化

このトピックでは、挿入、マージ、更新および削除操作を使用した場合のパラレルDMLについて説明します。

データ・ディクショナリで表またはパーティションにPARALLEL属性があるとき、この属性設定が、INSERT文、UPDATE文、DELETE文および問合せでの並列処理を決定するために使用されます。文での表に対する明示的なPARALLELヒントは、データ・ディクショナリのPARALLEL属性の効果よりも優先されます。

NO_PARALLELヒントを使用すると、データ・ディクショナリの表のPARALLEL属性を上書きできます。一般的にヒントは属性よりも優先されます。

DML操作の並列処理が考慮されるのは、ALTER SESSION ENABLE PARALLEL DML文を使用してセッションがPARALLEL DMLモードになっている場合、または、ENABLE_PARALLEL_DMLヒントを使用して特定のSQL文がPARALLEL DMLモードになっている場合です。このモードは、問合せまたはDML文の問合せ部分の並列処理には影響しません。

8.8.6.3.1 INSERT SELECTのパラレル化

INSERT ... SELECT文では、INSERTキーワードの後にPARALLELヒントを指定できます。このヒントはSELECTキーワードの後にも指定できます。

INSERTキーワードの後のPARALLELヒントはINSERT操作のみに適用され、SELECTキーワードの後のPARALLELヒントはSELECT操作のみに適用されます。したがって、INSERT操作とSELECT操作の並列処理は互いに独立しています。一方の操作をパラレルで実行できなくても、もう一方の操作をパラレルで実行できるかどうかには影響しません。

ユーザーがパラレルDMLをセッションで明示的に有効化した場合、および関連する表にデータ・ディクショナリ・エントリでPARALLEL属性が設定されている場合、挿入操作をパラレル化できる機能により既存の動作が変更されます。この場合、選択操作がパラレル化された既存のINSERT SELECT文で、挿入操作もパラレル化できます。

複数の表を問い合せる場合は、複数のSELECT PARALLELヒントと複数のPARALLEL属性を指定できます。

例8-5に、ACMEの買収後に雇用された新しい従業員の追加を示します。

例8-5INSERT SELECTのパラレル化

INSERT /*+ PARALLEL(employees) */ INTO employees
SELECT /*+ PARALLEL(ACME_EMP) */ *  FROM ACME_EMP;

この例ではAPPENDキーワードは必要ありません。PARALLELヒントによって追加が暗黙的に指定されるためです。

8.8.6.3.2 UPDATEとDELETEのパラレル化

PARALLELヒント(UPDATEまたはDELETEキーワードの直後に指定)は、基礎となるスキャン操作に適用されるだけではなく、UPDATEまたはDELETE操作にも適用されます。

または、変更対象の表の定義に指定されるPARALLEL句で、UPDATEまたはDELETEのパラレル化を指定できます。

セッションまたはトランザクションについてパラレルDMLを明示的に有効化した場合、問合せ操作がパラレル化されたUPDATE文またはDELETE文は、UPDATE操作またはDELETE操作もパラレル化できます。文の副問合せまたは更新可能ビューには、独自のPARALLELヒントまたは句を指定できますが、これらのパラレル・ディレクティブは更新または削除をパラレル化する決定には影響しません。これらの操作をパラレルで実行できなくても、UPDATEまたはDELETE部分をパラレルで実行できるかどうかには影響しません。

例8-6に、ダラスのすべての店員を10%昇給する更新操作を示します。

例8-6UPDATEとDELETEのパラレル化

UPDATE /*+ PARALLEL(employees) */ employees
 SET salary=salary * 1.1 WHERE job_id='CLERK' AND department_id IN
  (SELECT department_id FROM DEPARTMENTS WHERE location_id = 'DALLAS');

PARALLELヒントは、UPDATE操作とスキャンに適用されます。

例8-7には、カテゴリ39のすべての商品の削除を示します。最近、事業が別会社として分離されたためです。

例8-7UPDATEとDELETEのパラレル化

DELETE /*+ PARALLEL(PRODUCTS) */ FROM PRODUCTS 
  WHERE category_id = 39;

ここでも、並列性処理、表employeesのスキャンとUPDATE操作に適用されます。

8.8.7 パラレルでの増分データ・ロード

パラレルDMLを更新可能結合ビュー機能と組み合せると、データ・ウェアハウス・システムの表をリフレッシュするための効率のよいソリューションが得られます。

表をリフレッシュするには、OLTP本番システムで生成される差分データを使用して更新します。

次の例では、列c_key、c_nameおよびc_addrを含むcustomersという表をリフレッシュするとします。差分データには、新しい行またはデータ・ウェアハウスの最後のリフレッシュ以降に更新された行が含まれます。この例では、本番システムの更新データはデータ・ウェアハウス・システムにASCIIファイルとして送られます。リフレッシュ・プロセスを開始する前に、これらのファイルを一時表diff_customerにロードする必要があります。このタスクを効率よく実行するには、パラレル・オプションとダイレクト・オプションの両方を指定したSQL*Loaderを使用できます。パラレルでロードする場合はAPPENDヒントも使用します。

diff_customerがロードされたら、リフレッシュ・プロセスを開始できます。これは、次に示すように、2フェーズで実行するか、パラレルでのマージにより実行することができます。

8.8.7.1 パラレルでの表の更新のためのパフォーマンスの最適化

このトピックでは、パラレルでの表の更新のためのパフォーマンスの最適化方法について説明します。

次の文は、副問合せを使用して更新する単純なSQLの実装です。

UPDATE customers SET(c_name, c_addr) = (SELECT c_name, c_addr
  FROM diff_customer WHERE diff_customer.c_key = customer.c_key)
  WHERE c_key IN(SELECT c_key FROM diff_customer);

残念ながら、この文の2つの副問合せはパフォーマンスに影響します。

かわりに、更新可能結合ビューを使用してこの問合せを作成しなおすことができます。問合せを再作成するには、まず主キー制約をdiff_customer表に追加して、変更される列がキー保存表にマップされるようにします。 

CREATE UNIQUE INDEX diff_pkey_ind ON diff_customer(c_key) PARALLEL NOLOGGING;

ALTER TABLE diff_customer ADD PRIMARY KEY (c_key);

その後、次のSQL文を使用してcustomers表を更新できます。 

UPDATE /*+ PARALLEL(cust_joinview) */
  (SELECT /*+ PARALLEL(customers) PARALLEL(diff_customer) */
  CUSTOMER.c_name AS c_name CUSTOMER.c_addr AS c_addr,
   diff_customer.c_name AS c_newname, diff_customer.c_addr AS c_newaddr
   FROM diff_customer
   WHERE customers.c_key = diff_customer.c_key) cust_joinview
   SET c_name = c_newname, c_addr = c_newaddr;

結合ビューcust_joinviewにデータを提供するための基本スキャンはパラレルで実行されます。その後、更新をパラレル化して、さらにパフォーマンスを向上させることができます。ただし、これはcustomers表がパーティション化されている場合のみです。

8.8.7.2 パラレルでの表への新しい行の効率的な挿入

このトピックでは、パラレルでの表への新しい行の効率的な挿入方法について説明します。

リフレッシュ・プロセスの後半のフェーズでは、diff_customer一時表の新しい行をcustomers表に挿入します。更新の場合とは異なり、INSERT文の副問合せの指定は必要です。 

INSERT /*+PARALLEL(customers)*/ INTO customers SELECT * FROM diff_customer s);

ただし、HASH_AJヒントを使用すると、この副問合せは必ずアンチハッシュ結合に変換されます。こうすると、パラレルINSERTを使用して、前の文を効率よく実行できます。パラレルINSERTは、表がパーティション化されていなくても適用できます。

8.8.7.3 パラレルでのマージによるパフォーマンスの最適化

このトピックでは、パラレルでのマージによるパフォーマンス最適化方法について説明します。

次の例に示すように、更新と挿入を組み合せて1つの文にすることができます。これは一般的にはマージと呼ばれます。 

MERGE INTO customers USING diff_customer
ON (diff_customer.c_key = customer.c_key) WHEN MATCHED THEN
  UPDATE SET (c_name, c_addr) = (SELECT c_name, c_addr 
  FROM diff_customer WHERE diff_customer.c_key = customers.c_key) 
WHEN NOT MATCHED THEN
 INSERT VALUES (diff_customer.c_key,diff_customer.c_data);

前述の例のSQL文では、「パラレルでの表の更新のためのパフォーマンスの最適化」および「パラレルでの表への新しい行の効率的な挿入」のすべての文と同じ結果をアーカイブします。