Oracleの並列処理について理解する最も重要なことは、それが複雑であるということです。並列処理を最適化するには、Oracleに関する多くの知識、マニュアルの読み方、多くのパラメーターの確認、長時間実行されるクエリのテスト、および多くの懐疑論が必要です。
適切な質問をする
並列問題には、実際には3つの異なる質問が含まれます。
- 要求された並列サーバーの数は？
- 割り当てられた並列サーバーの数は？
- 意味のある並列サーバーの数はいくつですか？
最高のツールを使用する
最適なツールであるアクティブレポートを使用したSQLモニタリングに直接アクセスしてください。 SQL_IDを見つけて、HTMLレポートを生成します。select dbms_sqltune.report_sql_monitor(sql_id => 'your_sql_id', type => 'active') from dual; 。これは、実行プランの各ステップに費やされた時間を知る唯一の方法です。そして、どの程度の並列処理が効果的に使用されたか、そしてどこで使用されたかがわかります。例えば： 
もう1つの良いオプションは、type => 'text'です。 。それほど多くの情報はありませんが、見やすく、共有しやすいです。
SQLモニタリングには、要求されたDOPと割り当てられたDOPも含まれます。 
100行の並列select 美しく実行される可能性がありますが、キャッシュされていないシーケンスのため、すべてが1つのステップで停止します。説明プラン、トレース、またはAWRレポートを何時間も見つめても、問題はわかりません。アクティブなレポートを使用すると、遅いステップを見つけるのはほとんど簡単です。問題がどこにあるかを推測するのに時間を無駄にしないでください。
ただし、他のツールは引き続き必要です。 explain plan for ...で生成されたExplainPlan およびselect * from table(dbms_xplan.display);いくつかの重要な情報を提供します。具体的には、Notes セクションには、クエリが並列処理を要求しなかった多くの理由を含めることができます。
しかし、なぜその数の並列サーバーを取得したのですか？
関連情報はいくつかの異なるマニュアルに分散しています。これらのマニュアルは非常に便利ですが、不正確または誤解を招く場合があります。並列処理については、多くの神話と多くの悪いアドバイスがあります。また、テクノロジーはリリースごとに大幅に変更されます。
信頼できるソースをすべてまとめると、並列サーバーの数に影響を与える要因のリストは驚くほど多くなります。以下のリストは、私が最も重要な要素であると思うものによって大まかに並べられています。
- 操作間の並列処理 並べ替えまたはグループ化を使用するクエリでは、DOPの2倍の並列サーバーが割り当てられます。これはおそらく、「Oracleはできるだけ多くの並列サーバーを割り当てる」という神話の原因です。
- クエリのヒント できれば、
/*+ parallel */のようなステートメントレベルのヒント 、または/*+ noparallel(table1) */のようなオブジェクトレベルのヒント 。プランの特定のステップが連続して実行されている場合、それは通常、クエリの一部のみに対するオブジェクトレベルのヒントが原因です。 - 再帰SQL 一部の操作は並列で実行される場合がありますが、再帰SQLによって効果的にシリアル化できます。たとえば、大きな挿入のキャッシュされていないシーケンス。ステートメントを解析するために生成される再帰SQLもシリアルになります。たとえば、動的サンプリングクエリ。
- セッションの変更
alter session [force|enable] parallel [query|dml|ddl];並列DMLはデフォルトで無効になっていることに注意してください。 - テーブルの程度
- インデックスの程度
- インデックスの方が安かった 並列ヒントは、オプティマイザーに特定のDOPでの全表スキャンを検討するように指示するだけです。それらは実際には並列処理を強制しません。オプティマイザーは、安価だと思われる場合でも、シリアルインデックスアクセスを自由に使用できます。 （
FULLヒントはこの問題の解決に役立つ場合があります。） - 計画管理 SQLプランのベースライン、アウトライン、プロファイル、高度な書き換え、およびSQLトランスレーターはすべて、背後にある並列処理の程度を変更できます。計画のメモセクションを確認してください。
- エディション EnterpriseEditionとPersonalEditionのみが並列操作を許可します。パッケージDBMS_PARALLEL_EXECUTEを除く。
- PARALLEL_ADAPTIVE_MULTI_USER
- PARALLEL_AUTOMATIC_TUNING
- PARALLEL_DEGREE_LIMIT
- PARALLEL_DEGREE_POLICY
- PARALLEL_FORCE_LOCAL
- PARALLEL_INSTANCE_GROUP
- PARALLEL_IO_CAP_ENABLED
- PARALLEL_MAX_SERVERS これは、システム全体の上限です。ここにはトレードオフがあります。一度に実行する並列サーバーが多すぎると、システムに悪影響を及ぼします。ただし、クエリをシリアルにダウングレードすると、一部のクエリで悲惨な結果になる可能性があります。
- PARALLEL_MIN_PERCENT
- PARALLEL_MIN_SERVERS
- PARALLEL_MIN_TIME_THRESHOLD
- PARALLEL_SERVERS_TARGET
- PARALLEL_THREADS_PER_CPU
- RACノードの数 デフォルトのDOPのもう1つの乗数。
- CPU_COUNT デフォルトのDOPが使用されている場合。
- RECOVERY_PARALLELISM
- FAST_START_PARALLEL_ROLLBACK
- プロフィール
SESSIONS_PER_USER並列サーバーも制限します。 - リソースマネージャー
- システム負荷 parallel_adaptive_multi_userがtrueの場合。 Oracleがいつスロットルを開始するかを推測することはおそらく不可能です。
- プロセス
- 並列DML制限 次のいずれかの場合、並列DMLは機能しません。
- 互換性<パーティション内の9.2
- 値の挿入、トリガー付きのテーブル
- 複製
- 自己参照整合性、またはカスケードまたは遅延整合性制約の削除
- オブジェクト列へのアクセス
- LOBを含むパーティション化されていないテーブル
- LOBを使用したパーティション内並列処理
- 分散トランザクション
- クラスター化されたテーブル
- 一時テーブル
- スカラーサブクエリは並行して実行されませんか？ これはマニュアルにあります。これがだったらいいのにと思います。 本当ですが、私のテストでは、並列処理はここで11gで機能することが示されています。
- ENQUEUE_RESOURCES 10gの非表示パラメータ、これはもう関連性がありますか？
- インデックス編成のテーブル IOTへのダイレクトパス挿入を並行して行うことはできませんか？ （これはまだ本当ですか？）
- 並列パイプライン機能要件
CURSORを使用する必要があります （？）。 TODO。 - 関数はPARALLEL_ENABLEである必要があります
- ステートメントの種類 古いバージョンでは、パーティショニングに応じてDMLの並列処理が制限されていました。現在のマニュアルのいくつかにはまだこれが含まれていますが、それは確かにもう真実ではありません。
- パーティションの数 古いバージョンでのパーティション単位の結合のみ。（？）
- バグ 具体的には、構文解析に関する多くのバグを見てきました。 Oracleは適切な数の並列サーバーを割り当てますが、すべてが
cursor: pin s wait on xのようなイベントを待機するため、何も起こりません。 。
このリストは確かに完全ではなく、12cの機能は含まれていません。また、オペレーティングシステムとハードウェアの問題には対応していません。そして、それは「並列処理の最高度はどれくらいか」という恐ろしく難しい質問には答えません。 （簡単な答え：通常は多いほど良いですが、他のプロセスが犠牲になります。）少なくとも、これらの問題がどれほど難しいかを理解し、探し始めるのに適した場所になることを願っています。