表スペースは、 データベースとそのデータベース内に格納されている表との間に入る記憶モデルです。 表スペースは、ノードグループの中に常駐します。 表スペースによって、 データベースと表データの位置をコンテナーに直接割り当てることができます。 (コンテナーとしては、ディレクトリー名、装置名、ファイル名があります。) これによってパフォーマンスが改善され、構成の融通性が大きくなり、整合性が向上します。
表スペースの作成と変更について、 詳しくは 表スペースの作成 、 または 表スペースの変更 を参照してください。
表スペースはノードグループの中に常駐するので、 表の保持のために選択された表スペースは、 その表のデータがノードグループ内の複数のデータベース区画に わたって分配される方法を定義します。 1 つの表スペースが複数のコンテナーにわたる場合もあります。 (1 つまたは複数の表スペースからの) 複数のコンテナーを、 同じ物理ディスク (またはドライブ) 上に作成することも可能です。 パフォーマンスを向上させるためには、 各コンテナーごとに異なるディスクを使用する必要があります。 図 36 は、データベース内の表と表スペース、 またそのデータベースに関連するコンテナーの関係について示しています。
![]() |
EMPLOYEE 表と DEPARTMENT 表は、コンテナー 0、1、2、 および 3 にわたる HUMANRES 表スペースの中に入っています。 PROJECT 表は、コンテナー 4 の SCHED 表スペースに入っています。 この例では、それぞれのコンテナーは別々のディスクの中に存在しています。
データベース・マネージャーは、コンテナー間でデータ・ロードのバランスを取ろうとします。 結果として、データを格納するのにすべてのコンテナーが使われます。 別のコンテナーを使用する前に、 データベース・マネージャーがコンテナーに書き込むページ数は、 エクステント・サイズ と呼ばれます。 データベース・マネージャーは、毎回最初のコンテナーからデータを格納し始めるとは限りません。
図 37 は、 エクステント・サイズが 4 KB ページ 2 つ分の HUMANRES 表スペースを表しています。 それぞれのページには、 割り振りエクステントが小さく設定されているコンテナーが 4 つずつあります。 DEPARTMENT 表と EMPLOYEE 表は、どちらも 7 ページあり、 4 つのコンテナーすべてにわたっています。
![]() |
1 つのデータベースには、 少なくとも以下の 3 つの表スペースが含まれている必要があります。
表スペース名は、表の作成時に指定してください。 そうしないと、望みどおりの結果が得られないかもしれません。 表スペース名を指定しない場合、表は、以下の規則にしたがって配置されます。 ユーザー作成の表スペースが存在する場合、この表に十分な大きさの表スペースのうち、 最もページ・サイズが小さいものを選択してください。 存在しない場合は、 USERSPACE1 のページ・サイズがこの表に十分な大きさであれば、 この表スペースを使用してください。 ページ・サイズが十分な大きさの表スペースが 1 つも存在しない場合、 表は作成されません。
表のページ・サイズは、行サイズまたは列数のいずれかによって決定されます。 行の許容最大長は、表が作成された表スペースのページ・サイズに依存しています。 ページ・サイズに指定できる値は 4 KB (省略時)、8 KB、16 KB、および 32 KB です。 基礎表には 1 つのページ・サイズを持つ表スペース、 LONG または LOB データにはページ・サイズの異なる別の表スペースを使用できます。 (SMS は複数の表スペースにまたがる表をサポートしませんが、 DMS はそのような表をサポートすることに留意してください。) 列の数またはページ・サイズが表スペースのページ・サイズの限界を超えると、 エラーが戻されます (SQLSTATE 42997)。
データベースが複数の一時表スペースを使用する場合、 一時オブジェクトはラウンドロビン方式で一時表スペースに割り振られます。
省略時の 4 KB よりも大きいページ・サイズで定義された表スペース内の 表に対して照会が実行されると (たとえば 1012 列に対する ORDER BY)、 照会が失敗する場合があります。 これは、 より大きいページ・サイズで定義された一時表スペースが存在しない場合に起こります。 場合によっては、さらに大きいページ・サイズ (8 KB、16 KB、 または 32 KB) の一時表スペースを作成する必要があります。 データ操作言語 (DML) ステートメントは、 ユーザー表スペース内の最大ページ・サイズと同じページ・サイズの 一時表スペースがなければ失敗する可能性があります。
単一の SMS 一時表スペースの定義では、 大半のユーザー表スペースで使用されているページ・サイズと等しい ページ・サイズを指定してください。 そうすれば、一般的な環境と作業負荷に適したサイズが得られます。 一時表スペースについての推奨事項も参照してください。
区分データベース環境では、 カタログ・ノードは 3 つの省略時表スペースすべてを含み、 その他のデータベース区画はそれぞれ TEMPSPACE1 と USERSPACE1 だけを含みます。
表スペースには、次に示す 2 つの種類があります。 1 つのデータベースで両方を使用できます。
SMS (システム管理スペース) 表スペースでは、 オペレーティング・システムのファイル・システム・マネージャーが、 表の保管されるスペースの割り振りと管理を行います。 記憶モデルは、通常、 ファイル・システム・スペースに保管された表オブジェクトを表す多くのファイルからなります。 ユーザーがファイルの場所を決定し、DB2 がそれらの名前を制御し、 そしてファイル・システムがそれらを管理する責任を持ちます。 データベース・マネージャーは、各ファイルに書き込まれるデータの量を制御することにより、 それぞれの表スペース・コンテナーにデータを均等に分配します。 SMS 表スペースは、省略時の表スペースです。
各表には、それと関連した少なくとも 1 つの SMS 物理ファイルがあります。 それらのファイルのリストと内容の説明については、SMS 物理ファイルを参照してください。
SMS 表スペースでは、オブジェクトが増大するにつれて、ファイルが一度に 1 ページずつ拡張されます。 挿入のパフォーマンスを向上させる必要がある場合は、 複数ページのファイル割り振りを検討することができます。 これによって、システムは、 一度に複数ページずつファイルの割り振りまたは拡張を行うことができます。 複数ページのファイル割り振りを使用可能にするためには、 db2empfa を実行しなければなりません。 区分データベース環境では、 このユーティリティーを各データベース区画で実行する必要があります。 複数ページのファイル割り振りがいったん使用可能になると、 それを使用不能にすることはできません。 db2empfa についての詳細は、 コマンド解説書 を参照してください。
SMS 表スペースの定義は、 CREATE DATABASE コマンドまたは CREATE TABLESPACE ステートメント の MANAGED BY SYSTEM オプションを使用して明示的に行う必要があります。 SMS 表スペースを定義するときは、かぎとなる以下の 2 つの要素を考慮に入れる必要があります。
表スペースで使用するコンテナーの数を指定しなければなりません。 SMS 表スペースが作成された後ではコンテナーを追加または削除することができないため、 使用したいすべてのコンテナーを確認しておくことがきわめて重要です。 区分データベース環境では、 SMS 表スペースのノードグループに新しい区画が追加されたときに、 ALTER TABLESPACE ステートメントを使用して、 新しい区画にコンテナーを追加することができます。
SMS 表スペースの各コンテナーは、絶対または相対ディレクトリー名を識別します。 これらのディレクトリーは、 それぞれ別個のファイル・システム (または物理ディスク) に置くことができます。 表スペースの最大サイズは次のように見積もることができます。
コンテナー数 * (オペレーティング・システムによって サポートされるファイル・システムの最大サイズ)
この式は、各コンテナーごとに別個のファイル・システムがマップされており、 各ファイル・システムには使用できるスペースの上限があることを前提とします。 現実にはそのようなことはあまりなく、多くの場合、 表スペースの最大サイズはもっと小さくなります。
注: | コンテナーを定義するときには注意が必要です。 コンテナーにファイルやディレクトリーがすでに存在する場合は、 エラー (SQL0298N) が戻されます。 |
エクステント・サイズの指定は、表スペースの作成時にしか行えません。 後から変更することはできませんので、適切なエクステント・サイズを選択してください。 詳しくは、エクステント・サイズの選択を参照してください。
表スペースを作成するときにエクステント・サイズを指定しなければ、データベース・マネージャーは、 dft_extent_sz データベース構成パラメーターで 定義されている省略時エクステント・サイズを使って表スペースを 作成します (このパラメーターについての詳細は、管理の手引き: パフォーマンス を参照)。 この構成パラメーターは、データベースの作成時に指定した情報をもとに初期設定されます。 CREATE DATABASE コマンドで DFT_EXTENT_SZ パラメーターを指定しなければ、 省略時エクステント・サイズは 32 に設定されます。
コンテナーの数および表スペースのエクステント・サイズに適切な値を選択するには、 以下のことを理解しておく必要があります。
たとえば、一部のオペレーティング・システムでは、2 GB の制限があります。 そのため、64 GB の表オブジェクトを希望する場合は、 このタイプのシステムでは少なくとも 32 のコンテナーが必要です。
表スペースを作成するときに、 コンテナーが別々のファイル・システムに存在するよう指定すれば、 データベースに格納できるデータ量を増やすことができます。
最初の表データ・ファイル (SQL00001.DAT) は、 その表スペースに指定された最初のコンテナーの中に作成され、このファイルは、 エクステント・サイズまで拡張することが許されます。 そのサイズまで達したら、データベース・マネージャーは次のコンテナーの SQL00001.DAT にデータを書き込みます。 このプロセスは、 すべてのコンテナーに SQL00001.DAT が入るまで続きます。 その後、データベース・マネージャーは最初のコンテナーに戻ります。 このプロセス (ストライピング という) は、 コンテナーが満杯になるか (SQL0289N)、 またはオペレーティング・システムがそれ以上スペースを 割り振れなくなる (ディスク満杯エラー) まで、 コンテナー・ディレクトリーにわたって続行されます。 また、ストライピングは索引 (SQLnnnnn.INX)、 長形式フィールド (SQLnnnnn.LF)、 および LOB (SQLnnnnn.LB および SQLnnnnn.LBA) ファイルにも使用されます。
注: | SMS 表スペースは、そのコンテナーのうちのどれか 1 つが満杯になると、 ただちに満杯になります。 したがって、各コンテナーに同じ量のスペースを割り当てることが重要です。 |
複数のコンテナーにわたってデータをより均等に配分させるのに役立てるため、 データベース・マネージャーは、表の識別子 (上記の例では 1 ) とコンテナーの番号のモジュロをとることによって、 最初に使用するコンテナーを判別しています。 コンテナーは 0 から順番に番号が付けられます。
SMS 表スペースで使われるファイルの詳細については、 SMS 物理ファイルを参照してください。
SMS 表スペース・ディレクトリー・コンテナー内には次のファイルが含まれています。
注: | 索引が除去されても、索引ファイルが削除される時点まで、 スペースは索引 (.INX) ファイルから物理的には解放されません。 索引ファイルは、表のすべての索引が除去 (およびコミット) されるか、 表が再構成されるかした場合に削除されます。 索引ファイルが削除されていない場合、 スペースは除去がコミットされた時点で解放されたものとしてマークされ、 将来の索引作成または索引維持のために再使用できるようになります。 |
注:
DMS (データベース管理スペース) 表スペースでは、 データベース・マネージャーが記憶スペースを制御します。 記憶モデルは、DB2 によってスペースが管理される、限定された数の装置からなります。 管理者がどの装置を使用するかを決定し、 DB2 がそれらの装置上のスペースを管理します。 この表スペースは基本的に、データベース・マネージャーの必要を最もよく満たすように設計された 特別な目的のファイル・システムを実現したものです。 表スペース定義には、 データ格納用の表スペースに属する装置やファイルのリストが含まれます。
ユーザー定義の表およびデータが入っている DMS 表スペースは、以下のもの として定義することができます。
DMS 表スペースおよびコンテナーを設計するときは、以下の要素を考慮してください。
(extent_size * n) + 1extent_size は表スペース内の各エクステントのサイズ、 n はコンテナーに格納するエクステントの数を表します。
ALTER TABLESPACE ステートメントを使用すれば、 既存の表スペースにコンテナーを追加して、記憶容量を増やすことができます。 その後、 すべてのコンテナーにわたって表スペースの内容の配分バランスが再調整されます。 バランスの再調整中も、表スペースへのアクセスは制限されません。 複数のコンテナーを追加する必要がある場合、 1 つの ALTER TABLESPACE ステートメント内か、 または同じトランザクション内で同時にそれらを追加して、 データベース・マネージャーがコンテナーの再バランスを何度も行わなくても済むようにすべきです。
LIST TABLESPACE CONTAINERS または LIST TABLESPACES コマンドを使用することによって、 表スペース用のコンテナーがどの程度満杯かを検査する必要があります。 新しいコンテナーの追加は、既存のコンテナーがほとんど満杯か、 または完全に満杯になる前に行う必要があります。 すべてのコンテナーにわたる新しいスペースは、 再バランスが完了するまで使用可能になりません。
既存のコンテナーよりも小さいコンテナーを追加すると、データの分配が不均等になります。 この結果、等しいサイズのコンテナーの場合よりも、 データの事前取り出しなどの並列入出力の実行の効率が低下します。
このセクションでは、次のようなトピックを扱います。
表スペースのタイプと設計によって、 その表スペースに対して実行される入出力の効率が決まります。 表スペースの設計と使用に関する課題をさらに考慮する前に、 以下のような概念を理解しておく必要があります。
DB2 は、大ブロック読み取りが効率的であるときには常にこれを行います。 通常これは、順次または部分的に順次であるデータを検索する場合に行われます。 1 回の読み取り操作で読み取られるデータの量はエクステント・サイズによって決まり、 エクステント・サイズが大きければ大きいほど、 1 回に読み取られるページ数が多くなります。
エクステントがディスク上に格納される方法は、入出力の効率に影響を与えます。 装置コンテナーを使用する DMS 表スペースの場合、 データはディスク上で連続する傾向にあり、 最小のシーク時間とディスク待ち時間で読み取ることができます。 しかし、ファイルを使用する場合は、 データがファイル・システムによって分割され、 ディスク上の複数の場所に保管される可能性があります。 これは、SMS 表スペースを使用し、ファイルが一度に 1 ページずつ拡張され、 断片化が起こりやすい場合にもっともよく発生します。 DMS 表スペースで使用するために事前に割り振られた大きなファイルは、 特にクリーンなファイル・スペースにファイルが割り振られた場合には、 ディスク上で連続しやすくなります。
CREATE TABLESPACE ステートメントの PREFETCHSIZE パラメーターを 調整することによって、事前取り出しの程度を制御することができます。 (データベース内のすべての表スペースの省略時値は、 データベース構成パラメーター dft_prefetch_sz に よって設定されます。) PREFETCHSIZE パラメーターは、事前取り出しが起動されたときに、 どれだけのページ数を読み取るかを DB2 に指示します。 PREFETCHSIZE を CREATE TABLESPACE ステートメントの EXTENTSIZE パラメーターの倍数に設定すると、 複数のエクステントを並行して読み取らせることができます。 (データベース内のすべての表スペースの省略時値は、 データベース構成パラメーター dft_extent_sz によって 設定されます。) EXTENTSIZE パラメーターは、次のコンテナーにスキップするまでに、 あるコンテナーに書き込まれる 4 KB ページの数を指定します。
たとえば、3 つの装置を使用した表スペースがあるとします。 PREFETCHSIZE が EXTENTSIZE の 3 倍になるよう設定すれば、 DB2 は各装置から大ブロックを並列的に読み取ることができ、 それによって入出力のスループットがかなり増加します。 なお、ここでは、各装置が別々の物理装置であり、 制御装置が各装置からのデータ・ストリームを処理するために十分な処理速度を 持っていることを想定しています。 DB2 は、照会速度、バッファー・プール使用率、およびその他の要因に基づいて、 実行時に事前取り出しパラメーターを動的に調整しなければならなくなる場合があることに注意してください。
一部のファイル・システム (AIX のジャーナル・ファイル・システムなど) は、 独自の事前取り出し方式を使用します。 場合によっては、 DB2 事前取り出しよりもファイル・システムの事前取り出しの方が積極的に設定されます。 この結果、 ファイル・コンテナーを使用する SMS および DMS 表スペースの事前取り出しの方が、 装置を使用する DMS 表スペースの事前取り出しよりも速く実行されるように 見えることがあります。 しかしこれは、 ファイル・システム内で余分なレベルでの事前取り出しが行われているためにそう見せかけているに過ぎません。 DMS 表スペースは、同等のどの構成よりも速く実行できるはずです。
事前取り出しまたは均一な読み取りが効率的に行われるようにするために、 十分な数のクリーン・バッファー・プール・ページが存在しなければなりません。 たとえば、表スペースから 3 エクステントを読み取り、 読み取られる各ページごとにバッファー・プールから変更ページを 書き出さなければならない並列事前取り出し要求が存在するとします。 この並列事前取り出し要求の効率が下がって、 照会に対応できなくなる可能性があります。 ページ・クリーナーは、事前取り出し要求を満たす十分な数で構成されている必要があります。 データベースによって使用されるそれぞれの実ディスクごとに、 少なくとも 1 つのページ・クリーナーを定義する必要があります。 これらのトピックについての詳細は、管理の手引き: パフォーマンス を参照してください。
各表スペースは、それぞれ特定の 1 つのバッファー・プールに関連付けられます。 省略時のバッファー・プールは IBMDEFAULTBP です。 別のバッファー・プールを表スペースと関連付けるためには、 そのバッファー・プールが存在して (CREATE BUFFERPOOL ステートメントで定義されて) いなければならず、 (CREATE TABLESPACE ステートメントを使用して) 表スペースが作成されたときに関連が定義されます。 表スペースとバッファー・プールの関連は、 ALTER TABLESPACE ステートメントを使用して変更することができます。
複数のバッファー・プールを使うと、 全体のパフォーマンスが向上するようにデータベースの使用するメモリーを構成することができます。 ユーザーによってランダムにアクセスされる 1 つまたは複数の大きな表が 入っている表スペースの場合、 データ・ページをキャッシュしても有利ではないため、 バッファー・プールのサイズを制限することができます。 また、オンライン・トランザクション・アプリケーション用の 表スペースに対してより大きなバッファー・プールを関連付けると、 アプリケーションの使用するデータ・ページが長くキャッシュされて、 応答時間が速くなる場合があります。 新しいバッファー・プールを構成する場合には、注意が必要です。 このトピックについての詳細は、 管理の手引き: パフォーマンス の『データベース・バッファー・プールの管理』を参照してください。
注: | データベースで 8 KB、16 KB、または 32 KB のページ・サイズが必要であると決定したなら、 そのいずれかのページ・サイズを持つ表スペースはすべて、 同じページ・サイズのバッファー・プールにマップされなければなりません。 |
すべてのバッファー・プールに必要な記憶域が、データベースが開始されたときに、 データベース・マネージャーにとって使用可能でなければなりません。 DB2 が必要な記憶域を獲得できない場合、 データベース・マネージャーは省略時バッファー・プール (それぞれ 4 KB、8 KB、 16 KB、および 32 KB のページ・サイズ) を使用して開始し、警告を出します。
区分データベース環境では、データベース内のすべての区画について、 同じサイズのバッファー・プールを作成することができます。 異なる区画にそれぞれ別のサイズのバッファー・プールを作成することもできます。 CREATE BUFFERPOOL ステートメントの詳細については、SQL 解説書 を参照してください。
区分データベース環境では、 各表スペースが特定のノードグループと関連付けられます。 これによって、 表スペースの特性をそのノードグループ内の各ノードに適用することができます。 ノードグループはすでに存在して いなければならず (CREATE NODEGROUP ステートメントを使用して定義される)、 表スペースとノードグループの関連は、 CREATE TABLESPACE ステートメントを使用して表スペースが作成されるときに定義されます。
ALTER TABLESPACE ステートメントを使用して表スペースとノードグループの間の関連を変更することはできません。 ノードグループ内の個々の区画に対する表スペース仕様を変更できるだけです。 単一区画データベース環境では、 各表スペースは省略時ノードグループと関連付けられます。 表スペースを定義するときの省略時のノードグループは IBMDEFAULTGROUP です。 ただし、 システム一時表スペースが定義されている場合は IBMTEMPGROUP が使用されます。 CREATE NODEGROUP ステートメントの詳細については、SQL 解説書 を参照してください。 ノードグループと物理データベースの設計についての詳細は、 ノードグループの設計を参照してください。
表を表スペースにマッピングする方法を決定するときは、次の点を考慮してください。
最低でも、選択する表スペースが、 希望する区分化を使用するノードグループ内にあるようにする必要があります。
1 つの表スペースの中に多くの小さな表を保管する計画である場合、 その表スペースに対して SMS を使用することを検討してください。 入出力とスペース管理を効率的に行う DMS の利点は、 小さな表ではそれほど重要ではありません。 スペースを一度に 1 ページずつ、 しかも必要なときだけ割り当てるという SMS の利点の方が、小さな表の場合はより魅力的です。 表の 1 つがより大きいか、または表内のデータにより速くアクセスする必要がある場合には、 小さなエクステント・サイズを持つ DMS 表スペースを検討すべきです。
非常に大きな表の場合は、それぞれに別個の表スペースを使用し、 小さな表はすべて 1 つの表スペースにまとめるのが良いでしょう。 このように分けると、 表スペースの使用方法に基づいて適切なエクステント・サイズを選択することもできます。 (さらに詳しい情報については、エクステント・サイズの選択を参照してください。)
たとえば、あまり頻繁に使用されない履歴データの入った表がある場合、 このデータに対する照会については、 応答時間が長くてもよいとエンド・ユーザーは考えるかもしれません。 その場合、履歴データ表に別の表スペースを使用して、 その表スペースをアクセス速度が遅く、 費用のかからない物理装置に割り当てるのも一案です。
また、高可用性や短い応答時間が要求される重要な表を別扱いにするという方法もあります。 そのような表は、 そうした重要なデータ要件をサポートできる高速の物理装置に割り当てられた表スペースに入れておきます。
また、DMS 表スペースを使用して、 表データを 3 つの異なる表スペースに分けることもできます。 つまり 1 つは索引データ用、1 つは LOB および長形式フィールド・データ用、 残る 1 つは正規表データ用です。 これにより、データに最も適した表スペース特性、 およびそれらの表スペースをサポートする物理装置を選択することができます。 たとえば、利用可能な最高速の装置に索引データを入れると、 パフォーマンスはかなり向上します。 複数の DMS 表スペースにまたがって 1 つの表スペースを分割する場合、 ロールフォワード回復が使用可能であれば、 表のすべての部分をまとめてバックアップし復元することを考慮してください。 SMS 表スペースは、 複数の表スペースにまたがるこのようなタイプのデータ配分をサポートしません。
一部の管理機能は、データベースや表のレベルではなく、表スペースのレベルで実行できます。 たとえば、データベースではなく表スペースのバックアップをとれば、 時間とリソースの節約になります。 こうすれば、大量の変更がある表スペースを頻繁にバックアップする一方、 変更が非常に少ない表スペースは時折バックアップするだけにできます。
データベースや表スペースは復元することができます。 互いに無関係な表が表スペースを共有していない場合、 データベースのごく一部だけを復元して、コストを減らすことができます。
互いに関連する表は一まとまりの表スペースに一緒に入れておくのがよいでしょう。 そうした表は参照制約によって関連付けられる場合もあれば、 定義された他の業務制約によって関連付けられる場合もあります。
ある特定の表を頻繁に除去および再定義する必要がある場合、 表を除去するよりは DMS 表スペースを除去する方がより効率的であるため、 その表を独自の表スペースの中に定義したほうがよい場合があります。
表スペースのエクステント・サイズは、 次のコンテナーに書き込まれるまでに 1 つのコンテナーに書き込まれる表データのページ数を表します。 エクステント・サイズを選択するときには、次のことを考慮してください。
DMS 表スペースの中のスペースは、 1 つの表に対して一度に 1 エクステントずつ割り当てられます。 表に入力が行われ、エクステントがいっぱいになると、新しいエクステントが割り当てられます。
1 つの表は、以下の別個の表オブジェクトからなります。
それぞれの表オブジェクトは別々に保管され、 それぞれが必要に応じて新しいエクステントを割り当てます。 また、それぞれの表オブジェクトは、 (その表オブジェクトに属する表スペース内のすべてのエクステントを 記述する) エクステント・マップ という メタデータ・オブジェクトとも関連付けられます。 エクステント・マップ用のスペースも一度に 1 エクステントずつ割り当てられます。
このため、1 つの表のためのスペースの初期割り振りは、 それぞれの表オブジェクトごとに 2 エクステントになります。 このため、1 つの表スペース内に多くの小さな表がある場合は、 比較的少ないデータ量を保管するのに、比較的大きな量のスペースを割り振ることになります。 このような場合には、小さなエクステント・サイズを指定するか、 または一度に 1 ページを割り振る SMS 表スペースを使用する必要があります。
反対に、急速に大きくなっていく大きな表に対して小さなエクステント・サイズの DMS 表スペースを使用している場合は、 エクステントの割り振り追加が頻繁になされることに関連した不必要なオーバーヘッドが生じることになる可能性があります。
表へのアクセスに、 大量のデータを処理する照会やトランザクションが数多く使用される場合には、 パフォーマンスの点で、表からデータを事前に取り出しておくのがよいかもしれません。 (データの事前取り出しおよびエクステント・サイズとの関係については、 管理の手引き: パフォーマンス を参照してください。)
表スペース用の 5 個のエクステントが入るスペースがコンテナーの中になければ、 表スペースは作成されません。
単一の SMS 一時表スペースの定義では、 大半の正規表スペースで使用されているページ・サイズと等しいページ・サイズを指定することが推奨されています。 そうすれば、一般的な環境と作業負荷に適したサイズが得られます。 しかし、 一時表スペースの構成や作業負荷を変えるとよい結果が得られる場合もあります。 以下の点を考慮してください。
表を「インプレース」で、つまりターゲット表スペースで直接再編成すれば、 一時表スペースを使わずに再編成を行うことができます。 言うまでもなく、この「インプレース」再編成では、 ターゲット表スペースに再編成プロセス用の余分のスペースが必要になります。 表の再編成についての追加情報は、管理の手引き: パフォーマンス を参照してください。
注: | カタログ表スペースに使用できるページ・サイズは 4 KB に制限されます。 その場合、データベース・マネージャーは、 カタログ表を再編成できる 4 KB の一時表スペースが必ず存在するようにします。 |
以下のような理由のために、 データベース・カタログには SMS 表スペースを使用することが推奨されています。
これらのことを考慮すれば、SMS 表スペースのほうが、 カタログ用にはいくぶん優れた選択です。
考慮すべき別の要因は、将来カタログ表スペースを拡張する必要があるかどうかということです。 一部のプラットフォームは SMS コンテナー用の基礎となる記憶域の拡張をサポートしており、 リダイレクトされた復元 を使って SMS 表スペースを拡張ことも可能ですが、 DMS 表スペースを使用すれば新しいコンテナーを容易に追加することができます。
使用する表スペースのタイプ、および指定するページ・サイズを決定する際には、 実際の環境で DB2 が管理している基本的な作業負荷のタイプが影響する場合があります。 オンライン・トランザクション処理 (OLTP) の作業負荷の特徴は、 データに対してランダム・アクセスを行う必要がある、 通常は小さなデータ・セットを戻すトランザクションです。 アクセスがランダムであり、 そのアクセスが 1 ないし数ページに対するものであるとすれば、 事前取り出しは不可能です。
装置コンテナーを使用する DMS 表スペースは、この状態において最適に実行されます。 最高のパフォーマンスが必要なければ、 ファイル・コンテナーを使用した DMS 表スペースまたは SMS 表スペースもまた、 OLTP 作業負荷に対する適切な選択です。 順次入出力が少ないか、まったくない場合、 CREATE TABLESPACE ステートメントの EXTENTSIZE および PREFETCHSIZE パラメーターの設定値は、 入出力の効率にとって重要ではありません。
照会作業負荷の特徴は、 データに対して順次アクセスまたは部分的な順次アクセスを行う必要のある、 通常大きなデータ・セットを戻すトランザクションです。 複数の装置コンテナーを使用する DMS 表スペースで、 しかも各コンテナーが別々のディスクにある場合には、 並列的事前取り出しが最も効率的に行われる可能性があります。 CREATE TABLESPACE の PREFETCHSIZE パラメーターの値は、 EXTENTSIZE パラメーターの値に装置コンテナーの数を掛けた値に設定すべきです。 これによって、DB2 は、すべてのコンテナーから並列に事前取り出しすることができます。
照会の作業負荷の代わりの方法として、 ファイル・システムが独自の事前取り出しを使用している場合には、 ファイルを使用することもできます。 ファイルは、ファイル・コンテナーを使用した DMS タイプ、 または SMS タイプのいずれかが可能です。 SMS を使用する場合、入出力並列化を達成するために、 ディレクトリー・コンテナーを別々の物理ディスクにマップする必要があります。
作業負荷が混在している場合には、 OLTP 作業負荷のために単一の入出力要求をできるだけ効率的にすると同時に、 照会の作業負荷のために並列入出力の効率を最大化することが目標となります。
表スペースのページ・サイズを決定するための考慮事項は次のとおりです。
ページ・サイズ / 255各ページには無駄なスペースが生じます (1 ページの行数は最大で 255 です)。 この場合、ページ・サイズは小さい方がふさわしいでしょう。
データを格納するために使用する表スペースの種類を決定する際には、 いくつかの選択事項について考慮する必要があります。
SMS 表スペースの利点:
DMS 表スペースの利点:
パフォーマンスを改善するため、 または 1 つの表に格納できるデータの量を増やすために、表データを分割することができます。 たとえば、1 つの表に正規表データ 64 GB、索引データ 64 GB、 および長形式データ 2 TB を入れることができます。 8 KB のページを使用している場合は、表データと索引データは 128 GB までとすることができます。 16 KB のページを使用している場合は 256 GB までとすることができます。 32 KB のページを使用している場合は、表データと索引データは 512 GB までとすることができます。
注: | Solaris および DYNIX/ptx (IBM NUMA-Q) では、 パフォーマンス重視の作業負荷用には生の装置を含む DMS 表スペースを 使用することを強く推奨します。 |
普通、SMS 表スペースでは個人用の小さなデータベースを管理するのが一番簡単です。 一方、サイズが大きく、これからも拡張するデータベースの場合、 SMS 表スペースは一時表スペースとしてのみ使用し、 DMS 表スペースを分割して、各表に複数のコンテナーを割り当てるのが効果的です。 さらに、長形式フィールド・データおよび索引は それぞれ独自の表スペースに保管するとよいでしょう。
装置コンテナーを使って DMS 表スペースを使用する場合は、 使用環境を調整および管理する必要があります。 詳細については、 管理の手引き: パフォーマンス の『DMS 装置のパフォーマンスに関する考慮事項』を参照してください。
このセクションでは、 データが Redundant Array of Independent Disks (RAID) 装置に置かれている場合に、 パフォーマンスを最適化する方法について説明します。 一般に、RAID 装置を使用している表スペースごとに以下のことを行う必要があります。
DB2_PARALLEL_IO
DB2 は表スペース・コンテナーでのデータの読み取りまたは書き込みを行う際に、 データベース内のコンテナー数が複数であれば、並列入出力を使用することがあります。 しかし、 単一のコンテナー表スペースで並列入出力を実行するほうがよいと思える状況もあります。 たとえば、複数の物理ディスクから成る単一の RAID 装置にコンテナーが作成される場合、 並列読み取りおよび並列書き込みの呼び出しを発行することができます。
単一コンテナーを持つ表スペースの並列入出力を強制するには、 DB2_PARALLEL_IO レジストリー変数を使用できます。 この変数は、 各表スペースを意味する "*" (アスタリスク) に設定することも、 コンマで区切った表スペース ID のリストに設定することもできます。 次に例を示します。
db2set DB2_PARALLEL_IO=* {turn parallel I/O on for all table spaces} db2set DB2_PARALLEL_IO=1,2,4,8 {turn parallel I/O on for table spaces 1, 2, 4, and 8}
レジストリー変数を設定したら、変数を有効にするために、 DB2 を停止 (db2stop) した後、 再始動 (db2start) する必要があります。
DB2_STRIPED_CONTAINERS
現時点では、DMS 表スペース・コンテナー (装置またはファイル) を作成するときに、 1 ページのタグがコンテナーの先頭に保管されます。 残りのページは DB2 がデータ記憶用に使用するためのもので、 エクステント・サイズのブロックにグループ化されます。
表スペース・コンテナー用に RAID 装置を使用する場合、 表スペースの作成では、RAID ストライプ・サイズと同じか、 その整数倍のエクステント・サイズを指定することが提案されています。 しかし、1 ページのコンテナー・タグがあるため、 エクステントは RAID ストライプと同列にはならず、 入出力要求中に最適と思える数よりも多くの物理ディスクにアクセスする必要があるかもしれません。
DMS 表スペースのコンテナーは、 タグが独自の (フル) エクステント内に存在できるような仕方で作成できるようになりました。 これにより、上記の問題は避けられますが、 コンテナー内にオーバーヘッドによる余分のエクステントが必要になります。 この方法でコンテナーを作成するには、 次のように DB2 レジストリー変数 DB2_STRIPED_CONTAINERS を "ON" に設定してから、 インスタンスを停止し、再始動する必要があります。
db2set DB2_STRIPED_CONTAINERS=ON db2stop db2start
(CREATE TABLESPACE または ALTER TABLESPACE ステートメントを 使用して) DMS コンテナーを作成すると、 フル・エクステントを使用するタグを含むコンテナーになります。 既存のコンテナーは未変更のままです。
この属性を持つコンテナーの作成を停止するには、 次のように変数をリセットしてから、インスタンスを停止し、再始動します。
db2set DB2_STRIPED_CONTAINERS= db2stop db2start
コントロール・センターおよび LIST TABLESPACE CONTAINERS コマンドは、 作成されたコンテナーがストライピングされたものかどうかを表示しません。 コンテナーが作成された方法にしたがって、 "ファイル" または "装置" というラベルを使用します。 ストライピングされたコンテナーとして作成されたかどうかを検査するには、 DB2DART の /DTSF オプションを使って表スペースとコンテナー情報をダンプし、 それからタイプ・フィールドを見て問題のコンテナーを調べます。 照会コンテナー API (sqlbftcq および sqlbtcq) を使用して、 タイプを表示する簡単なアプリケーションを作成することもできます。