管理の手引き


表スペースの設計と選択

表スペースは、 データベースとそのデータベース内に格納されている表との間に入る記憶モデルです。 表スペースは、ノードグループの中に常駐します。 表スペースによって、 データベースと表データの位置をコンテナーに直接割り当てることができます。 (コンテナーとしては、ディレクトリー名、装置名、ファイル名があります。) これによってパフォーマンスが改善され、構成の融通性が大きくなり、整合性が向上します。

表スペースの作成と変更について、 詳しくは 表スペースの作成 、 または 表スペースの変更 を参照してください。

表スペースはノードグループの中に常駐するので、 表の保持のために選択された表スペースは、 その表のデータがノードグループ内の複数のデータベース区画に わたって分配される方法を定義します。 1 つの表スペースが複数のコンテナーにわたる場合もあります。 (1 つまたは複数の表スペースからの) 複数のコンテナーを、 同じ物理ディスク (またはドライブ) 上に作成することも可能です。 パフォーマンスを向上させるためには、 各コンテナーごとに異なるディスクを使用する必要があります。 図 36 は、データベース内の表と表スペース、 またそのデータベースに関連するコンテナーの関係について示しています。

図 36. データベース内の表スペースと表


データベース内の表スペースと表

EMPLOYEE 表と DEPARTMENT 表は、コンテナー 0、1、2、 および 3 にわたる HUMANRES 表スペースの中に入っています。 PROJECT 表は、コンテナー 4 の SCHED 表スペースに入っています。 この例では、それぞれのコンテナーは別々のディスクの中に存在しています。

データベース・マネージャーは、コンテナー間でデータ・ロードのバランスを取ろうとします。 結果として、データを格納するのにすべてのコンテナーが使われます。 別のコンテナーを使用する前に、 データベース・マネージャーがコンテナーに書き込むページ数は、 エクステント・サイズ と呼ばれます。 データベース・マネージャーは、毎回最初のコンテナーからデータを格納し始めるとは限りません。

図 37 は、 エクステント・サイズが 4 KB ページ 2 つ分の HUMANRES 表スペースを表しています。 それぞれのページには、 割り振りエクステントが小さく設定されているコンテナーが 4 つずつあります。 DEPARTMENT 表と EMPLOYEE 表は、どちらも 7 ページあり、 4 つのコンテナーすべてにわたっています。

図 37. コンテナーとエクステント


コンテナーとエクステント

1 つのデータベースには、 少なくとも以下の 3 つの表スペースが含まれている必要があります。

区分データベース環境では、 カタログ・ノードは 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 表スペース・ディレクトリー・コンテナー内には次のファイルが含まれています。

ファイル名
説明

SQLTAG.NAM
各コンテナー・サブディレクトリーにはこれらのファイルのいずれか 1 つがあります。 データベースに接続すると、データベース・マネージャーはこれらのファイルを用いて、 データベースが完全で一貫しているか検証します。

SQLxxxxx.DAT
表ファイル。 表のすべての行が格納されます。ただし、 LONG VARCHAR、 LONG VARGRAPHIC、 BLOB、 CLOB、 DBCLOB のデータは除きます。

SQLxxxxx.LF
LONG VARCHAR または LONG VARGRAPHIC のデータ (「長形式フィールド・データ」 ともいう) が入るファイル。 このファイルが作成されるのは、 LONG VARCHAR または LONG VARGRAPHIC の列が表内に存在する場合だけです。

SQLxxxxx.LB
BLOB、CLOB、DBCLOB のデータ (「LOB データ」ともいう) が入るファイル。 これらのファイルが作成されるのは、BLOB、CLOB、 または DBCLOB の列が表内に存在する場合だけです。

SQLxxxxx.LBA
SQLxxxxx.LB ファイルの割り振りおよび空きスペース情報が入るファイル。

SQLxxxxx.INX
表の索引ファイル。 対応する表のすべての索引は、この 1 つのファイルに格納されます。 このファイルが作成されるのは、索引が定義されている場合だけです。
注:索引が除去されても、索引ファイルが削除される時点まで、 スペースは索引 (.INX) ファイルから物理的には解放されません。 索引ファイルは、表のすべての索引が除去 (およびコミット) されるか、 表が再構成されるかした場合に削除されます。 索引ファイルが削除されていない場合、 スペースは除去がコミットされた時点で解放されたものとしてマークされ、 将来の索引作成または索引維持のために再使用できるようになります。

SQLxxxxx.DTR
DAT ファイルの再編成のための一時データ・ファイル。 表の再編成中に、 reorg (再編成) ユーティリティーは (REORG TABLE コマンドを 介して) システム一時表スペースの 1 つに表を作成します。 これらの一時表スペースは、ユーザー定義の表のために使われるコンテナーとは 別のコンテナーを使用するよう定義することができます。

SQLxxxxx.LFR
LF ファイルの再編成のための一時データ・ファイル。 表の再編成中に、 reorg (再編成) ユーティリティーは (REORG TABLE コマンドを 介して) システム一時表スペースの 1 つに表を作成します。 これらの一時表スペースは、ユーザー定義の表のために使われるコンテナーとは 別のコンテナーを使用するよう定義することができます。

SQLxxxxx.RLB
LB ファイルの再編成のための一時データ・ファイル。 表の再編成中に、 reorg (再編成) ユーティリティーは (REORG TABLE コマンドを 介して) システム一時表スペースの 1 つに表を作成します。 これらの一時表スペースは、ユーザー定義の表のために使われるコンテナーとは 別のコンテナーを使用するよう定義することができます。

SQLxxxxx.RBA
LBA ファイルの再編成のための一時データ・ファイル。 表の再編成中に、 reorg (再編成) ユーティリティーは (REORG TABLE コマンドを 介して) システム一時表スペースの 1 つに表を作成します。 これらの一時表スペースは、ユーザー定義の表のために使われるコンテナーとは 別のコンテナーを使用するよう定義することができます。

注:

  1. これらのファイルは、直接変更しないでください。 これらのファイルにアクセスできるのは、 文書 API およびその API を実現するためのツール (コマンド行プロセッサーやコントロール・センターなど) に よって間接的にアクセスする場合のみです。

  2. これらのファイルは移動しないでください。

  3. これらのファイルは削除しないでください。

  4. データベースや表スペースのバックアップ用にサポートされている唯一の手段は、 sqlubkp (データベースのバックアップ) API です。 これには、コマンド行プロセッサーおよびその API を実装するコントロール・センターが含まれます。

データベース管理スペース表スペース

DMS (データベース管理スペース) 表スペースでは、 データベース・マネージャーが記憶スペースを制御します。 記憶モデルは、DB2 によってスペースが管理される、限定された数の装置からなります。 管理者がどの装置を使用するかを決定し、 DB2 がそれらの装置上のスペースを管理します。 この表スペースは基本的に、データベース・マネージャーの必要を最もよく満たすように設計された 特別な目的のファイル・システムを実現したものです。 表スペース定義には、 データ格納用の表スペースに属する装置やファイルのリストが含まれます。

ユーザー定義の表およびデータが入っている DMS 表スペースは、以下のもの として定義することができます。

DMS 表スペースおよびコンテナーを設計するときは、以下の要素を考慮してください。

DMS 表スペースへのコンテナーの追加

ALTER TABLESPACE ステートメントを使用すれば、 既存の表スペースにコンテナーを追加して、記憶容量を増やすことができます。 その後、 すべてのコンテナーにわたって表スペースの内容の配分バランスが再調整されます。 バランスの再調整中も、表スペースへのアクセスは制限されません。 複数のコンテナーを追加する必要がある場合、 1 つの ALTER TABLESPACE ステートメント内か、 または同じトランザクション内で同時にそれらを追加して、 データベース・マネージャーがコンテナーの再バランスを何度も行わなくても済むようにすべきです。

LIST TABLESPACE CONTAINERS または LIST TABLESPACES コマンドを使用することによって、 表スペース用のコンテナーがどの程度満杯かを検査する必要があります。 新しいコンテナーの追加は、既存のコンテナーがほとんど満杯か、 または完全に満杯になる前に行う必要があります。 すべてのコンテナーにわたる新しいスペースは、 再バランスが完了するまで使用可能になりません。

既存のコンテナーよりも小さいコンテナーを追加すると、データの分配が不均等になります。 この結果、等しいサイズのコンテナーの場合よりも、 データの事前取り出しなどの並列入出力の実行の効率が低下します。

表スペース設計時の考慮事項

このセクションでは、次のようなトピックを扱います。

表スペースの入出力 (I/O) についての考慮事項

表スペースのタイプと設計によって、 その表スペースに対して実行される入出力の効率が決まります。 表スペースの設計と使用に関する課題をさらに考慮する前に、 以下のような概念を理解しておく必要があります。

大ブロック読み取り
単一の要求で複数ページ (通常 1 エクステント) を検索する読み取り。 一度に複数ページを読み取ることは、それぞれのページを別個に読み取るより効率的です。

事前取り出し
照会でページが参照されるのに先立って行うページの読み取り。 全体的な目標は、応答時間を削減することです。 ページの事前取り出しが照会の実行と非同期に行うことができれば、 この目標を達成することができます。 最適な応答時間は、 CPU または入出力サブシステムのいずれかが最大容量で操作されている場合に達成されます。

ページ・クリーニング
ページの読み取りおよび変更が行われると、 これらのページはデータベース・バッファー・プールの中に累積されます。 ページが読み込まれるときには、 バッファー・プール・ページの中に読み込まれます。 バッファー・プールが変更されたページでいっぱいである場合は、 それらの変更されたページのいずれかをディスクに書き出さないと、 新しいページを読み込むことができません。 バッファー・プールがいっぱいになるのを防ぐために、 ページ・クリーナー・エージェントは変更されたページを書き出して、 読み取り要求の際にバッファー・プール・ページが利用できる状態にします。

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 一時表スペースの定義では、 大半の正規表スペースで使用されているページ・サイズと等しいページ・サイズを指定することが推奨されています。 そうすれば、一般的な環境と作業負荷に適したサイズが得られます。 しかし、 一時表スペースの構成や作業負荷を変えるとよい結果が得られる場合もあります。 以下の点を考慮してください。

カタログ表スペースについての推奨事項

以下のような理由のために、 データベース・カタログには 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 作業負荷のために単一の入出力要求をできるだけ効率的にすると同時に、 照会の作業負荷のために並列入出力の効率を最大化することが目標となります。

表スペースのページ・サイズを決定するための考慮事項は次のとおりです。

SMS 表スペースか DMS 表スペースかの選択

データを格納するために使用する表スペースの種類を決定する際には、 いくつかの選択事項について考慮する必要があります。

SMS 表スペースの利点:

DMS 表スペースの利点:

注:Solaris および DYNIX/ptx (IBM NUMA-Q) では、 パフォーマンス重視の作業負荷用には生の装置を含む DMS 表スペースを 使用することを強く推奨します。

普通、SMS 表スペースでは個人用の小さなデータベースを管理するのが一番簡単です。 一方、サイズが大きく、これからも拡張するデータベースの場合、 SMS 表スペースは一時表スペースとしてのみ使用し、 DMS 表スペースを分割して、各表に複数のコンテナーを割り当てるのが効果的です。 さらに、長形式フィールド・データおよび索引は それぞれ独自の表スペースに保管するとよいでしょう。

装置コンテナーを使って DMS 表スペースを使用する場合は、 使用環境を調整および管理する必要があります。 詳細については、 管理の手引き: パフォーマンス の『DMS 装置のパフォーマンスに関する考慮事項』を参照してください。

データが RAID 装置にある場合のパフォーマンスの最適化

このセクションでは、 データが 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) を使用して、 タイプを表示する簡単なアプリケーションを作成することもできます。


[ ページのトップ | 前ページ | 次ページ | 目次 | 索引 ]