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

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

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

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

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

SQL文が発行されます。
文が解析され、DOPが自動的に決定されます。
使用可能なパラレル・リソースがチェックされます。
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待機イベントを使用します。

このセクションのトピックは次のとおりです:

関連項目:

パラレル文のキューの監視および分析のためのビューに関する詳細は、V$RSRC_SESSION_INFOおよびV$RSRCMGRMETRIC
PARALLEL_SERVERS_TARGET初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください

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

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

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

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

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

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

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

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

関連項目:

Oracle Database Resource ManagerによるOracle Databaseリソースの管理の詳細は、『Oracle Database管理者ガイド』を参照してください
パラレル実行(PX)サーバーおよびマルチテナント・コンテナ・データベース(CDB)とプラガブル・データベース(PDB)での使用率制限の詳細は、『Oracle Multitenant管理者ガイド』を参照してください
V$RSRC*ビュー、DBA_HIST_RSRC_CONSUMER_GROUPビューおよびパラレル問合せの待機イベントの詳細は、『Oracle Databaseリファレンス』を参照してください
DBMS_RESOURCE_MANAGERパッケージの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください

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プロシージャを実行して、そのパラレル文をデキューできます。

関連項目:

DBMS_RESOURCE_MANAGERパッケージのプロシージャの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください
リソース・プラン・ディレクティブの作成の詳細は、『Oracle Database管理者ガイド』を参照してください

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