作業ファイル・データベースのストレージ要件
作業ファイル・データベースは、作業用ストレージを必要とする SQL ステートメントを 処理するためのストレージとして使用されます。
作業ファイル・ストレージは、ソート、作業ファイルへの RID プール・オーバーフロー、および一時表と共通表式用に使用されます。
作業ファイルの使用量は、作業ファイルを必要とする操作の数と、作業ファイルを必要とする並列ユーザーの数に応じて異なります。 Db2統計トレースを収集することにより、作業ファイルの使用量をモニターすることができます。 作業ファイル用に割り振るスペースの量を算定するためのガイドラインとして、トレースからの作業ファイル使用量の上限基準点を使用します。
Db2 をインストールする場合は、 インストールに必要なストレージ容量を参照してください。
マイグレーションのストレージ要件
ソートすべきデータが大量で、同時並行のソート活動が大量にある場合は、作業ファイル・データベースにより 多くのストレージが必要になる可能性があります。 圧縮データをソートする場合は、データが圧縮されていないと仮定して 必要なストレージと同じ量を見積もってください。 必要となるストレージの最大量は、作業ファイル・ データベースを使用する同時並行活動数の最大の組み合わせの要件を満足する量です。 ソートに必要なストレージの量は、以下の変数によって異なります。
- データ・サイズ
- ソート・キー・サイズ
Db2 12 への移行に際しては、ワークファイルデータセットおよびワークファイルバッファプールの 32KB のワークファイル割り当てを増やす必要があるかもしれません。 以前の Db2 リリースで 32KB の作業ファイルを定義していない場合は、 32KB の作業ファイルを Db2 12 で定義する必要があるかもしれません。 ソート処理とパフォーマンスの改善を実装するために、 Db2 12 は以前の Db2 リリースよりも多くの 32KB 作業ファイルを使用しています。 膨大な数のレコードをソートする場合、 Db2 12 は、以前のリリースでは使用されていなかったとしても、 32KB の作業ファイルが必要になる場合があります。Db2 12が、大量のレコードをソートするために 32KB 作業ファイルを使用し、32KB 作業ファイル・スペースが不足している場合、Db2 12は、より小さいサイズの作業ファイルを使用することはできません。 ソートを必要とする操作が失敗し、十分な作業ファイル・スペースがないことを示すエラーが発生します。

ソートの実行に必要な作業ファイル・スペースの合計量は、以下のようにして見積もることができます。
- MIN は、値のセットから最小値を選択する操作を行うものとします。
- FLOOR は、実数の小数部分を切り捨てる操作を行います。
- CEILING は、実数を次に大きい整数に切り上げる操作を行います。
- Data は、合計データ長 (バイト単位) です。
- Key は、ソート・キーの合計の長さです。
- Row-overhead は、6 バイトのレコード・ヘッダーに 2 バイトのレコード・ページ・マップ・エントリーをプラスしたものです。
- Prefix は、16 バイトのヘッダーです。
- Rows は、ソートされる総行数です。
- Segsize はセグメント・サイズです。
Records per page = MIN(MAXROWS, FLOOR (4056 / (Data + Key + Row-overhead)))
Total pages = CEILING (Rows / Records per page)
Total segments = CEILING (Total pages / Segsize)
Total pages used = Total segments + Segsize)1 ページ当たりのレコード数は 255 (MAXROWS の値) を超えることができません。
この結果、ソート処理後の作業ファイル・データベースに必要なストレージの量が分かります。 ただし、ソート処理でマージ・フェーズが必要な場合は、いずれの時点でも、 レコードの中間コピーがさらにあるはずです。 大部分のサブシステムでは、ソートに関連するレコードの約半数に 2 つのコピーがあると 見なしても差し支えありません。 したがって、乗数は 1.5 が適しています。 余裕を持ちたい場合は、 乗数の値に 2 を選択します。 そのため、ソート処理中のワークファイルデータベースで使用されるストレージの量は、ソート処理後に必要なストレージの1~2倍の範囲で変動します。 使用可能なバッファー・プール・ストレージがほとんどない場合、実際に使用されるストレージも 増える可能性があります。
ラージ・オブジェクト (LOB) 列が結果表の一部であり、結果表はソートのために作業ファイルに 格納する必要がある場合、実際の LOB 列のデータは作業ファイルに格納されません。 したがって、LOB 列は、Db2が必要とする作業ファイル・スペースの量が大きく増加する必要はありません。 作業ファイルの計算では、作業ファイルの LOB 列当たり 51 バイトのストレージを想定できます。
ただし、ラージ・オブジェクト (LOB) 列が INLINE 属性で定義されており、結果表を作業ファイルに格納する必要がある場合、インライン LOB 列のデータは作業ファイルに格納されます。 したがって、作業ファイルの計算では、インライン LOB の長さを考慮する必要があります。
Tracks = CEILING (Total pages used / r) * safety_factor例 1: COL1 CHAR(3) NOT NULL、COL2 CHAR(4)、COL3 VARCHAR(20)、および COL4 SMALLINTの非固有の埋め込み索引を作成するための、45,327 行が含まれる表 (TABLE1) を検討してください。 この索引を作成するためにDb2が必要とする一時記憶域の量を判別します。
- データ = 3 + (4 + 1) + (20 + 1) + (2 + 1) + 4 = 36
- キー = 36 (データ に RID を加えたもの が CREATE INDEX 用のキー)
- 行数 = 45,327
- レコード・オーバーヘッド = 8
- ページ当たりのレコード数 = MIN(MAXROWS, FLOOR (4056 / (36 + 36 + 12))) = 48
- 合計ページ数 = CEILING (45,327 / 50) = 907
- セグメント数 = CEILING (907 / 24) = 38
- 合計使用ページ数 = CEILING (38 * 24) = 912
- トラック数 = CEILING (912 / 12) * 1.5 = 114
例 1 は、索引キーを作業ファイル・データベースに保管するためのデータ・ページ計算です。 この例では、3390 ストレージ・デバイスの 114 トラックが必要です。 VARCHAR 列の 2 バイトの長さフィールドは 、CREATE INDEX 用のデータ の一部ではありません。 RID フィールドは 、データ の一部であり、キー には、RID も 含めたデータ 部分の全体が含まれます。
例 2: 再び TABLE1 と次の SQL 照会について考えます。
SELECT COL1,COL2,COL3,COL4
FROM TABLE1
ORDER BY COL2,COL3,COL1;この照会は、ORDER BY 文節を含んでおり、ソートを必要としています。 この表に必要な一時ストレージの量は、次のようにして判別します。
- データ = 3 + (4 + 1) + (20 + 2 + 1) + (2 + 1) = 34
- キー = (4 + 1) + (20 + 1) + 3 = 29
- 行数 = 45,327
- レコード・オーバーヘッド = 8
- セグメント・サイズ = 24
- ページ当たりのレコード数 = MIN(MAXROWS, FLOOR (4056 / (34 + 29 + 12))) = 54
- 合計ページ数 (最終結果) = CEILING (45,327 / 57) = 796
- セグメント (最終結果) = CEILING (796 / 24) = 34
- 合計使用ページ数 = CEILING (34 * 24) = 816
- トラック数 = CEILING (816 / 12) * 1.5 = 102
- 合計ページ数 (処理中) = CEILING (1.5 * 796) = 1194
- セグメント数 (処理中) = CEILING (1.5 * 34) = 51
- 合計使用ページ数 (処理中) = CEILING (51 * 24) = 1224
- トラック数 (処理中) = CEILING (1224 / 12) * 1.5 = 153
表計算のこの例では、3390 ストレージ・デバイスの 102 トラックが必要です。 VARCHAR 列の 2 バイト長フィールドはデータの一部であり、キーにデータ部分の全体は含まれません。
ソートサマリートレースレコード(IFCID 96)を使用すると、一部の計算を簡略化することができます。 このレコードには、ソートされるレコードの数、ソート・レコード・ サイズ (データ + キー)、および個々のソート要求にマージ・フェーズが必要であったかどうかを示すものが記録されています。
また、レコード全体の長さ (データ + キー + 接頭辞) が 100 バイトを超えると、Db2は、32 KB ページ・サイズの表スペースに作業ファイルを作成しようとします。 レコード全体の長さが 100 バイト以下の場合、Db2は 4 KB ページ・サイズの表スペースを使用します。
インストールのストレージ要件
Db2をインストールする場合は、以下の計算を使用して、作業ファイル表スペースを作成するための PRIQTY (1 次スペース割り振り) または DSSIZE 値、および MAXPARTITION 値のいずれかを判別します。 インストール時に、少なくとも 1 つの 4 KB 作業ファイル表スペースと 1 つの 32 KB 作業ファイル表スペースを作成する必要があります。
- 合計スペースは、MB 単位での合計スペース量であるとします (パネル DSNTIP9 の TEMP 4K SPACE フィールドから)。
- 表スペース数は、表スペースの数で あるとします (パネル DSNTIP9 の TEMP 4K TBL SPACES フィールドから)。
- CEILING は、実数を次に大きい整数に切り上げる操作を行います。
- 表スペースごとのサイズ (GB) は、ギガバイト単位での作業ファイル表スペースごとのスペース量であるとします。
GB per table space = CEILING (total space / table spaces / 1024)
If GB per table space < 1 GB, then PRIQTY = CEILING (total space / table spaces
If GB per table space ≤ 16 384 GB, then DSSIZE = 4 GB
and MAXPARTITIONS = GB per table space / 4
Otherwise, DSSIZE = 4 GB and MAXPARTITIONS = 4096- 合計スペースは、MB 単位での合計スペース量であるとします (パネル DSNTIP9 の TEMP 32K SPACE フィールドから)。
- 表スペース数は、表スペースの数で あるとします (パネル DSNTIP9 の TEMP 32K TBL SPACES フィールドから)。
- CEILING は、実数を次に大きい整数に切り上げる操作を行います。
- 表スペースごとのサイズ (GB) は、ギガバイト単位での作業ファイル表スペースごとのスペース量であるとします。
GB per table space = CEILING (total space / table spaces / 1024)
If GB per table space < 1 GB, then PRIQTY = CEILING (total space / table spaces)
If GB per table space ≤ 16 384 GB, then DSSIZE = 4 GB
and MAXPARTITIONS = GB per table space / 4
If GB per table space ≤ 131 072 GB, then DSSIZE = 32 GB
and MAXPARTITIONS = GB per table space / 32
Otherwise, DSSIZE = 32 GB and MAXPARTITIONS = 4096