| Oracle Databaseデータ・ウェアハウス・ガイド 11gリリース1（11.1） E05763-01 |
|
 前へ |
 次へ |
この章では、パラレル実行環境におけるチューニングについて説明します。内容は次のとおりです。
パラレル実行を採用すると、一般的に意思決定支援システム（DSS）およびデータ・ウェアハウスに対応付けられている大規模なデータベースにおいて、データ処理集中型の操作の応答時間が大幅に短縮されます。パラレル実行は、特定のオンライン・トランザクション処理（OLTP）システムおよびハイブリッド・システムにも実装できます。パラレル実行は、パラレル化と呼ばれることもあります。パラレル化は、1つのプロセスで問合せの作業をすべて実行するかわりに、多数のプロセスで作業の各部を同時に実行できるように、タスクを分割するという概念です。その一例が、1つのプロセスで4つの四半期を単独ですべて処理するかわりに、4つのプロセスでそれぞれ1つずつ四半期を処理する場合です。これにより、パフォーマンスを大幅に改善できます。この場合、各四半期はパーティション、つまり、より小型で管理しやすい単位の索引または表となります。パラレル実行によって、次の処理を改善できます。
大規模な表のスキャン、結合またはパーティション索引スキャンを要求する問合せ
大規模な索引の作成
大規模な表の作成（マテリアライズド・ビューを含む）
大量挿入、更新、マージおよび削除
また、パラレル実行を使用して、Oracleデータベース内のオブジェクト型にアクセスすることもできます。たとえば、パラレル実行を使用するとラージ・オブジェクト（Large Object: LOB）にアクセスできます。
システムがパラレル実行による効果を得られるのは、そのシステムが次の特性をすべて持ちあわせている場合です。
挿入、ハッシングおよびI/Oバッファなどの、メモリー集中型で付加的な処理をサポートするのに十分なメモリー
システムにこれらの特性が1つでも欠けている場合、パラレル実行による大幅なパフォーマンスの向上は得られない場合があります。実際、使用率の高いシステムまたはI/O帯域幅が小さいシステムでは、パラレル実行によってパフォーマンスが低下する可能性があります。
パラレル実行の利点は、DSSおよびデータ・ウェアハウス環境で明らかになります。OLTPシステムにおいても、バッチ処理時および索引の作成などのスキーマ・メンテナンス操作時にパラレル実行の利点を活用できます。OLTPアプリケーションを特徴付ける平均的で単純なDMLまたはSELECT文の場合、パラレル実行による利点はありません。
通常の問合せまたはトランザクションが非常に短時間（数秒以内）で完了する環境。これには、ほとんどのオンライン・トランザクション・システムが当てはまります。このような環境では、パラレル実行サーバーの調整に関するコストのために、パラレル実行は有用なものにはなりません。トランザクションが短時間の場合、この調整のためのコストがパラレル化の利点を上回る可能性があります。
CPU、メモリー、I/Oリソースがすでに頻繁に使用されている環境。パラレル実行では、使用可能なハードウェア・リソースが通常よりも多く使用されることになります。そのようなリソースが使用できない場合、パラレル実行による利点はなく、パフォーマンスの低下につながる可能性があります。
アクセス方法
表スキャン、全索引スキャンおよびパーティション索引レンジ・スキャンなど。
結合方法
ネステッド・ループ、ソート・マージ、ハッシュおよびスター型変換など。
DDL文
CREATE TABLE AS SELECT、CREATE INDEX、REBUILD INDEX、REBUILD INDEX PARTITION、MOVE/SPLIT/COALESCE PARTITIONなど。
通常は、標準DDLを使用するパラレルDDLを使用できます。ただし、データベース設計の際にいくつか考慮すべき点があります。重要な制約事項として、オブジェクトまたはLOB列を持つ表では、パラレルDDLを使用できないことがあげられます。
これらのDDL操作はすべて、パラレル実行またはシリアル実行用にNOLOGGINGモードで実行できます。
索引構成表に対するCREATE TABLE文は、AS SELECT句を指定しても指定しなくてもパラレル化できます。
様々な操作に異なるパラレル化が使用されます。PARALLEL CREATE（パーティション化）TABLE AS SELECT文およびPARALLEL CREATE（パーティション化）INDEX文は、パーティション数に等しい並列度（DOP）で動作します。
パラレル操作では、最適に実行するために正確な統計情報が必要です。
DML文
INSERT AS SELECT、UPDATE、DELETEおよびMERGE操作など。
パラレルDML（パラレルINSERT、UPDATE、MERGEおよびDELETE）では、大きなデータベース表や索引に対する大規模なDML操作をスピードアップまたは拡張するために、パラレル実行メカニズムが使用されます。また、INSERT ... SELECT文を使用して、単一DML文の一部として複数の表に行を挿入できます。通常は、標準DMLを使用するパラレルDMLを使用できます。
通常、データ操作言語（DML）には問合せが含まれますが、パラレルDMLという用語は、パラレル実行される挿入、更新、アップサートおよび削除のみを指します。
パラレル問合せ
問合せと副問合せをSELECT文中でパラレル化できます。また、DDL文とDML文の問合せ部分（INSERT、UPDATE、DELETE、MERGE）もパラレル化できます。
その他のSQL操作
GROUP BY、NOT IN、SELECT DISTINCT、UNION、UNION ALL、CUBE、ROLLUP、集計関数およびテーブル・ファンクションなど。
SQL*Loader
大量のデータを定期的に扱うSQL*Loaderの処理をパラレル化できます。ロードをスピードアップするには、次のようにパラレル・ダイレクト・パス・ロードを使用します。
sqlldr CONTROL=LOAD1.CTL DIRECT=TRUE PARALLEL=TRUE sqlldr CONTROL=LOAD2.CTL DIRECT=TRUE PARALLEL=TRUE sqlldr CONTROL=LOAD3.CTL DIRECT=TRUE PARALLEL=TRUE
コマンドラインでユーザーIDとパスワードを入力します。パラメータ・ファイルを使用しても同じ結果を得られます。
パラレル・ロード時には、索引が保持されないので注意してください。
パラレル実行では、SQL文の実行タスクを複数の単位に細分化し、各単位を独立したプロセスで実行します。また、入力データ（表、索引、パーティション）をグラニュルという部分に分割できます。パラレルで問合せを実行するユーザーのシャドウ・プロセスが、パラレル実行コーディネータまたは問合せコーディネータとしての役割を担います。問合せコーディネータでは、次の処理を行います。
問合せを解析し、並列度を決定します。
1つまたは2つのスレーブ・セット（スレッドまたはプロセス）を割り当てます。
問合せを制御し、手順をパラレル問合せ（PQ）スレーブに送信します。
PQスレーブでスキャンする必要がある表または索引を決定します。
最終出力をユーザーに対して生成します。
パラレル実行コーディネータでは、場合により、1つのSQL文をインスタンスの複数のパラレル実行サーバーで処理するように指示が出されます。単一の操作に関連付けられるパラレル実行サーバーの数は、並列度と呼ばれます。
単一の操作とは、ORDER BYや、索引のない列表に対して結合を実行する全表スキャンなどのSQL文の一部です。
並列度が直接的に適用されるのはイントラ・オペレーション並列化のみです。インター・オペレーション並列化があり得る場合は、文に対するパラレル実行サーバーの総数が、指定した並列度の2倍になることがあります。パラレル実行サーバーのセットは2つまで同時に実行できます。パラレル実行サーバーの各セットで複数の操作を処理できます。最適なインター・オペレーション並列化を保証するためにアクティブにする必要のあるパラレル実行サーバーは、2セットのみです。
パラレル実行は、問合せに迅速に答えるため、複数のCPUやディスクを効率的に使用するように設計されています。複数のユーザーが同時にパラレル実行を使用すると、使用可能なCPU、メモリーおよびディスク・リソースが短時間で枯渇してしまいやすくなります。
Oracle Databaseでは、パラレル実行環境に伴うリソース使用率を管理できるように、次のような複数の方法が用意されています。
マルチユーザー問合せ調整アルゴリズム。デフォルトで有効になっています。システム負荷が増大するにつれて並列度を低下させます。
ユーザー・リソース制限およびプロファイル。各ユーザーが使用可能な各種システム・リソースの量に対する制限を、ユーザーのセキュリティ・ドメインの一部として設定できます。
データベース・リソース・マネージャ。様々なユーザー・グループにリソースを割り当てることができます。
インスタンスの起動時に、Oracleではすべてのパラレル操作に使用可能なパラレル実行サーバーのプールが作成されます。Oracle Databaseによりインスタンスの起動時に作成されるパラレル実行サーバーの数を、初期化パラメータPARALLEL_MIN_SERVERSで指定します。
パラレル操作の実行時には、パラレル実行コーディネータによってプールからパラレル実行サーバーが取得され、操作に割り当てられます。必要な場合は、Oracleで操作用のパラレル実行サーバーが追加作成されます。こうしたパラレル実行サーバーは、ジョブの実行中はその操作で保持され、実行後は他の操作に使用できるようになります。文の処理が完了すると、パラレル実行サーバーはプールに戻されます。
パラレル実行コーディネータとパラレル実行サーバーで処理できる文は、一度に1つのみであることに注意してください。パラレル実行コーディネータで、パラレル問合せとパラレルDML文などの同時調整はできません。
ユーザーがSQL文を発行すると、オプティマイザでは、操作をパラレルに実行するかどうかと、各操作の並列度が決定されます。操作に必要なパラレル実行サーバーの数は、様々な方法で指定できます。
文がオプティマイザでパラレル処理の対象とされた場合、次の順序でイベントが発生します。
SQL文のフォアグラウンド・プロセスがパラレル実行コーディネータになります。
パラレル実行コーディネータで、必要な数（DOPにより決定）のパラレル実行サーバーがサーバー・プールから取得されるか、または必要に応じて新規にパラレル実行サーバーが作成されます。
Oracle Databaseでは、文が一連の操作として実行されます。各操作は、可能であればパラレルに実行されます。
文の処理が完了すると、その文を発行したユーザー・プロセスにコーディネータから結果データが戻され、パラレル実行サーバーがサーバー・プールに戻されます。
パラレル実行コーディネータでは、SQL文の解析中ではなく実行中に、パラレル実行サーバーを要求します。したがって、パラレル実行を共有サーバーで使用する場合、ユーザーの文に対するパラレル実行コーディネータは、その文のEXECUTEのコールを処理するサーバー・プロセスとなります。詳細は、「パラレル実行の並列度の設定」を参照してください。
あるインスタンスで同時に処理されているパラレル操作の数が大幅に変化すると、Oracle Databaseではプール内のパラレル実行サーバーの数が自動的に変更されます。
パラレル操作の数が増加すると、Oracle Databaseでは、受信した要求を処理できるようにパラレル実行サーバーが追加作成されます。ただし、1つのインスタンスに対して、初期化パラメータPARALLEL_MAX_SERVERSに指定されている値よりも多くのパラレル実行サーバーが作成されることはありません。
パラレル操作の数が減少すると、しきい値に指定した期間の間アイドル状態になっていたパラレル実行サーバーがOracle Databaseによって終了されます。パラレル実行サーバーがアイドル状態になっていた期間がどんなに長くても、プールのサイズがPARALLEL_MIN_SERVERSの値を下回ることはありません。
Oracle Databaseでは、プロセス数が必要とされる数よりも少ない場合にもパラレル操作を処理できます。
プール内のパラレル実行サーバーがすべて占有されており、最大数のパラレル実行サーバーが起動している場合、パラレル実行コーディネータではシリアル処理への切り替えが行われます。
初期化パラメータPARALLEL_MIN_PERCENTの使用については「パラレル実行サーバーの最小数」を、初期化パラメータPARALLEL_MIN_PERCENTおよびPARALLEL_MAX_SERVERSについては「パラレル実行用の一般パラメータのチューニング」を参照してください。
Oracle Databaseでは、問合せをパラレルに実行するために、通常の場合、生成側のキュー・サーバーおよびコンシューマ・サーバーが作成されます。生成側のキュー・サーバーで表から行が取り出され、取り出された行に対してコンシューマ・サーバーで結合、ソート、DML、DDLなどの操作が実行されます。生成側の実行プロセス・セット内の各サーバーが、コンシューマ・セット内の各サーバーに接続します。つまり、パラレル実行サーバー間の仮想接続の数は、DOPに正比例して増加します。
各通信チャネルには1〜4個のメモリー・バッファがあります。メモリー・バッファが複数あると、パラレル実行サーバー間の非同期の通信が容易になります。
単一インスタンス環境では、各通信チャネルで最大3個のバッファが使用されます。Oracle Real Application Clusters環境では、各チャネルで最大4個のバッファが使用されます。図25-1に、メッセージ・バッファと、生成側パラレル実行サーバーからコンシューマ・パラレル実行サーバーへ接続する方法を示します。
同一インスタンスの2つのプロセス間の接続では、サーバーがバッファをやりとりして通信します。異なるインスタンスのプロセス間の接続では、外部の高速ネットワーク・プロトコルを使用してメッセージが送信されます。図25-1において、DOPはパラレル実行サーバーの数と等しく、この場合nで表されます。図25-1には、パラレル実行コーディネータは示されていません。実際には、各パラレル実行サーバーは、パラレル実行コーディネータにも接続しています。
各SQL文は、解析時に最適化プロセスとパラレル化プロセスの対象となります。データが変化した際に、より最適な実行やパラレル化の計画が使用できるようになった場合、Oracle Databaseによって自動的に新しい状況に適した状態へ調整されます。
オプティマイザによって文の実行計画が決定されると、パラレル実行コーディネータでその計画に含まれる各操作をパラレル化する方法が決定されます。パラレル化の方法には、ブロック範囲による全表スキャンのパラレル化や、パーティションによる索引レンジ・スキャンのパラレル化などがあります。コーディネータでは、操作をパラレルに実行できるかどうかと、実行できる場合には関与するパラレル実行サーバーの数が、必ず決定されます。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で示されている問合せ計画で、パラレル実行サーバーのSS1およびSS2という2つのセットがある場合、実行は次のように進められます。問合せにおいてPARALLELヒントでDOPを指定することにより、各サーバー・セット（SS1およびSS2）に4つの実行プロセスが与えられます。つまり、パラレル実行サーバーの各セットに4つのプロセスを与えるため、指定するDOPを4とします。
まず、スレーブ・セットSS1で表employeesがスキャンされます。一方、SS2ではSS1から複数行をフェッチして、それらの行のハッシュ表を作成します。これはつまり、SS2内において親サーバーと子サーバーが同時に動作している状況といえます。一方がemployeesをパラレルでスキャンし、他方はSS1から送られる行を使用してハッシュ結合用のハッシュ表をパラレルで作成します。これが、インター・オペレーション並列化の例です。
SS1で表employees全体のスキャンが終了すると（すなわち、employeesのすべてのグラニュル（タスク単位）が使用されると）、SS1では表departmentsがパラレルでスキャンされます。SS1からSS2内のサーバーに行が送られると、SS2ではパラレルでプローブが実行されてハッシュ結合が完了します。SS1では、表departmentsのパラレル・スキャンおよびSS2への行の送信を終了すると、GROUP BY句のパラレル実行が開始されます。このようにして、2つのサーバー・セットを同時に実行し、問合せツリー内の各種演算子におけるインター・オペレーション並列化を実現する中で、各操作のパラレル実行によるイントラ・オペレーション並列化が実現されます。
パラレル実行でもう1つ重要なのは、あるサーバー・セット内のサーバーから別のサーバー・セットへ行が送られてきた場合、そうした行が再パーティション化されることです。図25-2の問合せ計画において、SS1内のサーバー・プロセスでemployeesの行がスキャンされた後、その行はSS2のどのサーバー・プロセスに送信されるのでしょうか。前述の図の問合せツリーに沿って上へ移動する行のパーティション化は、行の移動を行う演算子によって決定されます。この場合、SS1（employeesのパラレル・スキャンの実行担当）から送られる行について、SS2（パラレル・ハッシュ結合の実行担当）内でパーティション化を行う処理は、結合列の値に基づくハッシュ・パーティション化によって行われます。つまり、employeesのスキャンを担当するサーバー・プロセスでは、列employees.employee_idの値のハッシュ関数を計算することにより、送信先となるSS2内のサーバー・プロセスの数が決定されます。パラレル問合せで使用するパーティション化の方法は、問合せのEXPLAIN PLANに明示的に示します。実行サーバー・セット間で送られる行のパーティション化を、Oracle Databaseのパーティション化機能（ハッシュやレンジなどの方法による表のパーティション化）と混同しないようにしてください。
他の操作の出力を必要とする操作を、コンシューマ操作と呼びます。図25-2では、GROUP BY SORT操作が、HASH JOIN操作のコンシューマです。これは、GROUP BY SORTでHASH JOINの出力が必要とされるためです。
コンシューマ操作では、生成側の操作で行が生成された直後から行を使用（コンシューム）できるようになります。前述の例では、パラレル実行サーバーでFULL SCAN departmentsという操作によって行が生成されると同時に、別のパラレル実行サーバー・セットでHASH JOIN操作の実行を開始してその行を使用できます。
同時に実行されている2つの操作には、それぞれ専用のパラレル実行サーバー・セットが割り当てられます。したがって、問合せ操作とデータ・フロー・ツリー自体の両方で並列化が実現します。個々の操作の並列化はイントラ・オペレーション並列化と呼ばれ、データ・フロー・ツリーにおける操作間の並列化はインター・オペレーション並列化と呼ばれます。Oracle Databaseにおける操作には生成側とコンシューマという性質があるため、特定のツリー内では操作を2つ同時に実行しさえすれば、実行時間を最短に抑えることができます。イントラ・オペレーション並列化とインター・オペレーション並列化を理解するために、次の文について考えてみます。
SELECT * FROM employees ORDER BY last_name;
この実行計画にはemployees表の全体スキャンが実装されています。この操作に続いて、取り出された行がlast_name列の値に基づいてソートされます。この例では、last_name列には索引が付いていないものとします。また、問合せのDOPは4に設定されているとします。これは、所定のどの操作に対しても、4つのパラレル実行サーバーをアクティブにできるという意味になります。
図25-3に、この問合せ例のパラレル実行を示します。
図25-3からわかるように、DOPが4であっても、実際には8つのパラレル実行サーバーが問合せに関与しています。これは、親演算子と子演算子を同時に実行できるためです（インター・オペレーション並列化）。
また、スキャン操作に関与するすべてのパラレル実行サーバーからは、SORT操作を実行する適切なパラレル実行サーバーに、行が送信されることに注意が必要です。パラレル実行サーバーによりスキャンされる行には、A〜Gのlast_name列の値が含まれ、その行が最初のORDER BYのパラレル実行サーバーに送信されます。スキャン操作が完了した時点で、ソート・プロセスではソート結果をコーディネータへ戻すことが可能になり、その結果、コーディネータでユーザーに対し完全な問合せ結果が戻されます。
様々なパラレル操作で、様々なタイプのパラレル化が使用されます。最適な物理データベース・レイアウトは、アプリケーションで最も一般的なパラレル操作や、パーティションを使用する必要があるかどうかによって異なります。
パラレル化の基本処理単位はグラニュルと呼ばれます。パラレル化された操作（表スキャン、表の更新または索引の作成など）は、Oracle Databaseによってグラニュルに分割されます。パラレル実行処理では、一度に1グラニュルの操作が実行されます。グラニュルの数とサイズは、並列度（DOP）と相互に関連します。また、問合せサーバー・プロセス間での動作の均衡化にも影響します。Oracle Databaseではこの決定が内部的に行われるので、ユーザー側で特定のグラニュル方針を指定する方法はありません。
ブロック範囲グラニュルは、ほとんどのパラレル操作の基本単位で、これはパーティション表においても同様です。つまり、Oracle Databaseでは、並列度はパーティションの数とは関連しません。
ブロック範囲グラニュルは、表の物理ブロックの範囲です。グラニュルの数とサイズはOracle Databaseにより実行時に計算され、これによって、影響を受けるすべてのパラレル実行サーバーの作業分散が最適化され、均衡化されます。グラニュルの数とサイズは、オブジェクトのサイズとDOPによって決まります。ブロック範囲グラニュルは、表または索引の静的な事前割当てには依存しません。グラニュルの計算時には、競合をできるかぎり回避するために、DOPを考慮して様々なデータファイルから各パラレル実行サーバーにグラニュルが割り当てられます。また、MPPシステムでは、グラニュルのディスク・アフィニティが考慮され、パラレル実行サーバーとディスクの間の物理的な近さが活用されます。
ブロック範囲グラニュルが、表または索引へのパラレル・アクセスで優先的に使用されている場合、パフォーマンス上の考慮点よりも、管理上の考慮点（リカバリや、データの部分削除へのパーティションの使用など）がパーティション・レイアウトに影響を与えることがあります。
パーティション・グラニュルが使用されると、問合せサーバー・プロセスでは、表または索引のパーティション全体またはサブパーティション全体に対する処理が行われます。パーティション・グラニュルは表または索引の作成時にその構造によって静的に決定されるため、ブロック範囲グラニュルほど柔軟に操作をパラレル化できるわけではありません。最大許容DOPは、パーティションの数となります。このため、システムの使用率やパラレル実行サーバー間のロード・バランシングが制限される場合があります。
パーティション・グラニュルが表または索引に対するパラレル・アクセスに使用される場合、問合せサーバー・プロセス間で作業が効率的に均衡化されるように、比較的多数のパーティション（理想的にはDOPの3倍）を使用する必要があります。
パーティション・グラニュルを基本単位とする操作には、パラレル索引レンジ・スキャン、2つの同一レベル・パーティション表間の結合（問合せオプティマイザによってパーティション・ワイズ結合の使用が選択されている場合）、およびパーティション・オブジェクトの複数パーティションを変更するパラレル操作があります。これらの操作には、パーティション索引のパラレル作成およびパーティション表のパラレル作成が含まれます。
この項では、次のタイプのパラレル化について説明します。
SELECT文での問合せと副問合せをパラレル化できます。また、DDL文とDML文の問合せ部分（INSERT、UPDATEおよびDELETE）もパラレル化できます。外部表の問合せをパラレルで実行することも可能です。
|
関連項目:
|
索引構成表では、次のパラレル・スキャン方法がサポートされます。
非パーティション索引構成表のパラレル高速全スキャン
パーティション索引構成表のパラレル高速全スキャン
パーティション索引構成表のパラレル索引レンジ・スキャン
これらのスキャン方法は、オーバーフロー領域を持つ索引構成表と、LOBを含む索引構成表に使用できます。
非パーティション索引構成表のパラレル問合せには、パラレル高速全スキャンが使用されます。DOPは、次のように優先順位の降順で決定されます。
PARALLELヒント（存在する場合）
ALTER SESSION FORCE PARALLEL QUERY文
CREATE TABLEまたはALTER TABLE文で並列度が指定されている場合は、表に対応付けられている並列度
作業の割当ては、索引セグメントを十分な数のブロック範囲に分割し、そのブロック範囲を必要に応じてパラレル実行サーバーに割り当てるという方法で行われます。行に対応するオーバーフロー・ブロックは、必要に応じて、その行を所有するプロセスからのみアクセスされます。
索引レンジ・スキャンと高速全スキャンの両方をパラレルに実行できます。パラレル高速全スキャンの場合、非パーティション索引構成表の場合とまったく同じ方法でパラレル化されます。パーティション索引構成表におけるパラレル索引レンジ・スキャンの場合、DOPは、前述の優先順位リストから選択された最小並列度（パラレル高速全スキャンと同様）と、索引構成表のパーティション数になります。各パラレル実行サーバーには、DOPに応じて1つ以上の（必要に応じて割り当てられた）パーティションが与えられます。各パーティションには、主キー索引セグメントと、（存在する場合には）対応するオーバーフロー・セグメントが用意されます。
パラレル問合せは、オブジェクト型の表やオブジェクト型の列を含む表に対して実行できます。オブジェクト型のパラレル問合せでは、オブジェクト型に対する順次問合せに使用できる次の機能がすべてサポートされます。
オブジェクト型のメソッド
オブジェクト型の属性アクセス
オブジェクト型のインスタンスを作成するコンストラクタ
オブジェクト・ビュー
オブジェクト型のPL/SQL問合せとOCI問合せ
パラレル問合せにおいて、オブジェクト型のサイズに制限はありません。
オブジェクト型に対してパラレル問合せを使用する場合、次の制限が適用されます。
結合とソート（ORDER BY、GROUP BYまたは集合演算）を伴う問合せをパラレル化するには、MAP関数が必要です。MAP関数がない場合、問合せは自動的にシリアル実行されます。
オブジェクト型ではパラレルDMLとパラレルDDLはサポートされません。DML文とDDL文は、常にシリアルに実行されます。
このいずれかの制限のために問合せをパラレルに実行できない場合は、問合せ全体がシリアルに実行され、エラー・メッセージは戻されません。
この項では、次のトピックでDDL文のパラレル化について説明します。
表および索引に対するDDL文は、対象とする表や索引がパーティション化されているかどうかにかかわらず、パラレル化できます。DDL文でパラレル化可能な操作については、表25-3に概要があります。
非パーティション表および索引に対するパラレル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列を持つ非パーティション表に対しては実行できません。
パフォーマンス上の理由から、意思決定支援アプリケーションでは多くの場合、非定型の意思決定支援用の問合せで使用できるように、大量のデータを小さな表にサマリーするかロールアップする必要があります。ロールアップは、システムがアクティブでない時間に定期的（毎晩、週次など）に短時間で実行されます。
パラレル実行によって、問合せをパラレル化し、別の表または表セットからの表の作成操作を副問合せとして作成できます。
クラスタ化表の作成と移入は、パラレルには実行できません。
図25-4に、表を副問合せからパラレルに作成する方法を示します。
サマリー表のデータが他の表のデータから導出される場合、小さなサマリー表に関するメディア障害からのリカバリ能力は重要ではなく、サマリー表の作成中はオフにできます。
パラレル表作成（または他のパラレルDDL操作）中にロギングを無効にする場合は、メディア障害により表が失われないように、表の作成後にその表を含む表領域のバックアップを作成する必要があります。
UNDOログとREDOログの生成を無効にするには、CREATE TABLE、CREATE INDEX、ALTER TABLEおよびALTER INDEX文でNOLOGGING句を使用します。
表または索引をパラレルに作成する場合、各パラレル実行サーバーではCREATE文のSTORAGE句の値を使用して、行の格納用に一時セグメントが作成されます。そのため、表のNEXTを5MB、PARALLEL DEGREEを12に設定して作成する場合、各プロセスが5MBのエクステントで開始するため、表の作成中には60MB以上の記憶域が消費されます。パラレル実行コーディネータでセグメントが組み合せられた時点で、一部のセグメントが削除されることがあるので、作成される表は指定した60MBよりも小さくなる場合があります。
索引や表をパラレルに作成する場合は、各パラレル実行サーバーによって新規にエクステントが割り当てられ、そのエクステントに表または索引のデータが格納されます。したがって、DOPを3として索引を作成した場合、その索引のエクステント数の初期値は3以上となります。エクステントの割当て方法は、索引をパラレルで再作成する場合や、パーティションをパラレルで移動、分割または再作成する場合と同様です。
シリアル操作では、スキーマ・オブジェクトに1つ以上のエクステントが必要です。パラレル作成の場合、表または索引には、スキーマ・オブジェクトを作成するパラレル実行サーバーと同数以上のエクステントが必要です。
表または索引をパラレルに作成する場合、空き領域のポケットが作成される、つまり、外部断片化または内部断片化が発生する可能性があります。これが発生するのは、パラレル実行サーバーで使用される一時セグメントが、行の格納に必要なサイズよりも大きい場合です。
各一時セグメントの未使用領域が、表領域レベルで設定されたMINIMUM EXTENTパラメータの値よりも大きい場合、Oracle Databaseですべての一時セグメントの行を表または索引にマージする際に、そうした未使用領域が切り捨てられます。未使用領域はシステムの空き領域に戻されるので、新規エクステントに割り当てることが可能ですが、連続する領域ではないため（外部断片化）、より大きなセグメントになるように結合することはできません。
各一時セグメントの未使用領域がMINIMUM EXTENTパラメータの値よりも小さい場合、一時セグメントの行がマージされる際に未使用領域の切り捨ては行われません。この未使用領域はシステムの空き領域に戻されず、表または索引の一部となり（内部断片化）、その後の挿入や更新で追加領域が必要とされる場合にのみ使用可能となります。
たとえば、CREATE TABLE ... AS SELECT文にDOPとして3を指定しても、表領域にデータファイルが1つしかないと、図25-5のように内部断片化が発生する可能性があります。データファイルの内部表のエクステント内にある空き領域のポケットは、他の空き領域と結合できず、エクステントとして割り当てることもできません。
表と索引をパラレルに作成する方法の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。
パラレルDML（PARALLEL INSERT、UPDATE、DELETEおよびMERGE）では、大きなデータベース表や索引に対する大規模な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データベースに対する問合せと更新が可能になり、こうした機能でパラレル問合せを補完できます。
パラレル化の設定に伴うオーバーヘッドのため、パラレルDML操作は短時間のOLTPトランザクションには適用できません。ただし、OLTPデータベースで実行されるバッチ・ジョブについては、パラレルDML操作によるスピードアップが可能です。
次に、パラレルDMLの使用例を示します。
データ・ウェアハウス・システムでは、大きな表を本番システムの新規データまたは変更済データで定期的にリフレッシュ（更新）する必要があります。パラレルDMLと更新可能な結合ビューを併用すると、この作業を効率的に行うことができます。また、MERGE文も使用できます。
リフレッシュを必要とするデータは、通常であれば、リフレッシュ・プロセスの開始前に一時表にロードされます。この表には、新しい行またはデータ・ウェアハウスの最後のリフレッシュ後に更新された行のいずれかが格納されます。更新された行は、更新可能な結合ビューとパラレルUPDATEを併用してリフレッシュできます。新しい行は、逆ハッシュ結合とパラレルINSERTを併用してリフレッシュできます。
DSS環境では、多くのアプリケーションにおいて、多数の大規模な中間サマリー表の構成や操作を伴う複雑な計算が必要とされます。こうしたサマリー表は、ほとんどの場合には一時表なので、頻繁にログに記録する必要はありません。パラレルDMLを使用すると、このような大規模な中間表に対する操作をスピードアップできます。その結果、中間結果を中間表に格納してパラレル更新を実行できるというメリットが得られます。
また、サマリー表には、アプリケーション・セッション後も持続する必要がある累積情報や比較情報が格納されることがあり、このような場合、一時表は使用できません。パラレルDML操作を使用すると、このような大規模なサマリー表に対する変更をスピードアップできます。
多くのDSSアプリケーションでは、一連の基準に基づいて顧客が定期的にスコアリングされます。スコアリングは、通常の場合、大規模なDSS表に格納されます。このスコアリング情報は、メーリング・リストに含めるかどうかなどの意思決定に利用されます。
このスコアリング・アクティビティでは、大規模な表内の多数の行に対して問合せや更新が行われます。パラレルDMLを使用すると、このような大規模な表に対する操作をスピードアップできます。
履歴表には、最新の時間間隔における企業のビジネス・トランザクションが記述されます。データベース管理者は定期的に、最も古い行セットを削除し、新しい行セットを表に挿入します。パラレルINSERT ... SELECT操作およびパラレルDELETE操作により、このロールオーバー・タスクをスピードアップできます。
パラレル・ダイレクト・ローダー（SQL*Loader）を使用しても外部ソースから大量のデータを挿入できますが、データベース内の別の表に存在するデータを挿入する場合は、パラレルINSERT ... SELECTを使用した方が高速です。
古い行の削除には、パーティションの削除を利用することもできます。ただし、この方法では、適切な時間間隔を指定して、表を日付でパーティション化する必要があります。
DML文をパラレル化できるのは、そのセッションにおいてパラレルDMLを明示的に有効化している場合のみです。明示的に有効化するには、ALTER SESSION文でENABLE PARALLEL DML句を使用します。このモードにする必要があるのは、パラレルDMLとシリアルDMLではロック、トランザクションおよびディスク領域の要件が異なるためです。
セッションのデフォルトのモードはDISABLE PARALLEL DMLです。パラレルDMLが無効になっていると、PARALLELヒントを使用しても、DMLはパラレルには実行されません。
パラレルDMLがあるセッションで有効になっている場合、このセッション中のすべてのDML文はパラレル実行の対象とみなされます。ただし、パラレルDMLが有効になっていても、パラレル・ヒントがない場合や、パラレル属性を持つ表がない場合、またはパラレル操作の制限に違反する場合は、DML操作がシリアルに実行されることがあります。
セッションのPARALLEL DMLモードは、SELECT文、DDL文およびDML文の問合せ部分のパラレル化には影響しません。つまり、このモードが設定されていなければ、DML操作はパラレル化されませんが、DML文中でのスキャン操作や結合操作はパラレル化される場合があります。
DML操作のパラレル実行においては、パラレル実行コーディネータで一連のパラレル実行サーバーが取得または起動され、各パラレル実行サーバーはそれぞれのパラレル・プロセス・トランザクションで作業の一部分を実行します。
各パラレル実行サーバーで、それぞれ異なるパラレル・プロセス・トランザクションが作成されます。
自動UNDO管理のかわりにロールバック・セグメントを使用する場合、ロールバック・セグメントにおける競合を軽減する必要が生じる場合があります。このためには、同一のロールバック・セグメントに属するパラレル・プロセス・トランザクションを少数にする必要があります。詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
また、コーディネータにも独自のコーディネータ・トランザクションがあり、独自のロールバック・セグメントを持つことができます。ユーザー・レベルのトランザクションの原子性を保証するために、コーディネータでは2フェーズ・コミット・プロトコルを使用して、パラレル・プロセス・トランザクションにより実行された変更をコミットします。
パラレルDMLが有効になっているセッションでは、セッション中に特定のモードでトランザクションを利用できます。トランザクション内のDML文により表がパラレルに変更されると、そのトランザクション中に後続のシリアル問合せ、パラレル問合せまたはDML文から、その表に対する再アクセスはできません。つまり、トランザクション中には、パラレル変更の結果を確認できません。
パラレルに変更された表に対して、同一トランザクション中にアクセスを試行したシリアル文やパラレル文は拒否され、エラー・メッセージが戻されます。
パラレルDMLが有効になっているセッションでPL/SQLプロシージャまたはブロックが実行されると、そのプロシージャまたはブロック内の文には、この規則が適用されます。
自動UNDO管理機能のかわりにロールバック・セグメントを使用する場合、パラレルDMLを使用する際にいくつかの制限があります。パラレルDMLおよびロールバック・セグメントの制限については、『Oracle Database SQL言語リファレンス』を参照してください。
パラレルDML操作のロールバック所要時間は、ロールフォワード操作の所要時間とほぼ同じです。
Oracle Databaseでは、トランザクションおよびプロセス障害後と、インスタンスおよびシステム障害後のパラレル・ロールバックがサポートされます。また、トランザクション・リカバリのロールフォワード段階とロールバック段階をパラレル化できます。
パラレル・ロールバックの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
文のエラーによるトランザクション障害中にユーザーが発行したロールバックは、パラレル実行コーディネータおよびパラレル実行サーバーによりパラレルに実行されます。このロールバックの所要時間は、ロールフォワード・トランザクションの場合とほぼ同じです。
パラレルUPDATEでは既存のオブジェクトの領域が使用されますが、ダイレクト・パス・インサートではデータ用に新規のセグメントが取得されます。
複数の同時の子トランザクションでオブジェクトが変更されるため、パラレル実行と順次実行では領域使用特性が異なる場合があります。
パラレルDML操作のロックの要件は、シリアルDML操作の場合の要件とは大きく異なります。パラレルDMLでは、より多くのロックを保持するためにDML_LOCKSパラメータの開始値を増やす必要があります。詳細は、「DML_LOCKS」を参照してください。
パラレルDML（ダイレクト・パス・インサートを含む）には、次の制限が適用されます。
UPDATE、MERGEおよびDELETEの各操作に対してパーティション内並列性を実現するには、COMPATIBLE初期化パラメータを9.2以上に設定する必要があります。
INSERT VALUES文はパラレル化されません。
トランザクションには、様々な表を変更する複数のパラレルDML文を含めることができますが、パラレルDML文により表が変更されると、後続のシリアル文やパラレル文（DMLまたは問合せ）では、その表に対してそのトランザクション中には再度アクセスできません。
この制限は、シリアルのダイレクト・パス・インサート文の後にも適用され、後続のSQL文（DMLや問合せ）は、そのトランザクション中には変更された表に対してアクセスできません。
同じ表にアクセスする問合せは、パラレルDML文またはダイレクト・パス・インサート文の前には許されますが、これらの文の後には許されません。
パラレルUPDATE、DELETE、MERGEまたはダイレクト・パス・インサートで変更済の表に対して、同じトランザクション中にアクセスを試行するシリアル文またはパラレル文は拒否され、エラー・メッセージが戻されます。
パラレルDMLは、自己参照型整合性、削除カスケード、遅延整合性など、特定の制約がある場合には実行できません。また、ダイレクト・パス・インサートの場合、参照整合性はサポートされません。
LOB列を持つ表に対するパラレルDMLは、その表がパーティション化されていれば実行できます。ただし、パーティション内並列性はサポートされません。
パラレルDML操作に関与するトランザクションは、分散トランザクションにはできません。
クラスタ化表はサポートされません。
パラレルのUPDATE、DELETEおよびMERGE操作は、一時表ではサポートされません。
これらの制限に違反すると、文はシリアルに実行され、警告やエラー・メッセージは戻されません（ただし、トランザクション中に同じ表にアクセスする文の制限については、エラー・メッセージが戻されることがあります）。たとえば、非パーティション表での更新はシリアル化されます。
この項では、整合性制約とパラレルDML文の相互作用について説明します。
参照整合性に関する制限が発生するのは、ある表に対するDML操作により、別の表に対する再帰的なDML操作が発生する場合です。また、この種の制限は、整合性チェックを実行するために、変更対象のオブジェクトに対するすべての変更を同時に参照する必要がある場合にも適用されます。
表25-1に、参照整合性制約に関与する表に対して実行可能なすべての操作を示します。
操作の影響を受ける表で、その文の結果により起動される可能性のあるトリガーが有効になっている場合、そのDML操作はパラレル化されません。このため、レプリケート対象の表に対するDML文もパラレル化されません。
このような表に対するDMLをパラレル化するには、関連トリガーを無効にする必要があります。トリガーの有効化や無効化を行うと、従属する共有カーソルが無効になるので注意してください。
この項では、分散トランザクション処理の例をいくつか紹介します。
例25-1 分散トランザクションのパラレル化
この例では、DML文を使用してリモート・オブジェクトを問い合せています。
INSERT /* APPEND PARALLEL (t3,2) */ INTO t3 SELECT * FROM t4@dblink;
この問合せ操作は、リモート・オブジェクトを参照しているため、通知なしでシリアルに実行されます。
SQL文には、PL/SQLやJavaで記述されたユーザー定義関数や、SELECT構文のリスト、SET句またはWHERE句の一部として使用できるC言語の外部プロシージャとして記述されたユーザー定義関数を含めることができます。こうした関数は、SQL文がパラレル化されると、パラレル実行サーバーにより行ごとに実行されます。関数で使用されるPL/SQLパッケージ変数やJavaの静的属性は、個々のパラレル実行プロセスで完全にプライベートであり、元のセッションからコピーされるのではなく、各行が処理されるときに新しく初期化されます。このため、パラレルに実行すると、適切な結果が生成されない関数もあります。
ユーザーが記述したテーブル・ファンクションを、文のFROMリストで使用できます。この種の関数は、行を出力するという点でソース・テーブルと同様に動作します。テーブル・ファンクションは、各パラレル実行プロセスの開始時に文中で一度初期化されます。変数はすべてパラレル実行プロセスで完全にプライベートです。
SELECT文、またはDML文やDDL文中の副問合せにおいて、ユーザーが記述した関数をパラレルに実行できるのは、PARALLEL_ENABLEキーワードを伴って宣言されている場合の他、パッケージまたは型で宣言され、WNDS、RNPSおよびWNPSがすべて記述されたPRAGMA RESTRICT_REFERENCESがある場合、またはCREATE FUNCTIONを伴って宣言され、システムでPL/SQLコードの本文を解析した結果、そのコードがデータベースへの書込みでもパッケージ変数の読取りや変更でもないことを確定できる場合です。
問合せまたは副問合せの他の部分については、特定の関数をシリアルのまま実行する必要がある場合にも、パラレルに実行される可能性があります。
PRAGMA RESTRICT_REFERENCESの詳細は『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を、CREATE FUNCTIONの詳細は『Oracle Database SQL言語リファレンス』を参照してください。
パラレルDML文やパラレルDDL文中において、パラレル問合せとしてユーザーが記述した関数をパラレルに実行できるのは、PARALLEL_ENABLEキーワードを伴って宣言されている場合の他、パッケージまたは型で宣言され、RNDS、WNDS、RNPSおよびWNPSがすべて記述されたPRAGMA RESTRICT_REFERENCESがある場合、または、CREATE FUNCTIONを伴って宣言され、システムでPL/SQLコードの本文を解析した結果、そのコードがデータベースの読み書きやパッケージ変数の読取り、変更のいずれでもないことを確定できる場合です。
パラレルDML文の場合は、パラレルに実行できない関数コールがあると、DML文全体がシリアルに実行されます。
INSERT ... SELECTまたはCREATE TABLE ... AS SELECT文の場合、問合せ部分の関数コールは、前述したパラレル問合せの規則に従ってパラレル化されます。問合せは、文の残りの部分をシリアルに実行する必要がある場合にも、パラレルに実行される可能性があり、その逆も同様です。
Oracle Databaseでは、パラレルSQL実行に加えて、次のタイプの操作もパラレル化できます。
パラレル・リカバリ
パラレル伝播（レプリケーション）
パラレル・ロード（SQL*Loaderユーティリティ）
パラレルSQLと同様に、パラレル・リカバリおよびパラレル伝播も、1つのパラレル実行コーディネータと複数のパラレル実行サーバーにより実行されます。一方、パラレル・ロードでは別のメカニズムが使用されます。
パラレル実行コーディネータおよびパラレル実行サーバーの動作は、実行する操作の種類（SQL、リカバリまたは伝播）に応じて変わります。たとえば、プール内のすべてのパラレル実行サーバーが占有され、最大数のパラレル実行サーバーが起動されている場合の動作は次のようになります。
パラレルSQLの場合は、パラレル実行コーディネータによってシリアル処理に切り替えられます。
パラレル伝播の場合は、パラレル実行コーディネータによってエラーが戻されます。
特定のセッションにおいて、パラレル実行コーディネータで調整されるのは1種類の操作のみです。たとえば、パラレル実行コーディネータで、パラレルSQLとパラレル・リカバリやパラレル伝播の同時調整はできません。
|
関連項目:
|
パラレル実行はデフォルトで有効になっています。一連のパラレル実行パラメータの初期計算値は、ほとんどのインストールに対応しています。この種のパラメータは、パラレル操作で使用するメモリーの使用量と並列度に影響を与えます。
この種のパラメータについては、Oracle Databaseにより、データベース起動時のCPU_COUNTおよびPARALLEL_THREADS_PER_CPUの値に基づいてデフォルトが計算されます。特定のシステム構成または目的のパフォーマンスに合うように、値を手動で増減してチューニングすることもできます。次に例を示します。
パラレル実行を使用しないシステムでは、PARALLEL_MAX_SERVERSを0（ゼロ）に設定できます。
十分なSGAメモリーがある大規模システムでは、PARALLEL_EXECUTION_MESSAGE_SIZEを増やしてスループットを向上できます。
パラレル実行パラメータは手動でもチューニングできますが、パラレル実行のデフォルト設定を使用することをお薦めします。パラレル実行の手動チューニングでは、自動チューニングの場合よりも慎重な管理が必要とされ、ユーザーによるロードやシステム・リソースの計算を誤る確率も高くなるので、デフォルト設定を使用する場合に比べて複雑な作業が発生します。
パラレル実行の初期化およびチューニングは、次の手順で行われます。
デフォルトでは、パラレル実行パラメータは、自動的に表25-2のように設定されます。ほとんどのシステムでは、適切にチューニングされたパラレル実行環境が実現されるため、これ以上の調整を行う必要はありません。
| パラメータ | デフォルト | コメント |
|---|---|---|
|
|
|
パラレル実行SQLによりDOPリクエストの数を制限し、システムのオーバーロードを防止する。 |
|
|
|
1つのインスタンスに対するパラレル実行プロセスおよびパラレル・リカバリ・プロセスの最大数を指定する。必要なプロセス数が増えるにつれて、インスタンス起動時に作成されたプロセス数からこの値までプロセス数が増加する。 このパラメータの設定値が小さすぎると、一部の問合せ処理でパラレル実行プロセスを使用できないことがある。また、設定値が大きすぎると、場合によっては処理量のピーク時にメモリー・リソースが不足し、パフォーマンスの低下につながる。
|
|
|
2KB（ポート固有） |
4KBまたは8KBに増やすと、SGAメモリーが十分にある場合にパラレル実行のパフォーマンスが向上する。 |
一部のパラメータでは、設定によってOracle Databaseが制約を受けることがあるので注意してください。たとえば、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 Databaseでは、パラレル実行に伴うリソース使用率に対処できるように、次の方法が用意されています。
マルチユーザー問合せ調整アルゴリズム。システム負荷が増大するにつれてDOPを低下させます。デフォルトでは、マルチユーザー問合せ調整アルゴリズムが有効になっており、同時発生するパラレルのSQL実行操作に合せてシステムのパフォーマンスが最適化されます。
ユーザー・リソース制限およびプロファイル。各ユーザーが使用可能な各種システム・リソースの量に対する制限を、ユーザーのセキュリティ・ドメインの一部として設定できます。
データベース・リソース・マネージャ。様々なユーザー・グループにリソースを割り当てることができます。
DOPは、パラレル実行コーディネータで複数の指定を検討することにより決定されます。コーディネータでは次の指定内容が検討されます。
SQL文自体に指定されているヒントまたはPARALLEL句のチェック
ALTER SESSION FORCE PARALLEL文に設定されたセッション値のチェック
表または索引の定義の参照
いずれかの指定にDOPが見つかると、それが操作のDOPになります。
ヒント、PARALLEL句、表または索引の定義およびデフォルト値では、コーディネータで特定の操作について要求されるパラレル実行サーバーの数のみが決まります。実際に使用されるパラレル実行サーバーの数は、パラレル実行サーバー・プール内で使用可能なプロセス数と、インター・オペレーション並列化があり得るかどうかに応じて変わります。
SQL文にヒントを指定すると、表や索引に対するDOPと操作のキャッシング動作に対するDOPを設定できます。
PARALLELヒントは、表を対象とした操作にのみ使用します。また、問合せおよびDML文（INSERT、UPDATE、MERGE、DELETE）のパラレル化にも使用できます。
PARALLEL_INDEXヒントでは、パーティション索引の索引レンジ・スキャンをパラレル化できます（索引操作の場合、PARALLELヒントは無効であり、無視されます）。
SQL文でヒントを使用する方法と、PARALLEL、NO_PARALLEL、PARALLEL_INDEX、CACHEおよびNOCACHEヒントの特定の構文については、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。
デフォルトのDOPが使用されるのは、操作のパラレル化を要求した際に、ヒント、表の定義または索引の定義でDOPを指定していない場合です。デフォルトのDOPはほとんどのアプリケーションに適しています。
SQL文のデフォルトのDOPは、次の要因により決定されます。
CPU_COUNTパラメータの値（デフォルトではシステムのCPU数）、Oracle Real Application Clusters（RAC）のインスタンス数、およびPARALLEL_THREADS_PER_CPUパラメータの値。
パーティションによるパラレル化の場合は、パーティション・プルーニングに基づく、アクセスされるパーティションの数。
グローバル索引のメンテナンスを伴うパラレルDML操作の場合は、更新対象となるすべてのグローバル索引間のトランザクション空きリストの最小数。パーティション・グローバル索引のトランザクション空きリストの最小数は、すべての索引パーティションにわたっての最小数です。これは、自己デッドロックを防ぐための要件です。
これらの要因により、使用するパラレル実行サーバーのデフォルトの数が決まります。ただし、実際に使用されるプロセス数は、実行時の要求側インスタンス上での可用性により制限されます。1つのインスタンスで保持できるパラレル実行サーバーの総数については、初期化パラメータPARALLEL_MAX_SERVERSで上限値が設定されます。
必要な最小数（初期化パラメータPARALLEL_MIN_PERCENTで指定）のパラレル実行サーバーが使用できない場合は、ユーザー・エラーが生成されます。システムがそれほどビジーでない場合は、問合せを再試行できます。
パラレル実行コーディネータでは、マルチユーザー問合せ調整アルゴリズムを使用して、システム負荷に応じたDOPの変更が行われます。システム負荷は、アクティブなOracle Databaseプロセス数を計算することで判断されます。現在割り当てられているサーバー・プロセス数が、使用可能なCPU数において最適なサーバー・プロセス数よりも多いと、アルゴリズムによりDOPが低下します。これにより、リソースの過剰割当てが回避され、システム全体のスループットが向上します。
Oracle Databaseでは、少なくとも2つのパラレル実行サーバーが使用可能であれば、操作をパラレルに実行できます。使用可能なパラレル実行サーバーが少なすぎると、SQL文の実行が予想より低速になる場合があります。要求されるパラレル実行サーバーのうち、操作を実行するために使用可能になっていなければならないサーバーの最小パーセンテージを指定できます。この方法により、SQL文が確実に最小許容範囲内のパラレル・パフォーマンスで実行されるようになります。要求されたパラレル実行サーバーのうち最小パーセンテージのサーバーが使用可能でなければ、SQL文は実行されず、エラー「ORA-12827」が戻されます。
要求されるパラレル実行サーバーに望ましい最小パーセンテージは、初期化パラメータPARALLEL_MIN_PERCENTで指定します。このパラメータは、DML操作、DDL操作および問合せに影響します。
たとえば、このパラメータに50を指定すると、パラレル操作が成功するには、その操作用に要求されたパラレル実行サーバー数のうち50パーセント以上が使用可能である必要があります。20のパラレル実行サーバーが要求された場合は、10以上が使用可能でなければ、エラーがユーザーに戻されます。PARALLEL_MIN_PERCENTをNULLに設定すると、すべてのパラレル操作は、少なくとも2つのパラレル実行サーバーが使用可能な場合にのみ処理されます。
パフォーマンスを最適にするには、すべてのパラレル実行サーバーのワークロードを均等にする必要があります。ブロック範囲またはパラレル実行サーバーによりパラレル化されたSQL文の場合、ワークロードはパラレル実行サーバー間で動的に分割されます。これによって、一部のパラレル実行サーバーで他のプロセスを大幅に上回る処理が実行される場合に発生する、ワークロードの偏りが最小限に抑えられます。
パーティションでパラレル化される比較的少数のSQL文の場合は、ワークロードがパーティション間で均等に分散されていれば、パラレル実行サーバー数をパーティション数と一致させるか、パーティション数がプロセス数の倍数になるようにDOPを選択すると、パフォーマンスを最適化できます。これは、Oracle9iより前のデータベースで作成された表に対するパーティション・ワイズ結合およびPDMLに適用されます。詳細は、「並列度の制限事項」を参照してください。
たとえば、表に10のパーティションがあり、パラレル操作の処理がパーティション間で均等に分割されるとします。10のパラレル実行サーバー（DOP = 10）を使用すると、単一プロセスの場合にかかる時間の約10分の1で処理を実行できます。また、5つのプロセスを使用すると処理時間は5分の1、2つのプロセスを使用すると2分の1になります。
ただし、9のプロセスを使用して10のパーティションに対して作業すると、最初のプロセスが1つのパーティションに対する作業を完了してから、10番目のパーティションに対する作業を開始します。また、他のプロセスは処理を完了するとアイドル状態になります。このような構成では、処理がパーティション間で均等に分割されていると高パフォーマンスは得られません。処理が不均等に分割されている場合は、最後まで残っているパーティションに対する作業量が他のパーティションに対する作業量より多いか少ないかに応じて、パフォーマンスが変動します。
同様に、4つのプロセスを使用して10のパーティションに対して作業し、処理が均等に分割されるとします。この場合、各プロセスが最初のパーティションを完了してから2つ目のパーティションに対する処理を行いますが、プロセスのうち2つは3つ目のパーティションに対する処理も行い、残りの2つはアイドル状態となります。
通常、特定数のパラレル実行サーバー（P）で特定数のパーティション（N）に対するパラレル操作を実行するための所要時間が、N/Pになるとは想定できません。この計算式では、一部のプロセスが最後のパーティションでの作業を完了するまで、他のプロセスが待機する必要がある場合が考慮されていません。ただし、適切なDOPを選択すると、ワークロードの偏りを最小限に抑えてパフォーマンスを最適化できます。
SQL文をパラレル化できるのは、パラレル・ヒントが指定されているか、操作対象となる表または索引がCREATEまたはALTER文でPARALLELを使用して宣言されている場合です。また、DDL文は、PARALLEL句を使用してパラレル化できます。ただし、こうした方法がすべて、あらゆるタイプのSQL文に適用されるわけではありません。
パラレル化は、パラレル化の判断およびDOPという2つの要素からなっています。この2つの要素の決定方法は、問合せ、DDL操作およびDML操作でそれぞれ異なります。
Oracle Databaseでは、DOPを決定するために次の参照オブジェクトが参照されます。
パラレル問合せでは、パラレル化する問合せの部分で各表と索引が参照され、いずれが参照表であるかが判断されます。原則として、最も大きなDOPが指定された表または索引が選択されます。
パラレルDML（INSERT、UPDATE、MERGEおよびDELETE）の場合、DOPを決定する参照オブジェクトは、挿入、更新または削除操作による変更対象となる表です。また、パラレルDMLでは、デッドロックを回避するためにDOPにある程度の制限も付加されます。つまり、パラレルDML文に副問合せが指定されている場合、その副問合せのDOPはDML操作の場合と同じになります。
パラレルDDLの場合、DOPを決定する参照オブジェクトは、作成、再作成、分割または移動される表、索引またはパーティションです。パラレルDDL文に副問合せが指定されている場合、その副問合せのDOPはDDL操作の場合と同じになります。
この項では、問合せのパラレル化ルールをいくつか説明します。
SELECT文をパラレル化できるのは、次の条件が満たされる場合に限られます。
問合せにパラレル・ヒント指定（PARALLELまたはPARALLEL_INDEX）が含まれているか、問合せで参照されるスキーマ・オブジェクトにPARALLEL宣言が対応付けられている場合
問合せで指定されている1つ以上の表に対して、次のいずれかが必要とされる場合
全表スキャン
複数のパーティションにまたがる索引レンジ・スキャン
SELECT構文のリストにスカラー副問合せがない場合
問合せのDOPは、次のルールにより決定されます。
問合せでは、問合せに関与するすべての表宣言と、問合せの回答を得られる可能性があるすべての索引（参照オブジェクト）に指定されているDOPのうち、最大のDOPが使用されます。つまり、最大のDOPが指定されている表または索引によって、その問合せのDOP（最大問合せディレクティブ）が決まります。
表に対する問合せにパラレル・ヒント指定があり、かつ、その表指定にパラレル宣言がある場合は、ヒント指定がパラレル宣言指定より優先されます。優先順位ルールについては、表25-3を参照してください。
UPDATE、MERGEおよびDELETE操作は、パーティションまたはサブパーティションでパラレル化されます。これらの操作はパーティション内部または非パーティション表ではパラレル化できません。適用される制限事項については、「並列度の制限事項」を参照してください。
UPDATE、MERGEおよびDELETE操作のパラレル・ディレクティブを指定するには、2つの方法があります（PARALLEL DMLモードが有効になっている場合）。
更新または削除する表（参照オブジェクト）の定義でPARALLEL句を使用します。
文中で更新、マージまたは削除のパラレル・ヒントを使用します。
パラレル・ヒントは、UPDATE、MERGEおよびDELETE文中のUPDATE、MERGEまたはDELETEキーワードの直後に配置します。ヒントは、変更される表の基底のスキャンにも適用されます。
ALTER SESSION FORCE PARALLEL DML文を使用すると、セッション中の後続のUPDATE、MERGEおよびDELETE文のPARALLEL句をオーバーライドできます。UPDATE、MERGEおよびDELETE文中でパラレル・ヒントを使用すると、ALTER SESSION FORCE PARALLEL DML文はオーバーライドされます。
UPDATE、MERGEまたはDELETE操作をパラレル化する必要があるかどうかは、次のルールにより決定されます。
UPDATEまたはDELETE操作がパラレル化されるのは、次のうち1つ以上に該当する場合に限られます。
更新または削除される表にPARALLEL指定がある場合
DML文でPARALLELヒントが指定されている場合
文に副問合せまたは更新可能なビューを指定する場合に、それらに別個のパラレル・ヒントまたは句を指定しても、そうしたパラレル・ディレクティブは、UPDATE、MERGEまたはDELETEのパラレル化の判断には影響しません。
表に対するパラレル・ヒントや句は、問合せとUPDATE、MERGE、DELETE部分の両方でパラレル化の決定に使用されます。UPDATE、MERGE、DELETE部分のパラレル化の決定は問合せ部分とは独立して行われ、その逆も同様です。
DOPは問合せの場合と同じルールにより決定されます。UPDATEおよびDELETE操作の場合、関与するのは変更対象となる表のみ（参照オブジェクトのみ）であることに注意してください。そのため、UPDATEまたはDELETEのパラレル・ヒント指定は、ターゲット表のパラレル宣言指定よりも優先されます。つまり、優先順位は、MERGE、UPDATE、DELETEヒント>セッション>ターゲット表のパラレル宣言指定となります。優先順位ルールについては、表25-3を参照してください。
1つのパラレル実行サーバーで複数のパーティションに対する更新、マージまたは削除を実行できます。ただし、各パーティションの更新または削除を担当できるのは、1つのパラレル実行サーバーに限られます。
DOPがパーティション数よりも少ない場合、最初のプロセスがあるパーティションの処理を終了した後で別のパーティションの処理を担当し、このようにしてすべてのパーティションの処理が終了するまで同様の手法で作業されます。DOPが操作に関与するパーティション数より大きい場合、余分なパラレル実行サーバーが処理を行うことはありません。
INSERT ... SELECT文では、そのINSERT操作とSELECT操作が（DOPを除けば）個別にパラレル化されます。
INSERT ... SELECT文中では、INSERTキーワードの後にパラレル・ヒントを指定できます。通常、問合せ対象の表は挿入対象の表とは異なるので、ヒントを使用すると挿入操作専用のパラレル・ディレクティブを指定できます。
INSERT ... SELECT文のパラレル・ディレクティブは、次の方法で指定できます（PARALLEL DMLモードが有効になっている場合）。
文中でSELECTパラレル・ヒントを指定
選択対象となる表の定義にPARALLEL句を指定
文中でINSERTパラレル・ヒントを指定
挿入対象となる表の定義にPARALLEL句を指定
ALTER SESSION FORCE PARALLEL DML文を使用すると、セッション中の後続のINSERT操作のPARALLEL句をオーバーライドできます。挿入操作でパラレル・ヒントを使用すると、ALTER SESSION FORCE PARALLEL DML文はオーバーライドされます。
INSERT ... SELECT文中のINSERT操作をパラレル化する必要があるかどうかは、次のルールで決定されます。
INSERT操作がパラレル化されるのは、次のうち1つ以上に該当する場合のみです。
DML文でINSERTの後にPARALLELヒントが指定されている場合
挿入対象の表（参照オブジェクト）にPARALLEL宣言指定がある場合
INSERT操作のパラレル化の判断は、SELECT操作から独立して行われます。その逆も同様です。
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句を使用すると、表のパラレル化が指定されます。DDL文および問合せのパラレル化は、表の定義にPARALLEL句が記述されている場合にはその句によって決定します。ただし、表に対する明示的なPARALLELヒントがDDL文に指定されている場合、そのヒントによってその表に対するPARALLEL句の効果がオーバーライドされます。ALTER SESSION FORCE PARALLEL DDL文を使用すると、PARALLEL句をオーバーライドできます。
次のルールが適用されます。
CREATE INDEXおよびALTER INDEX ... REBUILD文は、PARALLEL句またはALTER SESSION FORCE PARALLEL DDL文でのみパラレル化できます。
ALTER INDEX ... REBUILDをパラレル化できるのは非パーティション索引の場合のみですが、ALTER INDEX ... REBUILD PARTITIONは、PARALLEL句またはALTER SESSION FORCE PARALLEL DDL文でパラレル化できます。
ALTER INDEX ... REBUILD（パーティション化なし）、ALTER INDEX ... REBUILD PARTITIONおよびCREATE INDEXのスキャン操作の並列性は、REBUILDまたはCREATE操作と同じであり、同じDOPが使用されます。REBUILDやCREATEに対するDOPが指定されていない場合、デフォルトでCPU数が指定されます。
CREATE TABLE ... AS SELECT文は、CREATE部分（DDL）およびSELECT部分（問合せ）の2つに分かれています。Oracle Databaseでは、この文の両方の部分をパラレル化できます。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 TABLE ... AS SELECT文のCREATE操作は、PARALLEL句またはALTER SESSION FORCE PARALLEL DDL文でのみパラレル化できます。
CREATE TABLE ... AS SELECTのCREATE操作がパラレル化される場合、Oracle Databaseでは可能であればスキャン操作もパラレル化されます。スキャン操作をパラレル化できないのは、たとえば次のような場合です。
SELECT句にNO_PARALLELヒントがある場合
操作で非パーティション表の索引がスキャンされる場合
CREATE操作がパラレル化されないときにSELECTをパラレル化できるのは、PARALLELヒントがある場合、または選択される表（またはパーティション索引）にパラレル宣言がある場合です。
表25-3に、各種SQL文をパラレル化する方法と、パラレル化指定の優先順位を示します。
優先順位（1）の指定により、優先順位（2）および優先順位（3）がオーバーライドされます。
優先順位（2）の指定により、優先順位（3）がオーバーライドされます。
表25-3 句、ヒントまたは基礎となる表/索引の宣言によるパラレル化の優先順位
| パラレル操作 | PARALLELヒント | PARALLEL句 | ALTER SESSION | パラレル宣言 |
|---|---|---|---|---|
|
パラレル問合せの表スキャン（パーティション表または非パーティション表） |
1) |
2) |
3）表のパラレル宣言 |
|
|
パラレル問合せの索引レンジ・スキャン（パーティション索引） |
1) |
2) |
2）索引のパラレル宣言 |
|
|
パラレル |
1) |
3）更新または削除対象の表のパラレル宣言 |
||
|
パラレル |
1) INSERTの |
3）挿入先の表のパラレル宣言 |
||
|
|
|
|
|
|
|
|
1) |
2）選択元の表のパラレル宣言 |
||
|
パラレル |
注意: |
2) |
||
|
|
|
|
|
|
|
|
1) |
2）問合せ対象の表またはパーティション索引のパラレル宣言 |
||
|
パラレル |
2) |
|||
|
パラレル |
2) |
1) |
||
|
|
||||
|
パーティションのパラレル |
2) |
1) |
||
|
パーティションのパラレル |
2) |
パラレル操作に関与する表のDOPは、表に対する操作のDOPに影響を及ぼします。そのため、パラレル実行のチューニングに関するパラメータを設定した後には、CREATE TABLEまたはALTER TABLE文でPARALLEL句を使用して、パラレル化する各表についてもパラレル実行を有効にする必要があります。SQL文でPARALLELヒントを使用して、その操作に対してのみパラレル化を有効することもできます。また、ALTER SESSION文でFORCEオプションを使用して、そのセッションの後続の操作すべてに対してパラレル化を有効にすることも可能です。
表をパラレル化する場合は、DOPを指定するか、デフォルトのDOPを使用します。デフォルトのDOPの値は、PARALLEL_THREADS_PER_CPUの値とOracle Databaseで使用可能な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機能を有効にすると、DOPが小さくなり、認識された負荷に従ってリソースがより均等に分散されます。
問合せに対するDOPは、一度決定されると、問合せ処理中は変更されません。
マルチユーザー問合せ調整機能は、複数のユーザーがパラレル実行操作を同時に処理する場合に使用すると最も効果的です。PARALLEL_ADAPTIVE_MULTI_USERは、デフォルトでTRUEに設定されています。この場合、同時実行されるパラレルSQL実行操作が制御されてシステムのパフォーマンスが最適化されます。PARALLEL_ADAPTIVE_MULTI_USERをFALSEに設定すると、十分なリソースが構成されている場合には、システムのパフォーマンスに対する影響は考慮されずに、各パラレルSQL実行操作が要求した数のパラレル実行サーバー・プロセスを受け取ります。
マルチユーザー問合せ調整アルゴリズムには、複数の入力があります。まず、Oracle Databaseで計算されたアクティブなOracle Databaseプロセスの数が検討されます。続いて、初期化パラメータ・ファイルに設定されているデフォルトのパラレル化設定、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文に対して強制することも可能です。この句を指定すると、セッション中の後続の文に指定されたすべてのPARALLEL句がオーバーライドされます。ただし、この句の影響はパラレル・ヒントの使用によりオーバーライドされます。
たとえば、典型的なOLTP環境では、表に対してパラレル実行は設定されませんが、夜間のバッチ・スクリプトではこうした表からパラレルにデータを収集することが必要な場合もあります。DOPをセッション中に設定することで、各表の設定をパラレルに変更して完了後にシリアルに戻す作業を回避できます。
初期化パラメータPARALLEL_THREADS_PER_CPUは、DOPとマルチユーザー問合せ調整機能の両方を制御するアルゴリズムに影響を及ぼします。Oracle Databaseでは、各インスタンスについて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パラメータには、パラレル実行に使用できるプロセスの最大数に関するリソース制限を設定します。ほとんどのパラレル操作で必要とされる問合せサーバー・プロセス数は、その操作に関わる表に指定されている最大の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)
PGA_AGGREGATE_TARGETの値は、MEMORY_TARGETが設定されている場合に導出できます。PGA_AGGREGATE_TARGETの様々な場合における使用方法については、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。前述の式は、より大きな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 Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。
PARALLEL_MIN_SERVERSパラメータには、デフォルト値である0（ゼロ）を指定することをお薦めします。
このパラメータでは、単一インスタンスでパラレル操作用に開始および予約されるプロセス数を指定できます。構文は次のとおりです。
PARALLEL_MIN_SERVERS=n
nは、パラレル操作用に開始および予約する必要があるプロセス数です。
PARALLEL_MIN_SERVERSを設定すると、メモリー使用量と起動コストのバランスが保たれます。PARALLEL_MIN_SERVERSを使用して開始したプロセスは、データベースが停止されるまで終了しません。このため、そうしたプロセスは問合せが発行されたときに使用できる可能性が高くなります。ただし、この種のプロセスで使用されるメモリーが断片化され、最高水位標が徐々に増大する原因になることがあるので、問合せサーバー・プロセスは定期的にリサイクルすることをお薦めします。PARALLEL_MIN_SERVERSを設定しない場合、プロセスは5分間アイドル状態になると終了します。
パラレル実行では、シリアルSQL実行に必要なメモリー・リソースに加えて、さらにメモリー・リソースが必要とされます。追加分のメモリーは、通信と、問合せサーバー・プロセスおよび問合せコーディネータ間のデータのやりとりに使用されます。
問合せサーバー・プロセス用のメモリーは、共有プールから割り当てられます。共有プールは次のようにチューニングします。
共有プールの他のクライアント（共有カーソルやストアド・プロシージャなど）を考慮します。
大きな値を設定するとマルチユーザー・システムのパフォーマンスが向上しますが、小さな値を設定するとメモリー使用量が減少します。
パラレル実行を使用すると、より多くのカーソルが生成されることも考慮する必要があります。カーソルが再コンパイルされる頻度を判断するには、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 Databaseで取得できるメモリーのうち一部が割り当てられず、一定の領域が残されます。必要な領域の取得は問合せの実行時に試行されます。Oracle Databaseでは560KBが使用され、失敗するとさらに16KBが必要とされます。エラーが発生しても、必要とされた量の累積値はレポートされません。追加の必要があるメモリー量を判断する最善の方法は、「メッセージ・バッファへのメモリーの追加」で紹介する計算式を使用することです。
この例の問題を解決するには、SHARED_POOL_SIZEの値を増やします。サンプルの出力からわかるように、SHARED_POOL_SIZEは約2MBになっています。使用可能なメモリー量に応じて、SHARED_POOL_SIZEの値をたとえば4MBまで増やし、データベースの起動を試行します。ORA-4031メッセージが続いて表示される場合は、起動が成功するまでSHARED_POOL_SIZEの値を少しずつ増やします。
共有プールの初期設定の決定後には、メッセージ・バッファ用の追加メモリーの要件を計算し、カーソル用に必要な追加領域の量を判断する必要があります。
メッセージ・バッファに対応するためには、SHARED_POOL_SIZEパラメータの値を増やす必要があります。メッセージ・バッファを使用すると、問合せサーバー・プロセスが相互に通信できるようになります。
Oracle Databaseでは、生成側問合せサーバーとコンシューマ問合せサーバー間の仮想接続ごとに、一定数のバッファが使用されます。接続数は、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 x DOP)
システムがクラスタやMPPの場合にはDOPが増大するので、インスタンス数を考慮する必要があります。これはつまり、2インスタンスのクラスタでDOPとして4を使用すると、結果的なDOPは8となるためです。PARALLEL_MAX_SERVERSの値 × インスタンス数 / 4が、控えめな見積もりとして使用される開始値となります。
LOCAL = CONNECTIONS/INSTANCES
REMOTE = CONNECTIONS - LOCAL
この量を、共有プールの元の設定に追加します。ただし、これらのメモリー構造のいずれかに値を設定する前には、次の項で説明するカーソル用の追加メモリーについて検討する必要があります。
この項の計算式はあくまで開始値として使用します。自動または手動のいずれのチューニングを使用している場合にも、処理中の使用量を監視して、メモリー・サイズが大きすぎたり小さすぎたりしないように調整する必要があります。これには、次の問合せを使用して共有プールをチューニングします。
SELECT POOL, NAME, SUM(BYTES) FROM V$SGASTAT WHERE POOL LIKE '%pool%' GROUP BY ROLLUP (POOL, NAME);
出力は、次のようになります。
POOL NAME SUM(BYTES)
----------- -------------------------- ----------
shared pool Checkpoint queue 38496
shared pool KGFF heap 1964
shared pool KGK heap 4372
shared pool KQLS heap 1134432
shared pool LRMPD SGA Table 23856
shared pool PLS non-lib hp 2096
shared pool PX subheap 186828
shared pool SYSTEM PARAMETERS 55756
shared pool State objects 3907808
shared pool character set memory 30260
shared pool db_block_buffers 200000
shared pool db_block_hash_buckets 33132
shared pool db_files 122984
shared pool db_handles 52416
shared pool dictionary cache 198216
shared pool dlm shared memory 5387924
shared pool event statistics per sess 264768
shared pool fixed allocation callback 1376
shared pool free memory 26329104
shared pool gc_* 64000
shared pool latch nowait fails or sle 34944
shared pool library cache 2176808
shared pool log_buffer 24576
shared pool log_checkpoint_timeout 24700
shared pool long op statistics array 30240
shared pool message pool freequeue 116232
shared pool miscellaneous 267624
shared pool processes 76896
shared pool session param values 41424
shared pool sessions 170016
shared pool sql area 9549116
shared pool table columns 148104
shared pool trace_buffers_per_process 1476320
shared pool transactions 18480
shared pool trigger inform 24684
shared pool 52248968
90641768
出力に表示されたメモリーの使用量を評価し、ユーザーの処理要件に基づいてSHARED_POOL_SIZEの設定を変更します。
さらにメモリー使用量の統計情報を取得するには、次の問合せを実行します。
SELECT * FROM V$PX_PROCESS_SYSSTAT WHERE STATISTIC LIKE 'Buffers%';
出力は、次のようになります。
STATISTIC VALUE ------------------- ----- Buffers Allocated 23225 Buffers Freed 23225 Buffers Current 0 Buffers HWM 3620
メモリー使用量が、統計値Buffers CurrentとBuffers HWMに表示されています。このバッファの数とPARALLEL_EXECUTION_MESSAGE_SIZEの値を掛けた値（バイト単位）を計算します。この最高水位標（HWM）とパラレル実行メッセージ・プール・サイズとを比較して、割り当てたメモリーが多すぎるかどうかを判断します。たとえば、1つ目の出力では、px msg poolに表示されるラージ・プールの値は38,092,812つまり38MBです。2つ目の出力にあるBuffers HWMは3,620です。これにパラレル実行メッセージ・サイズの4,096を掛けると、この値は14,827,520、つまり約15MBになります。この場合、最高水位標はその容量の約40%に達しています。
PARALLEL_MIN_PERCENTパラメータには、0（ゼロ）を指定することをお薦めします。
このパラメータを使用すると、ユーザーが使用中のアプリケーションに応じた許容DOPを待機できます。このパラメータに0（ゼロ）以外の値を設定すると、要求されたDOPをシステムで所定の時点に満たせない場合に、エラーが戻されます。たとえば、PARALLEL_MIN_PERCENTを50に設定すると、この値は50%として扱われ、調整アルゴリズムやリソース制限によってDOPが50%以上削減されると、ORA-12827が戻されます。次に例を示します。
SELECT /*+ PARALLEL(e, 8) */ d.department_id, SUM(SALARY) FROM employees e, departments d WHERE e.department_id = d.department_id GROUP BY d.department_id ORDER BY d.department_id;
次のメッセージが戻されます。
ORA-12827: insufficient parallel query slaves available
この項の内容を検討する前には、『Oracle Databaseパフォーマンス・チューニング・ガイド』および『Oracle Database管理者ガイド』で、MEMORY_TARGETおよびMEMORY_MAX_TARGET初期化パラメータの詳細な説明に目を通すことをお薦めします。MEMORY_TARGETでSGAおよびPGAコンポーネントが自動チューニングされている場合、PGA_AGGREGATE_TARGET初期化パラメータの設定は不要です。
この項では、はじめに、すべてのパラレル操作、特にパラレル実行におけるメモリー使用やリソース使用に影響を及ぼすパラメータ群について説明します。このパラメータ群のパラメータは次のとおりです。
続いて、パラレルDMLおよびDDLに影響を及ぼすパラメータ群について説明します。
リソース使用を制御するには、メモリーを次の2レベルで構成する必要があります。
データベース・レベル。このレベルを構成することで、システムにおいてオペレーティング・システムのメモリーが適切な量だけ使用されるようになります。
オペレーティング・システム・レベル。一貫性を保ちます。一部のプラットフォームでは、すべてのプロセスについて合計した使用可能な仮想メモリーの総量を制御する、一連のオペレーティング・システム・パラメータを設定する必要があります。
データ・ウェアハウス操作で使用されるメモリーの大部分は、（OLTPの場合と比較して）より動的なものです。この種のメモリーは、プロセス・メモリー（PGA）から割り当てられます。プロセス・メモリーのサイズとプロセス数はいずれも幅広い範囲で変化します。そうしたプロセス・メモリーとプロセス数は、初期化パラメータPGA_AGGREGATE_TARGETを使用して制御します。PGA_AGGREGATE_TARGETをMEMORY_TARGETと併せて明示的に設定すると、自動チューニングは確実に実施されますが、PGA_AGGREGATE_TARGETは指定した値では調整されません。
自動PGAメモリー管理を有効にすることで、PGAメモリーの割当て方法を簡単かつ強力なものにできます。このモードに設定すると、DBAが明示的に設定したPGAメモリー・ターゲット全体を基に、PGAメモリーの作業領域に専用の部分のサイズが動的に調整されます。自動PGAメモリー管理を有効にするには、初期化パラメータPGA_AGGREGATE_TARGETを設定する必要があります。新規のインストールでは、PGA_AGGREGATE_TARGETとSGA_TARGETはDBCAで自動的に設定され、MEMORY_TARGETは0（ゼロ）になっています。つまり、この状況では自動メモリー管理は無効な状態です。有効化は、Enterprise Managerの「メモリー・パラメータ」ページで行うことができます。したがって、デフォルトでは集計PGAの自動チューニングが有効化されていることになりますが、MEMORY_TARGETをゼロ以外の値に設定して、自動メモリー管理を有効にしないかぎり、集計PGAの値は増加しません。
PGA_AGGREGATE_TARGETの様々な場合における使用方法については、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。
PARALLEL_EXECUTION_MESSAGE_SIZEパラメータでは、パラレル実行メッセージに使用されるバッファのサイズを指定できます。デフォルト値はオペレーティング・システム固有ですが、通常は2KBです。この値はほとんどのアプリケーションにおいて適切ですが、値を増やすとパフォーマンスが向上する場合もあります。共有プールに十分な空きメモリーがある場合、または十分なオペレーティング・システム・メモリーがあり、共有プール・サイズを増やして必要なメモリーの追加量に対応できる場合は、この値を増やすことを検討します。
次に、パラレルDMLおよびパラレルDDLのリソース使用量に影響するパラメータを示します。
パラレル挿入、更新および削除には、シリアルDML操作に比べて多くのリソースが必要です。同様に、PARALLEL CREATE TABLE ... AS SELECTおよびPARALLEL CREATE INDEXにも、より多くのリソースが必要になる場合があります。このため、他にいくつかの初期化パラメータ値の増加が必要になることもあります。こうしたパラメータが問合せ用のリソースに影響を与えることはありません。
パラレルDMLおよびDDLの場合は、各問合せサーバー・プロセスによってトランザクションが開始されます。パラレル・コーディネータでは、2フェーズ・コミット・プロトコルでトランザクションがコミットされるので、処理されるトランザクションの数はDOPに応じて増加します。そのため、場合によってはTRANSACTIONS初期化パラメータの値を増やす必要があります。
TRANSACTIONSパラメータでは、同時トランザクションの最大数が指定されます。デフォルトの場合は、パラレル化なしと想定されます。たとえば、DOPを20とすると、さらに新しくサーバー用に20個（サーバー・セットが2つの場合は40個）、コーディネータ用に1個のトランザクションが発生します。この場合、一連のトランザクションが同一インスタンス内で実行中であれば、TRANSACTIONSを21（または41）に増加する必要があります。このパラメータを設定しない場合、Oracle Databaseによって1.1 x SESSIONSの値に設定されます。この説明は、サーバー管理のUNDOを使用している場合には当てはまりません。
コミットされていないパラレルDMLトランザクションまたはパラレルDDLトランザクションがあるときに、システムで障害が発生した場合は、FAST_START_PARALLEL_ROLLBACKパラメータを使用して起動時のトランザクション・リカバリをスピードアップできます。
このパラメータでは、終了したトランザクションのリカバリ時に使用されるDOPを制御できます。終了したトランザクションとは、システム障害が発生する前にはアクティブであったトランザクションです。デフォルトでは、DOPとして選択される値は、最大でCPU_COUNTパラメータ値の2倍になります。
デフォルトのDOPで不十分な場合は、このパラメータをHIGHに設定します。この設定では、DOPの最大値がCPU_COUNTパラメータ値の4倍になります。この機能はデフォルトで使用可能です。
V$SYSSTATビューの統計値redo buffer allocation retriesをチェックします。この値がredo blocks writtenより大きい場合、LOG_BUFFERのサイズの増加を検討します。多数のログが生成されるシステムでは、通常、LOG_BUFFERのサイズは3〜5MBです。LOG_BUFFERのサイズを増やしても再試行が頻繁に行われる場合は、ログ・ファイルが格納されているディスクに問題がある可能性があります。その場合、I/Oサブシステムを調整して、REDO用のI/Oの割合を増加します。このための手段には、複数のディスクにファイングレイン・ストライプ化を使用するという方法があります。ストライプ・サイズとしては、たとえば16KBを使用します。また、さらに簡単な手段として、REDOログをそれぞれ個別のディスクに配置するという方法もあります。
このパラメータでは、DMLロックの最大数が指定されます。このパラメータの値は、すべてのユーザーが参照するあらゆる表のロックの総数と等しくなります。パラレルDML操作のロック要件は、シリアルDMLの場合とはかなり異なります。パラレルDMLではより多くのロックが保持されるので、DML_LOCKSパラメータの値を倍に増やす必要があります。
表25-4に、様々なパラレルDML文において、コーディネータおよびパラレル実行サーバー・プロセスで取得されるロックのタイプを示します。この表の情報から、こうしたパラメータに必要な値を決定できます。
表25-4 パラレルDML文によって取得されるロック
| 文のタイプ | コーディネータ・プロセスが取得するロック | 各パラレル実行サーバーが取得するロック |
|---|---|---|
|
パーティション表へのパラレル |
1つの表ロックSX プルーニングされた（サブ）パーティション当たり1つのパーティション・ロックX |
1つの表ロックSX 問合せサーバー・プロセスが所有するプルーニングされた（サブ）パーティション当たり1つのパーティション・ロック 問合せサーバー・プロセスが所有するプルーニングされた（サブ）パーティション当たり1つのパーティション待機ロックS |
|
パーティション表へのパラレル行移行 |
1つの表ロックSX プルーニングされた（サブ）パーティション当たり1つのパーティション・ロックX すべての他の（サブ）パーティションに対する1つのパーティション・ロックSX |
1つの表ロックSX 問合せサーバー・プロセスが所有するプルーニングされた（サブ）パーティション当たり1つのパーティション・ロック 問合せサーバー・プロセスが所有するプルーニングされたパーティション当たり1つのパーティション待機ロックS すべての他の（サブ）パーティションに対する1つのパーティション・ロックSX |
|
パーティション表に対するパラレル |
1つの表ロックSX すべての（サブ）パーティションに対するパーティション・ロックX |
1つの表ロックSX （サブ）パーティション当たり1つのパーティション・ロック （サブ）パーティション当たり1つのパーティション待機ロックS |
|
パーティション表に対するパラレル |
1つの表ロックSX 指定された（サブ）パーティション当たり1つのパーティション・ロックX |
1つの表ロックSX 指定された（サブ）パーティション当たり1つのパーティション・ロック 指定された（サブ）パーティション当たり1つのパーティション待機ロックS |
|
非パーティション表に対するパラレル |
1つの表ロックX |
なし |
|
注意: 表、パーティション、パーティション待機の各DMLロックはすべて、V$LOCKビューではTMロックとして表示されます。 |
すべてのパーティションがパラレルUPDATE文またはDELETE文に関与していて、かつ行移行がないことを前提として、100のDOPで実行される600のパーティションを持つ表について考えてみます。
コーディネータが取得するロック:
1つの表ロックSX
600のパーティション・ロックX
すべてのサーバー・プロセスが取得するロック:
100の表ロックSX
600のパーティション・ロックNULL
600のパーティション待機ロックS
I/Oに影響するパラメータを次に示します。
これらのパラメータは、パラレル実行I/O操作のパフォーマンスを最適化するオプティマイザにも影響します。
パラレルの更新、マージおよび削除を実行したときのバッファ・キャッシュの動作は、大量の更新を実行する際のOLTPシステムの動作とほぼ同様です。
このパラメータに対する推奨値は、8KBまたは16KBです。
データベースのブロック・サイズは、データベースの作成時に設定します。新しくデータベースを作成する際には、8KBや16KBなど大きなブロック・サイズを設定します。
このパラメータの推奨値は、ブロック・サイズが8KBの場合は8、16KBの場合は4で、デフォルトは8です。
このパラメータでは、オペレーティング・システムの1回のREADコールで読み込まれるデータベース・ブロックの数が決定されます。このパラメータの上限値はプラットフォームによって異なります。DB_FILE_MULTIBLOCK_READ_COUNTに設定した値が大きすぎる場合、データベースの起動時にオペレーティング・システムによって、許容される最大レベルの値にまで引き下げられます。この場合、各プラットフォームでは使用可能な最大の値が使用されます。最大値の範囲は、通常64K〜1MBです。
これらのパラメータの推奨値はTRUEです。
これらのパラメータでは、オペレーティング・システムの非同期I/O機能を有効または無効にできます。これにより、表スキャンの実行時に問合せサーバー・プロセスでI/O要求と処理を同時に実行できるようになります。オペレーティング・システムで非同期I/Oがサポートされている場合、これらのパラメータはデフォルト値のTRUEのままとします。非同期読取りの仕組みを図25-6に示します。
非同期操作は現在、パラレル表スキャン、ハッシュ結合、ソートおよびシリアル・テーブル・スキャンでサポートされています。ただし、この機能にはオペレーティング・システム固有の構成が必要な場合があり、すべてのプラットフォームでサポートされるとは限りません。
パラレル実行のパフォーマンス問題を診断する場合は、次のタスクを実行する必要があります。
パフォーマンス期待値を定量化し、問題があるかどうかを判断します。
問題が、最適化に関するもの（表の再分析やヒントの追加が必要な非効率的な計画など）か、実行に関するもの（公開されているガイドラインよりも大幅に低速で実行されているスキャン、ロード、グルーピング、索引化などの単純操作）かを判断します。
問題が、パラレル実行時に発生するもの（ロードの不均衡やリソースのボトルネックなど）か、シリアル操作でも発生するものかを判断します。
パフォーマンス期待値は、これまでのパフォーマンス測定（先週またはOracleの旧バージョンにおける特定の問合せの所要時間など）に基づくものか、シリアル実行時間からの測定または推定（シリアル実行の所要時間が10分なのでパラレル実行の所要時間は5分といった推定）に基づくものとします。期待どおりのパフォーマンスが得られない場合は、次の点を検討します。
実行計画の変更の有無
変更があった場合は、統計情報を収集し、索引構成表へのアクセスおよびCREATE TABLE AS SELECT文の使用の有無を決定する必要があります。システムがCPUバウンドの場合は、索引ヒントを使用してください。また、EXPLAIN PLANの出力も調べる必要があります。
データセットの変更の有無
変更があった場合は、統計情報を収集して相違点について評価する必要があります。
ハードウェアの過負荷の有無
過負荷になっている場合は、CPU、I/Oおよびスワップ・メモリーをチェックする必要があります。
基本とする目標を設定して、これらの点を考慮した後には、次のトピックの検討が必要です。
パラレル実行の実際のパフォーマンスが、期待値と異なるかどうかを判断します。パフォーマンスが期待値と同じ場合、基底となるパフォーマンス問題があるかどうかを判断します。おそらく、現行の結果との比較対象として目標とする結果が想定されることでしょう。正当なパフォーマンス期待値を設定しているのに、それがシステムでは実現されていないこともあり得ます。あるいは、期待するレベルのパフォーマンスや特定の実行計画が過去に達成されたことがあり、同様の環境や操作であるにもかかわらず、現時点ではシステムがこの目標に達していない可能性もあります。
パフォーマンスが期待どおりでない場合は、相違の程度を測定できるかどうかを考えます。データ・ウェアハウス操作では、実行計画がキーとなります。重要なデータ・ウェアハウス操作については、EXPLAIN PLANの結果を保存します。長期的に保存しておくと、データの分析時や再分析時、Oracle Databaseのアップグレード時および新しいデータのロード時に、新しい実行計画を古い計画と比較できるようになります。積極的でも積極的でなくてもかまわないので、この方法を実施するようにしてください。
また、ヒントの使用によってパフォーマンスが向上する場合もあります。ヒントが必要とされる理由を理解したり、望ましい計画をオプティマイザによってヒントなしで生成する方法を割り出したりすることが必要な場合もあります。また、統計情報のサンプル・サイズを大きくする方法もあります。統計情報がより適切なものになると、よりよい計画が得られる場合があります。
プラン・スタビリティおよびアウトラインを使用して、システムに対する一連の変更にわたって計画を保存する方法の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。
実行計画に変更があった場合、計画がパラレルかシリアルか（または、いずれである必要があるか）を判断します。
実行計画がパラレルであるか、パラレルである必要がある場合は、EXPLAIN PLANの出力を調べます。すべての表を分析の対象とします。場合によっては、ヒントの使用が必要なこともあります。ヒントによりパフォーマンスが向上するかどうかを検証します。rdbms/adminディレクトリのutlxplp.sqlを参照してください。
実行計画がシリアルであるか、シリアルである必要がある場合は、次の方法を検討します。
索引を使用します。索引を追加すると、パフォーマンスが大幅に向上する場合があります。索引への列の追加を検討します。操作によっては、すべてのデータを索引から取得でき、表スキャンが必要ないこともあります。場合によっては、ヒントの使用が必要なこともあります。ヒントにより、より適切な結果が得られるかどうかを検証します。
統計情報を計算します。分析を頻繁に行っておらず、時間が十分にある場合には、統計情報を計算することをお薦めします。これは大量の結合を実行する際には特に重要で、これによってより適切な計画が得られます。かわりに、統計情報の見積りを行うこともできます。様々なサンプル・サイズを使用すると、計画が変化する場合があります。通常であれば、サンプル・サイズが大きいほど、より適切な計画が得られます。
データが均一に分散していない場合は、ヒストグラムを使用します。
初期化パラメータをチェックして、値が適切かどうかを確認します。
CURSOR_SHARINGがforceまたはsimilarに設定されていないかぎり、バインド変数をリテラルで置換します。
実行がI/OバウンドまたはCPUバウンドかどうかを判断します。続いて、オプティマイザのコスト・モデルをチェックします。
副問合せを結合に変換します。
CREATE TABLE ... AS SELECT文を使用して、複雑な操作をより小さな操作に分割します。5個や6個の表を参照する大規模な問合せでは、問合せのどの部分に最も時間がかかっているのかを判断することが難しい場合もあります。問合せをいくつかのステップに分割し、各ステップを分析することで、問合せのボトルネックを分離できます。
退行の原因が計画の問題であることを確認できない場合、それは実行に関する問題です。データ・ウェアハウス操作（シリアルおよびパラレル）については、計画でのメモリーの使用状況を検討します。ページング率をチェックし、システムでメモリーができるだけ効率的に使用されるようにします。バッファ、ソートおよびハッシュ領域のサイズをチェックします。問合せまたはDML操作の実行後に、V$SESSTAT、V$PX_SESSTATおよびV$PQ_SYSSTATの各ビューを参照して、使用されたサーバー・プロセスの数と、セッションやシステムに関するその他の情報を確認します。
パラレル実行を使用している場合は、ワークロードの分散が均等でない可能性を検討します。たとえば、CPU数が10個でシングル・ユーザーの場合、ワークロードがCPU間で均等に分散されているかどうかを確認できます。これは長期的に見ると（I/O集中度が高い時期や低い時期があるので）変化が生じる時期もありますが、通常、各CPUにはほぼ同量のアクティビティが分散される必要があります。
V$PQ_TQSTATの統計情報には、各パラレル実行サーバーで生成および消費された行が示されます。この情報には偏りが適切に表され、ユーザー側で操作する必要もまったくありません。
オペレーティング・システムの統計情報には、プロセッサごとのCPU使用率やディスクごとのI/Oアクティビティが示されます。ただし、複数のタスクが同時に実行されている場合、何が行われているかを確認することは困難になります。シングル・ユーザー・モードで実行し、システム・レベルのCPUおよびI/Oアクティビティを表示するオペレーティング・システム・モニターをチェックすると効果的な場合があります。
I/O問題が発生する場合、データをより多くのデバイスに分散して、再編成する必要がある可能性もあります。パラレル実行で問題が発生した場合は、データが推奨されているとおり、少なくともCPUと同数のデバイスに分散されているかどうかをチェックします。
ワークロードの分散に偏りがない場合は、次の条件をチェックします。
デバイスの競合があるか。
コントローラの競合があるか。
パラレル化が少なすぎることによるシステムI/Oバウンドか。その場合は、パラレル化を最大でデバイス数まで増加することを検討します。
パラレル化が多すぎることによるCPUバウンドか。オペレーティング・システムのCPUモニターをチェックして、システム・コールに長い時間がかかっていないかを確認します。リソースが過剰にコミットされている場合や、過剰なパラレル化によってプロセス同士が競合している場合が考えられます。
同時ユーザー数がシステムでサポート可能なユーザー数を超過していないか。
Oracleのリアルタイム監視機能により、SQL文の実行中にそのパフォーマンスを監視できます。SQLの監視は、SQL文をパラレルに実行する際、または単独の実行においてCPUタイムまたはI/Oタイムを5秒以上消費した際に、自動的に開始されます。詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。
システムを数日間実行した後に、パラレル実行のパフォーマンスの統計情報を監視して、パラレル処理が最適かどうかを判断する必要があります。これを行うには、この項で説明するビューのいずれかを使用します。
Oracle Real Application Clustersでは、この項で説明するグローバル・バージョンのビューに、複数インスタンスの統計情報が集計されます。グローバル・ビューには、V$FILESTATに対するGV$FILESTATのように、Gで始まる名前が付けられます。
V$PX_BUFFER_ADVICEビューには、すべてのパラレル問合せにおける最大バッファ使用量の履歴と見積りが示されます。パラレル問合せでメモリー不足が生じた場合、このビューを参考にしてSGAサイズを再構成できます。
V$PX_SESSIONビューには、問合せサーバーのセッション、グループ、セットおよびサーバー番号に関するデータが示されます。パラレル実行のために動作しているプロセスに関する、リアルタイムのデータも示されます。この表では、要求されたDOPおよび操作に対して許可された実際のDOPに関する情報も確認できます。
V$PX_SESSTATビューには、表V$PX_SESSIONおよび表V$SESSTATのセッション情報が結合されて示されます。そのため、通常のセッションで利用できるすべてのセッション統計情報を、パラレル実行で実行されるあらゆるセッションで利用できます。
V$PQ_SESSTATビューには、システム内のすべての現行サーバー・グループの状態が示されます。たとえば、問合せによるプロセスの割当て方法や、マルチユーザーおよびロード・バランシング・アルゴリズムがデフォルト値やヒントの値に影響する仕組みなどについてのデータが表示されます。V$PQ_SESSTATは、将来のリリースで廃止される予定です。
これらのビューのデータを確認した後には、パフォーマンス向上のために、一部のパラメータ設定を調整する必要が生じる場合があります。そうした場合は、「パラレル実行用の一般パラメータのチューニング」を参照してください。長時間実行のパラレル操作の進行状況は、これらのビューを定期的に問い合せて監視します。
多数の動的パフォーマンス・ビューについて各自の統計情報を収集するには、各ビューにおいてパラメータTIMED_STATISTICSをTRUEに設定する必要があります。TIMED_STATISTICSのオン/オフは、ALTER SYSTEM文またはALTER SESSION文を使用して切り替えます。
V$FILESTATビューでは、各表領域内の各データファイルに対する読取り要求、書込み要求、ブロック数およびサービス時間が合計されます。V$FILESTATを使用して、I/Oおよびワークロード分散の問題を診断できます。
V$FILESTATの統計情報をDBA_DATA_FILESビューの統計情報と結合すると、表領域ごとにI/Oをグループ化したり、指定したファイル番号のファイル名を検索したりできます。割合分析を使用して、表領域内の各ファイルで使用される合計表領域アクティビティの割合を判断できます。表領域内に、頻繁にアクセスされる1つの大規模オブジェクトのみを配置する場合は、このテクニックを使用して、不適切な物理レイアウトのオブジェクトを識別できます。
DBA_EXTENTSビューを使用して、ディスク領域割当ての問題をさらに診断できます。領域は、表領域内のすべてのファイルから均等に割り当てられているようにします。長時間実行される操作中にV$FILESTATを監視して、その後でI/OアクティビティをEXPLAIN PLANの出力と相関付けると、進行状況を適切に把握できます。
V$PARAMETERビューには、すべてのシステム・パラメータの名前、現在の値およびデフォルト値が一覧表示されます。また、このビューには、パラメータがALTER SYSTEM文またはALTER SESSION文を使用してオンラインで変更できるセッション・パラメータであるかどうかも示されます。
単純な例として、2つの表を個別値が2種類のみの列で結合する、ハッシュ結合を考えてみます。この場合、ハッシュ関数では、パラレル実行サーバーAとパラレル実行サーバーBに最高でもそれぞれ1つずつのハッシュ値が用意されます。DOPは2の場合に適切な状態となりますが、4にした場合、少なくとも2つのパラレル実行サーバーが何の処理も行わないことになります。このタイプの偏りを検出するには、次の例のような問合せを使用します。
SELECT dfo_number, tq_id, server_type, process, num_rows FROM V$PQ_TQSTAT ORDER BY dfo_number DESC, tq_id, server_type, process;
おそらく、この問題を解決する最もよい方法は、別の結合方法を選択することです。ネステッド・ループ結合を選択すると、最も適切に解決できることがあります。結合表の一方が他方に比べて小さい場合は、かわりにBROADCAST分散方式でPQ_DISTRIBUTEヒントを使用することもできます。オプティマイザでは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_PARALLEL、SERIAL_TO_PARALLEL、PARALLEL_TO_SERIALの各行ラベルは、下位互換性のために旧リリースと同じセマンティックを持つので、従来どおりテーブル・キュー割当ての推測に使用できます。また、パラレル計画の最上部は、操作PX COORDINATORを持つ新しいノードによってマーキングされます。
V$PQ_TQSTATには、各テーブル・キューに対する読取りや書込みを行う各問合せサーバー・プロセス用の行があります。10個のコンシューマ・プロセスと10個の生成側プロセスを接続するテーブル・キューの場合、ビュー内には20行が用意されます。バイト列を合計し、テーブル・キュー識別子TQ_IDでグループ化すると、各テーブル・キューを介して送信された合計バイト数を取得できます。これをオプティマイザの見積りと比較します。差が大きい場合には、さらに大きなサンプルを使用したデータ分析が必要な可能性があります。
TQ_IDでグループ化されたバイトの平方偏差を計算します。平方偏差が大きい場合は、ワークロードが不均衡です。大きな平方偏差は調査して、生成側で開始時点にデータが不均等に分散されていたのか、分散自体に偏りがあるのかを判断する必要があります。データ自体に偏りがある場合は、カーディナリティが低いか、または個別値が少ない可能性があります。
V$PQ_TQSTATビューは、将来のリリースでV$PX_TQSTSATという名前に変更される予定なので注意してください。
この項では、「動的パフォーマンス・ビューでのパラレル実行パフォーマンスの監視」で説明した動的パフォーマンス・ビューを使用する例を紹介します。
GV$PX_SESSIONを使用して、パラレルで実行されているサーバー・グループの構成を割り出します。この例では、セッション9が問合せコーディネータであり、セッション7および21が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、データ・フロー演算子（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 Databaseで入手できる情報と、オペレーティング・システムのユーティリティ（UNIXベース・システムのsarやvmstatなど）を介して入手できる情報との間には、かなりの重複があります。オペレーティング・システムからは、I/O、通信、CPU、メモリー、ページング、スケジューリングおよび同期プリミティブのパフォーマンスに関する統計情報が得られます。一方、V$SESSTATビューにも、オペレーティング・システムの統計情報の主なカテゴリが表示されます。
通常、I/Oデバイスやセマフォ操作に関するオペレーティング・システム情報をデータベース・オブジェクトや操作にマップしなおすのは、Oracle Database情報の場合に比べて困難です。ただし、オペレーティング・システムによっては、データの収集に有効なビジュアル・ツールや効率的な手段が用意されているものもあります。
CPUやメモリー使用量に関するオペレーティング・システム情報は、パフォーマンスの評価において非常に重要です。おそらく、最も重要な統計情報はCPU使用率でしょう。低レベル・パフォーマンスのチューニングの目標は、すべてのCPUにおいてCPUバウンドになることです。この目標が達成されると、SQLレベルの作業で、よりI/O集中型でCPU使用率の少ない代替計画を検索できます。
オペレーティング・システムのメモリーやページングの情報は、メモリーがメモリー集中型データ・ウェアハウスのサブシステム間（パラレル通信、ソート、ハッシュ結合など）でどのように分割されるかを制御する、数多くのシステム・パラメータを適切にチューニングするために役立ちます。
共有ディスク・クラスタやMPP構成では、Oracle Real Application Clustersのインスタンスを実行しているプロセッサからデバイスが直接アクセスされる場合、そのインスタンスはそのデバイスに対してアフィニティを持つといわれます。同様に、あるファイルが格納されているデバイスに対してインスタンスがアフィニティを持つ場合、そのインスタンスはそのファイルに対してもアフィニティを持ちます。
アフィニティの判断においては、複数のデバイス間でストライプ化されるファイルに対し、任意での判断が行われる場合があります。あるインスタンスが表領域内の最初のファイルに対してアフィニティを持つ場合、そのインスタンスはある程度任意でその表領域（または表領域内の表や索引のパーティション）に対するアフィニティを持つと判断されます。
Oracle Databaseでは、作業をパラレル実行サーバーに割り当てる際にアフィニティが考慮されます。SQL文のパラレル実行に対するアフィニティの使用は、ユーザーに対して透過的に行われます。
パラレル問合せでアフィニティが利用されると、データに近いプロセッサでスキャン操作が行われるので、ディスクからのデータのスキャンがスピードアップします。これにより、本来、共有ディスクをサポートしていないマシンのパフォーマンスが大幅に向上します。
アフィニティが最も一般的に使用されるのは、単一デバイス上の単一ファイルに格納される、表または索引のパーティションの場合です。この構成では、デバイス障害によるダメージが抑えられることで最大限の可用性が実現し、パーティションのパラレル索引スキャンが最も適切に使用されるようになります。
DSSのユーザーは、表のパーティションを複数のデバイス間（ほとんどの場合デバイス全体数の一部）でストライプ化することが必要な場合があります。そうした構成にすることで、パーティション化基準を使用してアクセスされるデータの総量を一部の問合せでプルーニングし、ROWIDレンジ・パラレル・テーブル（パーティション）スキャンを通じてパラレル化することが可能になります。デバイスがRAIDとして構成されている場合、やはり高度な可用性が得られる可能性があります。DSSに対して使用する際にも、ほとんどの場合、索引は個々のデバイス上でパーティション化する必要があります。
その他の構成の場合（単一ファイルの複数パーティションが複数のデバイスにわたってストライプ化される場合など）は適切な問合せ結果が得られますが、適切なDOPを選択するためには、ヒントの使用やオブジェクト属性の明示的な設定が必要になる場合もあります。
パラレルDML（挿入、更新および削除）において、アフィニティ利用が強化されると、パーティションに対しアフィニティを持つノードに対してDML操作をルーティングすることにより、キャッシュ・パフォーマンスが向上します。
DML操作をパラレルに実行するため、インスタンス・セットやパラレル実行サーバー間で作業を分散する方法を判断する際に、アフィニティが利用されます。アフィニティを利用すると、次に示すような複数の方法で問合せのパフォーマンスを向上できます。
一部のMPPアーキテクチャでは、デバイスとノード間のアフィニティ情報が、パラレル実行サーバーを起動するノードの決定（パラレル・プロセスの割当て）と、特定のノードに送信する作業のグラニュル（ROWID範囲またはパーティション）の決定（作業の割当て）に利用されます。ノードのアクセス対象を主にローカル・デバイスとすることで、各ノードのバッファ・キャッシュのヒット率が高くなり、ネットワークのオーバーヘッドとI/O待機時間が抑えられるので、パフォーマンスが向上します。
SMP、クラスタ、MPPの各アーキテクチャでは、デバイスの独立性を実現するためにプロセスとデバイス間のアフィニティが利用されます。アフィニティを利用することで、複数のパラレル実行サーバーから同じデバイスに同時にアクセスする機会が削減されます。このプロセスとデバイス間のアフィニティ情報は、プロセス間のスティーリングの実装にも利用されます。
パーティション表および索引では、パーティションとノード間のアフィニティ情報により、プロセス割当てや作業割当てが決定されます。シェアード・ナッシング型のMPPシステムでは、Oracle Real Application Clustersでインスタンスに対するパーティションの割当てが試行される際に、パーティションのディスク・アフィニティが考慮されます。共有ディスク型のMPPやクラスタ・システムでは、パーティションはラウンドロビン法でインスタンスに割り当てられます。
アフィニティがパラレルDMLで利用されるのは、Oracle Real Application Clusters構成で実行している場合のみです。複数の文の間でアフィニティ情報が保持されることで、バッファ・キャッシュのヒット率が向上し、インスタンス間のブロックのピング回数が減少します。
この項では、パラレル実行環境でパフォーマンスを向上するための様々なアイディアを説明します。内容は次のとおりです。
パラレル更新やパラレル削除を行う場合を除けば、通常、パラレル操作ではバッファ・キャッシュ・サイズを大きくしても効果は得られません。その他のパラレル操作で効果が得られるのは、バッファ・プールのサイズを拡大して、ネストテッド・ループ結合の内部表や索引を格納できるようにした場合のみです。
デフォルトのDOPでは、どのようなパラレル操作でも適切に応答時間が短縮され、CPUやI/Oリソースの使用が約束されます。
操作がメモリー・バウンドである場合や、複数のパラレル操作が同時に実行されている場合には、デフォルトのDOPを減少させたほうがよい場合もあります。
Oracle Databaseでは、データ・ディレクトリ内にある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_USERパラメータをTRUEに設定します。
パラレル実行で最も重要なのは、大量のデータを処理する問合せ計画のあらゆる部分が、確実にパラレルに実行されるようにすることです。EXPLAIN PLANを使用すると、計画のすべての手順にOTHER_TAGのPARALLEL_TO_PARALLEL、PARALLEL_TO_SERIAL、PARALLEL_COMBINED_WITH_PARENTまたはPARALLEL_COMBINED_WITH_CHILDがあるかどうかを確認できます。その他のキーワード（またはNULL）はすべてシリアル実行であり、ボトルネックの可能性があります。また、このような計画手順が、操作のPX SEND <partitioning type>ノード（PX SEND HASHなど）で終了することも確認します。
また、utlxplp.sqlスクリプトを使用しても、すべての関連パラレル情報とともにEXPLAIN PLAN出力を表示できます。
副問合せ、特に相関副問合せを結合に変換するパラレル計画を生成すると、オプティマイザのパフォーマンスを向上できます。Oracle Databaseでは、副問合せよりも結合のほうが効率的にパラレル化されます。これは、更新にも適用されます。詳細は、「表のパラレル更新」を参照してください。
Oracle Databaseでは、ユーザー・プロセスに結果を戻す作業はパラレルには行われません。問合せで多数の行が戻される場合に、実際には問合せの実行は高速化されていても、ユーザー・プロセスではシリアルな形でしか行を受信できません。多数の結果セットを取り出す問合せにおいてパラレル実行のパフォーマンスを最適化するには、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;
一度これを行うと、ユーザーを表領域に明示的に割り当てる必要はなくなります。
ローカル管理一時表領域を使用する場合、断片化の回避に役立つのでエクステントはすべて同じサイズになります。一般に、一時領域に対する需要が高く、同時実行中のパラレル処理またはその他の操作が一時表領域を共有する必要があるため、一時エクステントは、永続エクステントより小さくする必要があります。通常、一時エクステントは1〜10MBの範囲内である必要があります。一度エクステントを割り当てると、操作の実行中は自由に使用できます。大規模なエクステントを割り当てても、小量の領域しか使用する必要がない場合にはエクステント内の未使用領域は使用できません。
同時に、一時エクステントは、プロセスの領域待機を回避するのに十分な程度には大きくする必要があります。一時表領域では、新しいエクステントの割当て時と解放時に使用されるオーバーヘッドが永続表領域に比べて少量で済みます。ただし、新しい一時エクステントを取得する際には、ラッチ取得およびSGA構造全体の検索の他、エクステント・プール・ソート用のSGA領域消費のためのオーバーヘッドも必要とされます。
ローカル管理一時表領域の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。
表および索引の分析後には、使用したDOPに基づいてパフォーマンスが向上します。
通常のプロセスと同様、簡単なパラレル操作から始めて、SELECT COUNT(*) FROM facts文でI/Oスループットの合計値を評価します。次に、この文に複雑なWHERE句を追加して、CPU総処理能力を評価します。I/Oが不均衡な場合、物理データベース・レイアウトの最適化が必要な場合があります。単純なスキャンの処理状態を理解した上で、集計、結合およびワークロード全体の個々の側面を反映するその他の操作を追加します。特に、ボトルネックについて調べる必要があります。
問合せのパフォーマンスに加えて、パラレル・ロード、パラレル索引作成およびパラレルDMLも監視し、I/OおよびCPUリソースの適切な使用率を判断する必要があります。
EXPLAIN PLAN文を使用して、パラレル問合せの実行計画を参照します。EXPLAIN PLANの出力には、COST、BYTESおよびCARDINALITY列内のオプティマイザ情報が表示されます。また、utlxplp.sqlスクリプトを使用しても、すべての関連パラレル情報とともにEXPLAIN PLAN出力を表示できます。
結合文のパラレル実行を最適化するには、いくつかの方法があります。システム構成を変更するか、この章で前述したようにパラメータを調整するか、またはDISTRIBUTIONヒントなどのヒントを使用します。
EXPLAIN PLANを使用する場合のキー・ポイントは、次のとおりです。
オプティマイザの選択的見積りの確認。オプティマイザで問合せから1行のみが生成されるとみなされている場合は、ネステッド・ループが使用される傾向があります。この場合、表が分析されない可能性や、オプティマイザで同一の表にある複数の述語の相関関係について不適切な見積りがなされている可能性があります。オプティマイザで別の結合方法が使用されるようにするには、ヒントを指定すると有効な場合があります。したがって、計画において特定の段階から1行しか生成されないことが示され、それが不適切な場合は、ヒントの使用や統計の収集を検討してください。
カーディナリティの低い結合キーでのハッシュ結合の使用。結合キーの個別値が少数の場合は、ハッシュ結合が最適でないことがあります。個別値の数がDOPより少ないと、一部のパラレル問合せサーバーが特定の問合せについて作業できないことがあります。
データの偏りの考慮。結合キーにデータの過剰な偏りがある場合は、ハッシュ結合によって一部のパラレル問合せサーバーに対し他よりも多くの作業が要求される場合があります。オプティマイザでBROADCAST分散方式が選択されなかった場合は、ヒントを使用してこれを行うことを検討してください。オプティマイザではOPTIMIZER_FEATURES_ENABLEが9.0.2以上に設定されている場合にかぎり、BROADCAST分散方式が検討されます。詳細は、「V$PQ_TQSTAT」を参照してください。
データ・ウェアハウス上でパラレル挿入、更新または削除を使用して、データ・ウェアハウス・データベースをリフレッシュする場合は、物理データベースの設計時にさらに考慮すべき点があります。これらの考慮点は、パラレル実行操作には影響しません。考慮すべき問題点は次のとおりです。
パラレル制限に違反があると、操作はシリアルに実行されます。ダイレクト・パス・インサートの制限に違反があった場合、APPENDヒントは無視され、従来型の挿入が実行されます。エラー・メッセージは戻されません。
パラレルUPDATE、MERGEまたは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要求が生成される場合があります。
ローカル索引のメンテナンスでは、ローカルのストライプ化がI/O競合の削減に最も効果的です。これは、1つのサーバー・プロセスが、その専用のディスクおよびディスク・コントローラのセットに対応すれば済むようになるからです。ローカルのストライプ化では、ディスク障害時の可用性も向上します。
グローバル索引のメンテナンス（パーティションまたは非パーティション）では、多くのディスクおよびディスク・コントローラに索引をグローバル・ストライプ化するのが、I/Oの数を分散するために最適な方法です。
グローバル索引がある場合、グローバル索引セグメントおよびグローバル索引ブロックは、同じパラレル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ログのアーカイブに対応しきれない場合があります。この問題を回避するために、複数のアーカイバ・プロセスを起動できます。これは、手動で行うか、ジョブ・キューを使用して行います。
パラレルDML操作では、短時間でバッファ・キャッシュ内の大量のデータ、索引およびUNDOブロックが使用済になります。たとえば、次の構文でV$SYSTEM_EVENTビューを問い合せた後に、free_buffer_waitsが大量に確認されることがあります。
SELECT TOTAL_WAITS FROM V$SYSTEM_EVENT WHERE EVENT = 'FREE BUFFER WAITS';
この場合、DBWnプロセスを増やすことを検討する必要があります。空きバッファの待機がない場合、この問合せで行は戻されません。
[NO]LOGGING句は、表、パーティション、表領域および索引に適用できます。NOLOGGING句が使用されると、特定の操作（ダイレクト・パス・インサートなど）に対して事実上ログが生成されません。NOLOGGING属性は、INSERT文レベルではなく、ALTERまたはCREATE文を使用して表、パーティション、索引または表領域に対して指定されます。
表または索引にNOLOGGINGが設定されている場合、パラレルまたはシリアルのダイレクト・パス・インサート操作のいずれにおいても、REDOログは生成されません。NOLOGGINGオプションが設定された状態で動作しているプロセスは、REDOが生成されないため高速で動作します。ただし、表、パーティションまたは索引に対するNOLOGGING操作後、バックアップを作成する前にメディア障害が発生した場合は、変更されたすべての表、パーティションおよび索引が破損する場合があります。
ダイレクト・パス・インサート操作（ディクショナリ更新を除く）では、REDOログは生成されません。NOLOGGING属性は、UNDOには影響せず、REDOにのみ影響します。正確には、NOLOGGINGでは、ダイレクト・パス・インサート操作によって非常に少量のREDO（フル・イメージREDOに対してレンジ無効REDO）が生成されます。
下位互換性用に、CREATE TABLE文の代替キーワードとして、[UN]RECOVERABLEがこれまでどおりサポートされています。ただし、この代替キーワードは、将来のリリースではサポートされなくなる可能性があります。
表領域のレベルでは、ロギング句によって、表領域内に作成されたすべての表、索引およびパーティションに対してデフォルトのロギング属性が指定されます。既存の表領域のロギング属性をALTER TABLESPACE文で変更すると、ALTER文の後に作成されたすべての表、索引およびパーティションに新しいロギング属性が指定されます。既存のもののロギング属性は変更されません。表領域レベルのロギング属性は、表、索引またはパーティション・レベルの指定によってオーバーライドされる可能性があります。
デフォルトのロギング属性はLOGGINGです。ただし、ALTER DATABASE NOARCHIVELOGを発行してデータベースをNOARCHIVELOGモードにした場合、ロギングなしで実行できるすべての操作では、ロギング属性の指定にかかわらずログは生成されません。
複数のプロセスを同時に連携させて索引を作成できます。索引の作成に必要な作業を複数のサーバー・プロセス間で分割することで、単一サーバー・プロセスで索引を順次作成する場合に比べ、迅速に索引を作成できます。
パラレルな索引作成は、ORDER BY句を指定した場合の表スキャンとほぼ同様の手順で行われます。表はランダムにサンプリングされ、索引をDOPと同数の部分に均等に分割する索引キーのセットが検出されます。問合せプロセスの最初のセットで表がスキャンされ、キーとROWIDの組が抽出されます。続いて、その各組がキーに基づいて、2番目の問合せプロセスのセット内にあるプロセスへと送信されます。2番目のセット内の各プロセスによってキーがソートされ、通常の方法で索引が作成されます。すべての索引部分が作成されると、パラレル・コーディネータによって（順序付けされた）部分が単純に連結され、索引が完成します。
パラレルなローカル索引作成では、単一のサーバー・セットが使用されます。セット内の各サーバー・プロセスにスキャン対象の表領域が割り当てられ、それに対して索引パーティションが作成されます。所定のDOPに対して半数のサーバー・プロセスが使用されるため、パラレルのローカル索引作成はDOPに大きな値を指定した場合に可能になります。ただし、DOPは、作成する索引パーティションの数以下に制限されます。この制限を回避するには、DBMS_PCLXUTILパッケージを使用します。
オプションで、索引の作成中にREDOおよびUNDOロギングが発生しないように指定できます。これによって、パフォーマンスは大幅に向上しますが、索引は一時的にリカバリ不能になります。リカバリは、新しい索引のバックアップ後に可能になります。アプリケーションにおいて、索引のリカバリで再作成に必要とされる時間枠の受け入れが可能な場合、NOLOGGING句の使用を検討する必要があります。
CREATE INDEX文のPARALLEL句は、索引の作成に対するDOPを指定するための唯一の方法です。CREATE INDEXのPARALLEL句にDOPを指定しない場合、CPUの数がDOPとして使用されます。PARALLEL句がない場合、索引作成はシリアルに実行されます。
索引をパラレルに作成する際には、問合せサーバー・プロセスで作成された各副索引の記憶域がSTORAGE句で参照されます。そのため、5MBのINITIALかつDOP12で作成される索引においては、各プロセスが5MBのエクステントで開始するため、作成中に60MB以上の記憶域が消費されます。ソート済の副索引が問合せコーディネータ・プロセスで組み合される際に、一部のエクステントは切り捨てられるので、作成される索引は要求された60MBよりも小さくなる場合があります。
表に対してUNIQUEまたはPRIMARY KEY制約を追加または有効化した場合、要求した索引が自動的にパラレルで作成されることはありません。かわりに、CREATE INDEX文と適切なPARALLEL句で目的の列に手動で索引を作成してから、制約を追加または有効化します。こうすることで制約の追加や有効化の際に、Oracle Databaseで既存の索引が使用されるようになります。
すべての制約がENABLE NOVALIDATE状態の場合、同じ表にある複数の制約を同時にパラレルに有効化できます。次の例では、ALTER TABLE ... ENABLE CONSTRAINT文によって、パラレルに制約をチェックする表スキャンが実行されます。
CREATE TABLE a (a1 NUMBER CONSTRAINT ach CHECK (a1 > 0) ENABLE NOVALIDATE) PARALLEL; INSERT INTO a values (1); COMMIT; ALTER TABLE a ENABLE CONSTRAINT ach;
この項では、パラレルDML機能の概要を示します。内容は次のとおりです。
表25-5 INSERT機能の要約
| INSERTのタイプ | パラレル | シリアル | NOLOGGING |
|---|---|---|---|
|
従来型 |
不可 |
可能 |
不可 |
|
ダイレクト・パス・インサート ( |
可能。次の指定が必要:
|
可能。次の指定が必要:
|
可能。次の指定が必要: パーティションまたは表に設定された |
パラレルDMLが使用可能で、PARALLELヒントまたはPARALLEL属性がデータ・ディクショナリ表に対して設定されている場合、制限が適用されないかぎり、INSERTはパラレルで追加されます。PARALLELヒントまたはPARALLEL属性がない場合、INSERTはシリアルに実行されます。
パラレルINSERT中は、APPENDモードがデフォルトです。常に、データは表に割り当てられた新しいブロックに挿入されます。そのため、APPENDヒントはオプションです。INSERT操作の処理速度を上げるには、APPENDモードを使用する必要がありますが、領域の使用率を最適化する必要がある場合には使用しないでください。APPENDモードのオーバーライドには、NOAPPENDを使用します。
APPENDヒントは、シリアルおよびパラレル両方のINSERTに適用されます。このヒントを使用すると、シリアルINSERTも高速化されます。ただし、APPENDではさらに多くの領域およびロック・オーバーヘッドが必要とされます。
NOLOGGINGをAPPENDとともに使用して、処理をより高速にできます。NOLOGGINGを指定した場合、操作に対してREDOログが生成されなくなります。NOLOGGINGはデフォルトではありません。パフォーマンスを最適化する場合に使用します。表またはパーティションにリカバリが必要な場合は、通常、使用しないようにします。リカバリが必要な場合は、操作後、すぐにバックアップを作成してください。ALTER TABLE [NO]LOGGING文を使用して、適切な値を指定します。
データ・ディクショナリ内の表またはパーティションにPARALLEL属性がある場合、その属性の設定は、INSERT、UPDATE、DELETE文および問合せのパラレル化の決定に利用されます。文中で表に対して明示的にPARALLELヒントを指定すると、データ・ディクショナリ内のPARALLEL属性の効果はオーバーライドされます。
NO_PARALLELヒントを使用して、データ・ディクショナリ内の表のPARALLEL属性をオーバーライドできます。一般に、ヒントは属性より優先されます。
DML操作については、セッションがPARALLEL DML使用可能モードにある場合にのみ、パラレル化が検討されます（ALTER SESSION ENABLE PARALLEL DMLを使用すると、このモードになります）。このモードが、問合せ、またはDML文の問合せ部のパラレル化に影響することはありません。
INSERT ... SELECT文では、SELECTキーワードの後だけでなく、INSERTキーワードの後にもPARALLELヒントを指定できます。INSERTキーワードの後のPARALLELヒントは、INSERT操作のみに適用され、SELECTキーワードの後のPARALLELヒントは、SELECT操作のみに適用されます。INSERTおよびSELECT操作のパラレル化は、それぞれ独立しています。1つの操作をパラレルで実行できなくても、他の操作をパラレルで実行できるかどうかには影響しません。
ユーザーがパラレルDMLに対して明示的にセッションを有効化し、データ・ディクショナリ・エントリ内の対象とする表にPARALLEL属性が設定されている場合、INSERTのパラレル化機能によって既存の動作が変更されます。既存のINSERT ... SELECT文でSELECT操作がパラレル化されている場合は、INSERT操作もパラレル化される場合があります。
複数の表を問い合せる場合、SELECT PARALLELヒントおよびPARALLEL属性はそれぞれ複数指定できます。
UPDATEまたはDELETEキーワードの直後に配置されたPARALLELヒントは、基礎となるスキャン操作のみでなく、UPDATEまたはDELETE操作にも適用されます。かわりに、変更する表の定義に指定されたPARALLEL句に、UPDATEまたはDELETEのパラレル化を指定することもできます。
セッションまたはトランザクションに対してパラレルDMLを明示的に有効化した場合は、問合せ操作がパラレル化されているUPDATEまたはDELETE文によって、UPDATEまたはDELETE操作もパラレル化されます。文中の副問合せや更新可能なビューには、独自のPARALLELヒントまたは句を個別に指定できますが、これらのパラレル指定は、UPDATEまたはDELETEのパラレル化の決定には影響しません。これらの操作をパラレルに実行できなくても、UPDATEまたはDELETEの部分をパラレルに実行できるかどうかには影響しません。
パラレルUPDATEおよびDELETEをサポートするには、表をパーティション化する必要があります。
パラレルDMLを更新可能な結合ビュー機能と組み合せると、データ・ウェアハウス・システムの表を効率的にリフレッシュできるようになります。表のリフレッシュとは、OLTP本番システムから生成された差分データで表を更新することです。
ここでは、例としてc_key列、c_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);
