パーティション化されたテーブルの処理時に、さまざまなメモリ制限が課せられることがあります。次の表は、これらの制限のいくつかに関連するエラー メッセージ番号を列挙し、それらの説明および対処方法を提供します。
| メッセージ番号 | 問題 | 考えられる原因 | 対処方法 |
|---|---|---|---|
| 3708 | テーブル ヘッダーのサイズ制限を超過しています(<Teradata Vantage™ - データベースの設計、B035-1094>を参照)。 制限はthinテーブル ヘッダーで64 KBで、fatテーブル ヘッダーで1 MBです。 |
テーブルの列が多すぎます。 | 可能なら、テーブルの列を減らしてください。 |
| テーブルで圧縮された固有の値が多すぎます。 | 可能なら、圧縮する値の数を減らしてください。 | ||
| パーティション式が複雑すぎます。 | パーティション式を簡潔にするか、数を減らしてください。 可能なら、CASE_Nではなく、RANGE_NをEACH句とともに使用します。 |
||
| 3710 | 構文解析プログラムのメモリ サイズ制限を超過しました。 この制限は可変であり、DBS制御のMaxParseTreeSegsパラメータの値によって決まります。 |
DBS制御のパラメータの現行値は、リクエストを処理するのに十分な構文解析プログラム メモリを割り振っていません。 | 次のDBS制御パラメータの値を、指定された設定に変更してください。 クエリーの作業負荷の大きさによっては、これらの値をさらに増やす必要があります。 DBS制御レコードのMaxParseTreeSegsの値を変更する方法については、<Teradata Vantage™ - データベース ユーティリティ、B035-1102>を参照してください。
|
| パーティション式が複雑すぎます。 | パーティション式を簡潔にするか、数を減らしてください。 可能なら、CASE_Nではなく、RANGE_NをEACH句とともに使用します。 |
||
| 3891 | パーティションCHECK制約のテキスト サイズ制限を超過したかどうかを調べます。 パーティションCHECK制約テキストは、テーブルまたは結合インデックスのパーティション式から派生されます。 |
PPI定義のパーティション式のテキストが長すぎます。 | パーティション制約のテキストを、16,000文字以下にしてください。 シングルレベル パーティションの場合は、次の制約を定義するために、16,000文字のうちの30文字の文字制限が適用されます。CHECK (partitioning_expression) BETWEEN 1 AND 65,535。このため、パーティション式の制限は16,000 - 30 = 15,970文字になります。 |
| 3930 | ディクショナリのキャッシュが満杯です。 | ディクショナリのキャッシュが小さすぎます。 | ディクショナリ キャッシュのサイズを1 MBに増やしてください。 ディクショナリ キャッシュのデフォルト サイズは1MBなので、DBAによってディクショナリ キャッシュのサイズがデフォルトより少ない値に減らされた場合にのみ、サイズを増やすことが必要になります。 |
これらのエラー メッセージについての詳細は、<メッセージ>を参照してください。
DBS制御ユーティリティ(詳細は<Teradata Vantage™ - データベース ユーティリティ、B035-1102>、<Teradata Vantage™- SQLリクエストおよびトランザクション処理、B035-1142>、および<Teradata Vantage™ - データベースの設計、B035-1094>を参照)のPPICacheThrPパラメータは、複数のパーティションを処理する操作で使用されるキャッシュのしきい値を計算するためにシステムにより使用されるパーセント値を指定します。値は0.10パーセント単位で指定され、0～500の範囲内に設定できます。
また、PPICacheThrPは、列パーティション テーブルの列パーティション値を列パーティションに追加するときに、バッファに割り当てることができるメモリ セグメント数を算出するパーセント値も指定します。
これらのメモリのサイズの合計からオーバーヘッドを引き、列パーティション コンテキストのサイズで割った数が、使用可能な列パーティション コンテキストの数です。列パーティション ターゲット テーブルに、使用可能な列パーティション文脈よりも多くの列パーティションが含まれる場合は、列パーティション セットを処理するためにソース行を介した複数の受渡しが必要です。ここで、各セットの列パーティションの数は、使用可能な列パーティション文脈の数です。この場合、開いているファイル コンテキストは1つのみですが、各列パーティション コンテキストがメモリにバッファを割り当てます。
最適化ルーチンは、パーティション化されたテーブルへのアクセスの時点で使用できる利用可能なファイル文脈の数を決定するためにも、DBS制御パラメータPPICacheThrPを使用します。
| PPICacheThrPによって決まる利用可能なファイル文脈の数 | Teradata Databaseが利用可能と判断するファイル文脈の実際の数 |
|---|---|
| < 8 | 8 |
| > 256 | 256 |
Teradata Databaseは、ファイル文脈の数を、列パーティション テーブルに対して利用可能な列パーティション文脈の数として使用します。
理想的には、列パーティション文脈の数を、最低でも、1つのリクエストでアクセスする必要のある列パーティションの数と同じにしてください。それより少ないと、必要な列パーティションのすべてを一度に読み取ることができないため、パフォーマンスが低下することがあります。
PPICacheThrPを高く設定し過ぎると、パフォーマンスとメモリ使用量が影響を受けます。これは、メモリ スラッシングやシステム クラッシュにつながることがあります。反対に、DBS制御パラメータPPICacheThrPの値を不必要に低く設定すると、パフォーマンスが大幅に低下し、パーティション化する利点がなくなる恐れがあります。
大部分のワークロードに対してはデフォルト値が適切と想定されますが、バランスをとるために調整が必要になることがあります。
PPIキャッシュしきい値(PCT)は、AMPごとのファイル システム キャッシュの値が100 MB未満のバイト パック形式システムおよびバイト整合形式システムでは次のように定義されます。
PCTは、AMPごとのファイル システム キャッシュの値が100 MBを超えるバイト整合形式システムでは次のように定義されます。
デフォルトは10。これは1.0パーセントを表わします。これは1.0パーセントを表わします。最初にクエリー ワークロードでの変更の影響を十分に分析せずに、この値を変更しないでください。
- データブロックはメモリに常駐させる。
ディスクにスワップされる必要がある場合、パフォーマンスが低下し始めることがあります。
- コンテキストの数は、処理されている空でない、非除去パーティションの数を超えることはありません。
この場合、各パーティションにはコンテキストがあり、追加のコンテキストが使用されることはないので、PPICacheThrPの値を大きくしてもパフォーマンスは向上されません。
- パーティション化されたテーブルでの結合。
- パーティション化されたテーブルの集約。
これらの種類の操作中にメモリの競合が発生する場合は、PPICacheThrPを減らす必要があります。
パーティション化されたテーブルでの結合。
パーティション化されたテーブルまたはスプールのプライマリ インデックスで結合が実行され、他方のテーブルまたはスプールがパーティション化されていない場合、パーティション テーブルまたはスプールから一度に処理されるパーティションの最大数は、以下のように計算されます。
結合が2つのパーティション化された関係のプライマリ インデックスで行われた場合、この関係から一度に処理されるパーティションの最大数は、以下のように計算されます。
説明
処理中のパーティションごとに1つのデータ ブロックが常にメモリに常駐します。
この等式での変数の定義は、以下のとおりです。
| 等式要素 | 指定内容 |
|---|---|
| f1 | 最適化ルーチンにより定義されているように、結合の左側の関係から一度に処理されるパーティション数。 |
| f2 | 最適化ルーチンにより定義されているように、結合の右側の関係から一度に処理されるパーティション数。 |
| db1 | 結合の左側の関係の、推定される平均データブロックサイズ。 |
| db2 | 結合の右側の関係の、推定される平均データブロックサイズ。 |
パーティション化されたテーブルの集約
パーティション化されたテーブルのプライマリ インデックスをシステムが集約する場合、テーブルから一度に処理されるパーティションの最大数は以下のように計算されます。
処理中のパーティションごとに1つのデータ ブロックが常にメモリに常駐します。