8.4 パラレル文のキューイング
状況によっては、パラレル文はリソースの待機中にキューに入れられます。
パラメータPARALLEL_DEGREE_POLICY
をAUTO
に設定すると、必要な数のパラレル実行サーバー・プロセスが使用可能でない場合、パラレル実行を必要とするSQL文はキューに入ります。必要なリソースが使用可能になると、SQL文はデキューされ、実行が許可されます。デフォルトのデキュー順序は、文が発行された時刻に基づく単純な先入先出キューです。
次に、パラレル文処理のサマリーを示します。
-
SQL文が発行されます。
-
文が解析され、DOPが自動的に決定されます。
-
使用可能なパラレル・リソースがチェックされます。
-
十分なパラレル実行サーバーが使用でき、キューにリソース待ちの文がない場合は、そのSQL文が実行されます。
-
十分なパラレル実行サーバーが使用できない場合、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;