ヘッダーをスキップ
Oracle Databaseデータ・ウェアハウス・ガイド
10gリリース2(10.2)
B19217-02
  目次へ
目次
索引へ
索引

前へ
前へ
次へ
次へ
 

25 パラレル実行の使用

この章では、パラレル実行環境におけるチューニングについて説明します。内容は次のとおりです。

パラレル実行のチューニングの概要

パラレル実行によって、一般的に意思決定支援システム(DSS)およびデータ・ウェアハウスに対応付けられている大規模なデータベースでの、データ処理集中型の操作における応答時間が大幅に削減されます。パラレル実行は、特定のオンライン・トランザクション処理(OLTP)システムおよびハイブリッド・システムでも実装できます。パラレル実行は、パラレル化と呼ばれることもあります。パラレル化は、1つのプロセスで問合せの作業をすべて実行するかわりに、多数のプロセスで作業の各部を同時に実行できるように、タスクを分割するという概念です。その一例が、1つのプロセスが4つの四半期を単独ですべて処理するかわりに、4つのプロセスがそれぞれ1つずつ四半期を処理する場合です。これにより、パフォーマンスを大幅に改善できます。この場合、各四半期はパーティション、つまり、より小型で管理しやすい単位の索引または表となります。パラレル実行によって、次の処理を改善できます。

また、パラレル実行を使用して、Oracleデータベース内のオブジェクト型にアクセスすることもできます。たとえば、パラレル実行を使用してラージ・オブジェクト(Large Object: LOB)にアクセスできます。

システムが次のすべての特性を持つ場合、そのシステムは、パラレル実行による効果を得られます。

システムにこれらの特性が1つでも欠けている場合、パラレル実行による大幅なパフォーマンスの向上は得られない場合があります。実際に、パラレル実行によって、使用率の高いシステムまたはI/O帯域幅が小さいシステムのパフォーマンスが低下する可能性があります。

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

パラレル実行の利点は、DSSおよびデータ・ウェアハウス環境で明らかになります。OLTPシステムにおいても、バッチ処理時および索引の作成などのスキーマ・メンテナンス操作時にパラレル実行の利点を活用できます。OLTPアプリケーションを特徴付ける平均的で単純なDMLまたはSELECT文の場合、パラレルに実行されることによる利点はありません。

パラレル実行を実装する必要がない場合

パラレル実行は通常、次の場合には有用ではありません。

  • 通常の問合せまたはトランザクションが非常に短い(数秒以内で完了する)環境。これには、ほとんどのオンライン・トランザクション・システムが含まれます。これらの環境では、パラレル実行サーバーの調整に関するコストが発生するため、パラレル実行は役に立ちません。短いトランザクションの場合、この調整のコストがパラレル化の利点を上回る場合があります。

  • CPU、メモリー、I/Oリソースがすでに頻繁に使用されている環境。パラレル実行は、追加の使用可能なハードウェア・リソースを活用するよう設計されています。そのようなリソースが使用できない場合、パラレル実行による利点はなく、パフォーマンスの低下につながる可能性があります。

パラレル化できる操作

パラレル実行を次の対象に使用できます。

  • アクセス方法

    表スキャン、全索引スキャンおよびパーティション索引レンジ・スキャンなど。

  • 結合方法

    ネステッド・ループ、ソート・マージ、ハッシュおよびスター型変換など。

  • DDL文

    CREATE TABLE AS SELECTCREATE INDEXREBUILD INDEXREBUILD INDEX PARTITIONMOVE/SPLIT/COALESCE PARTITIONなど。

    通常は、標準DDLを使用するパラレルDDLを使用できます。ただし、データベース設計の際に考慮すべきいくつかの詳細があります。重要な制約事項として、オブジェクトまたはLOB列を持つ表では、パラレルDDLを使用できないことがあげられます。

    これらのDDL操作はすべて、パラレル実行またはシリアル実行用にNOLOGGINGモードで実行できます。

    索引構成表に対するCREATE TABLE文は、AS SELECT句を指定してもしなくてもパラレル化できます。

    様々な操作に異なるパラレル化が使用されます。PARALLEL CREATE(パーティション化)TABLE AS SELECT文およびPARALLEL CREATE(パーティション化)INDEX文は、パーティション数と同じ並列度で動作します。

    パラレル操作では、最適に実行するために正確な統計情報が必要です。

  • DML文

    INSERT AS SELECT、UPDATE、DELETEおよびMERGE操作など。

    パラレルDML(パラレルINSERT、UPDATE、MERGEおよびDELETE)では、大きなデータベース表や索引に対する大規模なDML操作をスピードアップまたは拡張するために、パラレル実行メカニズムが使用されます。また、INSERT ... SELECT文を使用して、単一DML文の一部として複数の表に行を挿入できます。通常は、標準DMLを使用するパラレルDMLを使用できます。

    通常、データ操作言語(DML)には問合せが含まれますが、パラレルDMLという用語は、パラレル実行される挿入、更新、アップサートおよび削除のみを指します。

  • その他のSQL操作

    GROUP BYNOT INSELECT DISTINCTUNIONUNION ALLCUBEROLLUP、集計関数および表関数など。

  • パラレル問合せ

    問合せと副問合せをSELECT文中でパラレル化できます。また、DDL文とDML文の問合せ部分(INSERTUPDATEDELETEMERGE)もパラレル化できます。

  • SQL*Loader

    大量のデータが定期的に発生するSQL*Loaderの使用をパラレル化できます。ロードをスピードアップするには、次のようにパラレル・ダイレクト・パス・ロードを使用します。

    sqlldr USERID=SCOTT/TIGER CONTROL=LOAD1.CTL DIRECT=TRUE PARALLEL=TRUE
    sqlldr USERID=SCOTT/TIGER CONTROL=LOAD2.CTL DIRECT=TRUE PARALLEL=TRUE
    sqlldr USERID=SCOTT/TIGER CONTROL=LOAD3.CTL DIRECT=TRUE PARALLEL=TRUE
    
    

    また、パラメータ・ファイルを使用して同じ作業を実行することもできます。

    パラレル・ロード時には、索引が保持されないので注意してください。

パラレル実行の動作方法

パラレル実行では、SQL文の実行タスクを複数の単位に細分化し、各単位を独立したプロセスで実行します。また、入力データ(表、索引、パーティション)をグラニュルという部分に分割できます。パラレルで問合せを実行するユーザーのシャドウ・プロセスは、パラレル実行コーディネータまたは問合せコーディネータとしての役割を担います。問合せコーディネータでは、次の処理を行います。

並列度

パラレル実行コーディネータは、インスタンスの複数のパラレル実行サーバーに1つのSQL文を処理させる場合があります。単一の操作に関連するパラレル実行サーバーの数は、並列度と呼ばれます。

単一の操作は、ORDER BY、索引なしの列表に対して結合を実行する全表スキャンなどのSQL文の一部です。

並列度はイントラ・オペレーション並列化にのみ直接適用されます。インター・オペレーション並列化が可能な場合は、文のパラレル実行サーバーの合計数を指定した並列度の2倍にできます。同時に実行できるパラレル実行サーバーは2つまでです。パラレル実行サーバーの各セットは、複数の操作を処理できます。最適なインター・オペレーション並列化を保証するためにアクティブにする必要のあるパラレル実行サーバーは、2セットのみです。

パラレル実行は、複数のCPUおよびディスクを効率的に使用して問合せに迅速に答えるように設計されています。複数のユーザーが同時にパラレル実行を使用すると、使用可能なCPU、メモリーおよびディスク・リソースが短時間で消費されやすくなります。

Oracle Databaseには、パラレル実行環境に伴うリソース使用率を管理できるように、次の様々な方法が用意されています。

  • マルチユーザー問合せ調整アルゴリズム。デフォルトで有効になっています。システム負荷が増大するにつれて並列度を低下させます。

  • ユーザー・リソース制限およびプロファイル。各ユーザーが使用可能な各種システム・リソースの量に対する制限を、ユーザーのセキュリティ・ドメインの一部として設定できます。

  • Database Resource Manager。様々なユーザー・グループにリソースを割り当てることができます。

パラレル実行サーバー・プール

インスタンスの起動時に、Oracleではすべてのパラレル操作に使用可能なパラレル実行サーバーのプールが作成されます。初期化パラメータPARALLEL_MIN_SERVERSでは、Oracle Databaseによりインスタンスの起動時に作成されるパラレル実行サーバーの数を指定します。

パラレル操作の実行中に、パラレル実行コーディネータはプールからパラレル実行サーバーを取得して操作に割り当てます。必要な場合は、Oracleで操作用のパラレル実行サーバーを追加作成できます。これらのパラレル実行サーバーは、ジョブの実行中は操作で保持され、その後は他の操作に使用可能になります。文の処理が完了すると、パラレル実行サーバーはプールに戻されます。

パラレル実行コーディネータとパラレル実行サーバーで処理できる文は、一度に1つのみであることに注意してください。パラレル実行コーディネータで、パラレル問合せとパラレルDML文などを同時に調整することはできません。

ユーザーがSQL文を発行すると、オプティマイザでは操作をパラレルに実行するかどうかと、各操作の並列度(DOP)が決定されます。操作に必要なパラレル実行サーバーの数は、様々な方法で指定できます。

オプティマイザのターゲットがパラレル処理用の文の場合は、イベントが次の順序で発生します。

  1. SQL文のフォアグラウンド・プロセスがパラレル実行コーディネータになります。

  2. パラレル実行コーディネータが、必要な数(DOPにより決定)のパラレル実行サーバーをサーバー・プールから取得するか、必要に応じて新規パラレル実行サーバーを作成します。

  3. Oracleでは、文が一連の操作として実行されます。各操作は、可能であればパラレルに実行されます。

  4. 文の処理が完了すると、コーディネータはその文を発行したユーザー・プロセスに結果データを戻し、パラレル実行サーバーをサーバー・プールに戻します。

パラレル実行コーディネータは、SQL文の解析中ではなく実行中にパラレル実行サーバーを要求します。したがって、パラレル実行を共有サーバーで使用する場合は、ユーザーの文によるEXECUTEのコールを処理するサーバー・プロセスが、その文のパラレル実行コーディネータとなります。詳細は、「パラレル実行の並列度の設定」を参照してください。

パラレル実行サーバー数の変動

インスタンスにより現在処理されているパラレル操作の数が大幅に変化すると、Oracleではプール内のパラレル実行サーバーの数が自動的に変更されます。

パラレル操作数が増加すると、Oracleでは受信した要求を処理できるようにパラレル実行サーバーが追加作成されます。ただし、1インスタンスに対して、初期化パラメータPARALLEL_MAX_SERVERSで指定した値より多数のパラレル実行サーバーが作成されることはありません。

パラレル操作の数が減少すると、しきい値の期間だけアイドル状態になっていたパラレル実行サーバーが終了します。Oracleでは、パラレル実行サーバーがアイドル状態になっていた期間が長くても、プールのサイズがPARALLEL_MIN_SERVERSの値を下回ることはありません。

パラレル実行サーバーの数が足りない処理

Oracleでは、プロセス数が必要とするより少ない場合にもパラレル操作を処理できます。

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

初期化パラメータPARALLEL_MIN_PERCENTの使用方法については「パラレル実行サーバーの最小数」を、PARALLEL_MIN_PERCENTおよびPARALLEL_MAX_SERVERS初期化パラメータについては「パラレル実行用の一般パラメータのチューニング」を参照してください。

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

問合せをパラレルに実行するために、Oracleでは、通常は生成側の問合せサーバーとコンシューマ・サーバーが作成されます。生成側の問合せサーバーは表から行を取り出し、コンシューマ・サーバーはこれらの行に対して結合、ソート、DMLおよびDDLなどの操作を実行します。生成側の問合せサーバーの実行プロセス・セット内の各サーバーは、コンシューマ・セット内の各サーバーに接続します。つまり、パラレル実行サーバー間の仮想接続数は、DOPに正比例して増加します。

各通信チャネルには1〜4個のメモリー・バッファがあります。メモリー・バッファが複数の場合は、パラレル実行サーバー間の非同期通信が容易になります。

単一インスタンス環境では、通信チャネルごとに最大3個のバッファが使用されます。Oracle Real Application Clusters環境では、チャネルごとに最大4個のバッファが使用されます。図25-1に、メッセージ・バッファと、生成側のパラレル実行サーバーからコンシューマ・パラレル実行サーバーへの接続方法を示します。

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

図25-1の説明は図の下のリンクをクリックしてください。
「図25-1 パラレル実行サーバーの接続とバッファ」の説明

同一インスタンスの2つのプロセス間に接続がある場合、サーバーはバッファをやりとりして通信します。異なるインスタンスのプロセス間に接続がある場合は、外部の高速ネットワーク・プロトコルを使用してメッセージが送信されます。図25-1では、DOPはパラレル実行サーバーの数と同じで、この場合はnです。図25-1には、パラレル実行コーディネータは示されていません。各パラレル実行サーバーは、実際にはパラレル実行コーディネータにも接続しています。

SQL文のパラレル化

各SQL文は、解析時に最適化プロセスとパラレル化プロセスの対象となります。データが変化した場合に、より最適な実行またはパラレル化計画が使用可能になれば、Oracleでは新しい状況にあわせて自動的に調整できます。

オプティマイザが文の実行計画を決定すると、パラレル実行コーディネータは計画に含まれる各操作のパラレル化方法を決定します。たとえば、パラレル化方法には、ブロック範囲による全表スキャンのパラレル化や、パーティションによる索引レンジ・スキャンのパラレル化などがあります。コーディネータは、操作をパラレルに実行できるかどうかと、実行可能な場合は該当するパラレル実行サーバー数を決定する必要があります。1セットのパラレル実行サーバーの数は、DOPと同じです。詳細は、「パラレル実行の並列度の設定」を参照してください。

パラレル実行サーバー間での処理の分割

パラレル実行コーディネータにより、各操作の再分散化要件が検査されます。操作の再分散化要件は、操作により処理される行をパラレル実行サーバー間で分割または再分散させるために必要な方法です。

実行計画に含まれる各操作の再分散化要件が決定された後に、オプティマイザにより操作の実行順序が決定されます。オプティマイザでは、この情報を使用して文のデータ・フローが決定されます。

イントラ・オペレーション並列化およびインター・オペレーション並列化を持つパラレル問合せの例として、より複雑な次の問合せを考えてみます。

SELECT /*+ PARALLEL(employees 4) PARALLEL(departments 4)
       USE_HASH(employees) ORDERED */ MAX(salary), AVG(salary)
FROM employees, departments
WHERE employees.department_id = departments.department_id
GROUP BY employees.department_id;

ヒントを問合せで使用することによって、結合順序と結合方法を強制的に指定し、表employeesおよびdepartmentsのDOPを指定しています。通常は、オプティマイザに順序と方法を決定させる必要があります。

図25-2に、この問合せのデータ・フロー図または問合せ計画を示します。

図25-2 表の結合のデータ・フロー図

図25-2の説明は図の下のリンクをクリックしてください。
「図25-2 表の結合のデータ・フロー図」の説明

操作間のパラレル化

図25-2で示されている問合せ計画でパラレル実行サーバーSS1およびSS2の2つのセットがある場合、実行は次のように進められます。問合せにおいてPARALLELヒントでDOPを指定しているため、各サーバー・セット(SS1およびSS2)には、4つの実行プロセスが与えられます。つまり、パラレル実行サーバーの各セットには4つのプロセスがあるため、DOPは4になります。

スレーブ・セットSS1が最初に表employeesをスキャンします。他方、SS2はSS1から行をフェッチして、その行のハッシュ表を構築します。つまり、SS2内の親サーバーとSS2内の子サーバーは次のように同時に作業します。一方がemployeesをパラレルでスキャンし、他方が、SS1から送られる行を使用してハッシュ結合用のハッシュ表をパラレルで構築します。これが、インター・オペレーション並列化の例です。

SS1が表employees全体のスキャンを終了する(すなわち、employeesのすべてのグラニュルまたはタスク単位が使用される)と、表departmentsをパラレルでスキャンします。SS1が行をSS2内のサーバーに送ると、SS2はハッシュ結合を完了するため、プローブをパラレルで実行します。SS1は、表departmentsのパラレル・スキャンおよびSS2への行の送信を終了すると、GROUP BYのパラレル実行を開始します。これが、2つのサーバー・セットを同時に実行して、各操作のパラレル実行によるイントラ・オペレーション並列化を実現する一方、問合せツリー内の各種演算子に対するインター・オペレーション並列化を実現する方法です。

パラレル実行でもう1つ重要なのは、あるサーバーが別のサーバーに設定されているときに、サーバーから行の送信が行われた場合、行が再パーティション化されることです。図25-2の問合せ計画では、SS1内のサーバー・プロセスがemployeesの行をスキャンした後で、SS2のどのサーバー・プロセスに行が送信されるのでしょうか。問合せツリーからあふれた行のパーティション化は、行の送信先の演算子によって決定されます。この場合、employeesのパラレル・スキャンを実行するSS1からあふれた行を、パラレル・ハッシュ結合を実行するSS2にパーティション化する処理は、結合列の値に基づくハッシュ・パーティション化によって行われます。つまり、employeesをスキャンするサーバー・プロセスは、列employees.employee_idの値のハッシュ関数を計算して、列の送信先となるSS2内のサーバー・プロセスの数を決定します。パラレル問合せで使用するパーティション化の方法は、問合せのEXPLAIN PLANに明示的に示されます。実行サーバー・セット間に送られる行のパーティション化を、ハッシュ、レンジおよびその他の方法によって表のパーティション化が行われるOracleのパーティション化機能と混同しないでください。

生成側の操作

他の操作の出力を必要とする操作は、コンシューマ操作と呼ばれます。図25-2では、GROUP BY SORT操作は、HASH JOIN操作の生成側です。これは、GROUP BY SORTではHASH JOIN出力を必要とするためです。

生成側の操作では、生成側の操作により行が生成された直後に行を使用できるようになります。前述の例では、パラレル実行サーバーがFULL SCAN departments操作で行を生成すると同時に、別のパラレル実行サーバー・セットがHASH JOIN操作の実行を開始して行を使用できます。

現在実行されている2つの操作には、それぞれ専用のパラレル実行サーバー・セットが割り当てられます。したがって、問合せ操作とデータ・フロー・ツリー自体が並列性を持っています。個々の操作の並列化はイントラ・オペレーション並列化と呼ばれ、データ・フロー・ツリーにおける操作間の並列化はインター・オペレーション並列化と呼ばれます。Oracle Serverによる操作は生成側の問合せサーバーとコンシューマという性質があるため、実行時間を最短に抑えるために、特定のツリー内で同時に実行する必要がある操作は2つのみです。イントラ・オペレーション並列化とインター・オペレーション並列化を理解するために、次の文を考えてみます。

SELECT * FROM employees ORDER BY last_name;

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

図25-3に、問合せ例のパラレル実行を示します。

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

図25-3の説明は図の下のリンクをクリックしてください。
「図25-3 インター・オペレーション並列化と動的パーティション化」の説明

図25-3のように、DOPが4であっても、実際には8つのパラレル実行サーバーが問合せに関与しています。これは、親オペレータと子オペレータを同時に実行できるためです(インター・オペレーション並列化)。

また、スキャン操作に関与するすべてのパラレル実行サーバーから、SORT操作を実行中の適切なパラレル実行サーバーに、行が送信されるため注意してください。パラレル実行サーバーによりスキャンされる行には、AGlast_name列の値が含まれ、その行が最初のORDER BYのパラレル実行サーバーに送信されます。スキャン操作が完了すると、ソート・プロセスはソート結果をコーディネータに戻し、コーディネータはユーザーに問合せ結果全体を戻すことができます。

パラレル化のグラニュル

使用するパラレル化のタイプは、パラレル操作によって異なります。最適な物理データベース・レイアウトは、アプリケーションで行う主なパラレル操作や、パーティションを使用する必要があるかどうかによって異なります。

パラレル化の基本処理単位はグラニュルと呼ばれます。パラレル化された操作(表スキャン、表の更新または索引の作成など)は、Oracle Databaseによってグラニュルに分割されます。パラレル実行処理は、一度に1グラニュルの操作を実行します。グラニュルの数およびサイズには、並列度(DOP)との相関関係があります。また、問合せサーバー・プロセス間での動作の均衡化にも影響します。Oracle Databaseではこの決定が内部的に行われるため、特定のグラニュル方針を規定する方法はありません。

ブロック範囲グラニュル

ブロック範囲グラニュルは、パーティション表においても、ほとんどのパラレル操作の基本単位です。つまり、Oracle Databaseでは、並列度はパーティションの数に関連しません。

ブロック範囲グラニュルは、表の物理ブロックの範囲です。グラニュルの数とサイズはOracle Databaseにより実行中に計算され、影響を受けるすべてのパラレル実行サーバーの作業分散が最適化され、均衡化されます。グラニュルの数とサイズは、オブジェクトのサイズとDOPに依存します。ブロック範囲グラニュルは、表または索引の静的な事前割当てに依存しません。グラニュルの計算中には、競合をできるだけ回避するために、Oracle DatabaseはDOPを考慮して様々なデータファイルから各パラレル実行サーバーにグラニュルを割り当てます。また、MPPシステムでは、グラニュルのディスク・アフィニティを考慮して、パラレル実行サーバーとディスク間の物理的な近さが活用されます。

ブロック範囲グラニュルが、表または索引へのパラレル・アクセスで優先的に使用されている場合、パフォーマンス上の考慮点より、管理上の考慮点(リカバリ、パーティションを使用したデータの部分削除など)がパーティション・レイアウトに影響を与えることがあります。

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

パーティション・グラニュルが使用される場合、問合せサーバー・プロセスは、表または索引のパーティション全体またはサブパーティション全体に対して動作します。通常、パーティション・グラニュルは表または索引の作成時にその構造によって静的に決定されるため、ブロック範囲グラニュルほど柔軟に操作をパラレル化できるわけではありません。最大許容DOPは、パーティション数となります。このため、システムの使用率とパラレル実行サーバー間のロード・バランシングが制限される場合があります。

パーティション・グラニュルが表または索引へのパラレル・アクセスに使用される場合は、問合せサーバー・プロセス間で作業が効率的に均衡化されるように、比較的多くのパーティション(並列度の3倍が理想的)を使用する必要があります。

パーティション・グラニュルは、パラレル索引レンジ・スキャン、問合せオプティマイザによってパーティション・ワイズ結合の使用が選択されている場合の2つの同一レベル・パーティション表の間の結合、およびパーティション索引の複数パーティションを変更するパラレル操作(パーティション索引のパラレル作成など)の基本単位です。これらの操作には、パーティション索引のパラレル作成およびパーティション表のパラレル作成が含まれます。

パラレル化のタイプ

この項では、次のタイプのパラレル化について説明します。

パラレル問合せ

問合せと副問合せをSELECT文中でパラレル化できます。また、DDL文とDML文の問合せ部分(INSERTUPDATEおよびDELETE)もパラレル化できます。外部表の問合せをパラレルで実行することもできます。


関連項目:


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

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

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

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

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

これらのスキャン方法は、オーバーフロー領域を持つ索引構成表と、LOBを含む索引構成表に使用できます。

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

非パーティション索引構成表のパラレル問合せには、パラレル高速全スキャンが使用されます。DOPは、次のように優先順位の降順で決定されます。

  1. PARALLELヒント(存在する場合)

  2. ALTER SESSION FORCE PARALLEL QUERY

  3. CREATE TABLEまたはALTER TABLE文で並列度が指定されている場合は、表に対応付けられている並列度

作業の割当ては、索引セグメントを十分な数のブロック範囲に分割し、そのブロック範囲を必要に応じてパラレル実行サーバーに割り当てることで行われます。行に対応するオーバーフロー・ブロックには、その行を所有するプロセスのみが必要に応じてアクセスします。

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

索引レンジ・スキャンと高速全スキャンの両方をパラレルに実行できます。パラレル高速全スキャンの場合、並列性は非パーティション索引構成表の場合と同じです。パーティション索引構成表のパラレル索引レンジ・スキャンの場合、DOPは前述の優先順位リストから選択された最小並列度(パラレル高速全スキャンと同様)と、索引構成表のパーティション数です。各パラレル実行サーバーは、DOPに応じて1つ以上の(需要に応じて割り当てられた)パーティションを取得します。各パーティションには、主キー索引セグメントと、存在する場合は対応するオーバーフロー・セグメントが含まれています。

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

パラレル問合せは、オブジェクト型の表やオブジェクト型の列を含む表に対して実行できます。オブジェクト型のパラレル問合せでは、次のように、オブジェクト型に対する順次問合せに使用可能な機能がすべてサポートされます。

  • オブジェクト型のメソッド

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

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

  • オブジェクト・ビュー

  • オブジェクト型のPL/SQL問合せとOCI問合せ

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

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

  • 結合とソート(ORDER BYGROUP BYまたは集合演算)を伴う問合せをパラレル化するには、MAP関数が必要です。MAP関数がなければ、問合せは自動的にシリアルに実行されます。

  • オブジェクト型ではパラレルDMLとパラレルDDLはサポートされません。DML文とDDL文は、常にシリアルに実行されます。

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

パラレルDDL

この項では、次のトピックでDDL文のパラレル化について説明します。

パラレル化できるDDL文

表および索引に対するDDL文は、それらの表や索引がパーティション化されているかどうかにかかわらずパラレル化できます。表25-3は、DDL文でパラレル化可能な操作をまとめたものです。

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

  • CREATE INDEX

  • CREATE TABLE ...AS SELECT

  • ALTER INDEX ...REBUILD

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

  • CREATE INDEX

  • CREATE TABLE ...AS SELECT

  • ALTER TABLE ...[MOVE|SPLIT|COALESCE] PARTITION

  • ALTER INDEX ...[REBUILD|SPLIT] PARTITION

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

これらのDDL操作はすべて、パラレル実行またはシリアル実行用にロギングなしモードで実行できます。

索引構成表に対するCREATE TABLEは、AS SELECT句を指定してもしなくてもパラレル化できます。

様々な操作に異なるパラレル化が使用されます(表25-3を参照)。パーティション表に対するパラレルCREATE TABLE ... AS SELECT文と、パーティション索引に対するパラレルCREATE INDEX文は、パーティション数と等しいDOPで実行されます。

パーティション表全体のパラレル分析を複数のユーザー・セッションで構成できるため、ANALYZE {TABLE, INDEX} PARTITION文でパラレル分析表のパーティション化を行う必要はあまりありません。

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

パラレルのCREATE TABLE ... AS SELECT

パフォーマンス上の理由で、意思決定支援アプリケーションでは、通常、非定型の意思決定支援用の問合せで使用できるように、大量のデータを小さい表にサマリーまたはロールアップする必要があります。ロールアップは、システムがアクティブでない短い期間中に定期的(夜間や週次など)に実行されます。

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

クラスタ化表の作成と移入は、パラレルには実行できません。

図25-4に、副問合せからの表のパラレル作成を示します。

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

図25-4の説明は図の下のリンクをクリックしてください。
「図25-4 パラレルでのサマリー表の作成」の説明

リカバリ能力とパラレルDDL

サマリー表のデータが他の表のデータから導出される場合、小さいサマリー表に関するメディア障害からのリカバリ能力は重要ではなく、サマリー表の作成中はオフにできます。

パラレル表作成(または他のパラレルDDL操作)中にロギングを使用禁止にする場合は、メディア障害により表が失われないように、表の作成後にその表を含む表領域のバックアップを作成する必要があります。

UNDOログとREDOログの生成を使用禁止にするには、CREATE TABLECREATE INDEXALTER TABLEおよびALTER INDEX文のNOLOGGING句を使用します。

パラレルDDLの領域管理

表または索引をパラレルに作成する操作は、領域管理を伴います。これは、パラレル操作中に必要な記憶域と、表または索引の作成後に使用可能な空き領域に影響します。

ディクショナリ管理の表領域を使用した場合の記憶領域

表または索引をパラレルに作成する場合、各パラレル実行サーバーではCREATE文のSTORAGE句の値を使用して、行を格納する一時セグメントが作成されます。したがって、NEXTを5MB、PARALLEL DEGREEを12に設定して作成される表の場合、各プロセスは5MBのエクステントで始まるため、表の作成中に60MB以上の記憶域を消費します。パラレル実行コーディネータによってセグメントが組み合されると、いくつかのセグメントは切り捨てられ、作成された表は、要求された60MBより小さくなる場合があります。

空き領域とパラレルDDL

索引と表をパラレルに作成する場合は、各パラレル実行サーバーにより新規エクステントが割り当てられ、そのエクステントが表または索引データで埋められます。したがって、DOPが3の索引を作成すると、索引のエクステント数は最初は3以上になります。エクステントの割当ては、索引をパラレルで作成する場合や、パーティションをパラレルに移動、分割または再作成する場合と同じです。

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

表または索引をパラレルに作成する場合は、空き領域のポケットの作成、つまり、外部断片化または内部断片化が可能です。これが発生するのは、パラレル実行サーバーにより使用される一時セグメントが、行の格納に必要なサイズよりも大きい場合です。

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

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

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

表と索引をパラレルに作成する方法の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

図25-5 使用不能な空き領域(内部断片化)

図25-5の説明は図の下のリンクをクリックしてください。
「図25-5 使用不能な空き領域(内部断片化)」の説明

パラレルDML

パラレルDML(PARALLEL INSERTUPDATEDELETEおよびMERGE)では、大きいデータベース表や索引に対する大規模なDML操作をスピードアップまたは拡張するために、パラレル実行メカニズムが使用されます。


注意:

通常、DMLには問合せが含まれますが、この章で使用しているDMLという用語は、挿入、更新、マージおよび削除のみを指します。

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

手動パラレル化におけるパラレルDMLのメリット

異なるデータセットに対して同時に複数のDML文を発行すると、DML操作をパラレル化できます。たとえば、手動でパラレル化するには、次の方法があります。

  • Oracle Real Application Clustersの複数のインスタンスに対して複数のINSERT文を発行し、複数の空きリスト・ブロックの空き領域を使用可能にします。

  • 異なるキー値範囲またはROWID範囲を指定して、複数のUPDATEおよびDELETE文を発行します。

ただし、手動によるパラレル化には次のデメリットがあります。

  • 使用しにくさ。複数のセッションを(可能であれば異なるインスタンス上で)オープンし、複数の文を発行する必要があります。

  • トランザクション・プロパティの不足。DML文は様々な時点で発行されるため、変更はデータベースの一貫性のないスナップショットを使用して行われます。アトム性を得るには、各種の文のコミットまたはロールバックを手動で(インスタンス間でも)調整する必要があります。

  • 作業分割の複雑さ。ROWID値またはキー値の範囲を検索して作業を適切に分割するために、表の問合せが必要になる場合があります。

  • 計算の複雑さ。並列度の計算が複雑になる場合があります。

  • アフィニティとリソース情報の不足。Oracle Real Application Clustersの実行中に適切なDML文を適切なインスタンスで発行するには、アフィニティ情報を知る必要があります。また、インスタンス間でワークロードのバランスを調整するために、現行のリソース使用率に関する情報を知る必要があります。

パラレルDMLでは、挿入、更新および削除を自動的にパラレルに実行することで、このようなデメリットが解消されます。

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

パラレルDML操作は、主として大きいデータベース・オブジェクトに対する大規模なDML操作をスピードアップするために使用されます。また、大きいオブジェクトへのアクセスのパフォーマンスと拡張性が重要なDSS環境で有効です。パラレルDMLはパラレル問合せを補完し、DSSデータベース用の問合せおよび更新機能を提供します。

パラレル化の設定に伴うオーバーヘッドのため、短いOLTPトランザクションに対するパラレルDML操作は不可能です。ただし、パラレルDML操作により、OLTPデータベースで実行されるバッチ・ジョブをスピードアップできます。

パラレルDMLの使用例は、次のとおりです。

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

データ・ウェアハウス・システムでは、大きい表を本番システムからの新規データまたは変更済データで定期的にリフレッシュ(更新)する必要があります。これは、パラレルDMLと更新可能な結合ビューを併用すれば効率的に実行できます。また、MERGE文も使用できます。

リフレッシュを必要とするデータは、通常はリフレッシュ・プロセスの開始前に一時表にロードされます。この表には、新しい行またはデータ・ウェアハウスの最後のリフレッシュ後に更新された行のいずれかが含まれます。更新可能な結合ビューとパラレルUPDATEを併用して更新済の行をリフレッシュし、逆ハッシュ結合をパラレルINSERTと併用して新規行をリフレッシュできます。

中間サマリー表の作成

DSS環境では、多くのアプリケーションが、多数の大きい中間サマリー表の構成と操作を伴う複雑な計算を必要とします。これらのサマリー表は、通常は一時表であり、頻繁にログに記録する必要はありません。パラレルDMLを使用すると、このような大きい中間表に対する操作をスピードアップできます。そのメリットの1つは、中間結果を中間表に入れてパラレル更新を実行できることです。

また、サマリー表には、アプリケーション・セッション以降も持続する必要のある累積情報や比較情報が含まれている場合があるため、一時表は不可能です。パラレルDML操作を使用すると、このような大きいサマリー表の変更をスピードアップできます。

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

多数のDSSアプリケーションでは、基準に基づいて顧客が定期的にスコアリングされます。スコアリングは、通常は大きいDSS表に格納されます。スコアリング情報は、メーリング・リストに含めるかどうかなどの意思決定に使用されます。

このスコアリング・アクティビティでは、大きい表にある多数の行が問合せされ、更新されます。パラレルDMLを使用すると、このような大きい表に対する操作をスピードアップできます。

履歴表の更新

履歴表には、最新の時間間隔における企業のビジネス・トランザクションが記述されます。データベース管理者は、定期的に最も古い行セットを削除し、新しい行セットを表に挿入します。パラレルINSERT ... SELECTおよびパラレルDELETE操作により、このロールオーバー・タスクをスピードアップできます。

パラレル・ダイレクト・ローダー(SQL*Loader)を使用して外部ソースから大量データを挿入することもできますが、データベースの他の表に存在するデータを挿入する場合は、パラレルINSERT ... SELECTの方が高速です。

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

バッチ・ジョブの実行

オフ時間中にOLTPデータベース内で実行されるバッチ・ジョブには、ジョブを完了することが必要な固定の時間ウィンドウがあります。適切な時点でジョブを完了させる適切な方法は、その操作をパラレル化することです。ワークロードが増大するほど、より多くのマシン・リソースを追加でき、パラレル操作のスケールアップ・プロパティにより時間的な制約が満たされることが保証されます。

パラレルDMLの有効化

DML文をパラレル化できるのは、ALTER SESSION文のENABLE PARALLEL DML句を使用して、セッション中にパラレルDMLを明示的に有効化している場合のみです。このモードが必要となるのは、パラレルDMLとシリアルDMLではロック、トランザクションおよびディスク領域の要件が異なるためです。

セッションのデフォルト・モードはDISABLE PARALLEL DMLです。パラレルDMLが使用禁止になっていると、PARALLELヒントが使用される場合でもDMLはパラレルに実行できません。

パラレルDMLがセッションで使用可能になっている場合、このセッション中のすべてのDML文はパラレル実行用と見なされます。ただし、パラレルDMLが使用可能になっていても、パラレル・ヒントがないか、パラレル属性を持つ表がないか、パラレル操作の制限に違反する場合は、DML操作がシリアルに実行されることがあります。

セッションのPARALLEL DMLモードは、SELECT文、DDL文およびDML文の問合せ部分のパラレル化には影響しません。つまり、このモードが設定されていなければ、DML操作はパラレル化されませんが、DML文中でのスキャン操作や結合操作はPARALLEL DMLモードが設定されていなくてもパラレル化される場合があります。

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

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

  • 各パラレル実行サーバーでは、それぞれ異なるパラレル・プロセス・トランザクションが作成されます。

  • 自動UNDO管理のかわりにロールバック・セグメントを使用する場合、ロールバック・セグメントでの競合を軽減しなければならない場合があります。このために、1つのロールバック・セグメントに対してパラレル・プロセス・トランザクションを少数にする必要があります。詳細は、『Oracle Database SQLリファレンス』を参照してください。

また、コーディネータにも独自のコーディネータ・トランザクションがあり、独自のロールバック・セグメントを持つことができます。ユーザー・レベルのトランザクションのアトム性を保証するために、コーディネータは2フェーズ・コミット・プロトコルを使用して、パラレル・プロセス・トランザクションにより実行された変更をコミットします。

パラレルDMLが有効になっているセッションは、セッション中に特定のモードでトランザクションを入れることができます。トランザクション内のDML文により表がパラレルに変更されると、後続のシリアル問合せ、パラレル問合せまたはDML文は、そのトランザクション中には同じ表に再度アクセスできません。つまり、トランザクション中には、パラレル変更の結果を確認できません。

パラレルに変更済の表に対して、同一トランザクション中にアクセスを試みたシリアル文やパラレル文は拒否され、エラー・メッセージが戻されます。

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

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

自動UNDO管理機能のかわりにロールバック・セグメントを使用する場合、パラレルDMLを使用する際にいくつかの制限があります。パラレルDMLおよびロールバック・セグメントの制限については、『Oracle Database SQLリファレンス』を参照してください。

パラレルDMLのリカバリ

パラレルDML操作のロールバック所要時間は、ロールフォワード操作の所要時間とほぼ同じです。

Oracleでは、トランザクションおよびプロセス障害後と、インスタンスおよびシステム障害後のパラレル・ロールバックがサポートされます。また、トランザクション・リカバリのロールフォワード段階とロールバック段階をパラレル化できます。

パラレル・ロールバックの詳細は、『Oracle Databaseバックアップおよびリカバリ基礎』を参照してください。

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

文エラーによるトランザクション障害中にユーザーが発行したロールバックは、パラレル実行コーディネータおよびパラレル実行サーバーによりパラレルに実行されます。このロールバックの所要時間は、ロールフォワード・トランザクションの場合とほぼ同じです。

プロセス・リカバリ

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

システム・リカバリ

システム障害からのリカバリでは、新規に起動する必要があります。リカバリは、SMONプロセスと、SMONプロセスで起動されるリカバリ・サーバー・プロセスにより実行されます。パラレルDML文は、パラレル・ロールバックを使用してリカバリできます。初期化パラメータCOMPATIBLEが8.1.3以上に設定されている場合は、ファスト・スタート・オン・デマンド・ロールバックにより、終了したトランザクションを必要に応じて一度に1ブロックずつリカバリできます。

パラレルDMLの領域に関する考慮点

パラレルUPDATEでは既存のオブジェクトの領域が使用されますが、ダイレクト・パス・インサートではデータ用に新規セグメントが取得されます。

複数の同時の子トランザクションでオブジェクトが変更されるため、パラレル実行と順次実行では領域使用特性が異なる場合があります。

パラレルDMLのロックおよびエンキュー・リソース

パラレルDML操作のロックおよびエンキューのリソース要件は、シリアルDMLとはかなり異なります。パラレルDMLは、より多くのロックを保持するため、ENQUEUE_RESOURCESおよびDML_LOCKSパラメータの開始値を増やす必要があります。詳細は、「DML_LOCKS」を参照してください。

パラレルDMLの制限

パラレルDMLには(ダイレクト・パス・インサートを含めて)、次の制限が適用されます。

  • UPDATEMERGEおよびDELETEの各操作に対してパーティション内並列性を実現するには、COMPATIBLE初期化パラメータを9.2以上に設定する必要があります。

  • INSERT VALUES文はパラレル化されません。

  • トランザクションには、異なる表を変更する複数のパラレルDML文を含めることができますが、パラレルDML文により表が変更されると、後続のシリアル文やパラレル文(DMLまたは問合せ)は、そのトランザクション中は同じ表に再度アクセスできません。

    • この制限は、シリアルのダイレクト・パス・インサート文の後にも適用され、後続のSQL文(DMLや問合せ)は、そのトランザクション中には変更された表にアクセスできません。

    • 同じ表にアクセスする問合せは、パラレルDML文またはダイレクト・パス・インサート文の前には許されますが、これらの文の後には許されません。

    • パラレルUPDATEDELETEMERGEまたはダイレクト・パス・インサートにより変更済の表に対して、同じトランザクション中にアクセスを試みるシリアル文またはパラレル文は拒否され、エラー・メッセージが戻されます。

  • トリガーを持つ表に対するパラレルDML操作は実行できません。

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

  • パラレルDMLは、自己参照型整合性、削除カスケードおよび遅延整合性など、特定の制約がある場合は実行できません。また、ダイレクト・パス・インサートの場合、参照整合性はサポートされません。

  • オブジェクト列を持つ表に対するパラレルDMLは、そのオブジェクト列にアクセスしないかぎり実行できます。

  • LOB列を持つ表に対するパラレルDMLは、その表がパーティション化されていれば実行できます。ただし、パーティション内並列性はサポートされません。

  • パラレルDML操作に関与するトランザクションは、分散トランザクションにはできません。

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

これらの制限に違反すると、文はシリアルに実行され、警告やエラー・メッセージは戻されません(ただし、トランザクション中に同じ表にアクセスする文の制限については、エラー・メッセージが戻されることがあります)。たとえば、非パーティション表での更新はシリアル化されます。

パーティション化キーの制限

パーティション表のパーティション化キーを新しい値に更新できるのは、更新により行が新しいパーティションに移動しない場合のみです。ROW_MOVEMENT句を有効にして表が定義されている場合は、更新できます。

関数の制限

パラレルDMLの関数の制限は、パラレルDDLおよびパラレル問合せの場合と同じです。詳細は、「関数のパラレル実行」を参照してください。

データ整合性の制限

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

NOT NULLおよびCHECK

これらのタイプの整合性制約は使用可能です。NOT NULLとCHECKはそれぞれ列レベルと行レベルで規定されるため、パラレルDMLでは問題になりません。

一意および主キー

これらのタイプの整合性制約は使用可能です。

外部キー(参照整合性)

参照整合性に関する制限が発生するのは、ある表のDML操作により別の表に再帰的なDML操作が発生する場合です。また、これらの制限は、整合性チェックを実行するために、変更対象のオブジェクトに対するすべての変更を同時に参照する必要がある場合にも適用されます。

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

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

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

INSERT

(該当なし)

パラレル化なし

パラレル化なし

MERGE

(該当なし)

パラレル化なし

パラレル化なし

UPDATE No Action

サポート対象

サポート対象

パラレル化なし

DELETE No Action

サポート対象

サポート対象

パラレル化なし

DELETE Cascade

パラレル化なし

(該当なし)

パラレル化なし


削除カスケード

外部キーを持つ表での削除カスケードによる削除はパラレル実行サーバーが複数のパーティション(親表と子表)の行の削除を試みるため、パラレル化されません。

自己参照型整合性

自己参照型整合性制約を持つ表のDMLは、参照されるキー(主キー)が関与している場合はパラレル化されません。他のすべての列のDMLの場合は、パラレル化できます。

遅延可能な整合性制約

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

トリガーの制限

操作の影響を受ける表で文の結果起動されるトリガーが使用可能になっている場合、DML操作はパラレル化されません。このため、レプリケート対象の表に対するDML文もパラレル化されません。

表に対するDMLをパラレル化するには、関連トリガーを使用禁止にする必要があります。トリガーを使用可能または使用禁止にすると、従属する共有カーソルは無効になるため注意してください。

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

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

分散トランザクションのパラレル化の例

この項には、分散トランザクション処理の例がいくつか含まれています。

例25-1 分散トランザクションのパラレル化

この例では、DML文はリモート・オブジェクトを問い合せます。

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

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

例25-2 分散トランザクションのパラレル化

この例では、DML操作はリモート・オブジェクトに適用されます。

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

DELETE操作は、リモート・オブジェクトを参照しているためパラレル化されません。

例25-3 分散トランザクションのパラレル化

この例では、DML操作は分散トランザクションに含まれています。

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

DELETE操作は、分散トランザクション内で(SELECT文で起動されて)発生するためパラレル化されません。

関数のパラレル実行

SQL文には、PL/SQLやJavaで記述されたユーザー定義関数や、SELECTリスト、SET句またはWHERE句の一部として使用できるCの外部プロシージャとして記述されたユーザー定義関数を含めることができます。SQL文をパラレル化すると、これらの関数はパラレル実行サーバーにより行ごとに実行されます。関数で使用されるPL/SQLのパッケージ変数またはJavaの静的属性は、個々のパラレル実行プロセスに対して完全にプライベートであり、元のセッションからコピーされるのではなく、各行が処理されるときに新たに初期化されます。このため、パラレルに実行した場合、適切な結果が生成されない関数があります。

ユーザーが記述したテーブル・ファンクションは、FROM文のリストで使用できます。この種の関数は、行の出力という点でソース表と同様に動作します。テーブル・ファンクションは、各パラレル実行プロセスの開始時に文中で一度初期化されます。変数はすべてパラレル実行プロセスに対して完全にプライベートです。

パラレル問合せでの関数

ユーザーが記述した関数をSELECT文、またはDML文中やDDL文中の副問合せでパラレルに実行できるのは、PARALLEL_ENABLEキーワードで宣言されている場合、パッケージまたは型で宣言されており、WNDSRNPSおよびWNPSをすべて示すPRAGMA RESTRICT_REFERENCESがある場合、または、CREATE FUNCTIONで宣言されており、システムでPL/SQLコードの本体を分析し、そのコードがデータベースへの書込みでもパッケージ変数の読取りや変更でもないことを判別できる場合です。

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

PRAGMA RESTRICT_REFERENCESについては『Oracle Databaseアプリケーション開発者ガイド-基礎編』を、CREATE FUNCTIONについては『Oracle Database SQLリファレンス』を参照してください。

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

ユーザーが記述した関数をパラレルDML文中やパラレルDDL文中にパラレル問合せとしてパラレルに実行できるのは、PARALLEL_ENABLEキーワードで宣言されている場合、パッケージまたは型で宣言されており、RNDSWNDSRNPSおよびWNPSをすべて示すPRAGMA RESTRICT_REFERENCESがある場合、または、CREATE FUNCTIONで宣言されており、システムでPL/SQLコードの本体を分析し、そのコードがデータベースの読取り、データベースへの書込み、パッケージ変数の読取りまたは変更のいずれでもないことを判別できる場合です。

パラレルDML文の場合は、パラレルに実行できない関数コールがあると、DML文全体がシリアルに実行されます。

INSERT ... SELECTまたはCREATE TABLE ... AS SELECT文の場合、問合せ部分の関数コールは、前述したパラレル問合せの規則に従ってパラレル化されます。問合せは、文の残りの部分をシリアルに実行する必要がある場合にもパラレルに実行でき、その逆も同様です。

他のタイプのパラレル化

Oracleでは、パラレルSQL実行のみでなく、次のタイプの操作にもパラレル化を使用できます。

  • パラレル・リカバリ

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

  • パラレル・ロード(SQL*Loaderユーティリティ)

パラレルSQLと同様に、パラレル・リカバリとパラレル伝播も、1つのパラレル実行コーディネータと複数のパラレル実行サーバーにより実行されます。ただし、パラレル・ロードには異なるメカニズムが使用されます。

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

  • パラレルSQLの場合は、パラレル実行コーディネータがシリアル処理に切り替えます。

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

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


関連項目:

  • パラレル・ロードおよびSQL*Loaderについては、『Oracle Databaseユーティリティ』を参照してください。

  • パラレル・メディア・リカバリについては、『Oracle Databaseバックアップおよびリカバリ基礎』を参照してください。

  • パラレル・インスタンス・リカバリについては、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

  • パラレル伝播については、『Oracle Databaseアドバンスト・レプリケーション』を参照してください。


パラレル実行用のパラメータの初期化およびチューニング

パラレル実行はデフォルトで有効になっています。パラレル実行パラメータの初期計算値は、ほとんどのインストールで受け入れることができます。これらのパラメータは、パラレル操作で使用するメモリーの使用量と並列度に影響します。

Oracle Databaseは、データベース起動時のCPU_COUNTおよびPARALLEL_THREADS_PER_CPUの値を基に、これらのパラメータのデフォルト値を計算します。パラメータは、特定のシステム構成または目的のパフォーマンスに合うように値を手動で増減してチューニングすることもできます。次に例を示します。

パラレル実行パラメータは手動でもチューニングできますが、パラレル実行のデフォルト設定を使用することをお薦めします。パラレル実行の手動チューニングは、2つの理由で自動チューニングよりも複雑です。1つは、手動のパラレル実行チューニングにはより慎重な管理が必要であり、もう1つは、ユーザー負荷およびシステム・リソースの計算を誤りやすいことです。

パラレル実行の初期化およびチューニングには、次のステップがあります。

デフォルト・パラメータ設定の使用

デフォルトでは、パラレル実行パラメータは、表25-2で示されるように自動的に設定されます。ほとんどのシステムでは、適切にチューニングされたパラレル実行環境が実現されるため、これ以上の調整は必要ありません。

表25-2 パラメータとそのデフォルト値

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

PARALLEL_ADAPTIVE_MULTI_USER

TRUE

パラレル実行SQLにより、DOPリクエストの数が制限され、システムのオーバーロードを防ぐことができます。

PARALLEL_MAX_SERVERS

CPU_COUNT×PARALLEL_THREADS_PRE_CPU×(PGA_AGGREGATE_TARGET > 0の場合は2、それ以外の場合は1)×5

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

このパラメータの設定値が小さすぎると、一部の問合せ処理にパラレル実行プロセスが使用できなくなることがあります。また設定値が大きすぎると、処理量のピーク時にメモリー・リソースが不足し、パフォーマンスの低下につながる場合があります。

PARALLEL_EXECUTION_MESSAGE_SIZE

2KB(ポート固有)

4KBまたは8KBに増やすと、SGAメモリーが十分にある場合はパラレル実行のパフォーマンスが向上します。


一部のパラメータでは、設定によってOracleが制約を受けることがあるので注意してください。たとえば、PROCESSESを20に設定すると、25個のスレーブを使用できなくなります。

パラレル実行の並列度の設定

パラレル実行コーディネータは、インスタンスの複数のパラレル実行サーバーに1つのSQL文を処理させる場合があります。単一の操作に関連するパラレル実行サーバーの数は、並列度と呼ばれます。

DOPを指定する方法は、次のとおりです。

  • ヒントを持つ文レベルおよびPARALLEL句を持つ文レベルで

  • ALTER SESSION FORCE PARALLEL文を発行してセッション・レベルで

  • 表の定義内で表レベルで

  • 索引の定義内で索引レベルで

次の例では、表でのDOPを4に設定する文を示します。

ALTER TABLE orders PARALLEL 4;


次の例では、索引でのDOPを4に設定しています。

ALTER INDEX iorders PARALLEL 4;


この例では、問合せでヒントを4に設定しています。

SELECT /*+ PARALLEL(orders, 4) */ COUNT(*) FROM orders;


DOPはイントラ・オペレーション並列化にのみ直接適用されるため注意してください。インター・オペレーション並列化が可能な場合は、文のパラレル実行サーバーの合計を指定したDOPの2倍にできます。同時に実行できる操作は2つ以内です。

パラレル実行は、複数のCPUおよびディスクを効率的に使用して問合せに迅速に答えるように設計されています。複数のユーザーが同時にパラレル実行を使用すると、使用可能なCPU、メモリーおよびディスク・リソースが急速に消費されて不足状態になる場合があります。Oracleには、パラレル実行に伴うリソース使用率に対処できるように、次の方法が用意されています。

  • マルチユーザー問合せ調整アルゴリズム。システム負荷が増大するにつれてDOPを低下させます。デフォルトでは、同時パラレルSQL実行操作にあわせてシステムのパフォーマンスを最適化するマルチユーザー問合せ調整アルゴリズムが有効になっています。

  • ユーザー・リソース制限およびプロファイル。各ユーザーが使用可能な各種システム・リソースの量に対する制限を、ユーザーのセキュリティ・ドメインの一部として設定できます。

  • Database Resource Manager。様々なユーザー・グループにリソースを割り当てることができます。

Oracleによる操作の並列度の決定方法

DOPは、パラレル実行コーディネータが複数の指定を考慮することにより決定されます。コーディネータの動作は、次のとおりです。

  • SQL文自体で指定されているヒントまたはPARALLEL句のチェック

  • ALTER SESSION FORCE PARALLEL文で設定されたセッション値のチェック

  • 表または索引の定義の参照

いずれかの指定にDOPが見つかると、それが操作のDOPになります。

ヒント、PARALLEL句、表または索引の定義およびデフォルト値では、コーディネータが特定の操作について要求するパラレル実行サーバーの数のみが決定されます。実際に使用されるパラレル実行サーバーの数は、パラレル実行サーバー・プール内で使用可能なプロセス数と、インター・オペレーション並列化が可能であるかどうかに応じて異なります。

ヒントおよび並列度

SQL文にヒントを指定して、表や索引のDOPと操作のキャッシング動作のDOPを設定できます。

  • PARALLELヒントは、表の操作にのみ使用されます。また、問合せとDML文(INSERTUPDATEMERGEDELETE)もパラレル化できます。

  • PARALLEL_INDEXヒントでは、パーティション索引の索引レンジ・スキャンがパラレル化されます(索引操作の場合、PARALLELヒントは無効であり、無視されます)。

SQL文にヒントを使用する方法と、PARALLELNO_PARALLELPARALLEL_INDEXCACHEおよびNOCACHEヒントの特定の構文については、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

表および索引の定義

CREATE TABLEALTER TABLECREATE INDEXまたはALTER INDEX文のいずれかを使用すると、表または索引の定義内でDOPを指定できます。

デフォルトの並列度

デフォルトのDOPが使用されるのは、操作のパラレル化を要求したが、ヒント、表の定義または索引の定義でDOPを指定していない場合です。デフォルトのDOPはほとんどのアプリケーションに適しています。

SQL文のデフォルトのDOPは、次の要因により決定されます。

  • CPU_COUNTパラメータの値(デフォルトではシステム上のCPUの数)、RACインスタンスの数、PARALLEL_THREADS_PER_CPUパラメータの値。

  • パーティションによるパラレル化の場合は、パーティション・プルーニングに基づく、アクセスされるパーティションの数。

  • グローバル索引のメンテナンスを伴うパラレルDML操作の場合は、更新対象となるすべてのグローバル索引間のトランザクション空きリストの最小数。パーティション・グローバル索引のトランザクション空きリストの最小数は、すべての索引パーティション間の最小数です。これは、自己デッドロックを防ぐための要件です。

これらの要因により、使用するパラレル実行サーバーのデフォルトの数が決定されます。ただし、実際に使用されるプロセス数は、実行時の要求側インスタンス上での可用性により制限されます。初期化パラメータPARALLEL_MAX_SERVERSでは、インスタンスで使用できるパラレル実行サーバーの合計数の上限を設定します。

必要な最小数(初期化パラメータPARALLEL_MIN_PERCENTで指定)のパラレル実行サーバーが使用できない場合は、ユーザー・エラーが生成されます。システムがそれほどビジーでない場合は、問合せを再試行できます。

マルチユーザー問合せ調整アルゴリズム

マルチユーザー問合せ調整アルゴリズムでは、パラレル実行コーディネータはシステム負荷に応じてDOPを変更します。アクティブなOracle Serverプロセス数が計算され、ロードが決定されます。現在割り当てられているサーバー・プロセス数が、使用可能なCPU数など、最適なサーバー・プロセス数より多ければ、アルゴリズムによりDOPが低下します。これにより、リソースの過剰割当てが回避され、システム全体のスループットが改善されます。

パラレル実行サーバーの最小数

Oracleでは、複数のパラレル実行サーバーが使用可能であれば、操作をパラレルに実行できます。使用可能なパラレル実行サーバーが少なすぎると、SQL文の実行が予想より低速になる場合があります。要求されたパラレル実行サーバーのうち、操作を実行する場合に使用可能であることが必要な最小パーセンテージを指定できます。この方法により、SQL文が最小許容範囲内のパラレル・パフォーマンスで実行されることが保証されます。要求されたうち最小パーセンテージのパラレル実行サーバーが使用可能でなければ、SQL文は実行されず、エラー「ORA-12827」が戻されます。

初期化パラメータPARALLEL_MIN_PERCENTでは、要求されるパラレル実行サーバーに必要な最小パーセンテージを指定します。このパラメータは、DML操作、DDL操作および問合せに影響します。

たとえば、このパラメータに50を指定すると、パラレル操作が成功するには、その操作用に要求されたパラレル実行サーバー数のうち50パーセント以上が使用可能である必要があります。20のパラレル実行サーバーが要求された場合は、10以上が使用可能でなければ、ユーザーにエラーが戻されます。PARALLEL_MIN_PERCENTをNULLに設定した場合は、処理に2つ以上のパラレル実行サーバーが使用可能であるかぎり、すべてのパラレル操作が処理されます。

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

Oracle Real Application Clustersでは、インスタンス・グループを使用して、パラレル操作に参加するインスタンスの数を制限できます。それぞれ1つ以上のインスタンスで構成されるインスタンス・グループを、必要な数だけ作成できます。これにより、一部またはすべてのパラレル操作に使用するインスタンス・グループを指定できます。パラレル実行サーバーは、指定したインスタンス・グループのメンバーであるインスタンスでのみ使用されます。インスタンス・グループの詳細は、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

ワークロードの均衡化

パフォーマンスを最適化するために、すべてのパラレル実行サーバーのワークロードを均等にする必要があります。ブロック範囲またはパラレル実行サーバーによりパラレル化されたSQL文の場合、ワークロードはパラレル実行サーバー間で動的に分割されます。これにより、一部のパラレル実行サーバーで実行される処理が他のプロセスを大幅に上回っている場合に発生する、ワークロードの偏りが最小限に抑えられます。

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

たとえば、表に10のパーティションがあり、パラレル操作でパーティション間に処理が均等に分割されるとします。10のパラレル実行サーバー(DOP = 10)を使用して、単一プロセスの場合の約10分の1の時間で処理を実行できます。また、5つのプロセスを使用すると処理時間は5分の1、2つのプロセスを使用すると2分の1になります。

ただし、9のプロセスを使用して10のパーティションで作業すると、最初のプロセスはあるパーティションでの作業を完了してから、10番目のパーティションでの作業を開始します。また、他のプロセスは処理を完了するとアイドル状態になります。この構成では、処理がパーティション間で均等に分割されていると高パフォーマンスは得られません。処理が不均等に分割されている場合は、最後まで残っているパーティションでの作業量が他のパーティションでの作業量より多いか少ないかに応じて、パフォーマンスが変動します。

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

通常、特定数のパラレル実行サーバー(P)で特定数のパーティション(N)に対するパラレル操作を実行するための所要時間が、N/Pになるとは想定できません。この計算式では、一部のプロセスが最後のパーティションでの作業を完了するまで、他のプロセスが待機する必要があるという可能性が考慮されていません。ただし、適切なDOPを選択すると、ワークロードの偏りを最小限に抑えてパフォーマンスを最適化できます。

SQL文のパラレル化ルール

SQL文をパラレル化できるのは、パラレル・ヒントが含まれている場合か、操作対象となる表または索引がCREATEまたはALTER文でPARALLELを使用して宣言されている場合です。また、DDL文は、PARALLEL句を使用してパラレル化できます。ただし、どちらの方法も、すべての型のSQL文に適用されるわけではありません。

パラレル化は、パラレル化の判断およびDOPという2つのコンポーネントに分かれています。この2つのコンポーネントの決定方法は、問合せ、DDL操作およびDML操作でそれぞれ異なります。

Oracleでは、DOPを決定するために参照オブジェクトが参照されます。

  • パラレル問合せでは、パラレル化する問合せの部分で各表と索引が参照され、参照表が判断されます。原則として、最も大きいDOPを持つ表または索引が選択されます。

  • パラレルDML(INSERTUPDATEMERGEおよびDELETE)の場合、DOPを決定する参照オブジェクトは、挿入、更新または削除操作による変更対象となる表です。また、パラレルDMLでは、デッドロックを回避するためにDOPにある程度の制限も追加されます。つまり、パラレルDML文に副問合せが含まれている場合、その副問合せのDOPはDML操作の場合と同じになります。

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

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

この項では、問合せのパラレル化ルールをいくつか説明します。

パラレル化の判断

SELECT文をパラレル化できるのは、次の条件が満たされる場合のみです。

  • 問合せにパラレル・ヒント指定(PARALLELまたはPARALLEL_INDEX)が含まれているか、問合せで参照されるスキーマ・オブジェクトにPARALLEL宣言が対応付けられている場合

  • 問合せで指定されている1つ以上の表に次のいずれかが必要な場合

    • 全表スキャン

    • 複数のパーティションにまたがる索引レンジ・スキャン

  • SELECTリストにスカラー副問合せがない場合

並列度

問合せのDOPは、次のルールにより決定されます。

  • 問合せでは、問合せに関与するすべての表宣言と、問合せを満たす候補となる可能性のあるすべての索引(参照オブジェクト)からの、最大のDOPが使用されます。つまり、最大のDOPを持つ表または索引により、問合せのDOP(最大問合せディレクティブ)が決定されます。

  • 表の問合せにパラレル・ヒント指定があり、表指定にパラレル宣言がある場合は、ヒント指定がパラレル宣言指定より優先されます。優先順位ルールについては、表25-3を参照してください。

UPDATE、MERGEおよびDELETEのルール

UPDATEMERGEおよびDELETE操作は、パーティションまたはサブパーティションでパラレル化されます。パーティション内や非パーティション表では、これらの操作をパラレル化できません。適用される制限事項については、「並列度の制限事項」を参照してください。

UPDATEMERGEおよびDELETE操作のパラレル・ディレクティブを指定するには、2つの方法があります(PARALLEL DMLモードが有効になっている場合)。

  • 更新または削除する表(参照オブジェクト)の定義にPARALLEL句を使用します。

  • 文に更新、マージまたは削除のパラレル・ヒントを使用します。

パラレル・ヒントは、UPDATEMERGEおよびDELETE文中のUPDATEMERGEまたはDELETEキーワードの直後に置きます。ヒントは、変更される表の基礎となるスキャンにも適用されます。

ALTER SESSION FORCE PARALLEL DML文を使用すると、セッション中の後続のUPDATEMERGEおよびDELETE文のPARALLEL句をオーバーライドできます。UPDATEMERGEおよびDELETE文中のパラレル・ヒントにより、ALTER SESSION FORCE PARALLEL DML文がオーバーライドされます。

パラレル化の判断

UPDATEMERGEまたはDELETE操作をパラレル化する必要があるかどうかは、次のルールにより決定されます。

UPDATEまたはDELETE操作がパラレル化されるのは、次の1つ以上に該当する場合のみです。

  • 更新または削除される表にPARALLEL指定がある場合

  • DML文でPARALLELヒントが指定されている場合

  • ALTER SESSION FORCE PARALLEL DML文がセッション中に以前に発行されている場合

文に副問合せまたは更新可能なビューが含まれている場合は、別個のパラレル・ヒントまたは句を持つ場合があります。ただし、これらのパラレル・ディレクティブは、UPDATEMERGEまたはDELETEのパラレル化の判断には影響しません。

表のパラレル・ヒントまたは句は、問合せとUPDATEMERGEDELETE部分の両方で使用されてパラレル化が決定され、UPDATEMERGEDELETE部分のパラレル化の意思決定は問合せ部分から独立して行われ、その逆も同じです。

並列度

DOPは問合せと同じルールにより決定されます。UPDATEおよびDELETE操作の場合、関与するのは変更対象となる表のみ(参照オブジェクトのみ)のため注意してください。したがって、UPDATEまたはDELETEのパラレル・ヒント指定は、ターゲット表のパラレル宣言指定より優先されます。つまり、優先順位は、MERGEUPDATEDELETEヒント>セッション>ターゲット表のパラレル宣言指定となります。優先順位ルールについては、表25-3を参照してください。

パラレル実行サーバーは複数のパーティションに対する更新、マージまたは削除を実行できますが、各パーティションを更新または削除できるのは1つのパラレル実行サーバーのみです。

DOPがパーティション数より低い場合は、あるパーティションの処理を終了した最初のプロセスが別のパーティションを処理するというように、すべてのパーティションの処理が終了するまで続きます。DOPが操作に関与するパーティション数より高ければ、余分なパラレル実行サーバーが処理を行うことはありません。

例25-4 パラレル化: 例1

UPDATE tbl_1 SET c1=c1+1 WHERE c1>100;

tbl_1がパーティション表で、表の定義にPARALLEL句があると、表にc1が101以上のパーティションがある場合は、表のスキャンがシリアルな場合(索引スキャンなど)にも、更新操作はパラレル化されます。

例25-5 パラレル化: 例2

UPDATE /*+ PARALLEL(tbl_2,4) */ tbl_2 SET c1=c1+1;

tbl_2のスキャン操作と更新操作は、並列度4でパラレル化されます。

INSERT ...SELECTのルール

INSERT ... SELECT文では、そのINSERTおよびSELECT操作が個別にDOPを決定しパラレル化されます。

パラレル・ヒントは、INSERT ... SELECT文中でINSERTキーワードの後に指定できます。通常、問合せ対象の表は挿入対象の表とは異なるため、ヒントを使用すると挿入操作専用のパラレル・ディレクティブを指定できます。

INSERT ... SELECT文のパラレル・ディレクティブを指定するには、次の方法があります(PARALLEL DMLモードが有効になっている場合)。

  • 文でSELECTパラレル・ヒントを指定します。

  • 選択対象となる表の定義でパラレル句を指定します。

  • 文でINSERTパラレル・ヒントを指定します。

  • 挿入対象となる表の定義でパラレル句を指定します。

ALTER SESSION FORCE PARALLEL DML文を使用すると、セッション中の後続のINSERT操作のPARALLEL句をオーバーライドできます。挿入操作のパラレル・ヒントにより、ALTER SESSION FORCE PARALLEL DML文がオーバーライドされます。

パラレル化の判断

INSERT ... SELECT文中でINSERT操作をパラレル化する必要があるかどうかは、次のルールにより決定されます。

INSERT操作がパラレル化されるのは、次の1つ以上に該当する場合のみです。

  • DML文でINSERTの後にPARALLELヒントが指定されている場合

  • 挿入対象の表(参照オブジェクト)にPARALLEL宣言指定がある場合

  • ALTER SESSION FORCE PARALLEL DML文がセッション中に以前に発行されている場合

INSERT操作のパラレル化の判断は、SELECT操作から独立して行われます。その逆も同様です。

並列度

SELECTまたはINSERT操作のパラレル化の意思決定が行われると、文全体のDOPを決定するために1つのパラレル・ディレクティブが選択されます。その場合は、INSERTヒント・ディレクティブ>セッション>挿入する表のPARALLEL宣言指定>最大問合せディレクティブという優先順位が使用されます。

この場合、最大問合せディレクティブは、複数の表や索引のうち、最大のDOPを持つ表または索引により問合せ操作のパラレル化が決定されることを意味します。

選択されたパラレル・ディレクティブは、SELECTおよびINSERT操作の両方に適用されます。

例25-6 パラレル化: 例3

使用されるDOPは、INSERTヒントに指定されているとおり2です。

INSERT /*+ PARALLEL(tbl_ins,2) */ INTO tbl_ins
SELECT /*+ PARALLEL(tbl_sel,4) */ * FROM tbl_sel;

DDL文のルール

DDL文をパラレル化する場合は、次のことに注意する必要があります。

パラレル化の判断

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

ALTER SESSION FORCE PARALLEL DDL文を使用すると、セッション中の後続のDDL文のPARALLEL句をオーバーライドできます。

並列度

DOPは、ALTER SESSION FORCE PARALLEL DDL文でオーバーライドされないかぎり、PARALLEL句での指定により決定されます。パーティション索引の再作成は、パラレル化されません。

CREATE TABLEおよびALTER TABLE文のPARALLEL句では、表のパラレル化を指定します。表の定義にPARALLEL句がある場合は、その句によりDDL文と問合せのパラレル化が決定されます。ただし、表に対する明示的なPARALLELヒントがDDL文に含まれている場合は、そのヒントにより表に対するPARALLEL句の効果がオーバーライドされます。ALTER SESSION FORCE PARALLEL DDL文を使用すると、PARALLEL句をオーバーライドできます。

[CREATE | REBUILD] INDEXまたは[MOVE | SPLIT] PARTITIONのルール

次のルールが適用されます。

パラレルCREATE INDEXまたはALTER INDEX ...REBUILD

CREATE INDEXおよびALTER INDEX ... REBUILD文をパラレル化するには、PARALLEL句またはALTER SESSION FORCE PARALLEL DDL文を使用する必要があります。

ALTER INDEX ... REBUILDをパラレル化できるのは非パーティション索引の場合のみですが、ALTER INDEX ... REBUILD PARTITIONPARALLEL句またはALTER SESSION FORCE PARALLEL DDL文でパラレル化できます。

ALTER INDEX ... REBUILD(非パーティション化)、ALTER INDEX ... REBUILD PARTITIONおよびCREATE INDEXのスキャン操作の並列性はREBUILDまたはCREATE操作と同じで、同じDOPが使用されます。REBUILDまたはCREATEのDOPが指定されていなければ、デフォルトでCPU数となります。

パラレルMOVE PARTITIONまたはSPLIT PARTITION

ALTERINDEX ... MOVE PARTITION文およびALTERINDEX ...SPLIT PARTITION文は、PARALLEL句またはALTER SESSION FORCE PARALLEL DDL文でのみパラレル化できます。そのスキャン操作の並列性は、対応するMOVEまたはSPLIT操作と同じです。DOPが指定されていなければ、デフォルトでCPU数となります。

CREATE TABLE AS SELECTのルール

CREATE TABLE ... AS SELECT文は、CREATE部分(DDL)およびSELECT部分(問合せ)の2つに分かれています。Oracleでは、この文の両方の部分をパラレル化できます。CREATE部分に適用されるルールは、他のDDL操作の場合と同じです。

パラレル化の判断(問合せ部分)

CREATE TABLE ... AS SELECT文の問合せ部分をパラレル化できるのは、次の条件が満たされる場合のみです。

  • 問合せにパラレル・ヒント指定(PARALLELまたはPARALLEL_INDEX)が含まれているか、文のCREATE部分にPARALLEL句の指定があるか、問合せで参照されるスキーマ・オブジェクトにPARALLEL宣言が対応付けられている場合

  • 問合せで指定されている1つ以上の表に、複数のパーティションにまたがる索引レンジ・スキャンまたは全表スキャンのいずれかが必要な場合

並列度(問合せ部分)

CREATE TABLE ... AS SELECT文の問合せ部分のDOPは、次のいずれかのルールにより決定されます。

  • 問合せ部分では、CREATE部分のPARALLEL句で指定された値が使用されます。

  • PARALLEL句が指定されていなければ、デフォルトのDOPであるCPU数となります。

  • CREATEがシリアルの場合、DOPは問合せにより決定されます。

パラレル化のヒントで指定された値は無視されるため注意してください。

パラレル化の判断(CREATE部分)

CREATE TABLE ... AS SELECT文のCREATE操作をパラレル化するには、PARALLEL句またはALTER SESSION FORCE PARALLEL DDL文を使用する必要があります。

CREATE TABLE ... AS SELECTCREATE操作がパラレル化される場合、Oracleでは可能であればスキャン操作もパラレル化されます。たとえば、次の場合はスキャン操作をパラレル化できません。

  • SELECT句にNO_PARALLELヒントがある場合

  • 操作で非パーティション表の索引がスキャンされる場合

CREATE操作がパラレル化されないときにSELECTをパラレル化できるのは、PARALLELヒントがある場合、または選択される表(またはパーティション索引)にパラレル宣言がある場合です。

並列度(CREATE部分)

CREATE操作のDOPと、SELECT操作がパラレル化される場合のDOPは、ALTER SESSION FORCE PARALLEL DDL文でオーバーライドされないかぎり、CREATE文のPARALLEL句で指定されます。PARALLEL句でDOPが指定されていなければ、デフォルトのDOPであるCPU数となります。

パラレル化ルールのまとめ

表25-3に、各種SQL文をパラレル化する方法と、パラレル化指定の優先順位を示します。

  • 優先順位(1)の指定により、優先順位(2)および優先順位(3)がオーバーライドされます。

  • 優先順位(2)の指定により、優先順位(3)がオーバーライドされます。

表25-3 句、ヒントまたは基礎となる表/索引の宣言によるパラレル化の優先順位

パラレル操作 PARALLELヒント PARALLEL句 ALTER SESSION パラレル宣言

パラレル問合せの表スキャン(パーティション表または非パーティション表)

1) PARALLEL


2) FORCE PARALLEL QUERY

(3)表のパラレル宣言

パラレル問合せの索引レンジ・スキャン(パーティション索引)

1) PARALLEL_INDEX


2) FORCE PARALLEL QUERY

(2)索引のパラレル宣言

パラレルUPDATEまたはDELETE(パーティション表のみ)

1) PARALLEL


2) FORCE PARALLEL DML

(3)更新または削除元の表のパラレル宣言

パラレルINSERT... SELECTINSERT操作(パーティション表または非パーティション表)

1) INSERTのPARALLEL


2) FORCE PARALLEL DML

(3)挿入先の表のパラレル宣言

INSERTがパラレルの場合の、INSERT ... SELECTSELECT操作

INSERT文の並列度を使用

INSERT文の並列度を使用

INSERT文の並列度を使用

INSERT文の並列度を使用

INSERTがシリアルの場合の、INSERT ... SELECTSELECT操作

1) PARALLEL



(2)選択元の表のパラレル宣言

パラレルCREATE TABLE ... AS SELECTCREATE操作(パーティション表または非パーティション表)

注意: SELECT句のヒントはCREATE操作には影響しません

2)

1) FORCE PARALLEL DDL


CREATEがパラレルの場合の、CREATE TABLE ... AS SELECTSELECT操作

CREATE文の並列度を使用

CREATE文の並列度を使用

CREATE文の並列度を使用

CREATE文の並列度を使用

CREATEがシリアルの場合の、CREATE TABLE ... AS SELECTSELECT操作

1) PARALLELまたはPARALLEL_INDEX



(2)問合せする表またはパーティション索引のパラレル宣言

パラレルCREATE INDEX(パーティション索引または非パーティション索引)


2)

1) FORCE PARALLEL DDL


パラレルREBUILD INDEX(非パーティション索引)


2)

1) FORCE PARALLEL DDL


REBUILD INDEX(パーティション索引) − パラレル化なし





パーティションのパラレルREBUILD INDEX


2)

1) FORCE PARALLEL DDL


パーティションのパラレルMOVEまたはSPLIT


2)

1) FORCE PARALLEL DDL



表および問合せに対するパラレル化の有効化

パラレル実行操作に関係する表のDOPは、これらの表に対する操作のDOPに影響を及ぼします。したがって、パラレル実行のチューニングに関係するパラメータを設定した後は、CREATE TABLEまたはALTER TABLE文のPARALLEL句を使用して、パラレル化する表に対してそれぞれパラレル実行を有効にする必要があります。SQL文でPARALLELヒントを使用して、その操作のみにパラレル化を有効にすることや、ALTER SESSION文のFORCEオプションを使用して、そのセッションのすべての後続の操作に対してパラレル化を有効にすることもできます。

表をパラレル化する場合は、DOPを指定するか、OracleにデフォルトのDOPを使用させることもできます。デフォルトのDOPの値は、PARALLEL_THREADS_PER_CPUの値とOracleに使用可能なCPU数に基づいて自動的に導出されます。

ALTER TABLE employees PARALLEL;    -- uses default DOP
ALTER TABLE employees PARALLEL 4;  -- users DOP of 4

並列度とマルチユーザー問合せ調整: 両者の相互作用

DOPによって、パラレル実行操作に使用される使用可能なプロセス(スレッド)数を指定できます。各パラレル・スレッドは、問合せの複雑さによって、1つまたは2つの問合せプロセスを使用できます。

マルチユーザー問合せ調整機能によって、ユーザー負荷に基づいてDOPが調整されます。たとえば、DOPが5の表があるとします。このDOPは、10人のユーザーには適切です。ただし、ユーザーがさらに10人システムにログインし、このためPARALLEL_ADAPTIVE_MULTI_USER機能を使用可能にした場合、OracleはDOPの値を低くして、認識したOracle負荷に従ってリソースをより均等に分散します。

問合せに対するDOPは、一度決定されると、問合せ処理中は変更されません。

マルチユーザー問合せ調整機能は、ユーザーがパラレル実行操作を同時に処理する場合に使用すると最も効果的です。デフォルトでは、PARALLEL_ADAPTIVE_MULTI_USERTRUEに設定されています。この設定は、同時パラレルSQL実行操作にあわせてシステムのパフォーマンスを最適化します。PARALLEL_ADAPTIVE_MULTI_USERFALSEに設定した場合、各パラレルSQL実行操作は、十分なリソースが構成されている間は、システムのパフォーマンスに対する影響を考慮せずに、要求された数のパラレル実行サーバー・プロセスを受け取ります。

マルチユーザー問合せ調整アルゴリズムの動作

マルチユーザー問合せ調整アルゴリズムには、いくつかの入力があります。アルゴリズムによって、Oracleが計算したアクティブなOracle Serverプロセスの数が最初に考慮されます。次に、パラレル化のデフォルト設定が、初期化パラメータ・ファイル、CREATE TABLE文とALTER TABLE文およびSQLヒントに使用されているパラレル化オプションに設定されたものであるとみなされます。

システムがオーバーロード状態であり、入力DOPがデフォルトDOPより大きい場合、アルゴリズムによって、デフォルトのDOPが入力に使用されます。これによって、入力DOPに適用する減少要因が計算されます。たとえば、CPUの数が16のシステムを使用すると、最初のユーザーがシステムにログインしたときにシステムがアイドル状態の場合、このユーザーには32のDOPが付与されます。次のユーザーには8、その次のユーザーには4のDOPが付与されます。問合せを発行するユーザーが8人に決まっているシステムでは、すべてのユーザーには4のDOPが付与されます。したがって、すべてのパラレル・ユーザー間でシステムが均等に分割されます。

セッションに対するパラレル実行の強制

パラレルで実行する場合に、表のDOPの設定または関係する問合せの変更を行わないときは、次の文によって強制的にパラレル化できます。

ALTER SESSION FORCE PARALLEL QUERY;

これにより、制限違反がなければ、すべての後続の問合せがパラレルで実行されます。DML文およびDDL文を強制することもできます。この句は、セッションの後続の文に指定されたすべてのパラレル句をオーバーライドします。ただし、この句はパラレル・ヒントによってオーバーライドされます。

たとえば、典型的なOLTP環境では、表はパラレルに設定されませんが、夜間にバッチ・スクリプトでこれらの表からデータをパラレルに収集する必要があります。セッション中にDOPを設定すると、ユーザーは各表をパラレルに変更して完了後にシリアルに戻すことができません。

並列度によるパフォーマンスの制御

初期化パラメータPARALLEL_THREADS_PER_CPUは、DOPとマルチユーザー問合せ調整機能の両方を制御するアルゴリズムに影響を及ぼします。Oracleは、PARALLEL_THREADS_PER_CPUの値にインスタンスごとのCPU数を掛けて、パラレル操作で使用するスレッドの数を導出します。

マルチユーザー問合せ調整機能も、システムに存在する必要のある問合せサーバー・プロセスのターゲット数を計算するために、デフォルトのDOPを使用します。ターゲット数よりも多いプロセスがシステムで実行されている場合、動的なアルゴリズムによって、必要に応じて新しい問合せのDOPが減らされます。したがって、PARALLEL_THREADS_PER_CPUを使用して動的なアルゴリズムを制御することもできます。

PARALLEL_THREADS_PER_CPUを使用すると、CPU速度に比べて低速のI/Oサブシステムを持つハードウェア構成や、関与するデータ量に比べて少数の計算を実行するアプリケーションのワークロードにあわせて調整できます。システムがCPUバウンドでもI/Oバウンドでもない場合は、PARALLEL_THREADS_PER_CPUの値を大きくする必要があります。これにより、デフォルトのDOPが高くなり、ハードウェア・リソースの使用率を改善できます。ほとんどのプラットフォームでは、PARALLEL_THREADS_PER_CPUのデフォルトは2です。ただし、マシンのI/Oサブシステムが比較的低速の場合、デフォルトは最大8に設定できます。

パラレル実行用の一般パラメータのチューニング

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

パラレル実行のリソース制限を設定するパラメータ

リソース制限を設定するパラメータを次に示します。

PARALLEL_MAX_SERVERS

PARALLEL_MAX_SEVERSパラメータによって、リソース制限が、パラレル実行に使用可能なプロセスの最大数に設定されます。ほとんどのパラレル操作では、その操作におけるすべての表の最大DOPの最大2倍の問合せサーバー・プロセスが必要です。

PARALLEL_MAX_SERVERSは、ほとんどのシステムで十分なデフォルト値に設定されます。PARALLEL_MAX_SERVERSパラメータのデフォルト値は、次のとおりです。

(CPU_COUNT x PARALLEL_THREADS_PER_CPU x (2 if PGA_AGGREGATE_TARGET > 0; otherwise 1) x 5)

この値は、より高いDOP属性を持つ表に対するパラレル問合せでは、十分ではない可能性もあります。より高いDOPの問合せを実行する場合は、PARALLEL_MAX_SERVERSを次のように設定することをお薦めします。

2 x DOP x NUMBER_OF_CONCURRENT_USERS

たとえば、PARALLEL_MAX_SERVERSを64に設定すると、問合せで、各セットについてDOPが8のスレーブ・セットを2つ使用している場合は、4つのパラレル問合せを同時に実行できます。

ハードウェア・システムがCPUバウンドでもI/Oバウンドでもなければ、さらに問合せサーバー・プロセスを追加して、システム上の同時パラレル実行ユーザー数を増やすことができます。ただし、システムがCPUバウンドまたはI/Oバウンドになった場合は、さらに同時ユーザーを増やすと全体のパフォーマンスが低下します。PARALLEL_MAX_SERVERSを慎重に設定すれば、同時パラレル操作数を効率的に制限できます。

ユーザーが起動する同時操作の数が多すぎる場合は、十分な問合せサーバー・プロセスを使用できない場合があります。この場合は、操作が順次実行されるか、PARALLEL_MIN_PERCENTがデフォルト値の0(ゼロ)以外に設定されている場合はエラーが表示されます。

この条件は、GV$SYSSTATビューを通じて、ダウングレードされていないパラレル操作の統計情報と、シリアルにダウングレードされたパラレル操作を比較することで検証できます。次に例を示します。

SELECT * FROM GV$SYSSTAT WHERE name LIKE 'Parallel operation%';
ユーザーのプロセスが多すぎる場合

同時ユーザーの問合せサーバー・プロセスが多すぎる場合、メモリー競合(ページング)、I/O競合または過剰なコンテキスト切替えが発生する場合があります。この競合によって、パラレル実行が使用されていないときのレベルまでシステム・スループットが低下する場合があります。PARALLEL_MAX_SERVERSの値は、発生する負荷に対して十分なメモリーおよびI/O帯域幅がシステムにある場合にのみ増やしてください。

メモリー、スワップ領域およびI/O帯域幅にどれくらい空きがあるかを判断するには、オペレーティング・システム・パフォーマンス監視ツールを使用します。システム上のI/Oに対するサービス時間、およびCPUとディスクの両方のrunq長を調べます。より多くのプロセスを追加するために十分なスワップ領域が、マシンに存在することを確認します。問合せサーバー・プロセスの合計数を制限すると、パラレル操作を実行できる同時ユーザーの数が制限されることがあります。ただし、システム・スループットは通常安定します。

同時ユーザー数の増加

同時ユーザー数を増やすには、各ユーザーのリソース使用量を制限する必要があります。これには、マルチユーザー問合せ調整機能を使用するか、リソース・コンシューマ・グループを使用します。リソース・コンシューマ・グループとDatabase Resource Managerの詳細は、『Oracle Database管理者ガイド』および『Oracle Database概要』を参照してください。

ユーザーに対するリソース数の制限

任意のユーザーに使用可能なパラレル化の量を、そのユーザーにリソース・コンシューマ・グループを設定することによって制限できます。これによって、単一のユーザーまたはユーザー・グループのすべてが行うことができるセッション、同時ログインおよびパラレル処理の数を制限できます。

あるパラレル実行文に対して動作する各問合せサーバー・プロセスは、セッションIDを使用してログインし、そのユーザーの同時セッションの制限に対してカウントされます。たとえば、1人のユーザーのパラレル実行プロセス数を10に制限する場合、ユーザーの制限は11に設定します。1つのプロセスはパラレル・コーディネータ用であり、残りの10プロセスは2つの問合せサーバー・セットに分かれます。これによって、パラレル・コーディネータが1つのセッション、およびパラレル実行プロセスが10セッションを使用できます。

ユーザー・プロファイルを使用してリソースを管理する方法の詳細は『Oracle Database管理者ガイド』を、GV$ビューに対する問合せの詳細は『Oracle Database Oracle ClusterwareおよびOracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

PARALLEL_MIN_SERVERS

PARALLEL_MIN_SERVERSパラメータに対する推奨値は、デフォルトの0(ゼロ)です。

このパラメータによって、単一インスタンスでパラレル操作用に開始および予約されるプロセス数を指定できます。構文は次のとおりです。

PARALLEL_MIN_SERVERS=n

nは、パラレル操作用に開始および予約するプロセス数です。

PARALLEL_MIN_SERVERSを設定すると、メモリー使用量に対して起動コストが均衡化されます。PARALLEL_MIN_SERVERSを使用して開始したプロセスは、データベースが停止されるまで終了しません。このため、そのプロセスは、問合せが発行されたときに使用可能です。ただし、これらのプロセスが使用するメモリーは断片化され、最高水位標が徐々に減少する原因になることがあるため、問合せサーバー・プロセスは再利用することをお薦めします。PARALLEL_MIN_SERVERSを設定しない場合、プロセスは5秒間アイドル状態になると終了します。

SHARED_POOL_SIZE

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

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

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

  • 大きい値を設定すると、マルチユーザー・システムのパフォーマンスが向上しますが、小さい値を設定すると、メモリー使用量が減少するため注意してください。

  • また、パラレル実行を使用すると、より多くのカーソルが生成されることも考慮する必要があります。カーソルが再コンパイルされる頻度を判断するには、V$SQLAREAビューの統計情報を参照します。カーソル・ヒット率が低い場合、プール・サイズを増やします。これが発生するのは、大量の個別問合せがある場合のみです。

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


    注意:

    十分なメモリーがない場合は、エラー・メッセージ12853(PXバッファのメモリーが不足しています。: 現在は(バイト数)KB、最大必要量は(バイト数)KB)が表示されます。このエラーは、PXバッファでSGAメモリーが不足していることによって発生します。追加メモリーとして最低でも(MAX - CURRENT)バイト確保するようにSGAを再構成する必要があります。

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

たとえば、起動時に次のエラーが表示されたとします。

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

この場合は、データベースを起動できるように、SHARED_POOL_SIZEの値を減らす必要があります。SHARED_POOL_SIZEの値を減らした後に次のエラーが表示されたとします。

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

この場合は、次の問合せを実行して、16,084バイトが割り当てられなかった原因を判断します。

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

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

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

SHARED_POOL_SIZEを指定するときに、予約の必要なメモリー量がプールより大きい場合、取得できるメモリーをすべて割り当てるかわりに、一部の領域が残されます。問合せの実行時には、必要な領域の取得が試みられます。Oracleでは560KBが使用され、失敗するとさらに16KBが必要になります。エラーになっても、必要な累積量はレポートされません。追加で必要なメモリー量を判断する最善の方法は、「メッセージ・バッファへのメモリーの追加」の計算式を使用することです。

この例の問題を解決するには、SHARED_POOL_SIZEの値を増やします。サンプル出力のように、SHARED_POOL_SIZEは約2MBです。使用可能なメモリー量に応じて、SHARED_POOL_SIZEの値を4MBに増やし、データベースを起動してみます。ORA-04031メッセージが続いて表示される場合は、起動が成功するまでSHARED_POOL_SIZEの値を少しずつ増やします。

メッセージ・バッファに対する追加メモリー要件の計算

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

メッセージ・バッファへのメモリーの追加

メッセージ・バッファに対応するためには、SHARED_POOL_SIZEパラメータの値を増やす必要があります。メッセージ・バッファを使用すると、問合せサーバー・プロセスが相互に通信できるようになります。

Oracleは、プロデューサ問合せサーバーとコンシューマ問合せサーバー間の仮想接続ごとに、固定数のバッファを使用します。接続は、DOPの2乗の増加に従って増加します。このため、パラレル実行が使用するメモリー量の最大値は、システムで使用可能な最も高い値のDOPに制限されます。この値は、PARALLEL_MAX_SERVERSパラメータ、またはポリシーおよびプロファイルを使用して制御できます。

必要なメモリー量を計算するには、次のどちらかの計算式を使用します。

  • SMPシステムの場合

    mem in bytes = (3 x size x users x groups x connections)
    
    
  • SMP 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グループで十分です。ただし、問合せがパラレルに処理される副問合せを伴う場合は、問合せサーバー・プロセス・グループが追加使用されます。

  • CONNECTIONS = (DOP2 + 2 × DOP)

    システムがクラスタまたはMPPの場合は、DOPが高くなるため、インスタンス数を考慮する必要があります。つまり、2つのインスタンスのクラスタでDOPとして4を使用すると、DOPは8になります。PARALLEL_MAX_SERVERSの値 × インスタンス数 / 4は、開始値として最初に使用される値です。

  • LOCAL = CONNECTIONS/INSTANCES

  • REMOTE = CONNECTIONS - LOCAL

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

カーソルに対する追加メモリーの計算

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

処理開始後のメモリー調整

この項の計算式は、スタート・ポイントにすぎません。自動チューニングと手動チューニングのどちらを行う場合でも、処理中の使用量を監視し、メモリー・サイズが大きすぎず、また小さすぎないことを確認する必要があります。これには、次の問合せを使用して共有プールをチューニングします。

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 enqueue_resources               29016
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の値を掛けて、値をバイト単位で計算します。最高水位標をパラレル実行メッセージ・プール・サイズと比較して、割り当てたメモリーが多すぎるかどうかを判断します。たとえば、1つ目の出力では、px msg poolに表示されるラージ・プールの値は38,092,812または38MBです。2つ目の出力にあるBuffers HWMは3,620です。これにパラレル実行のメッセージ・サイズの4,096を掛けると、この値は14,827,520、つまり約15MBになります。この場合、最高水位標はその容量の約40%に達しています。

PARALLEL_MIN_PERCENT

PARALLEL_MIN_PERCENTパラメータの推奨値は、0(ゼロ)です。

このパラメータを設定すると、ユーザーは、使用中のアプリケーションに基づいた許容DOPを待つことができます。このパラメータを0(ゼロ)以外の値に設定すると、要求されたDOPをシステムが特定の時点で満たすことができない場合に、エラーが戻されます。たとえば、PARALLEL_MIN_PERCENTを50(50%に変換)に設定し、動的なアルゴリズムまたはリソース制限によってDOPが50%以上削減されると、ORA-12827が戻されます。次に例を示します。

SELECT /*+ PARALLEL(e, 8, 1) */ 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;

次のメッセージが戻されます。

ORA-12827: insufficient parallel query slaves available

リソース使用に影響を及ぼすパラメータ

この項で説明する1つ目のパラメータ・グループは、すべてのパラレル操作、特にパラレル実行のためのメモリー使用およびリソース使用に影響を及ぼします。これらのパラメータを次に示します。

この項で説明する2つ目のパラメータのサブセットは、パラレルDMLおよびDDLに影響を及ぼすパラメータです。

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

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

  • オペレーティング・システム・レベル。一貫性を保ちます。プラットフォームによっては、すべてのプロセスにわたって合計した仮想メモリー量を制御するオペレーティング・システム・パラメータを設定する必要があります。

SGAは、通常、実物理メモリーの部分です。SGAは静的であり、サイズも固定されています。SGAのサイズを変更するには、データベースを停止し、SGAサイズを変更してからデータベースを再起動します。Oracleは、共有プールをSGAから割り当てます。

データ・ウェアハウス操作で使用されるメモリーの大部分は、より動的です。このメモリーは、プロセス・メモリー(PGA)から割り当てられます。プロセス・メモリーのサイズおよびプロセス数は様々です。プロセス・メモリーおよびプロセス数を制御するには、PGA_AGGREGATE_TARGETパラメータを使用します。

PGA_AGGREGATE_TARGET

自動的なPGAメモリー管理を使用可能にすることで、PGAメモリーを割り当てる方法を簡素化および改善できます。このモードでは、作業領域専用のPGAメモリー部分のサイズは、DBAによって明示的に設定された全体的なPGAメモリー・ターゲットに基づいて動的に調整されます。自動的なPGAメモリー管理を使用可能にするには、初期化パラメータPGA_AGGREGATE_TARGETを設定する必要があります。様々な環境におけるPGA_AGGREGATE_TARGETの使用方法については、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

HASH_AREA_SIZE

HASH_AREA_SIZEは廃止されました。かわりに、PGA_AGGREGATE_TARGETを使用してください。

SORT_AREA_SIZE

SORT_AREA_SIZEは廃止されました。かわりに、PGA_AGGREGATE_TARGETを使用してください。

PARALLEL_EXECUTION_MESSAGE_SIZE

PARALLEL_EXECUTION_MESSAGE_SIZEパラメータによって、パラレル実行メッセージで使用されるバッファ・サイズを指定できます。デフォルト値はオペレーティング・システム固有ですが、通常は2KBです。この値は、ほとんどのアプリケーションに適切ですが、この値を増やすと、パフォーマンスが向上する場合があります。共有プールに十分な空きメモリーがある、または十分なオペレーティング・システム・メモリーがあり、共有プール・サイズを増やして、必要なメモリーの追加量に対応できる場合は、この値を増やすことを検討します。

パラレルDMLおよびパラレルDDLのリソース使用量に影響するパラメータ

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

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

TRANSACTIONS

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

TRANSACTIONSパラメータは、同時トランザクションの最大数を指定します。デフォルトはパラレル化なしとみなされます。たとえば、DOPが20の場合、20の新しいサーバー・トランザクション(2つのサーバー・セットがある場合は40)および1つのコーディネータ・トランザクションがあることになるため、それらを同じインスタンスで実行する場合は、TRANSACTIONSに21(または41)を加える必要があります。このパラメータを設定しない場合、Oracleによって1.1 × SESSIONSに設定されます。これは、サーバー管理のUNDOを使用している場合には当てはまりません。

FAST_START_PARALLEL_ROLLBACK

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

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

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

LOG_BUFFER

V$SYSSTATビューの統計redo buffer allocation retriesをチェックします。この値が、redo blocks writtenより大きい場合は、LOG_BUFFERのサイズを増やしてみます。多数のログを生成するシステムの場合、LOG_BUFFERサイズは通常3〜5MBです。LOG_BUFFERサイズを増やしてもまだ再試行の回数が多い場合は、ログ・ファイルが常駐するディスクに問題がある可能性があります。その場合は、REDOに対するI/Oの割合を増やすために、I/Oサブシステムをチューニングします。これを行う方法の1つとして、複数のディスクにファイングレイン・ストライプ化を使用します。たとえば、16KBのストライプ・サイズを使用します。さらに簡単な方法では、REDOログをそれぞれディスクに個別に配置します。

DML_LOCKS

このパラメータは、DMLロックの最大数を指定します。この値は、すべてのユーザーが参照する表のロック総数と等しい必要があります。パラレルDML操作のロックおよびエンキューのリソース要件は、シリアルDMLとはかなり異なります。パラレルDMLは、より多くのロックを保持するため、ENQUEUE_RESOURCESおよびDML_LOCKSパラメータの値を同じ量だけ増やす必要があります。

表25-4に、様々なパラレルDML文について、コーディネータおよびパラレル実行サーバー・プロセスによって取得されるロックのタイプを示します。この情報を使用すると、これらのパラメータで必要となる値を計算できます。

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

パーティション表に対するパラレルUPDATEMERGEDELETEまたはINSERT

1つの表ロックSX

すべての(サブ)パーティションに対するパーティション・ロックX

1つの表ロックSX

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

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

パーティション表に対するパラレルINSERT: PARTITION句またはSUBPARTITION句で宛先表を指定

1つの表ロックSX

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

1つの表ロックSX

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

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

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

1つの表ロックX

なし



注意:

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

すべてのパーティションがパラレルUPDATEまたはDELETE文に含まれていることを前提として、100のDOPで実行される600のパーティションを持つ表を考えてみます。

コーディネータが取得するロック:

  • 1つの表ロックSX

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

すべてのサーバー・プロセスが取得するロック:

  • 100の表ロックSX

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

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

ENQUEUE_RESOURCES

このパラメータは、ロック・マネージャによってロックできるリソース数を設定します。パラレルDML操作には、シリアルDMLより多くのリソースが必要です。Oracleでは、必要に応じてさらにエンキュー・リソースが割り当てられます。

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

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

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

DB_CACHE_SIZE

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

DB_BLOCK_SIZE

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

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

DB_FILE_MULTIBLOCK_READ_COUNT

このパラメータの推奨値は、ブロック・サイズが8KBの場合は8、16KBの場合は4で、デフォルトは8です。

このパラメータによって、オペレーティング・システムの1回のREADコールで読み込まれるデータベース・ブロック数が決定されます。このパラメータの上限は、プラットフォーム固有です。DB_FILE_MULTIBLOCK_READ_COUNTを非常に大きい値に設定すると、データベース起動時に、オペレーティング・システムで許可される最も高いレベルに引き下げられます。この場合、各プラットフォームは使用可能な最も大きい値を使用します。最大値の範囲は、通常64KB〜1MBです。

DISK_ASYNCH_IOおよびTAPE_ASYNCH_IO

これらのパラメータの推奨値はTRUEです。

これらのパラメータは、オペレーティング・システムの非同期I/O機能を使用可能または使用禁止にします。これによって、表スキャンを実行するときに問合せサーバー・プロセスがI/O要求と処理を同時に行えるようになります。オペレーティング・システムが非同期I/Oをサポートしている場合、これらのパラメータは、デフォルト値TRUEのままにしておきます。図25-6に非同期読取りの動作方法を示します。

図25-6 非同期読取り

図25-6の説明は図の下のリンクをクリックしてください。
「図25-6 非同期読取り」の説明

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

パラレル実行パフォーマンスの監視および診断

パラレル実行のパフォーマンス問題を診断する場合は、次のタスクを実行する必要があります。

パフォーマンス期待値は、前回のパフォーマンス測定(先週またはOracleの旧バージョンにおける特定の問合せの所要時間など)に基づくものか、シリアル実行時間からスケール変更または外挿したもの(シリアル実行の所要時間が10分であるのに対してパラレル実行の所要時間は5分など)に基づいています。パフォーマンスが期待どおりでない場合は、次の質問を考慮してください。

基本的な目標を設定し、これらの質問に答えた後は、次のトピックを考慮する必要があります。

リグレッションの有無

パラレル実行の実際のパフォーマンスが、期待値と異なるかどうかを判断します。パフォーマンスが期待値と同じ場合、基になるパフォーマンス問題があるかどうかを判断します。現行の結果と比較するための目標の結果があると思われます。システムが達成できないような正当なパフォーマンス期待値がある可能性があります。過去に、このレベルのパフォーマンスまたは特定の実行計画を達成した場合がありますが、現在、同じような環境および操作でも、システムはこの目標に達していません。

パフォーマンスが期待値と異なる場合は、偏りの程度を定量化できるかどうかを判断します。データ・ウェアハウス操作では、実行計画がキーとなります。重要なデータ・ウェアハウス操作では、EXPLAIN PLANの結果を保存します。その後、データの分析、再分析、Oracleのアップグレードおよび新しいデータのロードを行い、長い年月での実行計画を古い計画と比較できます。この方法を先行的または反動的に行います。

また、ヒントの使用によってパフォーマンスが向上する場合もあります。ヒントが必要な理由を理解し、オプティマイザが目標の計画をヒントなしで生成できる方法を判断する必要があります。統計情報のサンプル・サイズを増加させます。より適切な統計情報によって、より適切な計画を取得できる場合があります。

プラン・スタビリティおよびアウトラインを使用した、システムへの変更全体に対する計画保持の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

計画変更の有無

実行計画に変更があった場合、計画がパラレルかシリアルかを判断します。

パラレル計画の有無

実行計画がパラレルの場合は、EXPLAIN PLANの出力を調べます。すべての表を分析します。ヒントの使用が必要な場合があります。ヒントによって、より適切なパフォーマンスが得られるかどうかを検証します。rdbms/adminディレクトリのutlxplp.sqlを参照してください。

シリアル計画の有無

実行計画がシリアルの場合は、次の方法を検討します。

  • 索引を使用します。索引を追加すると、パフォーマンスが大幅に向上する場合があります。索引への列の追加を検討します。操作ですべてのデータを索引から取得できます。また、表スキャンは必要ありません。ヒントの使用が必要な場合があります。ヒントによって、より適切な結果が得られるかどうかを検証します。

  • 統計を計算します。頻繁に分析を行います。時間が十分にある場合は、統計情報の計算のよい練習になります。これは、多くの結合を実行する場合は特に重要で、より適切な結果を得ることができます。または、統計情報を見積ることができます。異なるサンプル・サイズを使用すると、計画が変わる可能性があります。通常、サンプル・サイズが大きいほど、計画はより適切になります。

  • 均一にデータが分散していない場合には、ヒストグラムを使用します。

  • 初期化パラメータをチェックし、値が適切かどうかを確認します。

  • CURSOR_SHARINGforceまたはsimilarに設定されていないかぎり、バインド変数をリテラルで置換します。

  • 実行がI/OバウンドまたはCPUバウンドかどうかを判断します。その後、オプティマイザのコスト・モデルをチェックします。

  • 副問合せを結合に変換します。

  • CREATE TABLE ... AS SELECT文を使用して、複雑な操作をより小さいピースに分割します。5つまたは6つの表を参照する大規模な問合せでは、問合せのどの部分に大半の時間がかかっているのかを判断することが困難な場合があります。問合せをいくつかのステップに分割し、各ステップを分析することによって、問合せのボトルネックを分離させることができます。

パラレル実行の有無

リグレッションの原因が計画の問題であることを確認できない場合、それは実行上の問題です。シリアルおよびパラレルの両方のデータ・ウェアハウス操作では、メモリー使用の計画を検討します。ページング率をチェックし、システムができるだけ効率的にメモリーを使用していることを確認します。バッファ、ソートおよびハッシュ領域のサイズをチェックします。問合せまたはDML操作の実行後、V$SESSTATV$PX_SESSTATおよびV$PQ_SYSSTATビューを参照して、使用されたサーバー・プロセスの数、セッションおよびシステムに関するその他の情報を確認します。

ワークロードの均等分散の有無

パラレル実行を使用している場合、ワークロードの分散が均等でないかどうかを判断します。たとえば、10のCPUおよびシングル・ユーザーの場合、CPU間でワークロードが均等に分散されているかどうかを確認できます。これは、長い年月の間(I/O集中が大きかったり小さかったりする期間)に変化する場合がありますが、通常、各CPUにはほぼ同量のアクティビティが必要です。

V$PQ_TQSTATの統計情報は、パラレル実行サーバーごとに生成および消費された行を示します。これは、偏りを適切に示し、シングル・ユーザーによる操作を必要としません。

オペレーティング・システム統計情報は、プロセッサごとのCPU使用率およびディスクごとのI/Oアクティビティを示します。ただし、処理が同時に実行している場合は、何が発生しているかを確認することが困難になります。シングル・ユーザー・モードで実行し、システム・レベルのCPUおよびI/Oアクティビティを表示するオペレーティング・システム・モニターをチェックすると効果的です。

I/O問題が発生した場合は、より多くのデバイスに分散させることで、データを再編成する必要がある場合があります。パラレル実行の問題が発生した場合は、データがCPUと同じ数のデバイスに分散されているかどうかをチェックします。

ワークロードの分散に偏りがない場合は、次の条件をチェックします。

  • デバイス競合があるか。

  • コントローラ競合があるか。

  • パラレル化が少なすぎることによるシステムI/Oバウンドか。その場合は、パラレル化を最大でデバイス数まで増加させることを検討します。

  • パラレル化が少なすぎることによるCPUバウンドか。オペレーティング・システムのCPUモニターをチェックして、システム・コールに長時間かかっていないかどうかを確認します。リソースが過剰にコミットされている場合があります。また、過剰なパラレル化によってプロセス同士が競合している場合があります。

  • システムのサポート数より同時ユーザーの数が多いか。

動的パフォーマンス・ビューでのパラレル実行パフォーマンスの監視

システムが数日間実行した後、パラレル実行パフォーマンスの統計情報を監視し、パラレル処理が最適かどうかを判断します。これを行うには、この項で説明するビューのいずれかを使用します。

Oracle Real Application Clustersでは、この項で説明するグローバル・バージョンのビューで、複数インスタンスの統計情報が集計されます。グローバル・ビューには、V$FILESTATに対するGV$FILESTATなどのGで始まる名前があります。

V$PX_BUFFER_ADVICE

V$PX_BUFFER_ADVICEビューには、すべてのパラレル問合せによる履歴または算出最大バッファ使用量の統計データが表示されます。パラレル問合せのメモリー不足の場合、このビューを参考にSGAサイズを再構成できます。

V$PX_SESSION

V$PX_SESSIONビューには、問合せサーバーのセッション、グループ、セットおよびサーバー番号に関するデータが表示されます。パラレル実行を代表して動作しているプロセスに関する、リアルタイムのデータも表示されます。この表には、要求されたDOPおよび操作に対して許可された実際のDOPに関する情報が含まれます。

V$PX_SESSTAT

V$PX_SESSTATビューには、V$PX_SESSIONおよびV$SESSTAT表から結合されたセッション情報が表示されます。そのため、通常のセッションに使用可能なすべてのセッション統計情報は、パラレル実行を使用して実行されたすべてのセッションに使用可能です。

V$PX_PROCESS

V$PX_PROCESSビューには、ステータス、セッションID、プロセスIDなど、パラレル・プロセスに関する情報が表示されます。

V$PX_PROCESS_SYSSTAT

V$PX_PROCESS_SYSSTATビューには、問合せサーバーの状態が表示され、バッファ割当ての統計情報が提供されます。

V$PQ_SESSTAT

V$PQ_SESSTATビューには、システム内のすべての同時サーバー・グループの状態が表示されます。たとえば、問合せによるプロセスの割当て方法、および、マルチユーザーやロード・バランシング・アルゴリズムが、デフォルト値およびヒントによって示された値にどのように影響するかに関するデータです。V$PQ_SESSTATは、将来のリリースで廃止される予定です。

これらのビューのデータを検討した後、いくつかのパラメータ設定を調整して、パフォーマンスを向上させる必要があります。この場合は、「パラレル実行用の一般パラメータのチューニング」を参照してください。これらのビューを定期的に問い合せて、長時間実行のパラレル操作の進行状況を監視します。

多くの動的パフォーマンス・ビューに対して、パラメータTIMED_STATISTICSTRUEに設定し、Oracleに各ビューに対する統計情報を収集してください。ALTER SYSTEMまたはALTER SESSION文を使用して、TIMED_STATISTICSをオンおよびオフにできます。

V$FILESTAT

V$FILESTATビューでは、読取り要求、書込み要求、ブロック数、および各表領域内の各データファイルに対するサービス時間が合計されます。V$FILESTATを使用して、I/Oおよびワークロード分散の問題を診断します。

V$FILESTATの統計情報をDBA_DATA_FILESビューの統計情報と結合して、表領域によってI/Oをグルーピングするか、または任意のファイル番号に対するファイル名を検索できます。割合分析を使用して、表領域内の各ファイルで使用される合計表領域アクティビティの割合を判断できます。表領域内に、頻繁にアクセスされる1つのオブジェクトのみを入れる場合は、このテクニックを使用して、不適切な物理レイアウトのオブジェクトを識別できます。

DBA_EXTENTSビューを使用して、ディスク領域割当ての問題をさらに診断できます。表領域内のすべてのファイルの領域が、均等に割り当てられていることを確認します。長時間実行操作中にV$FILESTATを監視し、その後、I/OアクティビティをEXPLAIN PLANの出力と相関させると、進行状況を適切に把握できます。

V$PARAMETER

V$PARAMETERビューには、すべてのシステム・パラメータの名前、現行の値、デフォルト値がリストされます。また、ビューには、パラメータがALTER SYSTEMまたはALTER SESSION文を使用してオンラインで変更できるセッション・パラメータであるかどうかも示されます。

V$PQ_TQSTAT

単純な例として、2つの表を個別値が2つのみの1つの列上で結合するハッシュ結合を考えてみます。最善の場合、このハッシュ処理では一方のハッシュ値がパラレル実行サーバーAにハッシュされ、他方がパラレル実行サーバーBにハッシュされます。2つのDOPは適切ですが、DOPが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によって操作列で明示的に表されます。下位互換性のために、PARALLEL_TO_PARALLELSERIAL_TO_PARALLELまたはPARALLEL_TO_SERIALの行ラベルは、旧リリースと同じセマンティックを持つので、従来どおりテーブル・キュー割当てを推論するために使用できます。また、パラレル計画の最上部は、操作PX COORDINATORを持つ新しいノードによってマーキングされます。

V$PQ_TQSTATの各テーブル・キューには、読取りまたは書込みを行う各問合せサーバー・プロセスに対する行があります。受取側の10のプロセスを生成側の10のプロセスに接続するテーブル・キューには、ビュー内に20の行があります。バイト列を合計し、テーブル・キュー識別子TQ_IDでグルーピングし、各テーブル・キューを介して送信された合計のバイト数を取得します。これをオプティマイザの見積りと比較します。差が大きい場合は、より大きいサンプルを使用して、データを分析する必要がある場合があります。

TQ_IDでグルーピングされたバイトの平方偏差を計算します。平方偏差が大きい場合は、ワークロードが不均衡です。大きい平方偏差を調べて、生成側がデータを不均等に分散して開始したか、または分散自体に偏りがあるかを判断する必要があります。データ自体に偏りがある場合は、カーディナリティが低いか、または個別値が少ない場合があります。

V$PQ_TQSTATビューの名前は、将来のリリースでV$PX_TQSTSATに変更される予定なので注意してください。

V$SESSTATおよびV$SYSSTAT

V$SESSTATビューには、各セッションに対するパラレル実行の統計情報が表示されます。統計情報には、セッション内で実行された問合せ、DMLおよびDDLの合計数が含まれます。また、セッションでのパラレル実行中に交換されたインスタンス内およびインスタンス間のメッセージの合計数も含まれます。

V$SYSSTATで得られる統計情報はV$SESSTATと同じですが、システム全体が対象です。

セッション統計情報の監視

この項の例では、「動的パフォーマンス・ビューでのパラレル実行パフォーマンスの監視」で説明した動的パフォーマンス・ビューを使用しています。

GV$PX_SESSIONを使用して、パラレルで実行しているサーバー・グループの構成を判断します。この例では、セッション9が問合せコーディネータで、セッション7および21が1番目のグループの1番目の集合にあります。セッション18および20は、1番目のグループの2番目の集合にあります。この問合せで要求および許可された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
---- --------- ------ --------- ------ ------
P002 IN USE        16     16955     21   7729
P003 IN USE        17     16957     20   2921
P004 AVAILABLE     18     16959
P005 AVAILABLE     19     16962
P000 IN USE        12      6999     18   4720
P001 IN USE        13      7004      7    234

システム統計情報の監視

V$SYSSTATおよびV$SESSTATビューには、パラレル実行を監視するためのいくつかの統計情報が含まれます。これらの統計情報を使用して、パラレル問合せ、DML、DDL、データ・フロー演算子(Data Flow Operator: 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

次の問合せは、システムのQCプロセスおよび各スレーブの現在の待機状態を示します。

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;

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

Oracleで入手できる情報と、オペレーティング・システム・ユーティリティ(UNIXベース・システム上のsarvmstatなど)を介して入手できる情報との間には、多くの重複があります。オペレーティング・システムでは、I/O、通信、CPU、メモリーやページング、スケジューリングおよび同期プリミティブに関するパフォーマンス統計情報が提供されます。V$SESSTATビューにも、主なカテゴリのオペレーティング・システム統計情報が表示されます。

通常、I/Oデバイスおよびセマフォ操作に関するオペレーティング・システム情報は、Oracle情報に比べて、データベース・オブジェクトおよび操作にマップしなおすのが困難です。ただし、いくつかのオペレーティング・システムには、データの収集に有効なビジュアル・ツールおよび効率的な方法があります。

CPUおよびメモリー使用量に関するオペレーティング・システム情報は、パフォーマンスの評価に非常に重要です。最も重要な統計情報は、CPU使用率です。低レベル・パフォーマンス・チューニングの目標は、すべてのCPUでCPUバウンドになることです。これが達成されると、SQLレベルで作業し、よりI/O集中型でより少ないCPUを使用する代替計画を検索できます。

オペレーティング・システムのメモリーおよびページング情報は、メモリーがパラレル通信、ソート、ハッシュ結合などのメモリー集中型データ・ウェアハウス・サブシステム間でどのように分割されるかを制御する、多くのシステム・パラメータの適切なチューニングに有効です。

アフィニティおよびパラレル操作

共有ディスク・クラスタまたはMPP構成では、デバイスがインスタンスを実行中のプロセッサから直接アクセスされる場合に、Oracle Real Application Clustersのインスタンスはそのデバイスに対してアフィニティを持っていると言われます。同様に、インスタンスは、ファイルが格納されているデバイスに対してアフィニティを持っている場合は、そのファイルに対してもアフィニティを持っています。

アフィニティを判断するには、複数のデバイス間でストライプ化されるファイルを任意に判断する必要があります。インスタンスは、表領域内の最初のファイルに対するアフィニティがあれば、ある程度は任意に、その表領域(または表領域内の表または索引のパーティション)に対するアフィニティを持っていることになります。

Oracleでアフィニティが考慮されるのは、作業をパラレル実行サーバーに割り当てる時点です。SQL文のパラレル実行に対するアフィニティの使用は、ユーザーに対して透過的です。

アフィニティおよびパラレル問合せ

パラレル問合せでのアフィニティにより、データに近いプロセッサ上でスキャンすることでディスクからのデータ・スキャンがスピードアップします。これにより、本来は共有ディスクをサポートしていないマシンのパフォーマンスが大幅に向上します。

アフィニティの最も一般的な用途は、単一デバイスの単一ファイルに格納される表または索引のパーティションです。この構成では、デバイス障害によるダメージが限定されることで最大限の可用性が得られ、パーティションのパラレル索引スキャンが最も適切に使用されます。

DSSのユーザーは、表のパーティションを複数(おそらく、合計デバイス数のサブセット)のデバイス間でストライプ化するのが適切です。この構成では、一部の問合せでパーティション化基準を使用してアクセスするデータの総量をプルーニングし、ROWIDレンジ・パラレル・テーブル(パーティション)スキャンを通じてパラレル化できます。デバイスがRAIDとして構成されている場合も、高度な可用性が得られます。DSSに使用される場合も、索引は個々のデバイス上でパーティション化する必要があります。

他の構成(単一ファイル内の複数パーティションが複数のデバイスにまたがってストライプ化される場合など)の場合は、適切な問合せ結果が得られますが、ヒントを使用するか、オブジェクト属性を明示的に設定し、適切なDOPを選択することが必要な場合があります。

アフィニティおよびパラレルDML

パラレルDML(挿入、更新および削除)の場合、アフィニティの拡張によりDML操作がパーティション・アフィニティを持つノードにルーティングされることで、キャッシュ・パフォーマンスが改善されます。

アフィニティにより、DML操作をパラレルに実行するための、インスタンスまたはパラレル実行サーバーのセット間における作業の分散方法が決定されます。アフィニティにより、問合せのパフォーマンスを複数の方法で改善できます。

  • 特定のMPPアーキテクチャについて、Oracleではデバイスとノードとのアフィニティ情報を使用して、パラレル実行サーバーを起動するノードが決定され(パラレル・プロセスの割当て)、特定のノードに送信する作業のグラニュル(ROWID範囲またはパーティション)が決定されます(作業の割当て)。ノードでは主としてローカル・デバイスにアクセスさせることでパフォーマンスが改善されるほど、各ノードのキャッシュ・ヒット率が高くなり、ネットワーク・オーバーヘッドとI/O待機時間が減少します。

  • SMP、クラスタおよびMPPアーキテクチャでは、プロセスとデバイスとのアフィニティを使用して、デバイスが分離されます。これにより、複数のパラレル実行サーバーが同じデバイスに同時にアクセスする可能性が少なくなります。このプロセスとデバイスとのアフィニティ情報は、プロセス間のスティーリングの実装にも使用されます。

パーティション表および索引の場合は、パーティションとノードとのアフィニティ情報により、プロセス割当てと作業割当てが決定されます。シェアード・ナッシングMPPシステムの場合、Oracle Real Application Clustersはパーティションのディスク・アフィニティを考慮して、インスタンスに対するパーティションの割当てを試みます。共有ディスクMPPおよびクラスタ・システムの場合、パーティションはラウンドロビン法でインスタンスに割り当てられます。

アフィニティをパラレルDMLに使用できるのは、Oracle Real Application Clusters構成で実行している場合のみです。文と文の間で持続するアフィニティ情報により、バッファ・キャッシュのヒット率が改善され、インスタンス間のブロック・ピングが減少します。

様々なパラレル実行のチューニング・ヒント

この項では、パラレル実行環境でパフォーマンスを向上するための様々なアイディアを説明します。内容は次のとおりです。

パラレル操作用のバッファ・キャッシュ・サイズの設定

パラレル更新および削除以外のパラレル操作では、通常、バッファ・キャッシュ・サイズを大きくしても効果はありません。パラレル操作によるその他の効果を得られるのは、バッファ・プールを大きくでき、それによって、ネストされたループ結合のための内部表または索引を適応させることができた場合のみです。

デフォルトの並列度のオーバーライド

デフォルトのDOPが応答時間を削減するために適切であり、すべてのパラレル操作に対するCPUおよびI/Oリソースの使用が保証されます。

操作がメモリー・バウンドであるか、またはいくつかの同時パラレル操作が実行中の場合、デフォルトのDOPを減少させてください。

Oracleは、PARALLEL属性のある表に対して、またはPARALLELヒントが指定された場合に、デフォルトのDOPを使用します。表にパラレル化の属性がない場合、またはNO_PARALLEL(デフォルト)属性がある場合に、ALTER SESSION FORCE PARALLELを通じてパラレル化が強制されていなければ、その表がパラレルにスキャンされることはありません。このオーバーライドは、CPU数、インスタンス数およびその表を格納するデバイスの数で示されるデフォルトのDOPに関係なく発生します。

DOPは、次のガイドラインに従って調整できます。

  • PARALLEL_THREADS_PER_CPUパラメータの値を変更して、デフォルトのDOPを変更します。

  • ALTER TABLEまたはALTER SESSIONを使用するか、ヒントを使用して、DOPを調整します。

  • 同時パラレル操作の数を増加させるには、DOPを減らすか、またはパラメータPARALLEL_ADAPTIVE_MULTI_USERTRUEに設定します。

SQL文のリライト

パラレル実行で最も重要なのは、大量のデータを処理する問合せ計画のすべての部分が、パラレルに実行されるようにすることです。EXPLAIN PLANを使用すると、計画のすべての手順にPARALLEL_TO_PARALLELPARALLEL_TO_SERIALPARALLEL_COMBINED_WITH_PARENTまたはPARALLEL_COMBINED_WITH_CHILDOTHER_TAGがあるかどうかを検証できます。その他のすべてのキーワード(またはNULL)は、シリアル実行であり、ボトルネックの可能性があることを示します。この計画手順が、操作PX SEND <partitioning type>ノード(PX SEND HASHなど)で終了することも確認してください。

また、utlxplp.sqlスクリプトを使用すると、すべての関連パラレル情報をEXPLAIN PLAN出力とともに表示できます。

副問合せ、特に相関副問合せを結合に変換するパラレル計画を生成する、オプティマイザのパフォーマンスを向上させることができます。Oracleは、副問合せより効率的に結合をパラレル化できます。これは、更新にも適用されます。詳細は、「表のパラレル更新」を参照してください。

パラレルでの表の作成および移入

Oracleは、パラレルではユーザー・プロセスに結果を戻せません。問合せによって多数の行が戻される場合は、問合せの実行が高速になる場合があります。ただし、ユーザー・プロセスは、行をシリアルにしか受信できません。大規模な結果セットを取り出す問合せでのパラレル実行のパフォーマンスを最適化するには、PARALLEL CREATE TABLE ... AS SELECTまたはダイレクト・パス・インサートを使用して、結果セットをデータベースに格納します。その後、ユーザーは結果セットをシリアルに参照できます。

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

NOLOGGINGオプションと組み合せた場合は、パラレルのCREATE TABLE ... AS SELECTによって、非常に効率的な中間表機能が提供されます。次に例を示します。

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

これらの表は、パラレルINSERTで増分的にもロードできます。次のテクニックを使用して、中間表の効果を得ることができます。

  • 一般の副問合せは、一度の計算で、何度も参照できます。これによって、スター・スキーマに対するいくつかの問合せ(特に、WHERE句の述語を選択しない問合せ)が、より適切にパラレル化されるようになる場合があります。スター変換テクニックを使用した、WHERE句の述語を選択するスター問合せは、SQLを変更しなくても、自動的に効率的にパラレル化されます。

  • 複合問合せをより単純なステップに分解し、アプリケーション・レベルのチェックポイントまたは再開を実現します。たとえば、サイズが1TBのデータベース上での複雑な複数表結合は、実行時間が何十時間にも及ぶ場合があります。この問合せ中に障害が発生すると、最初からやり直す必要があります。CREATE TABLE ... AS SELECTまたはPARALLEL INSERT AS SELECTを使用すると、それぞれが数時間ずつ実行される、より単純な問合せの連続としてリライトできます。システムに障害が発生した場合、問合せは、最後に計算されたステップから再開されます。

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

  • 集計表を作成し、効率的な多次元のドリルダウン分析を行います。たとえば、集計表に、月、ブランド、地域および販売員でグルーピングされた収益の合計額を格納できます。

  • 古い表を新しい表にコピーして、表の再編成、連鎖行の排除、空き領域の圧縮などを行います。これは、エクスポート/インポートより非常に高速で、再ロードより簡単です。

新しく作成した表に、DBMS_STATSパッケージを使用していることを確認してください。また、索引の作成も検討してください。I/Oのボトルネックを回避するには、最低でもCPUと同じ数のデバイスで表領域を指定してください。割当て領域の断片化を回避するには、表領域内のファイル数をCPUの数の倍数にしてください。ボトルネックの詳細は、第4章「データ・ウェアハウスにおけるハードウェアおよびI/Oの考慮事項」を参照してください。

パラレル・ソートおよびハッシュ結合に対する一時表領域の作成

領域管理のパフォーマンスを最適化するには、ローカル管理一時表領域を使用します。次に例を示します。

CREATE TEMPORARY TABLESPACE TStemp TEMPFILE '/dev/D31'
SIZE 4096MB REUSE EXTENT MANAGEMENT LOCAL UNIFORM SIZE 10m;

次のような文を発行して、一時表領域をデータベースに関連付けることができます。

ALTER DATABASE TEMPORARY TABLESPACE TStemp;

一度これを行うと、ユーザーを表領域に明示的に割り当てる必要はなくなります。

一時エクステントのサイズ

ローカル管理一時表領域を使用する場合、断片化の回避に役立つのでエクステントはすべて同じサイズになります。一般に、一時領域に対する需要が高く、同時実行中のパラレル処理またはその他の操作が一時表領域を共有する必要があるため、一時エクステントは、永続エクステントより小さくする必要があります。通常、一時エクステントは1MB〜10MBの範囲内である必要があります。一度エクステントを割り当てると、操作の実行中は自由に使用できます。大規模なエクステントを割り当てても、小量の領域しか使用する必要がない場合にはエクステント内の未使用領域は使用できません。

同時に、プロセスの領域待機を回避するために、一時エクステントを十分大きくする必要があります。一時表領域は、新しいエクステントの割当ておよび解放時に、永続表領域より少ないオーバーヘッドを使用します。ただし、新しい一時エクステントを取得するには、ラッチ取得およびSGA構造全体の検索以外に、エクステント・プール・ソートに対するSGA領域消費のオーバーヘッドも必要です。

ローカル管理一時表領域の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

パラレルSQL文の実行

表および索引の分析後は、使用したDOPに基づいてパフォーマンスが向上します。

通常のプロセスと同様に、簡単なパラレル操作から始め、SELECT COUNT(*) FROM facts文を使用してI/Oスループット合計を評価します。次に、この文に複雑なWHERE句を追加して、CPU総処理能力を評価します。I/Oが不均衡な場合、物理データベース・レイアウトを最適化する必要があることを示します。スキャンがどれほど単純に処理されるかを理解してから、集計、結合およびワークロード全体を反映する他の操作を追加します。特に、ボトルネックを調べる必要があります。

問合せのパフォーマンスに加えて、パラレル・ロード、パラレル索引作成およびパラレルDMLも監視し、I/OおよびCPUリソースの適切な使用率を判断する必要があります。

EXPLAIN PLANを使用したパラレル操作計画の参照

EXPLAIN PLAN文を使用して、パラレル問合せに対する実行計画を参照します。EXPLAIN PLANの出力には、COSTBYTESおよびCARDINALITY列内のオプティマイザ情報が表示されます。また、utlxplp.sqlスクリプトを使用すると、すべての関連パラレル情報をEXPLAIN PLAN出力とともに表示できます。

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

EXPLAIN PLANを使用する場合のキー・ポイントは、次のとおりです。

  • オプティマイザの選択的見積りの確認。オプティマイザで問合せから1行のみが生成されるとみなされている場合は、ネステッド・ループが使用される傾向があります。これは、表が分析されないこと、またはオプティマイザが同じ表の複数の述語の相関関係について不適切な見積りを行っていることを示す場合があります。オプティマイザに別の結合方法を使用させるには、ヒントが必要な場合があります。したがって、計画が特定の段階から1行しか生成されないことを示し、それが不適切な場合は、ヒントまたは統計収集を考慮してください。

  • カーディナリティの低い結合キーでのハッシュ結合の使用。結合キーの個別値が少数の場合は、ハッシュ結合が最適でないことがあります。個別値の数がDOPより少ないと、一部のパラレル問合せサーバーが特定の問合せで作業できないことがあります。

  • データの偏りの考慮。結合キーがデータの過剰な偏りに関係している場合は、ハッシュ結合により一部のパラレル問合せサーバーの作業量を他よりも大きくする必要がある場合があります。オプティマイザでBROADCAST分散方法が選択されなかった場合は、ヒントを使用してこれを行うことを考慮してください。オプティマイザはOPTIMIZER_FEATURES_ENABLEが9.0.2以上に設定されている場合にかぎり、BROADCAST分散方法を考慮することに注意してください。詳細は、「V$PQ_TQSTAT」を参照してください。

パラレルDMLに対するその他の考慮点

データ・ウェアハウス上で、パラレル挿入、更新または削除を使用して、データ・ウェアハウス・データベースをリフレッシュする場合は、物理データベースの設計時に考慮する、いくつかの追加問題があります。これらの考慮点は、パラレル実行操作には影響しません。これらの問題は次のとおりです。

PDMLおよびダイレクト・パス制限

パラレル制限に違反があった場合、操作はシリアルに実行されます。ダイレクト・パス・インサートの制限に違反があった場合、APPENDヒントは無視され、従来型の挿入が実行されます。エラー・メッセージは戻されません。

並列度の制限事項

パラレルUPDATEMERGEまたはDELETE操作を実行する場合、DOPは表のパーティション数以下になります。

リリース9.0.1より前のOracle9iデータベースで作成された表、または不変PDML ITLプロパティを持たない表の場合、以前のPDMLの制限が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;

ローカルおよびグローバル・ストライプ化の使用

パラレル更新とパラレル削除は、パーティション表にのみ機能します。索引メンテナンス中に大量のランダムI/O要求を生成する場合があります。

ローカル索引のメンテナンスでは、1つのサーバー・プロセスのみが、ディスクおよびディスク・コントローラのプロセス独自の集合に転送されるため、ローカル・ストライプ化がI/O競合の削減に最も効率的です。ローカル・ストライプ化では、ディスク障害のイベント時の可用性も増加します。

グローバル索引のメンテナンス(パーティションまたは非パーティション)では、多くのディスクおよびディスク・コントローラに索引をグローバル・ストライプ化する方法が、I/Oの数を分散するために最適です。

INITRANSの増加

グローバル索引がある場合、グローバル索引セグメントおよびグローバル索引ブロックは、同じパラレルDML文のサーバー・プロセスで共有されます。操作が同じ行に対して実行されていない場合でも、サーバー・プロセスは同じ索引ブロックを共有できます。各サーバー・トランザクションには、ブロックに変更を行う前に、索引ブロック・ヘッダーに1つのトランザクション・エントリが必要です。そのため、CREATE INDEXまたはALTER INDEX文では、INITRANS(各データ・ブロック内に割り当てられたトランザクションの初期数)を、この索引に対する最大DOPなどの大きい値に設定する必要があります。

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

ディクショナリ管理の表領域内のセグメントで使用可能なトランザクション空きリスト数には制限があります。一度セグメントが作成されると、プロセスおよびトランザクション空きリストの数は固定され、変更できません。セグメント・ヘッダー内に多くのプロセス空きリストを指定すると、これによって使用可能なトランザクション空きリストの数が制限される場合があります。プロセス空きリストの数を減少させることによって、次回、セグメント・ヘッダーを再作成する場合に、この制限を軽減できます。

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

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

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

複数のアーカイバの使用

パラレルDDLおよびパラレルDML操作では、大量のREDOログが生成される場合があります。単一のARCHプロセスでこれらのREDOログをアーカイブするには、対応しきれない場合があります。この問題を回避するために、複数のアーカイバ・プロセスを起動できます。これは、手動で行うか、またはジョブ・キューを使用して行います。

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

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

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

この場合は、DBWnプロセスを増やすことを考慮する必要があります。空きバッファの待機がない場合、この問合せで行は戻されません。

[NO]LOGGING句

[NO]LOGGING句は、表、パーティション、表領域および索引に適用されます。NOLOGGING句が使用された場合、事実上、ある操作(ダイレクト・パス・インサートなど)に対してログが生成されません。NOLOGGING属性は、INSERT文のレベルでは指定されませんが、そのかわりに、表、パーティション、索引または表領域に対してALTERまたはCREATE文が使用される場合に指定されます。

表または索引にNOLOGGINGが設定されている場合、パラレルまたはシリアル・ダイレクト・パス・インサート操作のどちらでも、REDOログは生成されません。NOLOGGINGオプションが設定されている状態で実行しているプロセスは、REDOが生成されないため、高速で実行します。ただし、表、パーティションまたは索引に対するNOLOGGING操作後、バックアップを作成する前にメディア障害が発生した場合は、変更されたすべての表、パーティションおよび索引が破損する場合があります。

ダイレクト・パス・インサート操作(ディクショナリ更新を除く)では、REDOログは生成されません。NOLOGGING属性は、UNDOには影響せず、REDOにのみ影響します。正確には、NOLOGGINGでは、ダイレクト・パス・インサート操作によって非常に少量のREDO(フル・イメージREDOに対してレンジ無効REDO)が生成されます。

下位互換性用に、[UN]RECOVERABLECREATE TABLE文の代替キーワードとして、これまでどおりサポートされています。ただし、この代替キーワードは、将来のリリースでサポートされなくなる場合があります。

表領域のレベルでは、ロギング句によって、デフォルトのロギング属性が表領域内に作成された表、索引およびパーティションに指定されます。ALTER TABLESPACE文によって、既存の表領域のロギング属性が変更され、ALTER文の後に作成されたすべての表、索引およびパーティションには新しいロギング属性が付きます。既存のものが、ロギング属性を変更することはありません。表領域レベルのロギング属性は、表、索引またはパーティション・レベルの仕様によって上書きされる可能性があります。

デフォルトのロギング属性はLOGGINGです。ただし、ALTER DATABASE NOARCHIVELOGを発行してデータベースをNOARCHIVELOGモードにした場合、ロギング属性の指定にかかわらず、ロギングなしで実行できるすべての操作でログは生成されません。

索引のパラレル作成

マルチ・プロセスは、同時に動作して索引を作成できます。複数のサーバー・プロセス間に索引を作成するために必要な作業を分割することによって、Oracle Databaseは、単一サーバー・プロセスが索引を順次作成する場合より高速に索引を作成できます。

パラレル索引作成は、ORDER BY句での表スキャンとほとんど同じ方法で動作します。表はランダムにサンプリングされ、索引をDOPと同じ数のピースに均等に分割する索引キーの集合が検出されます。問合せプロセスの最初の集合によって表がスキャンされ、キーおよびROWIDの組が抽出されます。その後、キーに基づいて各組が問合せプロセスの2番目の集合に送信されます。2番目の集合にある各プロセスによってキーがソートされ、通常の方法で索引が作成されます。すべての索引ピースが作成されると、パラレル・コーディネータは単純に(順序付けされた)ピースを連結し、索引を完成させます。

パラレル・ローカル索引作成は、単一サーバー・セットに使用されます。セット内の各サーバー・プロセスは、スキャン、および索引パーティションを作成する表パーティションに割り当てられます。半数のサーバー・プロセスが任意のDOPに対して使用されるため、パラレル・ローカル索引の作成は大きい値のDOPで実行できます。ただし、DOPは、作成する索引パーティションの数以下に制限されます。これを避けるために、DBMS_PCLXUTILパッケージを使用できます。

オプションで、索引の作成中にREDOおよびUNDOロギングが発生しないように指定できます。これによって、パフォーマンスが大幅に向上しますが、索引が一時的にリカバリ不能になります。リカバリは、新しい索引のバックアップ後に可能になります。アプリケーションが、索引のリカバリに再作成する必要があるウィンドウを受け付ける場合、NOLOGGING句の使用を検討する必要があります。

CREATE INDEX文のPARALLEL句は、索引の作成に対してDOPを指定できる唯一の方法です。DOPがCREATE INDEXのPARALLEL句に指定されない場合、CPUの数がDOPとして使用されます。PARALLEL句がない場合、索引作成はシリアルに実行されます。

索引をパラレルに作成する場合、STORAGE句には、問合せサーバー・プロセスによって作成された各副索引の記憶域が参照されます。そのため、5MBのINITIALおよび12のDOPで作成された索引は、各プロセスが5MBのエクステントで開始するため、索引の作成中に60MB以上の記憶域を消費します。問合せコーディネータ・プロセスによってソートされた副索引が組み合されると、いくつかのエクステントは切り捨てられ、作成された索引は、要求された60MBより小さくなる場合があります。

一意キー制約またはキー制約を表に追加または使用可能にする場合、要求された索引を自動的にパラレルで作成することはできません。そのかわりに、CREATE INDEX文および適切なPARALLEL句を使用して、目的の列に手動で索引を作成し、制約を追加または使用可能にします。Oracleは、制約を使用可能または追加する場合に既存の索引を使用します。

すべての制約が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;

パラレルDMLのヒント

この項では、パラレルDML機能の概要を示します。内容は次のとおりです。

パラレルDMLのヒント1: INSERT

次に、OracleのINSERT機能について示します。

表25-5 INSERT機能の要約

INSERTのタイプ パラレル シリアル NOLOGGING

従来型

不可

可能

不可

ダイレクト・パス・インサート

(APPEND

可能。次のものが必要:

ALTER SESSION ENABLE PARALLEL DMLPARALLEL属性またはPARALLELヒントAPPENDヒント(オプション)

可能。次のものが必要:

APPENDヒント

可能。次のものが必要:

パーティションまたは表に設定されたNOLOGGING属性


パラレルDMLが使用可能で、PARALLELヒントまたはPARALLEL属性がデータ・ディクショナリ表に対して設定されている場合、制限が適用されないかぎり、INSERTはパラレルになり、追加されます。PARALLELヒントまたはPARALLEL属性のいずれかがない場合、INSERTはシリアルに実行されます。

パラレルDMLのヒント2: ダイレクト・パス・インサート

パラレルINSERT中は、APPENDモードがデフォルトです。常に、データは表に割り当てられた新しいブロックに挿入されます。そのため、APPENDヒントはオプションです。APPENDモードを使用してINSERT操作処理速度を上げる必要がありますが、領域の使用率を最適化する必要がある場合は使用しないでください。NOAPPENDを使用してAPPENDモードをオーバーライドできます。

APPENDヒントは、シリアルおよびパラレルINSERTの両方に適用されます。このヒントを使用すると、シリアルINSERTでも、より高速になります。ただし、APPENDにはより多くの領域およびロック・オーバーヘッドが必要です。

NOLOGGINGAPPENDとともに使用して、処理をより高速にできます。NOLOGGINGとは、操作に対してREDOログが生成されないことを意味します。NOLOGGINGがデフォルトになることはなく、パフォーマンスを最適化する場合に使用します。通常、表またはパーティションにリカバリが必要な場合は、使用しないでください。リカバリが必要な場合は、操作後、すぐにバックアップを作成してください。ALTER TABLE [NO]LOGGING文を使用して、適切な値を設定します。

パラレルDMLのヒント3: INSERT、MERGE、UPDATEおよびDELETEのパラレル化

データ・ディクショナリ内の表またはパーティションにPARALLEL属性がある場合、属性の設定は、INSERTUPDATEDELETE文、および問合せのパラレル化の判断に使用されます。文にある表に対する明示的なPARALLELヒントによって、データ・ディクショナリ内のPARALLEL属性の文字修飾がオーバーライドされます。

NO_PARALLELヒントを使用して、データ・ディクショナリ内のPARALLEL属性をオーバーライドできます。一般に、ヒントは属性より優先されます。

DML操作は、セッションがPARALLEL DML使用可能モードにある場合にのみ、パラレル化が考慮されます(ALTER SESSION ENABLE PARALLEL DMLを使用して、このモードに入ります)。モードが、問合せ、またはDML文の問合せ部のパラレル化に影響することはありません。

INSERT ... SELECTのパラレル化

INSERT ... SELECT文では、SELECTキーワードの後に加えて、INSERTキーワードの後にPARALLELヒントを指定できます。INSERTキーワードの後のPARALLELヒントは、INSERT操作のみに適用され、SELECTキーワードの後のPARALLELヒントは、SELECT操作のみに適用されます。INSERTおよびSELECT操作のパラレル化は、それぞれ独立しています。1つの操作がパラレルで実行できない場合、他の操作がパラレルで実行できるかどうかには影響しません。

ユーザーがパラレルDMLに対してセッションを明示的に使用可能にし、データ・ディクショナリ・エントリにある問題の表にPARALLEL属性が設定されている場合は、INSERTのパラレル化機能によって、既存の動作が変更されます。既存のINSERT ... SELECT文でSELECT操作がパラレル化されている場合は、INSERT操作もパラレル化される場合があります。

複数の表を問い合せる場合、複数のSELECT PARALLELヒントおよび複数のPARALLEL属性を指定できます。

例25-7 INSERT ... SELECTのパラレル化

ACMEの取得後に雇用された新しい従業員を追加します。

INSERT /*+ PARALLEL(employees) */ INTO employees
SELECT /*+ PARALLEL(ACME_EMP) */ *  FROM ACME_EMP;

この例では、APPENDキーワードがPARALLELヒントに含まれるため、APPENDキーワードは必要ありません。

UPDATEおよびDELETEのパラレル化

UPDATEまたはDELETEキーワードの直後に置かれた)PARALLELヒントは、基礎となるスキャン操作のみでなく、UPDATEまたはDELETE操作にも適用されます。または、変更する表の定義に指定されたPARALLEL句に、UPDATEまたはDELETEのパラレル化を指定できます。

セッションまたはトランザクションに対してパラレルDMLを明示的に使用可能にした場合は、問合せ操作がパラレル化されているUPDATEまたはDELETE文によって、UPDATEまたはDELETE操作もパラレル化されます。文中のすべての副問合せまたは更新可能なビューには、独自の個別PARALLELヒントまたは句がある場合がありますが、これらのパラレル指定は、UPDATEまたはDELETEのパラレル化の判断には影響しません。これらの操作がパラレルで実行できない場合、UPDATEまたはDELETEの部分がパラレルで実行できるかどうかには影響しません。

パラレルUPDATEおよびDELETEをサポートするには、表をパーティション化する必要があります。

例25-8 UPDATEおよびDELETEのパラレル化

ダラスにいるすべての事務員の給与を10%昇給します。

UPDATE /*+ PARALLEL(employees) */ employees
SET SAL=SAL * 1.1 WHERE JOB='CLERK' AND DEPTNO IN
  (SELECT DEPTNO FROM DEPT WHERE LOCATION='DALLAS');

PARALLELヒントは、UPDATE操作およびスキャンに適用されます。

例25-9 UPDATEおよびDELETEのパラレル化

食料雑貨のビジネス・ラインが別々の会社に分離新設されたため、食料雑貨のカテゴリ内のすべての製品を削除します。

DELETE /*+ PARALLEL(PRODUCTS) */ FROM PRODUCTS
WHERE PRODUCT_CATEGORY ='GROCERY';

ここでも、パラレル化は、employees表のスキャンおよびUPDATE操作に適用されます。

パラレルでの増分データのロード

更新可能な結合ビュー機能と組み合されたパラレルDMLによって、データ・ウェアハウス・システムの表のリフレッシュに効率的なソリューションが提供されます。表のリフレッシュとは、OLTP本番システムから生成された差分データで更新することです。

次の例では、列c_keyc_nameおよびc_addrを持つ表customerをリフレッシュするとします。差分データには、新しい行またはデータ・ウェアハウスの最後のリフレッシュ後に更新された行のいずれかが含まれます。この例では、更新されたデータが、ASCIIファイルによって本番システムからデータ・ウェアハウス・システムに送信されます。これらのファイルは、リフレッシュ処理を開始する前に、diff_customerという名前の一時表にロードする必要があります。パラレルおよびダイレクト・オプションの両方を指定してSQL*Loaderを使用し、この作業を効率的に実行できます。パラレルでロードする場合も、APPENDヒントを使用できます。

一度diff_customerがロードされると、リフレッシュ処理を開始できます。これは、次に示すように、2つのフェーズで実行することも、パラレルにマージして実行することもできます。

表のパラレル更新

次の文は、副問合せを使用した更新の簡単な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表がパーティション化されている場合のみです。

表に対するパラレルでの新しい行の挿入

リフレッシュ処理の最後のフェーズでは、diff_customer一時表からcustomer表への新しい行の挿入が行われます。更新の場合と同様に、INSERT文にも副問合せが必要です。

INSERT /*+PARALLEL(customers)*/ INTO customers SELECT * FROM diff_customer s);

ただし、HASH_AJヒントを使用すると、副問合せが逆ハッシュ結合に変換されるように保証できます。これによって、パラレルINSERTを使用して、前述の文を効率的に実行できます。パラレルINSERTは、表がパーティション化されていない場合でも適用されます。

パラレルでのマージ

UPDATEとINSERTを組み合せて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文の最適な実行計画を見つけるために有効な方法です。Oracleは、パラレル実行で自動的に問合せ最適化を使用します。

コストベースの最適化で使用する現在の統計情報を収集するには、DBMS_STATSパッケージを使用する必要があります。特に、パラレルで使用される表は、必ず分析する必要があります。統計情報は、DBMS_STATSパッケージを使用して常に最新の状態に維持するようにしてください。統計情報が古いと、最適な実行計画が生成されずに実行時のパフォーマンスが低下する場合があります。

ヒントの採用は、慎重に行います。これによって、必要かつ重要なパフォーマンス上のメリットが示された場合にのみ、ヒントは、チューニングの最終ステップとして使用されます。この場合、問合せ最適化で推奨された実行計画で開始し、パフォーマンス期待値を定量化した後にのみ、続けてヒントの影響をテストします。ヒントは強力であることに注意してください。ヒントを使用して基礎となるデータが変更された場合、ヒントの変更が必要な場合があります。そうしないと、実行計画の効率が低下します。

FIRST_ROWS(n)ヒント

FIRST_ROWS(n)ヒントにより、オプティマイザは最短時間でn行を戻すよう問合せを最適化する、新しい最適化モードを使用できます。オンライン問合せには、古いFIRST_ROWSヒントのかわりに、この新しいヒントを使用することをお薦めします。新しい最適化モードでは、古い最適化モードにくらべて、応答時間が向上します。

できるだけ短時間に最初のn行が必要な場合に、FIRST_ROWS(n)ヒントを使用します。たとえば、できるだけ短時間に最初の10行を取得するには、次のようなヒントを使用します。

SELECT /*+ FIRST_ROWS(10) */ article_id
FROM articles_tab WHERE CONTAINS(article, 'Oracle')>0 ORDER BY pub_date DESC;

動的なサンプリングの有効化

動的なサンプリングを使用すると、より正確な統計情報を導出できるので、統計情報が存在しない場合や情報が古い場合に、問合せのパフォーマンスが向上します。これは、データ・ウェアハウス環境やロング・トランザクションや時間のかかる問合せが予測される場合に特に有用です。これらの状況では、最善の実行計画が使用されるようにすることが重要です。ただし、動的サンプリングには多少のコストがかかるため、このコストが全体的な実行時間に対して比較的小さい場合にのみ使用してください。

統計情報の動的サンプリングを有効にすると、Oracleは問合せに動的サンプリングが役立つかどうかをコンパイル時に判断します。役立つ場合は、小さくてランダムな表ブロックのサンプルをスキャンする再帰的SQL文が発行され、述語の選択性を評価するのに適した単一の表述語が適用されます。関連する表、索引および列の統計情報も評価されます。選択性と統計情報の評価が正確であるほど、オプティマイザはより優れたパフォーマンス計画を作成できます。

動的サンプリングは、初期化パラメータOPTIMIZER_DYNAMIC_SAMPLINGで制御されます。このパラメータは、0から10までの値に設定できます。このパラメータの値を増やすと、サンプリングされる表の種類(分析なし/分析あり)とサンプリングに費やされるI/Oの量の両方について、動的サンプリングがより幅広く適用されます。

Oracleでは、表固有のヒントDYNAMIC_SAMPLINGも提供しています。表名を省略すると、ヒントはカーソル・レベルと見なされます。表レベルのヒントは、表に対して動的サンプリングを強制的に実行します。

動的サンプリングの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。