EXPLAINリクエスト修飾子句の用語 - Advanced SQL Engine - Teradata Database

この句が出現する場合、列パーティション化されたテーブルまたは結合インデックスは行パーティション化されていません。

m1 ≥ 2。アクセス対象の列パーティションの1つが削除列パーティションである可能性があります。

該当する行がない場合は、m1個の列パーティションの一部にはアクセスする必要がなくなります。

テーブル名または結合インデックス名の後ろにusing rowid Spool句が続くことがあります。この場合、m1は行IDスプールの使用時にアクセスされる列パーティションの数になります。その一方、using rowid Spool句のm2は行IDスプールをビルドするためにアクセスされる列パーティションの数になります。

この句は、列パーティション化されたソースを読み込む可能性のある、RETRIEVEやDELETE、JOIN、MERGEなどのステップで使用されます。

削除操作の場合、Teradata Databaseが、LOBおよびROW形式の列パーティション以外の削除済み行のストレージを直ちに再利用することはありません。テーブルまたは結合インデックスのすべての行の後続の高速パス削除では、以前に削除された行を含む、テーブルで削除されたすべての行のストレージが再利用されます。

この句が出現する場合、列パーティション化されたテーブルまたは結合インデックスは行パーティション化されていません。

m1 ≥ 2。

2 < c1 < m1-1

c1は使用できる列パーティション コンテキストの数と等しいか、それより1少ない数になります。

アクセス対象の列パーティションの1つが削除列パーティションである可能性があります。該当する行がない場合は、m1個の列パーティションの一部にはアクセスする必要がなくなります。

using CP merge Spool句またはusing covering CP merge Spool句がテーブル名または結合インデックス名の後ろに続きます。

この句は、列パーティション化されたソースを読み込む可能性のある、RETRIEVEやDELETE、JOIN、MERGEなどのステップで使用されます。

m1個の列パーティションにアクセスするために、その列パーティションの列は、該当する行について射影されたすべての列が取得されるまで、一度に最大c1個の列パーティションが、列パーティション化されたスプールにマージされます。

1回以上のマージで、削除列パーティションへのアクセスが必要になることがあります。このようなマージごとの削除列パーティションが、m1に含まれます。

c1がm1よりも大幅に少なく、取得の選択性が非常に低い場合にはパフォーマンスが低下することがあります。この場合は、アクセスする必要のある列パーティションの数を減らす、テーブルのデータ ブロック サイズを減らす、列パーティションを結合して列パーティションの数を少なくする、またはPPICacheThrPを増やす(そのために使用できる十分なメモリがある場合)ことを検討してください。

削除操作の場合、Teradata Databaseが、LOBおよびROW形式の列パーティション以外の削除済み行のストレージを直ちに再利用することはありません。テーブルまたは結合インデックスのすべての行の後続の高速パス削除では、以前に削除された行を含む、テーブルで削除されたすべての行のストレージが再利用されます。

この句は、行パーティション プライマリ インデックス付きの(RPPI)テーブルまたは結合インデックスにのみ適用されます。

この句が出現する場合、テーブルまたは結合インデックスは行IDを通してアクセスされます。

テーブル名または結合インデックス名の後ろにusing rowid Spool句が続くことがあります。この場合、行IDスプールの使用時に1つの列パーティションがアクセスされます。その一方で、using rowid Spool句のm2は行IDスプールをビルドするためにアクセスされる列パーティションの数になります。

この句は、列パーティション化されたソースを読み込む可能性のある、RETRIEVEやDELETE、JOIN、MERGEなどのステップで使用されます。

列パーティション化レベルごとに、m1個の列パーティションにアクセスする必要があります。m1個の列パーティションのそれぞれに使用できる列パーティションのコンテキストが存在します。

この句が出現する場合、列パーティション化されたテーブルまたは結合インデックスは、行パーティション化と列パーティション化の両方が行なわれています。アクセス対象の列パーティションの1つが削除列パーティションである可能性があります。

該当する行がない場合は、m1個の列パーティションの一部にはアクセスする必要がなくなります。

テーブル名または結合インデックス名の後ろにusing rowid Spool句が続くことがあります。この場合、m1は行IDスプールの使用時にアクセスされる列パーティションの数になります。その一方、using rowid Spool句のm2は行IDスプールをビルドするためにアクセスされる列パーティションの数になります。

この句は、列パーティション化されたソースを読み込む可能性のある、RETRIEVEやDELETE、JOIN、MERGEなどのステップで使用されます。

削除操作の場合、Teradata Databaseが、LOBおよびROW形式の列パーティション以外の削除済み行のストレージを直ちに再利用することはありません。行パーティションのすべての行の後続の高速パス削除では、以前にそのパーティションで削除された行を含む、その行パーティションのすべての削除済み行のストレージが再利用されます。テーブルまたは結合インデックスのすべての行の後続の高速パス削除では、以前に削除された行を含む、テーブルで削除されたすべての行のストレージが再利用されます。

列パーティション化レベルごとに、m1個の列パーティションにアクセスする必要があります。この句が出現する場合、列パーティション化された表または結合インデックスは、行パーティション化と列パーティション化の両方が行なわれています。

列パーティション化レベルごとに、c1個の列パーティション コンテキストが最大m1個の列パーティションにアクセスするために使用されます。n1 ≥ 2。

m1 ≥ 2。

2 < c1 < m1-1であり、使用できる列パーティション コンテキストの数と等しいか、それより1少ない数になります。

アクセス対象の列パーティションの1つが削除列パーティションである可能性があります。該当する行がない場合は、m1個の列パーティションの一部にはアクセスする必要がなくなります。using CP merge Spool句またはusing covering CP merge Spool句がテーブル名または結合インデックス名の後ろに続きます。

この句は、列パーティション化されたソースを読み込む可能性のある、RETRIEVEやDELETE、JOIN、MERGEなどのステップで使用されます。m1個の列パーティションにアクセスするために、その列パーティションの列は、該当する行について射影されたすべての列が取得されるまで、一度に最大c1個の列パーティションが、列パーティション化されたスプールにマージされます。

1回以上のマージで、削除列パーティションへのアクセスが必要になることがあります。このようなマージごとの削除列パーティションが、m1に含まれます。

c1がm1よりも大幅に少なく、取得の選択性が非常に低い場合にはパフォーマンスが低下することがあります。この場合は、アクセスする必要のある列パーティションの数を減らす、テーブルのデータ ブロック サイズを減らす、列パーティションを結合して列パーティションの数を少なくする、またはPPICacheThrPを増やす(そのために使用できる十分なメモリがある場合)ことを検討してください。

削除操作の場合、Teradata Databaseが、LOBおよびROW形式の列パーティション以外の削除済み行のストレージを直ちに再利用することはありません。行パーティションのすべての行の後続の高速パス削除では、以前にそのパーティションで削除された行を含む、その行パーティションのすべての削除済み行のストレージが再利用されます。テーブルまたは結合インデックスのすべての行の後続の高速パス削除では、以前に削除された行を含む、テーブルで削除されたすべての行のストレージが再利用されます。

この場合、Teradata DatabaseはARSA集約アルゴリズムの4つのステップをすべて実行します。

1. マップ内の各AMPにローカルで集約します。
2. ローカルな集約をそれらのターゲットAMPに再構築。
3. 再構築した集約のソート。

   プロセスのこの段階には、重複行の排除も含まれます。

4. 最終的な集約を計算するためのグローバルな集約。

この場合、Teradata DatabaseはARSA集約アルゴリズムのステップのローカル集約のみを実行します。

この句は、列パーティション化されたテーブルまたは結合インデックスには適用されません。これらのオブジェクトには、プライマリ インデックスがないためです。

テーブル名または結合インデックス名の後ろにusing rowid Spool句が続くことがあります。この場合、行IDスプールの使用時に1つの列パーティションがアクセスされます。その一方で、using rowid Spool句のm2は行IDスプールをビルドするためにアクセスされる列パーティションの数になります。

この句は、列パーティション化されたソースを読み込む可能性のある、RETRIEVEやDELETE、JOIN、MERGEなどのステップで使用されます。

削除操作の場合、Teradata Databaseが、LOBおよびROW形式の列パーティション以外の削除済み行のストレージを直ちに再利用することはありません。テーブルまたは結合インデックスのすべての行の後続の高速パス削除では、以前削除された行を含むテーブルのすべての削除済み行のストレージが再利用されます。

この句が出現する場合、列パーティション化されたテーブルまたは結合インデックスは、行パーティション化と列パーティション化の両方が行なわれています。また、この句は、列パーティションがROW形式であるか、アクセスが行ID経由であるため、削除列パーティションはアクセスされる必要がないことを示しています。

テーブル名または結合インデックス名の後ろにusing rowid Spool句が続くことがあります。この場合、行IDスプールの使用時に1つの列パーティションがアクセスされます。その一方で、using rowid Spool句のm2は行IDスプールをビルドするためにアクセスされる列パーティションの数になります。

この句は、列パーティション化されたソースを読み込む可能性のある、RETRIEVEやDELETE、JOIN、MERGEなどのステップで使用されます。

この句は、列パーティション化されたテーブルまたは結合インデックスには適用されません。

句が指定されていない場合、結合はハッシュ ベースです。つまり、派生されるハッシュからプライマリ インデックス列に等号制約があります。

なお、いずれの方法でも結合条件が検証される必要があります。

現在のステップから、ステップnのEND ROW TRIGGER LOOP句が現われるステップまでのすべてのAMPステップが行トリガー ループを構成します。

制御がトリガー外の次のステップに移行します。

この場合の値は、m3 ≥ 2になります。

次のリクエストでは、employee.empno = department.mgrnoが結合に適用される制約です。

     SELECT deptname, name
     FROM employee, department
     WHERE employee.empno = department.mgrno;

結合条件は、外部結合のON句、またはANSI SQL規格形式の内部結合でも指定されます。

読み取りモードが(load uncommitted)の場合は、Teradata Databaseが論理的に削除された行を処理中に無視することを示します。その他すべての行は読み取られます。

ロード分離の詳細については、<Teradata Vantage™ - SQLデータ定義言語-構文規則および例、B035-1144>および<Teradata Vantage™ - SQLデータ操作言語、B035-1146>を参照してください。

この句が出現する場合、変更されているテーブルはロード分離テーブルまたはロード分離テーブルで定義された結合インデックスです。

ロード分離である削除操作は、行を物理的に削除するのではなく、行を論理的に削除されたもの、および行のバージョン情報が設定されたものとしてマークします。ロード分離である更新操作は、古い値が保持されるなどの対象行にバージョンを設定します。ロード分離である挿入操作は、同時読み取りユーザーに行のコミット プロパティを提供するロード識別値を持つ行をマークします。

そのような変更の最中に、テーブルまたは結合インデックスの同時読み取りセッションは、引き続きロード コミット済み行を取得することができますが、実行中のロードでの変更はコミットするまで表示されません。

ロード分離の詳細については、<Teradata Vantage™ - SQLデータ定義言語-構文規則および例、B035-1144>および<Teradata Vantage™ - SQLデータ操作言語、B035-1146>を参照してください。

m3 ≥ 2。

最適化ルーチンは、コストが最小になる方法を使用するように提案します。ただし、行を挿入するときに、AMPが別の方法に変更する場合があります(別の方法が実行に適しているとAMPが判断した場合)。

m3 ≥ 2。

2 < c3 < m3

最適化ルーチンはAMPに対して使用する方法を提案しますが、行を挿入するときに、AMPが別の方法に変更する場合があります(別の方法が実行に適しているとAMPが判断した場合)。

• 更新操作と挿入操作の両方
• 挿入操作のみ
• 更新操作のみ

このステップは、ソース テーブルが常にソース テーブルの結合列で分散されることを前提としています。これは、ターゲット テーブルのプライマリ インデックスとの等式制約としてON句で指定され、RowKeyに基づいてソートされます。

このステップは、ターゲット行を更新する条件を満たすソース行と、挿入の条件を満たすソース行を識別して、RowKeyベースのマージ結合を内部的に実行してから、更新と挿入を実行します。

このステップは、マージ操作中にターゲット テーブルのデータ ブロックの読取りおよび書込みが一度だけ実行されることを保証するので、MultiLoadのAPPLYフェーズに非常に似ています。

外部テーブルでは、Teradata DatabaseがAWS S3などの外部のクラウドベースのデータ ストレージからデータにアクセスできるため、最初にデータを元々あった場所から手動でデータベースに移動する必要はありません。外部テーブルは、ホスト名やパスのほか、外部ストレージを参照するその他のメタデータによって識別されます。Teradata Databaseは、標準SQLを使用して、外部テーブル内の半構造化または非構造化データを読み取り、処理することができます。例えば、Teradataの分析関数を使用してデータを調べ、データベース内のリレーショナル データに結合し、Teradata Database内の他のデータと同じようにクエリーを発行できます。

このフェーズでは、前にロックが取得されたステップが常にレポートされるわけではありません。

この句が出現する場合、変更されているテーブルはロード分離テーブルまたはロード分離テーブルで定義された結合インデックスです。

そのような変更は、行にバージョンを設定しないロード分離ではないテーブルでの通常の変更と同様です。違いは、そのような変更が発生するとEXCLUSIVEロックが適用されることです。

そのような変更の最中は、トランザクションが終了するまで(ACCESSロックが使用される場合を含む)同時読み取りセッションがブロックされます。

ロード分離の詳細については、<Teradata Vantage™ - SQLデータ定義言語-構文規則および例、B035-1144>および<Teradata Vantage™ - SQLデータ操作言語、B035-1146>を参照してください。

n3 > 1。

n3は1より大きくなります。

nの値は、常に1より大きくなります。

場合によっては、これはパーティション全体のより高速な削除が可能になります。

この句は、列パーティション化されたテーブルまたは結合インデックスには適用されません。そのような場合には、別の句が使用されるためです。

場合によっては、これは組み合わせパーティション全体のより高速な削除が可能になります。

この句は、列パーティション化されたテーブルまたは結合インデックスには適用されません。これは、列パーティション化されたテーブルまたは結合インデックスには少なくとも2つの列パーティションが存在するためです(少なくとも1つの指定された列パーティションと削除列パーティション)。

「in all partitions」句は、テーブル レベル ロックのプロキシを示します。

「in n partitions」句は、パーティション範囲ロックのプロキシを示します。

「in a single partition」句は、単一パーティション ロックのプロキシを示します。

詳細については、プロキシ ロックを参照してください。

例えば、NUSIサブテーブルを調査して、問合わせの条件を満たす可能性がある基本テーブルの行の行ID値を入手することができますが、NUSIの基礎となる基本テーブルにアクセスして、確実に条件を満たす行を入手する必要もあります。

説明文のLOCK部分で明確に説明されていませんが、テーブルは固有プライマリ インデックスによりアクセスされるため、行ハッシュ ロックが必要です。

固有に定義されるスプール行のその他の値(集約およびsubquery を含む複雑な問合わせに使用される)。

例えば、“…SORT to partition by rowkey…”または“…SORT to order Spool 1 by the sort key in spool field1 (THU.JI1.b1)…”です。

例えば、“…SORT to partition by rowkey…”または“…SORT to order Spool 1 by the sort key in spool field1 (THU.JI1.b1)…”です。

• 通常、Spool 1はユーザーに返す前に結果を保持するために使用されます。
• Spool 2、Spool 3などには結果を作成する中間データが含まれます。

例:

     personnel.employee.empno = spool_2.mgrno
     Statement 1...

この用語はリクエストの処理開始を指します。

ステップの後に、スプールn統計の格納場所が報告され、統計は統合されます。統計が追加実行時情報から取得された場合、スプールのサイズは指定されます。

表示される時間は時刻ではないことに注意してください。別の操作と比較するために使用できる任意の測定単位と見なしてください。

表示される時間は時刻ではありません。別の操作と比較するために使用できる任意の測定単位と見なしてください。

バイト単位のスプール サイズは次のように計算されます。

行サイズは、行に可変長または圧縮された列が含まれている場合の推定平均行サイズです。

この句が含まれる場合、DBC.DBQLExplainTblの汎用計画の最初のステップより前に置かれます。計画のEXPLAINテキストがDBQLによってログに記録されている場合、EXPLAIN、STATIC EXPLAIN、DYNAMIC EXPLAINのいずれかのリクエスト修飾子を指定すると、示されません。

これは、増分計画および実行に適格な特定の静的計画ですが、システム指定の特定のコストしきい値を満たしていません。Teradata Databaseがリクエストを実行すると、この静的計画が生成および実行されます。

汎用計画は必ず静的計画になります。リクエストが実行されると、汎用計画、特定の静的計画、または動的計画のいずれかが生成および実行される可能性があります。この句は、DBQLによってログが記録されている計画のEXPLAINテキスト内のDBC.DBQLExplainTblでは示されません。

これは、増分計画および実行に適格な特定の静的計画ですが、リクエストが実行される場合、この静的計画ではなく、動的計画が生成および実行される可能性があります。ただし、この静的計画は、ワークロードのフィルタ、スロットル、および分類基準を評価する際に使用されます。

リクエストが実行されるもののIPEが引き続き無効な場合には、Teradata Databaseは静的計画を生成および実行します。リクエストが実行されてIPEが有効な場合は、動的計画が生成されます。動的計画を有効にするには、Teradataカスタマー サポートに問い合わせてください。

• 多くても、サブテーブルの行が格納されているAMPにハッシュ格納されているインデックス値を使用して、USIサブテーブルの単一行が選択されます。
• インデックス行IDのハッシュ値により、データ行が格納されるAMPが決定されます。

s1 は、s1 + s2 中のマージに必要な中間subrow列パーティションの数は必要な結合の数を示しますを示します。

s 1が含まれていない場合、中間副行列パーティションがマージに必要なく、s2回のマージが必要になります。

必要になるマージの回数は、アクセスする必要のある列パーティションの数と、使用できる列パーティション コンテキストの数(先行する接続元句で示される)に応じて決まります。これで、この列パーティション化されたマージ スプールの使用が終わるため、このスプールを削除できます。

qは、列パーティション化されたマージ スプールのスプール番号です。

s1は、マージに必要な中間副行列パーティションの数を示します。

s 1 + s 2は、必要になるマージの回数を示します。

s1が含まれていない場合、中間サブ行列パーティションがマージに必要なく、s2回のマージが必要になります。

必要になるマージの回数は、アクセスする必要のある列パーティションの数と、使用できる列パーティション コンテキストの数(先行するfrom句で示される)に応じて決まります。

これで、この列パーティション化されたマージ スプールと行IDスプールの使用が終わるため、これらのスプールを削除できます。

qは、列パーティション化されたマージ スプールのスプール番号です。

kは、行IDスプールのスプール番号です。

行IDスプールのkが、前のステップではなく、このAMPステップで生成される場合は、このbuilt from句の後に使用句が続きます。

s1は、マージに必要な中間副行列パーティションの数を示します。

s1 + s2は、必要になるマージの回数を示します。

s1が含まれていない場合、中間副行列パーティションがマージに必要なく、1回またはs2回のマージが必要になります。

必要になるマージの回数は、アクセスする必要のある列パーティションの数と、使用できる列パーティション コンテキストの数(先行するfrom句で示される)に応じて決まります。

これで、この列パーティション化されたマージ スプールの使用が終わるため、このスプールを削除できます。

qは、列パーティション化されたマージ スプールのスプール番号です。

s1は、マージに必要な中間副行列パーティションの数を示します。

s1 + s2は、必要になるマージの回数を示します。

s1が含まれていない場合、中間副行列パーティションがマージに必要なく、1回またはs2回のマージが必要になります。

これで、この列パーティション化されたマージ スプールと行IDスプールの使用が終わるため、これらのスプールを削除できます。

qは、列パーティション化されたマージ スプールのスプール番号です。

kは、行IDスプールのスプール番号です。

行IDスプールのkが、前のステップではなく、このAMPステップで生成される場合は、このbuilt from句の後に使用句が続きます。

これで、この行IDスプールの使用が終わるため、このスプールを削除できます。

kは、行IDスプールのスプール番号です。

行IDスプールのkが、前のステップではなく、このAMPステップで生成される場合は、このbuilt from句の後に使用句が続きます。

この句は、列パーティション化されたソースを読み込む可能性のある、RETRIEVEやJOIN、MERGEなどのAMPステップで使用されます。

述部の評価と行IDスプールの作成のために、列パーティション化されたテーブルまたは結合インデックスの最大m2個の列パーティションにアクセスする必要があります。

m2個の列パーティションのそれぞれに使用できる列パーティションのコンテキストが存在します。

この句が出現する場合、列パーティション化されたテーブルまたは結合インデックスが行パーティション化されていることはありません。

m2 ≥ 2。

アクセス対象の列パーティションの1つが削除列パーティションである可能性があります。

該当する行がない場合は、m2個の列パーティションの一部に実際にはアクセスする必要がなくなります。

この句は、列パーティション化されたソースを読み込む可能性のある、RETRIEVEやJOIN、MERGEなどのAMPステップで使用されます。

述部の評価と行IDスプールの作成のために、c2の列パーティション コンテキストを使用して、列パーティション化されたテーブルまたは結合インデックスの最大m2個の列パーティションにアクセスする必要があります。この句が出現する場合、列パーティション化された表または結合インデックスは行パーティション化されていません。

kは、行IDスプールのスプール番号です。

m2 ≥ 2。

2 < c2 < m2-1であり、使用できる列パーティション コンテキストの数と等しいか、それより1少ない数になります。

アクセス対象の列パーティションの1つが削除列パーティションである可能性があります。該当する行がない場合は、m2個の列パーティションの一部にはアクセスする必要がなくなります。

この句は、列パーティション化されたソースを読み込む可能性のある、RETRIEVEやJOIN、MERGEなどのAMPステップで使用されます。

述部の評価と行IDスプールの作成のために、テーブルまたは結合インデックス(この場合、行パーティション化と列パーティション化の両方が行なわれている)の最大n2個の組み合わせパーティションの行と列にアクセスする必要があります。

kは、行IDスプールのスプール番号です。

m2個の列パーティションのそれぞれに使用できる列パーティションのコンテキストが存在します。

m2 ≥ 2。

アクセス対象の列パーティションの1つが削除列パーティションである可能性があります。

該当する行がない場合は、m2個の列パーティションの一部にはアクセスする必要がなくなります。

この句は、列パーティション化されたソースを読み込む可能性のある、RETRIEVEやJOIN、MERGEなどのAMPステップで使用されます。

kは、行IDスプールのスプール番号です。

述部の評価と行IDスプールの作成のために、行パーティション化と列パーティション化の両方が行なわれているテーブルまたは結合インデックスの最大n2個の組み合わせパーティションの行と列にアクセスする必要があります。

列パーティション化レベルごとに、c2個の列パーティション コンテキストが最大m2個の列パーティションにアクセスするために使用されます。

n2 ≥ sおよびm2 ≥ 2

2 < c2 < m2-1であり、使用できる列パーティション コンテキストの数と等しいか、それより1少ない数になります。

アクセス対象の列パーティションの1つが削除列パーティションである可能性があります。該当する行がない場合は、m2個の列パーティションの一部にはアクセスする必要がなくなります。

この句は、列パーティション化されたソースを読み込む可能性のある、RETRIEVEやJOIN、MERGEなどのAMPステップで使用されます。

BMSMSは、次の行IDビット マップに共有部分を持ちます。

     1)   The bit map built for … by way of index #  n...
     2)   The bit map built for … by way of index #  n...
      …

結果のビットマップがスプールnに置かれます..。

     BMSMS...

2つ以上のビットマップがAND 演算によって交差することがわかったため、1つの大きなビットマップが形成される、ことを示しています。

     index #  n...

AND演算で使用される各非固有セカンダリ インデックスを、ANDで結合する順に識別します。

     resulting bit map is placed in Spool  n...

BMSMSにより作成される大きなビットマップが最終結果の作成に使用できるように格納される一時ファイルを特定します。

EXPLAINリクエスト修飾子: 例も参照してください。

この場合、column_name_1とcolumn_name_2の固有性が極めて低くなります。その理由は、これらの2つの行に対する事前集約のために、最適化ルーチンがコストベースの決定を行ない、その結果をそれぞれの列に収集するためです。この最適化によって、基本テーブルの読み取りが1回だけになり、それぞれの列に対する集約は事前集約されたデータに対する操作になるため実行速度が速くなります。

この最適化は、統計の再収集にのみ使用されます。また、適用可能な統計が単一のCOLLECT STATISTICSリクエストに指定されている場合にのみ、この最適化が可能になります。

これに該当する場合、単一列統計がcolumn_name_1とcolumn_name_2について収集され、複数列統計が(column_name_1, column_name_2)について収集されます。

複数列の場合の集約が最初に実行されます。この集約の結果は、column_name_1とcolumn_name_2に対する個別の統計にいての統計を収集するために使用されます。この方法によって、基本テーブルの読み取りが1回だけになり、それぞれの列に対する集約は事前集約されたデータに対する操作になるため実行速度が速くなります。

この最適化は、3つの統計のすべてが、単一のCOLLECT STATISTICSリクエスト内に指定されている場合にのみ可能になります。

最初のレベルは非行パーティション テーブルに使用され、レベル2から4は行パーティション テーブルに使用されます。

2つ目の句は、行パーティション テーブルに使用されるプロキシ ロックを示します。

最初および2つ目の句は両方とも、3つ目の句のプロキシ ロックのためのシリアル化ロックを示します。テーブル レベル単一WRITEロックでは、行ハッシュWRITEロックされていないデータで同時読み取りを行なうことができます。

4つ目の句は、5つめの句の全AMP単一WRITEロックをシリアル化するために使用されるプロキシ ロックを示します。このタイプの単一WRITEロックは、ターゲット テーブルでNUSI、USI、またはRIメンテナンスが必要な、パーティション ロック バルクDMLの特定のケースに使用されます。

5つ目の句は、バルクDML処理中にWRITEロックされていないテーブルのデータで同時読み取りを行なうことができる単一WRITEロックを示します。

nは、計画フラグメントの数を示します。計画フラグメントの先頭を示す、計画内のステップはありません。

動的計画の場合、最初のステップは最初の計画フラグメントの先頭になります。END PLAN FRAGMENTステップの後の最初のステップは、次の計画フラグメントの先頭になります。動的計画の最後のステップは、最後の計画フラグメントの末尾になり、最後の計画フラグメントのEND PLAN FRAGMENTステップはありません。計画内の計画フラグメントの数および最後の計画フラグメントの数は、最後のEND PLAN FRAGMENTステップの数に1を加えた数になります。