hUZ6T

データベース物理設計 

【DB2 9.5 対応版】 

お断り:当資料は、DB2 for Linux, UNIX and Windows V9.1をベースに作成されています。 

©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部 

DB2デザイン・ガイド 


ブランク・ページです 

2 

データベース物理設計


目次 

物理設計の流れ 

物理設計作業開始にあたって 

①表/索引定義の作成 

②データ容量の見積もり 

③インスタンスの構成とデータベースの分割 

④表の分類と表スペースの構成 

⑤表スペースの配置 

⑥表スペース以外のオブジェクトの配置 

⑦構成パラメーターの設定 

⑧シェル/コマンドの作成 

OS特有の設定 


3 





4 



物理設計の流れ 



③ インスタンスの構成とデータベースの 

分割 







・表の分割/参照整合や制約/属性、長さの決定 

・主キー(1次索引) 

・検索やジョインのパターンによって2次索引作成 

・データ項目、長さ、索引などは既に決まっている前提 

・ページ・サイズの決定 

・表、(索引)サイズの見積もり 

・インスタンスの分割も検討 

・バックアップ単位であるデータベースの分割を検討 

・表の分類と表スペース構成の決定 

・表スペースのタイプ、その他の属性の決定 

・物理ディスク上への表スペースの配置 

・コンテナーの設計 

・ログ、バックアップ用、ワークスペースの配置 

・物理設計にあわせた構成パラメーターの変更 

・これまでに設計したオブジェクトを作成するコマンドおよびシェルを作成 

5 



解説 


6 


� データベースの物理設計を行う場合、ディスクおよびサーバーを含むハードウェア構成が決まっている必要がありま 

す。また、表の論理設計も既に終了していることが前提です。 

� 表の論理設計を実際のハードウェア上にどのように構築するかを決定することが、「物理設計」ということになります。 

� 純粋な論理設計では、まだどのデータベース製品を使うかにはあまり依存しません。しかし、どのようにディスク上に 

配置し、メモリを割り振るかを決定する物理設計はデータベース製品に特化した作業になります。 

� ①DBMSに特化しない論理設計では、カラムの属性・長さなどが決まりません。物理設計の最初にまずこれらの 

DBMSに特化した表定義を決定します。例えば、データは日付なのですが、格納方法はDATEにするか 

TIMESTAMP,CHARまたはVARCHARにするかなどの選択肢があります。 

� ②データ容量を見積もります。論理設計によってできあがった表のレイアウトとレコード数から容量を見積もり、必要 

となるディスク容量を計算します。 

� ④次にそれらの表を幾つかのグループに分類します。そしてそれらの表を配置する表スペースの定義を決めていき 

ます。 

� ⑤物理ディスクへの表スペースの配置を決定します。 

� ⑥⑤で配置した表スペース以外のオブジェクトの配置を決定します。 

� ⑦物理設計に関連した構成パラメーターを設定します。 

� ⑧最後に行うのは、これらの設計に基づいたファイルシステムや論理ボリュームなどを作成するシェル・スクリプトの 

作成と、これらの上に表スペースおよび表、索引を作成するDDLの作成です。 

� データベースの物理設計は基本的には以上の作業を行い、ドキュメントを作成し、実際のハードウェア上に構築する 

ところで終了します。


物理設計作業開始にあたって 

�論理データベース設計作業が完了していることが前提 

� 論理データベース仕様の後からの変更は困難 

� アプリケーション開発作業に多大な手戻りを発生させる可能性がある 

� 論理設計で決めた表をDB2データベースの表として定義 

� 作成したデータベース仕様をシステム上の物理記憶域にマッピング 

� DB2の製品仕様に依存する作業であるため、DB2の製品知識が必要 

� 使用するオペレーティング・システム毎の知識も要求される 

�データベース設計の最終目標 


7 


� 時代の変化に伴う多様な要求の出現に対応できる安定したデータベースを構築す 

る 

� 各種要件(アプリケーション、性能、運用等)を最適に実装するデータベースを検討 

する � 運用設計、障害回復設計とも同期を取りながら進めて行く 

� パフォーマンス・チューニングや運用の効率化のため適宜物理設計の見直しも必要 

� 充分にテストを実施して、データベース設計が最適に実装されているかを検証する 

必要がある


解説 


8 


� 物理設計作業開始にあたっては、論理データベース設計作業がきちんと完了していることが必要です。論理設計完 

了後の変更は、アプリケーション開発作業に多大な手戻りを発生させる可能性があります。 

� 物理設計作業は、表の論理設計で決められた表を、DB2のデータベースの表として定義することです。 

� 実際に、物理記憶域のどこにどのように表スペースや表、索引といった各オブジェクトを配置するかのマッピングを 

行ないます(論理設計で作られた論理モデルの｢実装｣を行なうことになります。) 

� DB2の製品仕様に依存する作業であるため、DB2の製品知識が必要とされます。 

� また、ファイル・システムなど使用するオペレーティング・システム毎の知識が要求されることもあります。 

� データベースの設計の目標となるのは、自分の環境を、理解しやすくしかも将来の拡張の基礎となるよう表現したも 

のを作ることです。また、データの一貫性や整合性を保ちやすいデータベース設計が望ましいと言えます。そのため 

には、設計の段階で冗長性を少なくし、データベースの更新時に生じ得る異常をなくす必要があります。 

� また、アプリケーション要件や、性能、運用要件等を最適に実装するものでなければいけません。 

� 運用設計、障害回復設計とも同期を取りながら進めて行く必要があります。 

� データベースの設計は、一度で終了するものではありません。多くの場合、何度かやり直すことが必要になります。 

パフォーマンス・チューニングや運用の効率化のため適宜物理設計の見直しも必要になるのです。



�列の設計 

� データ・タイプと長さの決定 

�主キーと外部キー 

�制約 

� 固有制約 

� 参照制約 

� 表検査制約 

�表の設計 

�索引の設計 


9 



解説 


10 


� 表、および索引定義の作成にあたっては、事前にDBMSに特化した仕様を考慮して、様々 

な項目を決定する必要があります。 

� ページサイズは、データの容量やディスク容量、DB2の制限値を考慮して、適切なものを 

決定します。 

� 主に以下のような点について、DBMSに特化した表定義を決定していきます。 

� 列の設計(データ・タイプと長さなど) 

� 主キーと外部キー 

� 制約 � 固有制約 



� 索引設計(1次、2次) 

� 変更により適用業務に大きな影響を与えるものとして、例えば以下のものがあります。(V9 

では、以下の変更はALTER TABLEステートメントで行うことができます。) 

� データ・タイプの変更 

� データの長さの変更 

� NOT NULL指定の変更 

� 以下のものは、変更があっても適用業務に影響しないよう回避する方法はあります。 

� データベース名の変更 

� CATALOG DATABASEで別名設定 

� 表名の変更 

� RENAME TABLEで表名の変更、視点の作成により対応 

� 列名の変更 

� 視点の作成により対応 

� 列の順序変更 

� 視点の作成により対応


列の設計 


11 


�列のデータ・タイプと長さの決定 

� データ長やとり得る値の制限値により、最適なデータ・タイプを選択する 

� 開発言語環境による生産性の観点での考慮なども必要 

� 文字列(CHAR/VARCHAR/GRAPHIC/VARGRAPHIC) 

� 可変長 or 固定長? ⇒ 原則、固定長を使用することを推奨 

– 可変長(VARCHAR)は固定長(CHAR)に比べて4バイト分余計に必要 

– 可変長は、該当列の位置を認識するためにCPU負荷が増加 

– 固定長は定義した長さ分の領域を必ず使用する(圧縮を採用した場合はこの限りでない) 

� GRAPHICはホスト系(EBCDIC)との互換のために使用 

� 日付/時刻形式(DATE/TIME/TIMESTAMP) 

� CHARで保持するより、格納サイズが小さい 

� YEAR , MONTH , DAY などの日付計算、時間計算関数が使用可能。DB2が計算・値のチェックを 

行える 

� 数値(SMALLINT/INTEGER/BIGINT/REAL/DOUBLE/DECIMAL/DECFLOAT) 

� 算術に使用するのであれば、通常は数値型。最大取り得る値によって、データ・タイプを選択する 

� CHARで保持するより、格納サイズが小さい 

� 小数点以下がある場合はDECIMALを検討 

� LONG型(LONG VARCHAR/LONG VARGRAPHIC/CLOB/DBCLOB/BLOB) 

� LONG VARCHARは文字列というよりLONG型である。(ページ内にデータが格納されない) 

� LONG VARCHAR、LONG VARGRAPHICについてはdescriptorのための20バイトが行データ中に 

とられる。 

� 上限値にほとんど差異はない。LONG VARCHAR,LONG VARGRAPHICよりも、 

VARCHAR,VARGRAPHICを使用する。 

� LOBについても、他の表データとは別の場所に保管され、各列の情報(ポインター)のみを他データ 

と共に持つ 

� データが4KB以下の場合、LONGはなるべく使用しない 

� 拡張マークアップ言語(XML) 

� XML文書を格納する。 

� 単一パーティションで、コード・セットUTF-8のデータベースの場合のみ使用可能。 

V9.5


解説 

� 数値・文字列(固定長・可変長)・日付・XMLなどのうちどれを選択するか、データ長や、と 

り得る値の制限値により適したデータ・タイプを選択します。 

� また、開発言語環境によって扱い易いデータ・タイプであるのか、生産性の観点などから 

の考慮も必要です。 


12 


� 文字列 

� 可変長か固定長か決定する必要がありますが、まずは固定長を検討します。 

� 可変長の場合は、長さとオフセット情報を入れる領域が列あたり4バイト分余計に必要になります。 

� 可変長の場合は、該当列の位置は先頭からたどらなければならないため、CPUの負荷が該当列の位置がわかっている固定 

長よりも余計にかかります。 

� 列長の差が大きい(列あたり平均20バイト以上)時には可変長を採用することで、DISKスペースは削減されます。 

� GRAPHICはダブルバイト文字列のためのものですが、主にホスト系(EBCDIC)環境のDBとの互換のために使用されます。 

� 日付/時刻のデータ 

� 日付計算、時間計算、関数の使用が可能になるように、DATE/TIME/TIMESTAMPを使用してください。また、その方が、 

CHARデータタイプとして格納するよりもDISKスペースは軽減されます。 

� 数値 � 算術に使用するのであれば、通常は数値型で格納すべきです。該当の項目の最大取り得る値によって、データ・タイプを選択 

します。また、文字列で格納するよりもDISKスペースは軽減されます。 

� LONG型 

� LONGタイプは表データ・ページに実際の列のデータは含まれません。別の表オブジェクトとして表スペースに格納されます。 

行データ中にはそれらの列の20バイトの記述子(descriptor)は含まれます。 

� LONGタイプのデータをLONG専用の表スペースに格納させることも、CREATE TABLE時の指定で可能です。 

� 4KB以下の文字データについては、上述のような特異な扱いを避けるためにもLONGタイプは使用しないようにするなど、 

データ長の制限値により、適したデータタイプを選択してください。 

� XML � XML文書は、階層構造を持つデータとして格納されます。 

� LOB 列と同様に、XML列は列の記述子であるXMLデータ指定子(XDS)のみを保持します。XMLデータ自体は、別個にXDAと 

呼ばれるストレージ構造保管されます。 

� XML文書のサイズの上限は、2GBです。


参考:DB2がサポートするデータ･タイプ 

時刻 

日付/時刻 

タイム・ 

スタンプ 

日付 

TIME TIMESTAMP DATE 

固定長 

CHAR 

文字グラフィック 

可変長 

16ビット 

固定長 

ストリング 

GRAPHIC 

32ビット 


可変長 

バイナリー 

BLOB 

可変長 

13 

正確な値 

VARCHAR CLOB VARGRAPHIC DBCLOB 

2進整数 

64ビット 

SMALLINT INTEGER BIGINT 

符号付数値 

10進 

パック 

概算値 

浮動 

小数点数 

単精度 

DECIMAL 

倍精度 

Extensible 

Markup 

Language 

XML 

REAL DOUBLE 


10進浮動小数 

点数 

V9.5 

DECFLOAT


V9.5 


・文字タイプ 

データタイプ説明制限値 

CHAR(n) nバイトの固定長文字列 1



・ラージ・オブジェクト 


CLOB(n 

DBCLOB(n 

BLOB(n 

K|M|G) 文字ラージ・オブジェクトストリング 2,147,483,647バイト 

K|M|G) 2バイト文字ラージ・オブジェクト 1,073,741,823文字 

K|M|G) 2進ラージ・オブジェクト 2,147,483,647バイト 

・ラージ・オブジェクトのディスクリプタ 

LOBの最大長 LOB 

1,024 72 

8,192 96 

65,536 120 

524,000 144 

4,190,000 168 

・XML 

Descriptor長 


LOBの最大長 LOB 

134,000,000 200 

536,000,000 224 

1,070,000,000 256 

1,470,000,000 280 

2,147,483,647 316 


XML XML文書 2ギガバイト 

15 

Descriptor長 



V9.5 

参考: 

Decimal Floating Point 

�16桁または34桁の最大精度を持つ10進浮動小数点数 

� より大きな数、より精度の高い演算が可能 

� 従来のDECIMAL型では、1-10 31 から10 31-1 までの範囲、精度は31桁が最大 

Type DECFLOAT(16) DECFLOAT(34) 

Size 8 Bytes 16 Bytes 

指数範囲 10 -383 

� DECFLOAT(16): 


~10 +384 10 -6143 ~10 +6144 

精度 16 34 

� 負の値: -9.999999999999999 x 10 +384 ~ -1.000000000000000 x 10 -383 

� 正の値: 1.000000000000000 x 10 -383 ~ 9.999999999999999 x 10 +384 

� DECFLOAT(34): 

� 負の値: -9.999999999999999999999999999999999 x 10 +6144 ~ 

1.000000000000000000000000000000000 x 10 -6143 

� 正の値: 1.000000000000000000000000000000000 x 10 -6143 ~ 

9.999999999999999999999999999999999x 10 +6144 

16 



列の設計(続き) 

� その他設計上の考慮点 

� NOT NULLの指定 

� NULL可能にした場合、列毎に1バイトのNULLフラグが必要であり、CPU負荷が増加する 

� NULL標識変数を準備しなければならず、プログラムが煩雑になる 

� 比較、結合、UNIONの処理がある列はデータ・タイプを揃える 

� データ変換負荷の軽減 

� パフォーマンスを考慮した列の順序 

� 可変長列は、自動的に全ての固定長列の後ろに配置される 

� 更新される列は可能であれば近くに並べる 

� 適用業務には列の指定順序は影響しない(順序にこだわる場合、視点(View)で対応も可) 


17 


� 圧縮効率を考慮した列の順序 

� データ行圧縮を使用する場合、複数列に跨って繰り返されるパターンのデータがあれば、それらの列は隣接 

して並べる(圧縮効果が高くなる) 

� VARCHAR列:適当なデータ・タイプかどうか要検討 

� 読み取りに2ステップ要:長さ→データ 

� VARCHAR列への変更:長くなった場合、Tombstoneが発生する場合あり 

� 更新がある場合、データのフラグメンテーションを招く ⇒ REORG運用が必要となる可能性が高い 

� 列の自動生成 

� 生成列(GENERATED COLUMN)の利用 

– 指定されたルールに従い、列の値が動的に生成される列 

– 列の値を事前に加工して入れておくことにより、SQL実行時のパフォーマンスを向上させる 

� 識別列(IDENTITY COLUMN)の利用 

– DB2が列の値として、固有の数値を生成する列 

– 固有の値を取得するために別途表を用意したり、MAX関数を使用して取得したりする必要がない 

– 行をユニークに識別可能な、列の値を事前に入れておくことにより、識別列を使用した照会処理が可能 

– シーケンス・オブジェクトの利用も検討


解説 


18 


� 列にNULLデータが入る可能性がなければ、以下の理由からNOT NULLを指定してください。 

� NOT NULLでない場合 

� 列毎に1バイトのNULLフラグが必要 

� NULLか否か調べるCPU負荷の増加 

� NULLフラグによるDISKスペースの増加 

� プログラムではNULL標識変数の準備が必要 

� 比較、結合、UNIONの処理がある列は、列同士のデータタイプをそろえることでデータ変換負荷を 

軽減させることができます。 

� パフォーマンスを考慮した場合、更新される列は近くに並べて下さい。 

� 更新時のログは、先頭の更新列から、最後の更新列まで取得される為、更新列が離れているとロ 

グデータが増加します。 

C1 C2 C3 C4 C5 C6 C7 C8 C9 C10 

� update testtab set c5=50 ・・・・・・・・・ログは、c5のみ 

� update testtab set c3=20, c9=90 ・・・ログはc3~c9まで 

� ただし、可変長列でその列長が変更されるような更新がおこなわれた場合、行全体(新旧)がログとして取得されます。 

� 可変長列は、全ての固定長列の後ろに配列されます。 

� DB2は、データの保存時に固定長列、可変長列、LONG VARCHARポインター(20バイト)の順で自動的に格納しています。 

LL VARCHAR CHAR INTEGER 

固定長のinteger列を得るためにはその前のVARCHAR列からたどらなければならない 

CHAR INTEGER LL VARCHAR 

integer列は行の先頭からの相対位置が変わらないので直接得ることができる




19 

解説 

� データ行圧縮を使用する場合、複数列に跨って特定のパターンの値が繰り返されるようなデー 

タがあれば、それらの列を続けて定義すると圧縮効率が良くなります。 

� 圧縮は列単位ではなく行単位で行われますので、列を跨ったパターンで辞書が作成されることもあります。 

圧縮後 

圧縮前 

… 

… 

Plano, TX, 

24355 

02 

500 

01 

… 

… 

Plano, TX, 

24355 

02 

500 

01 

24355 

TX 

Plano 

10000 

500 

Fred 

24355 

TX 

Plano 

20000 

500 

John 

ZipCode 

State 

City 

Salary 

Dept 

Name 

24355 

TX 

Plano 

10000 

500 

Fred 

24355 

TX 

Plano 

20000 

500 

John 

ZipCode 

State 

City 

Salary 

Dept 

Name 

… 

24355 

TX 

Plano 

20000 

500 

John 

24355 

TX 

Plano 

10000 

500 

Fred … 

24355 

TX 

Plano 

20000 

500 

John 

24355 

TX 

Plano 

10000 

500 

Fred 

… 

(02) 

20000 

(01) 

John 

(02) 

10000 

(01) 

Fred … 

(02) 

20000 

(01) 

John 

(02) 

10000 

(01) 

Fred 

Dictionary


解説 


20 


� VARCHAR/VARGRAPHIC列を使用する場合には、可変長であるメリットとデメリットを考慮し 

た上で、使用して下さい。 

� 可変長列は、2種類の情報を持っています。 

� データの長さ 

� データ 

� 可変長データを読み込む場合、まずデータの長さを読み取り、次にデータをその長さ分読み取るという2段階を経るため、 

パフォーマンスに影響が出ます。 

� また、可変長データに変更が発生した場合、元データより長くなると同じページに収まらなくなってしまう可能性がありま 

す。 

� その場合、移動先の情報を持ったTombstoneが元のデータ位置に残されます。 

� その為、そのレコードを取得するために、ページを2段階経なければならなくなる可能性があります。 

C1 C3 C2Len C2 Data 

BPS header 

OS0OS1OS2 

Tombstone 

新しいページ 

� 更新がある場合、データのフラグメンテーションを招き、 REORG運用が必要となる可能性が高くなります。 

� VARCHAR列を使用するのが望ましい場合: 

� データの長さの範囲がまちまちで、ほとんどの列は短い 

� データの長さの範囲がまちまちで、全ての範囲でほぼ均等に分布 

� VARCHAR列を使うべきでない場合: 

� データの長さの範囲はまちまちだが、ほとんどの列は範囲の上の方にある 

� VARCHAR列にすることによって、ディスク・スペースが余計にかかり、パフォーマンスが低下するケース 

3 

Record 2 

Record 1 

Rec 0


解説(生成列) 


21 


� 生成列とは、各行の値を挿入操作または更新操作からではなく、定義した式によって定めることが 

できる列です。更新トリガーおよび挿入トリガーを組み合わせて使用すると同様のことが行えます 

が、生成列を使用すると、派生した値が式と一貫したものであることを保証できます。 

� 表で特定の式や述部を頻繁に使用することがわかっている場合、生成列を使用してあらかじめ値 

を生成しておくことにより照会の際のパフォーマンスを向上させることが可能です。 

� 表で生成列を作成するには、ALTER TABLEまたはCREATE TABLE時にGENERATED ALWAYS 

AS 文節を使用して、列の値を定義する式を含んだ列を指定します。 

� 生成列には検査制約やユニーク索引/基本キーが使用できない、生成列を持つ表に対して 

RENAME TABLE ができない等の制約事項があるので使用にあたっては考慮が必要です。 

� 生成列の例 

� "c1" および "c2" という通常の 2 つの列と、表の通常の列から派生した "c3" および "c4" という 2 つの生成された列の入った表 

を作成します。 

CREATE TABLE T1(c1 INT, c2 DOUBLE, 

c3 DOUBLE GENERATED ALWAYS AS (c1 

+ c2), 

c4 GENERATED ALWAYS AS 

(CASE WHEN c1 > c2 THEN 1 

ELSE 0 

END) 

); 

INSERT t1 (C1, 

C2) 

VALUES (10, 3) 

INSERT 

t1表 

t1表 

C1 C2 C3 C4 

C1 + C2 

C1 C2 C3 C4 

10 3 13 1 

10 + 3 = 13 

10 > 3 なので1 

C1 > C2 の時は1 

それ以外は 0 

データベース 

マネージャーが 

値を生成


解説(IDENTITYE列とSEQUENCE) 


22 


� IDENTITY列(識別列)は生成列の中の一つで、表の各行に対して固有な基本キー値を自動 

的に生成します。 

� 識別列では、アプリケーションがデータベースの外に独自のカウンターを生成する際に生じる、並行性およびパフォーマ 

ンス上の問題を回避することが可能です。 

� 固有な基本キーを自動生成する際に識別列を使用しない場合には、単一行の表にカウンターを保管するのが一般的な 

設計方法です。各トランザクションはこの表をロックして、数を増分してからトランザクションをコミットして、カウンターの 

ロックを解除します。しかし、残念ながら、この設計では、カウンターを増分できるのは一度に 1 つのトランザクションのみ 

です。一方、識別列を使用して基本キーを自動的に生成すると、アプリケーションでより高度なレベルの並行性を実現で 

きます。 

� SEQUENCE(シーケンス)とは、値の自動生成を可能にするデータベース・オブジェクトです。 

� シーケンスを使用すると、固有キー値を生成することが可能です。IDENTITY列と同様アプリケーションはシーケンスを使 

用することで、データベースの外部に固有カウンターを生成したことによって発生する可能性のある、並列性およびパ 

フォーマンスの問題を回避することができます。 

� 識別列属性とは異なり、シーケンスは特定の表列に関連付けられていないデータベースオブジェクトです。 

� シーケンス・オブジェクトはどのアプリケーションでも使用できるため、NEXTVALおよびPREVALの二つの値を返す式が定 

められています。 

IDENTITY列 

IDENTITY列 SEQUENC 

t1表 

t1表 

E 

C1 C2 C3 C4 

C1 C2 C3 C4 

create table t1 

(c1 int generated always as 

identity 

(start with 10, increment by 2), 

c2 char(10), c3 double, c4 int) 

列内で固有な値を自動生成 

NEXTVAL 

SEQUENCE 

オブジェクト 

insert into t1 (c1,c2) values (nextval for seq1, 100) 

シーケンス・オブジェクト内で固有な値を自動生成


主キーと外部キー 

� 主キー(Primary Key) 

� 主キーは表の保全性を保証する 

� 格納されるデータの値は、ユニークでなければならない 

� NOT NULL指定必須 

� 主キーを付与するとユニーク索引(1次索引) は自動的に作成される(固有制約) 

� 参照制約を使用しない場合は基本キーではなく、別途ユニーク索引を定義しても可 


 

部門番号部門名 

100 営業部 

200 電算部 

300 総務部 

主キー 

23 

社員番号社員名部門番号 

A111 田中 100 

B222 山田 200 

C333 鈴木 200 


 

� 外部キー(Foreign Key) 

外部キー 

� 親表と従属表の間の親子関係を示す働きをする 

� 別の表の主キーが、その表のデータ項目になっている時、そのキーは外部キーとなりうる 

� 結合操作の結合列になる ⇒ 索引の候補 

� 外部キーは参照の整合性を保証するために、主キーに存在しない値を持ってはいけない(参照制 

約) 

� 参照制約を使用しない場合、あくまでも論理的なものであって、物理定義する必要はない 

� 定義時には、CONSTRAINTにより制約名をつける 

� 管理が容易


解説 


24 


� 主キー 

� 表の固有キーとは、それぞれの値が固有の行を識別する、1つの列または複数の列の順序集合のことです。たとえば、社員 

番号の列の各値は一人の社員だけを指すものなので、これを固有キーとして定義することができます。二人の社員が同じ社 

員番号を共有することはできません。 

� 表の主キーは、1つの表上に定義された固有キーの1つですが、その表上で1番目に重要なキーとして選択されたものです。 

1つの表上には1つだけの基本キーが可能で、そのエンティティ内で行を唯一無二のものとして識別できるデータ項目です。 

� 主キーはエンティティの保全性を保証するために、ユニークであり、空白値は許されません。 

� 外部キー 

� 表の外部キーは、親表の固有キーまたは主キーを参照する、表内の1つの列または1組の列のことです。 

� 外部キーは表(親表)と表(従属表)の間の参照の整合性を保証するために、基本キーに存在しない値を持ってはならず、結 

合操作時には結合列になります。 

� 参照制約を使用しないのであれば、親表と従属表の間の親子関係を示すあくまでも論理的な 

意味合いのものであり、主キーと外部キーの物理的な設定は必須ではありません。 

� 主キー、外部キーの定義時には、CONSTRAINTにより制約名をつけたほうが管理しやすくなり 

ます。 

� 主キーの定義 

CREATE TABLE 親表名 

(主キー列名・・・ NOT NULL, 

・・・・・・・, 

・・・・・・・, 

CONSTRAINT 制約名 PRIMARY KEY(主キー列名)) 

� 外部キーの定義 

CREATE TABLE 従属表名 

(・・・・・・・, 

外部キー列名 

・・・ 

NOT 

NULL, 

・・・・・・・, 

CONSTRAINT 制約名 FOREIGN KEY(外部キー列名) 

REFERENCES 親表名 

ON DELETE 規則)


制約 


25 


� データの保護や、データ間の相互関係の定義をDBMSに行わせる 

� アプリケーション・ロジックとしてコードを作成する必要がない 

� 事前に制約を使用するか否かの方針決めが必要 

� 使用する場合は、制約違反エラーのハンドリング・ロジックが必要 

� データ格納時にDB2により厳格にチェックされる 

� バッチによる大量の更新時や、テスト環境でのテスト・データ作成時に、格納順番やデータの値を考 

慮する必要あり 

� 3種類の制約を提供 


col1 col2 

固有? 

� 表の 1 つまたは複数の列に重複する値を指定することを禁止する規則 

1 A1 


� 表の各行の1つ以上の列について可能な値を指定する規則 

20 


INSERT 

� 外部キーの値が親キーの値として現れる場合、または外部キーの構成要素の一部がヌル値の場合 

のみ有効とする規則 

'A3' INSERT 

� (情報制約) 

� DB2による制約情報チェックの適用/非適用の設定が可能な制約(V8) 

1 

INSERT 

col3 

col3 < 20? 

col2 

10 A1 

col1 col2 

1 A1 

親表に存在する? 

c1 

A1 

A2


解説 


26 


� 制約を利用すると、データの保護や、データ間の相互関係の定義をデータベース・システ 

ムに行わせることが可能です。これにより、アプリケーションでコードを作成し、これらの規 

則を施行する必要がなくなります。 

� 事前に制約を使用するか否かの方針決めを最初に確定させる必要があり、使用するので 

あれば、制約違反エラーのハンドリング・ロジックは必要となります。 

� データ格納時にDB2により厳格にチェックされるため、バッチによる大量の更新時や、特に 

テスト環境でのテスト・データ作成時に、格納順番やデータの値を考慮するが必要ありま 

す。例えば、参照制約が定義されている表については、データのINSERTは必ず親表を先 

にする必要があります。 

� DB2は以下の種類の制約を提供しています。 


� 表の 1 つまたは複数の列に重複する値を指定することを禁止する規則 


� 表の各行の1つ以上の列について可能な値を指定する規則のことです。 


� 外部キーの値が親キーの値として現れる場合、または外部キーの構成要素の一部がヌル値の場合のみ有効とする 

規則 

� (情報制約) 

� V8から、情報制約(Informational Constraint)と呼ばれる新しいタイプの制約により、DB2による制約情報チェックの適 

用/非適用が設定可能になりました。 

� 制約情報を非適用とすることにより、ビジネス・アプリケーションのロジックによってチェックされ、この場合、データベー 

ス・マネージャーによってチェックされることはありません。また、オプティマイザーによる制約の利用を活動化、または 

非活動化させる指定も可能です。 

� 下記のオプションを CREATE または ALTER TABLE で指定します。 

– ENFORCED:DB によって更新操作時、常に制約をチェックさせる。 

– NOT ENFORCED:DB に制約をチェックさせない。また、SET INTEGRITY を使用しても、チェックされません。この場合、 

実際に制約に違反するデータが入る可能性あるため、アプリケーションでのチェックする必要があります。 

– ENABLE QUERY OPTIMIZATION:オプティマイザーのQuery Rewriteを活動化する。 

– DISABLE QUERY OPTIMIZATION:オプティマイザーのQuery Rewriteを非活動化する。 

� 制約は、CREATE TABLE文およびALTER TABLE文を使用して、表の列に対して定義します。


解説 


27 


� 固有制約の例 

� 表t1 には、列 (col1, col2, col3) があり、col1 の各データは表で固有でなくてはならない場合、例えば次のように定 

義します。 

create table t1 (col1 int not null, 

col2 char(10) not null, 

col3 int, 

constraint t1_uniq UNIQUE (col1)) 

� このcol1列に重複した値をINSERTすると、SQL0803Nのエラーとなります。 

� 表検査制約の例 

� t1のcol3には、かならず20未満でなくてはならない場合は、以下のように表を定義します。 



col3 int, 

constraint col3check CHECK (col3 < 20)); 

� col3に20以上の値をINSERTしようとすると、SQL0545Nのエラーになります。 

� 情報制約の例 

� 上記で定義した表検査制約と同等ですが、アプリケーションで保証することとし、DB2はチェックしません。 



col3 int, 

constraint col3check CHECK (col3 < 20) NOT ENFORCED ENABLE QUERY 

OPTIMIZATION);




28 



表の設計 

�1行のレコードがページをまたがることはできない 

� LONGデータを除く 

� 最適なページ・サイズの決定(4KB/8KB/16KB/32KB) 

�行の削除によるスペース解放はない 

� 削除してもDiskの使用率は変わらない 

� 再利用はされる 

� APPENDモードの指定により再利用させないことも可能 

� REORGなどの運用が必要 

�ページの空き領域の設定 

� 予め、ページ内にフリー・スペースを残す設定 

� 設定が必要か否かの検討が必要 

� 離れたページにデータが挿入されると、パフォーマンスに影響を与える 

– クラスター索引を持つ表 

– 可変長列の更新がある表 

� ALTER TABLEによるPCTFREE指定 

� LOAD、REORG時に指定されたフリー・スペースを確保 


29 



解説 

� 1行のレコードが複数のページにまたがることはできません。 

� 1レコードの長さがページ内に収まらない場合は、ページサイズを大きくして下さい。 

� 4KB → 8KB → 16KB → 32KB 


30 


� データの削除が行われたとき、そのレコードのあった場所は解放されません。(再利用はされま 

す。)削除のフラグが立つのみです。Diskの使用率は変わりません。 

� 削除されたスペースを解放させるためには、reorg tableを実行して下さい。 

� APPENDモード 

� INSERT時に表内の空きページを検索することなく、最終ページにレコードを追加する機能。(APPENDモード ON) 

� レコードが単調増加していく特性の表にINSERTする場合、パフォーマンスが向上しますが、DELETEによる削除レコードの空 

き領域は再利用されないため、別途、表自体の再作成(もしくは、0件)、または再編成などの運用により、表容量を適正に保 

つ仕組みの検討が必要とななります。 

� クラスター索引のある表には適用不可。 

� ページの空き領域(PCTFREE) 

� 離れたページにデータが挿入されると、パフォーマンスに影響を与える為、予めページ内にフリー・スペースを残す様に設定 

することができます。 

� ALTER TABLE 表名 PCTFREE 数値 

� PCTFREE:0~99 (デフォルト:-1) 

� データのロード、およびREORG TABLE時に、指定されたサイズのフリー・スペースをページ内に残します。 

� PCTFREEの設定が必要な例 

� クラスター索引を持つ表(データの挿入時に、索引順とデータの並び順を同じにするようにデータを格納しようと試みる)に対し 

て、業務上の観点から、データの追加、削除処理の頻度にも留意し、ページの空き領域(PCTFREE)の設定の検討が必要 

です。データの挿入が多い場合、索引順序にデータを配置しようとしても、ページ内に収まらない場合があります。 

� また、可変長の属性の列項目を持つ表において、その列項目に対して更新がある場合、空き領域を設けることを検討する。 

� オンライン中の更新がない、または、クラスター索引を持たない列項目の属性が固定長のみで定義されている表については、 

空き容量は特に必要ありません。


ページ・サイズの決定 


31 


�表を格納するページサイズを決定する 

� データの行長・カラム数の制限 

� 表容量の制限 

� LARGE RID(V9)が使用可能な表スペース(LARGE DMS表スペース、一時表スペース)の場合、 

制限値が異なる。(下表参照。) 

� 格納効率も考慮する必要がある 

� LARGE RIDを使用しない表スペースでは、ページ・サイズにかかわらず1ページに格納できる 

行数は最大255行まで。 

� LARGE RIDを使用する表スペースでは、1ページに255行以上格納可能。(下表参照。) 

� アプリケーションの特性(OLTP or DSS)や管理面も考慮する 

�ページ・サイズによる制限値 

ページ・ 

サイズ 

行長 

(bytes) 

�表の分割、パーティション表(V9)も検討する 

� UNION ALL VIEWに対する参照(V6,V7でも可) 

� UNION ALL VIEWに対する更新、INSERTも可(V8) 

� パーティション表(V9) 

列数非LARGE表スペース LARGE表スペース 

表容量行数/ページ表容量行数/ページ 

4KB 4005 500 64GB 255 2TB 287 

8KB 8101 1012 128GB 255 4TB 580 

16KB 16293 1012 256GB 255 8TB 1165 

32KB 32677 1012 512GB 255 16TB 2335


解説 


32 


� ページ・サイズ 

� 表に必要となるディスク容量を計算する時に、どのページサイズを使用するかが非常に重要な要素になります。 

� DB2では、4K/8K/16K/32Kバイトの4種類のページサイズをサポートします。 

� 1行のレコードが複数のページにまたがることはできません。1レコードの長さがページ内に収まらない場合は、ペー 

ジサイズを大きくして下さい。 

� 表の最大容量の制限 

� V8までは、表の最大容量は64/128/256/512GB(それぞれのページサイズは4/8/16/32KB)でしたが、V9以降では、 

LARGE RIDを使用することにより、最大容量が2/4/8/16TB (ページサイズは4/8/16/32KB)に拡張されました。 

� 格納効率 

� LARGE RIDを使用しない表スペースの場合、1ページに格納できるのは最大255行までという制限があります。 

� 1行のサイズが100バイトの表があった場合、32KBページでは最大約 (32000 ÷ 100) 320行を1ページに格納できるは 

ずですが、この制限によって(320 - 250)約70行分のデータ領域にはデータが格納されず使われない無駄な領域にな 

ります。 

� 例えば、レコードサイズがLOB(Large Object:BLOB,CLOB,DBCLOB,LONG VARCHAR)を含まない5000バイトの表が 

あった場合、4KBページでは表を作成することができません。5000バイトの長さを持つ表を作成するためには、少なくと 

も8Kバイトのページサイズを使用する必要があります。しかしこの場合、8Kバイトページのうち5000バイトにしかデータ 

が書かれない為、残りの3000バイトは使用されない無駄な領域になります。このようなケースの場合、16KBページとい 

う選択肢もあります。16KBページには、5000バイト長のレコードは3レコード入ります。残りは1000バイトとなり、使用さ 

れないスペースを抑えることができます。 

� LARGE RIDを使用する表スペースでは、この行数の上限値が大きくなりますので、レコードが格納されない無駄な 

領域を減らすことができます。(1ページ当たりに格納できる行数の上限値は、ページサイズ毎に異なります。) 

� 行のランダム読み取りおよび書き込みを実行するOLTPアプリケーションは、不必要な行に使用するバッファー 

ページを少なくするために小さいページサイズを使用するようにしてください。 

� 一度に多くの連続した行にアクセスするDSSアプリケーションは、指定された数の行を読み取るのに必要な入出力 

要求の数を減らすように大きなページサイズを使用するようにしてください。 

� 異なるページ・サイズによる考慮点 

� バッファプール、一時表スペースはページサイズ毎に必要 

� USEオプションを使用した再編成では、一時表スペースは表スペースと同じページサイズである必要がある 

� 拡張ストレージは大きなページサイズに合わせる 

� バックアップを異なるページサイズに復元することは出来ない


参考:デフォルト・ページ・サイズの変更(V8.2.2以降) 

�V8.2.2以降では、データベース作成時に4KB以外(8,16,32KB)のデフォルト・ 

ページ・サイズを指定可能。 

� 指定方法 

� CREATE DATABASEコマンドのPAGESIZEオプション 

– 4096, 8192, 16384, 32768または、4 K, 8 K, 16 K, 32 Kを指定可能 

� sqlecrea()APIの引数pDbDescriptorExt 


33 


� 初期表スペースSYSCATSPACE, TEMPSPACE1, USERSPACE1、デフォルト・バッファー 

プールIBMDEFAULTBPは、データベース作成時に指定されたページ・サイズで作成され 

る。 

� 明示的にページ・サイズを指定して表スペース、バッファープールを作成することも可能。 

�考慮点 

� 不必要に大きいページ・サイズを使用すると、領域が無駄になることがある。 

� バッファープールに読まれるときの領域の無駄 

– 特に、データにランダムにアクセスするOLTPアプリケーションの場合 

� 1ページあたりの行数の制限 

– ページ・サイズに関わらず255行まで 

� データベース作成時に指定したデフォルト・ページ・サイズは後から変更できない。




34 



参考:UNION ALL VIEWによる表分割 

�UNION ALLビューとは 

� 複数の結果表を組み合わせて新たな結果表として定義されたView 

� UNION ALLを指定すると結果は該当表のすべての行から構成される 

�表分割の目的 

� 表スペースサイズの制限による分割 

� 履歴データ等のレンジ・パーティションを実現 

� データ削除を分割された表単位のIMPORT REPLACEなどで実行できる 

� REORGなどの運用を表毎に個別に行える 

�VIEW定義の方法 

� CREATE VIEW文中のSELECT文で、WHERE文節によって値を制限 

� このVIEWに対するINSERTは不可 

� 表に対するCONSTRAINTによって値を制限 

� INSERTを使うためにはCONSTRAINTが必要(V8以降) 


35 



解説 

�UNION ALLビューの例 

CREATE TABLE Q1(order DATE,month SMALLINT,item VARCHAR(10)); 

ALTER TABLE Q1 ADD CONSTRAINT q1ckc1 CHECK (MONTH BETWEEN 1 AND 3); 

ORDER MONT ITEM 

2003-01-01 H 

2003-02-01 

1 xxxx 

2 xxxx 

表Q1 

2003-03-01 3 xxxx 

CREATE TABLE Q2(order DATE, month SMALLINT,item VARCHAR(10)); 



2003-04-01 H 4 xxxx 

2003-05-01 5 xxxx 

2003-06-01 6 xxxx 

表Q2 




2003-07-01 H 

2003-08-01 

7 xxxx 

8 xxxx 

表Q3 

2003-09-01 9 xxxx 




2003-10-01 H 

2003-11-01 

10 xxxx 

11 xxxx 

表Q4 

2003-12-01 12 xxxx 


36 


CREATE VIEW VIEW_YEAR(order, 

month,item) AS SELECT * FROM Q1 

UNION ALL 

SELECT * FROM Q2 

UNION ALL 

SELECT * FROM Q3 

UNION ALL 

SELECT * FROM Q4; 

ビュー 

VIEW_YEAR 

ORDER MONTH ITEM 

2003-01-01 1 xxxx 

2003-02-01 2 xxxx 

2003-03-01 3 xxxx 

2003-04-01 4 xxxx 

2003-05-01 5 xxxx 

2003-06-01 6 xxxx 

2003-07-01 7 xxxx 

2003-08-01 8 xxxx 

2003-09-01 9 xxxx 

2003-10-01 10 xxxx 

2003-11-01 11 xxxx 

2003-12-01 12 xxxx


参考:UNION ALL VIEWによる表分割(続き) 


37 


�UNION ALL VIEW 使用上の注意点 

� アクセス・パスを充分確認した上で使用する 

� VIEWへのSELECTを表へのSELECTに変換するのはオプティマイザーであ 

る。 

� オプティマイザーが解らない場合は、表を特定できない。その場合、全て 

の表にアクセスしてしまう 

� 表を特定できない例 

– 照会の条件が、CHECK制約やVIEW定義のWHERE条件に合致しない 

– CHECK制約にMONTHなどの関数を使用...等 

� オプティマイザーはVIEW中のSQL文を展開してから評価するので、展開後 

のSQL文が長くなる可能性がある 

� ステートメント・ヒープ、アプリケーション・ヒープがより多く必要 

� SQL文の長さの制限(64K)を超える可能性がある 

� 長すぎるSQL文でオプティマイザーがあきらめて、単純なアクセスパスに 

走る可能性がある 

� UNION ALL VIEWへの更新系処理はオーバーヘッドが生じる 

� 各表へのチェック処理 

� 更新処理は、なるべく実体の表に対して直接処理を行う


解説 

�オプティマイザ-によって表が特定される例 

Create Table Q1_2(Order Date,month smallint,item varchar(10)); 

alter table q1_2 add constraint q1chck2 check (month between 1 and 3); 







Create view VIEW_YEAR2(order,month,item) as 

select * from Q1_2 union all 



select * from Q4_2; 

Original Statement: 

-----------------select 

* from view_year2 where month = 1 

Optimized Statement: 

------------------- 

SELECT Q1."ORDER" AS "ORDER", Q1."MONTH" AS "MONTH", 

Q1."ITEM" AS "ITEM" 

FROM ADMINISTRATOR.Q1_2 AS Q1 

WHERE (Q1."MONTH" = 1) 


�オプティマイザ-によって表が特定されない例 

38 



alter table q1_1 add constraint q1chck1 check (MONTH(order) between 1 and 3); 







Create view VIEW_YEAR1(order,month,item) as 




select * from Q4_1; 

Original Statement: 

-----------------select 

* from view_year1 where month = 1 

Optimized Statement: 

------------------- 

SELECT Q9.$C0 AS "ORDER", Q9.$C1 AS "MONTH", Q9.$C2 AS "ITEM" 

FROM 

(SELECT Q1."ORDER", Q1."MONTH", Q1."ITEM" 

FROM ADMINISTRATOR.Q1_1 AS Q1 WHERE (Q1."MONTH" = 1) 

UNION ALL 

SELECT Q3."ORDER", Q3."MONTH", Q3."ITEM" 


UNION ALL 



UNION ALL 


FROM ADMINISTRATOR.Q4_1 AS Q7 WHERE (Q7."MONTH" = 1) ) AS Q9


参考:パーティション表による表分割 


39 


�データの範囲によって、ひとつの表を複数のパーティションに物理的に分割し 

て保存する 

� CREATE TABLEステートメントのPARTITION BY文節で指定されたパーティション・キー列の値 

に従って、表を複数のパーティションに分割する 

� それぞれのパーティションは、異なる表スペースにも、同じ表スペース内にも配置することがで 

きる 

�新しいパーティションのアタッチ/デタッチが可能 

履歴表A 

区分の 

デタッチ 

JAN01 JAN02 JAN03 JAN04 

JAN01 

JAN05 

JAN05 

区分の 

アタッチ


参考:パーティション表による表分割(続き) 

�表を分割 

�区分化された単位は「データ・パーティション」、または「レンジ」と呼ばれる 

�キーレンジによるデータ分散 

�大規模データベースの実現 

�巨大な表 

�高速なデータアクセス 

�高速なロールイン/ロールアウト 

CREATE TABLE T1 

( COL1 INT, COL2 DATE ) 

PARTITION BY RANGE (COL2) 

( 

STARTING FROM (‘2006-01-01’) 

ENDING (‘2006-12-31’) 

EVERY (3 MONTH) 


) 

40 

表 T1 

キーレンジによるデータ分散 

JAN-MAR APR-JUN JUL-SEP OCT-DEC 

データ・ 

パーティショﾝ0 

データ・ 


データ・ 


DBパーティショﾝ0 


データ・ 

パーティショﾝ3


参考:パーティション表による表分割(続き) 


41 


� パーティション表のメリット 

1. 保存期間を過ぎた行の高速な削除 

� 保存期間の過ぎた行を含むパーティションをデタッチし、デタッチした表をDROPする 

2. 新規データのオンライン高速ロード 

� あらかじめLOADしておいた表を、既存のパーティション表にアタッチする 

3. データアクセスの性能向上 

� 指定された条件によって、特定パーティションのみにアクセスする 

4. 故障範囲の局所化(各パーティションを異なる表スペースへ配置) 

� 各パーティションを異なる表スペースへ配置しておけば、ある表スペースがアクセス 

不能になっても、その他の表スペースに配置されたパーティションへのアクセスは可 

能 

5. バックアップ性能の向上 

� 各パーティションを異なる表スペースへ配置し、並列でバックアップを実行する 

(BACKUPコマンドのPARALLELISMオプションを使用)




42 



索引の設計 

� 索引の目的 

� 照会処理の処理効率を高める 

� アクセス・パスにおける索引の使用による効率のよいデータへのアクセス 

� 行のユニーク性を維持する 

� ユニーク索引 

� データの並び順を索引順に維持することにより、データ・アクセスの効率を向上させる 

� クラスター索引 

� 設計手順 

� パフォーマンス改善を目的とし、繰り返し行う必要がある 

� 索引候補の検討 

� 索引数の検討 

� 索引候補の取捨選択 

� 索引の物理定義と検証 

� 索引が有効に利用され最適なアクセスパスになっているか 

� 意図した索引を使用しているか 

� メンテナンス負荷を軽減するため、使用されていない場合にはDROP 

� SYSCAT.PACKAGES(静的SQL)、または、EXPLAINツールで確認 


43 



解説 


44 


� 表に作成する索引は、本の索引と同様の機能を果たします。 

� 索引の第一の目的は、データをアクセスする際の処理効率を向上させることです。余計な 

入出力をすることなく、最短の方法で目的のデータにたどりつくには、索引は非常に有効 

です。 

� ユニーク索引を作成した際には、索引のキー列のユニーク性を保証する機能を使用可能 

です。 

� クラスター索引 

� クラスター索引を作成すると、データの挿入時に、索引順とデータの並び順を同じにするようにデータを格納しようと 

試みます。 

� データを索引の列項目の値順に読み込む場合、I/O回数が軽減され、処理効率が向上します。 

� クラスター索引を作成する場合、データが格納されるページに空きスペースを準備する必要があります。 

� 索引の列項目の値が更新される(更新があった場合、索引順に再格納は行わないため、再編成の必要性を検討す 

る必要がある)場合や、検索結果が常に1件となる照会処理が頻繁に行われる場合は、作成してもメリットはありま 

せん。 

� 索引の設計手順 

� パフォーマンス改善を目的とし、内部設計から統合テストの局面まで、繰り返し行う必要があります。 

� 索引候補の検討 

� 主キーや外部キーなどは、データの意味から索引候補として決定可能であるため、外部設計後に可能な作業です。一 

方、その他の2次索引については、具体的なSQL文を元にアクセス・プランを検討し、候補の洗い出しを行います。 

� 索引数の検討 

� 索引数が増えると、索引のメンテナンス負荷が高くなり、処理効率が低下します。従って、トランザクションの内容によ 

り、索引数を制限して作成する必要があります。 

� 索引候補の取捨選択 

� どの列に索引を付与するか、最適なアクセス・プランを検討し、本当に必要と思われる索引を選択します。 

� 索引の物理定義と検証 

� 索引が有効に活用されているかを確認し、使用されていない場合には、DROPする必要があります。索引が存在す 

ることによるメンテナンス負荷を軽減するためです。静的SQLプログラムについては、SYSCAT.PACKAGESで確認で 

きます。また、動的SQLプログラムについては、EXPLAINツールで確認します。


索引候補の検討 


45 


�ユニーク索引が必要か 

� ユニーク性の維持が必要な場合:ユニーク索引 

� 参照の整合性が必要な場合:主キー 

� CREATE TABLE実行時に、自動的に主キーに対する昇順のユニーク索引が作成 

される 

– 索引名 : SQL+タイムスタンプ+番号 

– 索引スキーマ: SYSIBM 

– CONSTRAINTで制約名をつけると管理が容易 

�外部キーに索引をつける 

� 結合列になる可能性が高い列に索引があると、処理効率は良い 

�条件句(WHERE句に現れる述語)の中で頻繁に使用される列を 

検討 � 結合列 

� 探索条件の列 

� ANDで結ばれた等号述語 

� 範囲指定の述語(BETWEEN,不等号述語) 

� ソート列(DISTINCT、ORDER BY、GROUP BYで指定された列) 

� 索引のみのアクセスを目的とした索引 

� INCLUDE列つきのユニーク索引


解説 


46 


� 基本的な索引候補 

� まず、ユニーク索引が必要かどうかを検討します。ユニーク性を維持しなければならない列が存在するので 

あれば、ユニーク索引が必要です。 

� 主キーの必要性を検討します。他の表の列と整合性を保たなければならない、マスターとなる列が存在す 

るのであれば、表に主キーを設定します。基本キーの設定は、表の作成(CREATE TABLE)時に指定す 

るか、または、表の変更(ALTER TABLE)で指定します。 

� 外部キーがある場合、検索条件の結合列となる可能性が高いため、索引の候補になります。 

� さらに、その他の2次索引候補を検討します。 

� 候補になる列は、条件節での登場回数が多い列です。 

� また、ソートの対象となる列も候補になります。 

� FOREIGN KEY(外部キー)が定義されている列項目 

� レコードの探索条件として、「=」述部に指定されることの最も多い列項目、もしくは、最初のキーとしての個 

別の値が最も多い列 

� 表を結合するときに使用するすべての列 

� INCLUDE列つきのユニーク索引 

� ユニーク索引の列として、ユニークではない列を含むことが可能 

� 目的: 索引のみのアクセスによるパフォーマンス向上 

� 冗長な索引を作成しない 

� 表にアクセスすることなく、索引のみで照会処理要求を満たすことができます。これをindex-only accessとい 

います。 

� INCLUDE列を指定してユニーク索引を作成することにより、データページのアクセス頻度が軽減されます。 

� 索引キーの一部の列については、ユニーク性を保持する 

� ユニークではない列については、ユニーク性の検査が発生しない 

� 作成方法: CREATE UNIQUE INDEX 索引名 ON 表名 (列名) INCLUDE (列名) 

� 複数列の指定が可能 

� ユニークではない列については、索引順(ASC,DESC)の指定は無効


参考:INCLUDE列つきのユニーク索引の使用例 


47 


� 処理するSQLステートメントの例:(employee_idに主キーがある) 

� SELECT employee_id, mgr_id FROM my_employee WHERE employee_id = 78379 ; 

� INCLUDE列を使用しない例:2つの索引を作成・維持する必要あり 

� 1.表の作成 

� CREATE TABLE my_employee ( employee_id integer not null, mgr_id integer, phone_no integer, 

hire_date date, PRIMARY KEY (employee_id) ); 

– DB2は主キーには自動的にユニーク索引を作成する 

� 2.索引のみのアクセスのために、索引を作成する 

� CREATE INDEX col_index ON my_employee (employee_id, mgr_id) ; 

� INCLUDE列を使用する例:1つの索引だけで INDEX ONLY ACCESS 

� 1.表の作成 

� CREATE TABLE my_employee ( employee_id integer not null, mgr_id integer, phone_no integer, 

hire_date date) ; 

� 2.INCLUDE列つき索引の作成 

� CREATE UNIQUE INDEX my_index on my_employee (employee_id) INCLUDE (mgr_id) ; 

� 3.主キーの作成 

� ALTER TABLE my_employee add PRIMARY KEY (employee_id); 

– 既存の索引が主キーになる


索引候補の取捨選択 

� 索引の作成を避けた方がよい列 

� 可変長列 

� 索引のメンテナンスの負荷が高い 

� 統計情報のCOLCARDの値が小さい(重複値の多い)列 

� (例) フラグ(0 or 1)や区分など 

� SYSCA.COLUMNSのCOLCARD列:ユニークな値の数 

� オプティマイザ-が索引を選択しない 

� サイズがごく小さい表の列 

� アクセス・パスの決定時に索引が有効とみなされず、表スキャンになる可能性が高い 


48 


� 複合列索引の考慮点 

� 複合列索引の全ての列が等号で使用されるものは有効 

� 索引列は、最も頻繁に等号で指定される列か、最もユニーク性の高い列から順に指定する 

� 最初の索引列で結果行を大幅に絞り込める索引は使用されやすい 

� 完全にマッチングする索引を優先する 

� (例)索引1(col1,col2,col3) と索引2(col1,col2)がある場合で、条件がcol1=x and col2=x であ 

れば索引2を優先 

– 索引2はFULLKEYCARDが有効であり、かつ、キー長が短いのでバッファーヒット率が高い 

� 統計情報でFULLKEYCARDが大きいものは有効 

� SYSCAT.INDEXES(FULLKEYCARD):列全体でユニークな値の数


索引数の検討 

�索引数の目安:表あたり5個以下が望ましい 

� むやみに索引を作成することは、ディスクを無駄に消費し、負荷を増やすことになる 

� オンラインでの更新処理環境:1-2個 

� 照会のみの環境:5個以上作成してもよい 

� オンラインの更新処理と照会処理の混在した環境:2-5個 

�更新処理時には索引のメンテナンスが必要となり、負荷が発生する 

� INSERT処理では、索引列の追加処理が発生 

� DELETE処理では、索引列の削除処理が発生 

� 索引列に対するUPDATE処理では、索引列の変更処理 

� 索引のスプリット処理 

� 行のランダムな追加を予想し、事前にページにフリースペースを確保しておく(PCTFREE) 

�その他の負荷 

� クラスター索引がある表へのINSERTは、索引順を極力保持するようにデータを格納する 

� ディスク・スペース使用量の増加 

� LOAD、REORG時の索引の再作成の負荷 

� 索引の追加によりプログラムのPREPARE時間が増加 

� 静的SQLではBIND時、動的SQLでは実行時の時間が増加する 

� 検討すべきアクセスパスの組み合わせが増加する 


49 


� 前方スキャン、逆方向スキャンの両方が必要な場合、ALLOW REVERSE 

SCANSオプションを指定して索引を作成する(二つの異なる索引を作成する 

必要はない) 

� V9以降、新規で作成される主キー、ユニーク・キー、または索引(拡張索引は除く)は、デフォル 

トでALLOW REVERSE SCANS設定になる。


解説 


50 


� 索引数が増えると、照会のパフォーマンスは向上する可能性がある一方で、索引のメンテナン 

ス負荷が高くなり、更新の際の処理効率が低下します。従って、トランザクションの内容により、 

索引数を制限して作成する必要があります。 

� 複数の索引を作成する前には、ディスク・スペースや処理時間への影響も留意し検討する必要 

があります。 

� 索引のスプリット処理 

� 索引のリーフ・ページが満杯になった時点で、さらにそのページにデータが格納される必要があったとき、索引ページは分割 

され、2つのリーフ・ページになります。分割されるデータの割合は、満杯になった索引ページが索引構造内でどの場所にあっ 

たかにより異なります。 

� 索引ページのフリースペース(PCTFREE) 

� 表にランダムにデータをINSERTするようなアプリケーションにより、索引のリーフページが頻繁にスプリットされてしまうのを 

防ぐために有効です。 

� CREATE INDEX ステートメントのオプションです。また、LOAD時にMODIFIED BY INDEXFREESPACE=xにより、再指定するこ 

とも可能です。 

� フリースペースが確保されるタイミングはLOADおよびREORG時です。 

� 以下の場合には、フリースペースは必要ありません。 

� INSERT,DELETEがない 

� 索引キーの更新がなく、固定長列のみなので更新による行のネスティングが発生しない 

� 照会のみである 

� LOADに関する考慮点 

� LOADの前に索引作成を行っておいたほうが、LOAD後に索引を作成した場合と比較すると、合計時間が短くてすみます。ま 

た、事前にユニーク索引を作成しておいた場合には、LOAD時にユニーク性の検査が行われます。 

� LOADの前に索引を作成しておく場合には、索引を作成するための一時領域を確保しておく必要があります。メモリー領域と 

しては、DB構成パラメーターSORTHEAPに設定された容量のソート領域が使用されます。また、ディスク領域としては、一時 

表スペースが使用されます。


V9.5 

索引に関するその他の検討事項 

� 索引用の表スペース 

� 索引用の表スペースを作成する(DMSのみ) 

� 表データとは別の物理ディスクに配置することによる並列I/Oが期待できる 

� 索引だけ早いディスクに格納することができる 

� 索引用の表スペースに対するバッファープールを作成する 

� 索引をメモリー上に保持し、バッファーヒットさせたい場合 

� 索引用の表スペースはDMSファイル表スペースにすることも検討? 

� AIXファイルシステムのキャッシュが使用可能 


51 


� 索引が有効利用され、最適なアクセスパスを得るために 

� 索引順を維持する 

� クラスター索引により索引順を維持する 

� REORGにより定期的に索引順を維持する 

� ユニーク索引の列による1件検索の場合には、クラスター率が低くても問題はない 

� RUNSTATSの実行による統計情報更新とBIND実行 

� 実行タイミング 

– 表のデータがLOADされ、適切な索引が作成された時 

– 表のデータがREORGされた時やアプリケーションをBINDする時 

– 表および索引のデータの10%-20%がUPDATE/DELETE/INSERTされた時 

� 現時点の統計情報に更新することにより、現状で最適なアクセス・パスが選択される(動的SQ 

Lの場合) 

� RUNSTATS実行後、BINDを実行する(静的SQLの場合) 

� 索引のTYPE 

� DB2 V9.5 では、タイプ 1 索引は推奨されません、将来のリリースで廃止される可能性があります。


解説 


52 


� 索引データを索引用の表スペースに格納するためには、表の作成(CREATE TABLE)時に、 

その表に対して作成された索引のデータをどの表スペースに格納するかを明示的に指定しま 

す。 � CREATE TABLE 表名 (COL1 INTEGER, .......) IN 表の表スペース名 INDEX IN 索引の表スペース名 

� 索引が作成されている索引用の表スペースをDROPすることはできません。DROP時に、関連す 

るデータベース・オブジェクトが存在するためにDROPが不可能である旨のエラー･メッセージが 

戻されます。この場合、索引を全てDROP後に、表スペースをDROPするか、または、DROP 

TABLESPACE文で、関連する表スペースを全て指定することにより、表スペースをDROPするこ 

とが可能です。 

� RUNSTATSは、表のデータが大きく変化した場合に、統計情報を最新の状態に更新するために 

実行します。動的SQLは動的にBINDを実行するため、RUNSTATSで統計情報を変更するこ 

とによりアクセス・パスが変わる可能性があります。 

� 静的SQLの場合は、RUNSTATS実行後、より最適なアクセス・パスを得るには、BINDを実行す 

る必要があります。 

� RUNSTATSはAND INDEXESオプションつきで実行します。また、必要に応じて、WITH 

DISTRIBUTIONオプションつきで実行し、非一様分布統計情報を収集してみます。


参考:索引列の最大数と索引キーの最大長 


53 


�索引列の最大数と索引キーの最大長は、V8以前とV9で異なる。 

(V9で拡張された。) 

バージョンページ・ 

サイズ 

索引列の最大数索引キーの最大長 

(bytes) 

V8まで 4/8/16/32KB 16 1024 

V9 4KB 64 1024 

8KB 64 2048 

16KB 64 4096 

32KB 64 8192




54 




�表/索引の見積もり 

�表スペースの見積もり 

� カタログ表スペース 

� ユーザー表スペース 

� 一時表スペース 

�ログ領域の見積もり 

� アクティブ・ログ領域 

� アーカイブ・ログ領域 

�製品インストール・ディレクトリーの見積もり 


55 





56 



表/索引の見積もり 

�前提: 

� 見積もりの基礎となる前提の数値、算定根拠を明確にする 

� 各表のレコード件数を見積もる上で必要な数値の収集 

– コード類、マスター類の件数、1日あたりの処理件数 

– データの保持期間、データ増加率 ...etc. 

� お客様にAuthorizeされた前提の数値であることが重要 

– 前提に変更があれば、都度再見積もり可能なようにワークシートにまと 

めておく 

� あくまでも見積もりであり、テスト環境のDBでデータを格納し確認 


57 



解説 


58 


� 論理設計のアウトプットである表を作成した場合に、どれだけのディスク容量が必要となるかを見積もる必要があり 

ます。 

� この容量見積もりは、表に含まれるデータだけではなく、索引のデータも含まれます。後段階でパフォーマンス 

チューニングを行う際に索引が追加されることも考慮し、索引を作成する表スペースの容量には余裕を持たせる必 

要があります。 

� 見積もり作業を開始するにあたっては、表や索引の定義が決定していることは言うまでもありませんが、見積もりの 

基礎となる前提の数値(コード類、マスター類の件数、1日あたりの処理件数、データの保持期間、データ増加率... 

etc)や算定根拠を明確にする必要があります。 

� 各表のレコード件数を見積もる上で必要な数値の収集は、お客様にAuthorizeされた前提の数値であることが重要 

です。 

� 前提に変更があれば、都度再見積もりが必要となりますので、再見積もりが容易になるようにワークシートにまとめ 

ておきましょう。 

� データベース・オブジェクトのサイズは、正確に見積もることができません。サイズの見積もりを難しくする原因は、 

ディスクのフラグメント化によって発生するオーバーヘッド、フリー・スペース、および可変長列の使用などです。これ 

は、列タイプや行の長さが広い範囲で異なる可能性があるためです。まずデータベースのサイズを見積もってから、 

テスト・データベースを作成し、それに標準的なデータを入れてみてください。


表/索引の見積もり 


59 


� 表容量概算:(論理レコード長+10)×レコード件数×安全率 

� 論理レコード長 

� 各データ項目のデータ・タイプ、桁数から各項目の物理サイズを算出。可変長の場合は、平均長を採用。 

� NULL値を許す場合1バイト、可変長の場合4バイトを各該当の列項目あたり加算 

� すべてを合計したのが1行あたりの論理レコード長 

� レコード件数 

� 保存期間、データ増加率も加味 

� 安全率(余裕率) 

� PCTFREEの割合やAPPENDモードであるかも考慮する 

� オーバーヘッド分(フラグメンテーションやオーバー・フロー・レコードの有無) 

� Long列データは他の表データとは別のところに保管 

� LONG VARCHAR、LONG VARGRAPHICは24バイト、LOBは各列の情報(ポインターなど)のみを他データと共 

に持つ 

� 必要なディスク容量 

� 表スペースのページ・サイズを決定し、1ページあたりの行数から必要ページ数を導く(後述) 

� 索引容量概算:(平均索引キー・サイズ+9)×行数×安全率 

� 基本的な算出方法の考え方は表と同等 

� LARGE表スペースに作成した表に定義する索引の場合(LARGE RIDを使用する場合) 

� 索引の1つの行項目当たり 2 バイトが追加で必要。 

– (平均索引キー・サイズ+9 +2 )×行数×安全率 

� LARGE表スペースに作成したパーティション表に定義する索引の場合、LARGE RID分の2バイトと、パーティ 

ションID用の2バイトが追加で必要。 

– (平均索引キー・サイズ+9 +2 +2)×行数×安全率 

� 安全率 

� ノンリーフ・ページやフリー・スペースなどのオーバーヘッドのため、少なくとも2倍は必要 

� 索引の作成時のソートに必要な一時スペースの領域は、上記の式の安全率を3.2として見積もる 

� 後にパフォーマンスチューニングで索引が追加されることも考慮し余裕を見ておく


解説 


60 


� ここで、レコード長を計算する場合、ヌルが可の場合1バイト、可変長の場合4バイトを加える必要があります。 

� 論理レコード長は、各データ項目のデータ・タイプ、桁数から各項目の物理サイズを算出して、可変長の場合は、平 

均長を採用します。NULL値を許す場合1バイト、可変長の場合4バイトを各該当の列項目あたり加算し、これらをす 

べて合計したのが1行のレコード長となります。 

� レコード件数は、保存期間、データ増加率も加味します。また、安全率としてPCTFREEの割合やAPPENDモードであ 

るかの考慮や、オーバーヘッド分(フラグメンテーションやオーバー・フロー・レコードの有無)も考慮します。 

� 索引のキー長も算出方法は基本的には表と同等です。 

� V9からサポートされたLARGE RID(6バイト)は、通常のRID(4バイト)より2バイト拡張されているため、LARGE表ス 

ペースに作成した表に対して定義する索引の場合、索引の1つの行項目あたり追加で2バイト必要です。 

� 更に、その表がパーティション表である場合、索引キーにパーティションIDが含まれますので、その分の2バイトが追 

加で必要になります。 

� 後段階でパフォーマンスチューニングを行う際に索引が追加されることも考慮し、索引を作成する表スペースの容量 

には余裕を持たせる必要があります。 

� 最終的に必要なディスク容量は、表スペースのページ・サイズを決定し、1行の長さから1ページあたりの行数を算出 

し、全データ件数をその1ページあたりの行数で割ることにより、必要ページ数を導きます。(後述)


解説 

�各データ・タイプ毎のサイズ 

データ・タイプバイト 

INTEGER 4 

SMALLINT 2 

DOUBLE 8 

DECIMAL(n,m) (n/2 + 1) 

CHARACTER(n) n 

VARCHAR(n) n+4 

LONG VARCHAR 24 

GRAPHIC n*2 

VARGRAPHIC (n*2)+4 

LONG VARGRAPHIC 24 

DATE 4 

TIME 3 

TIMESTAMP 10 

XML 96 


61 



解説 


62 


� LONG列データ 

� long varchar, long vargraphic のデータです。 

� ファイル名は、SQLxxxx.LFです。 

� 32KB + 4KB(アロケーションとフリースペース情報) 

� 32KBのデータエリアの中は 512×2の累乗のセグメントにわかれています。 

� 512、1024、2048、・・・、32KB 

� LOBデータ 

� SQLXXXX.LB 1024*2の累乗のセグメントずつ増えます。 

� 1024、2048、・・・、64MB 

� SQLXXXX.LBA アロケーションとフリー・スペース情報 

� 64GB毎に4KBページ 1個 + 8MB毎に4KBページ1個。 

� COMPACTパラメータ(CREATE TABLE XXXX) 

� LOBデータの将来の更新のために予めフリースペースを確保しないようにします。 

– LOBデータをより小さいセグメントに分割させます。(パフォーマンスは悪くなりますが,ディスク 

スペースは少なくなります) 

� not compactはスペースを確保します(デフォルト) 

– LOBデータをひとつのセグメントの中に連続してとります 

� 例) create table blob (col0 clob(10m) compact) 

– 2500バイト/行 × 1000 行 load 

– compact-3MB 2048+1024バイトずつとります 

– not compact -4MB 4096バイトずつとります


参考:LOBデータ 

�セグメント(1024)単位でデータを格納 

� 1024バイト*2の累乗 

1MBセグメント 2MBセグメント 

1MB 

LOBデータ 

1.1MBバイト 

LOBデータ 


63 


�compactオプション 

� データが格納されないままのディスク・スペースを有効に活用できる 

� パフォーマンスは低下する可能性がある 

� 再編成(REORG)に注意する 

� compactオプションを使用しない場合、再編成でサイズが大きくなる可能性が 

ある


参考:LOBデータ 

�LOBデータオブジェクト 

� CREATE TABLE時のLOB最大サイズはディスク使用量に影響しない 

�LOB割り振りオブジェクト 

� 64GBごとに4Kページ1個 +8MBごとに4Kページ1個 

�LOB記述子 

REGULAR表スペース 

LONG表スペース 

LOB記述子 

LOBデータオブジェクト 

LOB割り振りオブジェクト 


64 

LOB最大サイズ(バイト) LOB記述子サイズ 


1K 72 

8K 96 

64K 120 

512K 144 

4M 168 

128M 200 

512M 224 

1G 256 

1.5G 280 

2G 316


参考:LOBデータの表スペース計算 

�LOBデータオブジェクト: 

� 実際に格納されるデータのセグメント * レコード件数 

�LOB割り振りオブジェクト: 

� ROUNDUP(LOBデータオブジェクトサイズ/64GB) * 4KB 

+ 

ROUNDUP(LOBデータオブジェクトサイズ/8MB) * 4KB 

�LOB記述子 

� LOB記述子サイズ * レコード件数 


65 



参考:XMLデータの容量見積もり 

�XML部分はRelationalデータとは別に保管される(XDA) 

�Relationalデータ部分には、XMLデータ指定子(XDS)と呼ばれるポインターが格納される。 

�SMS表スペースにXMLデータを保管する場合、拡張子.xdaのファイルとして格納される。 

�XML文書をXML列に格納すると、XML文書サイズの1.5-2.5倍になる 

�さらに大きくなることもあるため、余裕を見てXML文書サイズの3倍程度用意する。 

create table dept (deptID int,…, deptdoc xml) 

deptID 

(int) … deptdoc 

1 … 

… … … 


(XML) 

XML データ指定子(XDS) 

66 

XDA (XML Data Area) 



V9.5 

データ・オブジェクト 

ID … DOC (XML) 

PR27 … 

PR28 … XML記述子 

ACC … 

XDAオブジェクト(XML Data) 


67 

索引オブジェクト 

Regions 

Index 


参考:DB2 V9.5でのXMLデータの基礎表への格納(inline格納) 

�DB2 V9.5では、指定したサイズ以下のXMLデータを基礎表に保持可能 

� 基礎表に保持させたいXML列を定義する際に「INLINE LENGTH 」キーワードを付加する。 

� 表の作成時に、カラムオプションとして指定 

� 下記の例では、10000バイト以下のXMLデータを、ベース表に保持する。 

create table dept (deptID char(8),...,doc XML inline length 10000)


V9.5 

参考:XMLデータの基礎表への格納のメリット 


68 


�メリット 

� XMLデータを参照する際に必要なI/Oリクエスト削減 

� SELECT/INSERT/UPDATE全般の性能向上 

� XMLデータを処理する際にReagions IndexやXDAの参照が不要になる 

� 行圧縮の対象にすることが可能 

�考慮点 

� 通常データとXMLデータを別テーブルスペースに配置する場合、基礎表と 

XDAの容量バランスに注意する。 

� XMLデータの基礎表への保管を行う場合、基礎表のページサイズを大きくした 

上で、基礎表とXDAを同じ表スペースへ格納することも検討する。 

� リレーショナルデータへのアクセスが主たる表に、XML列を追加する場合 

� XMLデータを基礎表に保管する場合、1ページ当たりに格納可能なレコード数 

が減少する。 

� 特に既存のアプリケーション、SQLが存在する場合、1ページ当たりのレコード 

数減少が処理性能に影響する可能性があるため、パフォーマンス検証を行うこ 

とを推奨。


参考:NULLとシステム・デフォルト値のデータ圧縮 

�V8からの新機能 


69 


�目的 � 格納スペースの節約 

� 新しいレコードフォーマットでNULL値の場合には実際のデータページを節約 

� NULL値でないSYSTEM Default値の場合にも実際のデータをページを節約 

� 実際の領域を確保しない 

� 結果として1 page上に入る行数を増やすことが可能 

– 1page 255行の制約は緩和されたわけではない(LARGE RIDを使用しない表 

スペースの場合) 

�圧縮指定方法 

� CREATE/ALTER TABLEでCompressの指定 

� (Table level) VALUES COMPRESS指定 

– NULLsおよび0-length varying-length data type (varchar, vargraphics, long 

varchar, long vargraphic, BLOB, CLOB, DBCLOB) はInsert/Update時にDisk 

上に保管されない 

� (Column level) Compress system default指定 

– numerical 0s, blanksが圧縮可能 

�考慮点 

� 内部的にフォーマットが変更されているため、条件によっては、容量が増大する 

� カラムのオフセット情報等で各列2バイト確保される 

� 圧縮したことにより、オーバーフローが発生する可能性があるので、メリットがある 

かを充分検討する必要がある


解説 

Data Type Byte count (new row format) Byte count (old row format). If column 

is nullable, add 1 more byte to the 

shown list 

ROW OVERHEAD 2 0 

INTEGER 6 4 

SMALLINT 4 2 

BIGINT 10 8 

REAL 6 4 

DOUBLE 10 8 

DECIMAL The integral part of (p/2)+3, where p is the The precision integral part of (p/2)+1, where p is 

the precision 

CHAR(n) n+2 n 

VARCHAR(n) n+2 n+4 

LONG VARCHAR 22 24 

GRAPHIC(n) n*2+2 n*2 

VARGRAPHIC(n) (n*2)+2 (n*2)+4 

LONG VARGRAPHIC 22 24 

DATE 6 4 

TIME 5 3 

TIMESTAMP 12 10 

DATALINK(n) n+52 n+54 

Maximum LOB length 1024 70 72 











70 



参考:データ行圧縮 

� V9からの新機能 

� 目的 

� データ・ページ使用量の削減 

� 特に、繰り返しデータがあるような場合はお奨め 

� I/O負荷の削減 

� トレード・オフとして、CPU使用率の増加(圧縮、解凍のため) 

� バッファー・プールの使用率向上 

� 圧縮された状態でバッファープールに読み込まれる 

� ログ書き出し量の削減(例外有り) 

� Insert/Delete は圧縮されたイメージでロギング 

� Update についてはログ量が増える可能性有り 

� 圧縮指定方法 

1. 

2. 

CREATE/ALTER TABLEで表に対する「COMPRESS YES」の定義 

オフライン再編成の実施 

� 辞書を作成するために「REORG … KEEPDICTIONARY(もしくはRESETDICTIOANRY)」コマンドの実行 

� 辞書作成フェーズを経て、表データの圧縮が行われる 


71 


� 圧縮率の見積もり 

� INSPECTコマンドを使用 

� 指定した表のデータのサンプルを基に辞書を作成し、この辞書を使用して圧縮テストを行うことで、圧縮率を 

見積もる 

� 使用方法 

1. 

2. 

見積もり対象表に対してINSPECTコマンドを実行する 

– $ db2 “inspect rowcompestimate table name t1 results keep t1_estimate.dmp” 

$INSTANCE_HOME/sqllib/db2dumpディレクトリ配下に生成されたファイルに対して、DB2INSPFコマンドを実行する 

– $ db2inspf t1_estimate.dmp t1_estimate.out 

� 考慮点 

� XML列、LONG/LOB列、索引は圧縮の対象にならない 

� データ行圧縮機能を利用するためには、ESEかつ「Storage Optimization Feature」を導入する必要がある


参考:データ行圧縮 

�Lempel Ziv アルゴリズム(LZ78,静的辞書圧縮法)を応用した圧 

縮方法 

�特定のフレーズを辞書に登録し、辞書にあるデータを基に実 

データを圧縮していく 

■LZ78の例 

辞書を作成 

番号 

1 

2 

3 

LZ78辞書 

文字列 

‘AB’ 

‘BU’ 

‘UR’ 


圧縮前 

A B U R A K A T A B U R A 

圧縮後 

1 3 A K A T A 2 R A 

辞書を元にデータを圧縮 

72 


圧縮前「13文字」あったのが、圧 

縮後に「10文字」になっている


表スペースの見積もり 


73 


� システム・カタログ表スペース 

� システム・カタログ表が使用する容量は、表スペースのタイプ(SMS or DMS)とエクステント・サイズによって 

異なる。 

� DMSの場合、各表オブジェクトについて最低 2つのエクステントが割り当てられる。この未使用のスペースを 

削減するために、カタログ表スペースをDMSで作成する場合は、エクステント・サイズを小さくすることを(2 か 

ら 4 ページ) を検討する。 

� データベース作成時、デフォルトでは自動サイズ拡張が使用可能なDMS(ファイル)表スペースとして作成さ 

れる(初期サイズはDB2が自動決定)ため、表スペース容量が不足する前に自動的にサイズが拡張される。 

� ファイル・システムがいっぱいになると自動拡張が失敗するため、余裕をもって作成しておく。(通常、数百MB 

~1GB程度あれば問題なし。) 

� 自動ストレージ表スペースであるため、ALTER TABLESPACEによる拡張はできない。 

� ユーザー表スペース 

� 既に決まっているページ・サイズと平均行サイズから、1ページに格納できる行数を算出 

� 予想される行数を格納するために必要となるページ数を算出 

� ROUND DOWN(ページ・サイズ/(論理レコード長)) = 1ページあたりの行数 

� (レコード件数/1ページあたりの行数) * 安全率 = 必要ページ数 

– 安全率:オーバーヘッド分、PCTFREEの分や、同じ表スペース内でREORGする場合なども考慮 


� 一番大きく使用すると思われるケースで検討する 

� システム一時表スペース 

� JoinやSortを行うアプリケーションやREORG、LOADなどの運用次第で大きく変わる 

� SMS表スペースの使用が望ましい 

– DMSでは一時表の作成時に多くのオーバーヘッドがある 

– SMSではディスク・スペースを動的に割り当てるが、DMSでは事前に割り当てられてしまうため、領域 

を有効活用できない 

� ユーザー一時表スペース 

� 宣言済み一時表を使用する場合 

� デフォルトのユーザー一時表スペースはないため、作成する必要がある 

� 一時表スペースの見積もりは最終的には事前に入念なテストを行って確認する


解説 

� DMS表スペース - 必要な最小ページ値 

表スペースの作成コンテナー・タグ 1 ページ/コンテナー 

表スペース 

メタデータ 

表(オブジェクト)の作成 

表スペースのヘッダー 

スペース・マップ 


オブジェクト表データ 1 エクステント 

エクステント・マップ 

データのエクステント 

コンテナーで最小限必要なスペース = 

(最初のオブジェクトを作成した時) 

EXTENTSIZE = 32 ページなら、 

1 エクステント 






74 

+ 1 ページ 

+ 1 ページ 

5*32+1=161ページがコンテナーに必要 


� 表の再編成実行時に表スペースの名前を指定しない場合、再編成しようとする表を含む表スペースにその表の作業コピーを保管しま 

す。 

� 一時表スペースを使って表を再編成する場合、一時表スペースのページ・サイズは表のページ・サイズと一致しなければなりません。 

� 宣言済み一時表は、独自のユーザー一時表スペース・タイプの中にのみ作成されます。デフォルトのユーザー一時表スペースはありま 

せん。 

� 一時表スペースの必要なスペースの量は照会および戻される表のサイズや照会アプリケーション、REORG、LOADなどの運用に依存 

するため、正確に見積もることは難しいため、事前にテストで確認することが必要です。


自動保守用表スペースの見積もり(V8.2以降) 

� 自動保守用表スペース(SYSTOOLSPACE) 


75 


� V8.2の新機能、データベースの自動保守(自動統計収集および再編成)を使用する場合に自 

動作成される表スペース 

� 自動統計収集および再編成の作業データを、SYSTOOLSPACE表スペース中の表に格納する 

� SYSTOOLS表スペース作成時、約700KB 

� 通常、SYSTOOLSPACEに必要な容量は、データベース中の表の数に比例し、1つの表に対し 

て約1KB として計算する




76 



ログ領域の見積もり 

� アクティブ・ログ領域の見積もり 

� 最低限必要なサイズ:(logprimary + logsecond) * (logfilsiz + 2 ) * 4096 

� 循環ロギングの場合 


– 上記の式で求めた値に余裕を持たせたサイズを用意する 

� アーカイブ・ロギングの場合 

77 


– アーカイブ処理の失敗によりログ・ファイルが再利用されない場合や、ロールフォワード時にロ 

グがリトリーブされる領域を考慮し、余裕を持たせる(上記の式で求めた値の2倍程度) 

� アクティブ・ログの二重化を行う場合、2倍の容量が必要。 

� アーカイブ・ログ領域の見積もり 

� 一日にアーカイブされるログ容量と保持期間を掛け合わせて必要な容量を算出する。更に、 

アーカイブ・ログの削除や退避が行われなかった事態に備え、余裕を持たせて用意する。 

� 複数パスへのアーカイブを行う場合(LOGARCHMETH1とLOGARCHMETH2を使用)、2倍の容 

量が必要。(FAILARCHPATHを使用する場合は、その分の容量も必要。)


参考:ログ・アーカイブ機能(V8.2以降) 

� 内容 � アクティブ・ログのアーカイブ機能をDB2の標準機能として提供する 

� V8.1までのログのUSER EXITの機能の代替機能を提供する 

� アーカイブ方法を2つまで指定することができる 

� 最大で2つの別個のロケーションにアーカイブ・ログ・ファイルを保管できる 

� アーカイブが失敗した場合の代替ディレクトリーを指定できる 

� アーカイブ先が使用可能になると、ログ・ファイルは自動的に移動される 

� 方法 � 次のデータベース構成パラメーターにアーカイブ方法を指定する 

� LOGARCHMETH1 

� LOGARCHMETH2 

� 次のデータベース構成パラメーターにアーカイブ・ログ・ファイル用の代替ディレクトリーを指定する 

� FAILARCHPATH 


データベースアクティブ・ 

ログ 

ミラー・ログ 

アーカイブに失敗した場合 

78 

LOGARCHMETH1 

LOGARCHMETH2 

FAILARCHPATH 

DISK 

TSM 

VENDOR 

db2tapemgr 

コマンド 


テープ


製品インストール・ディレクトリーの見積もり 


79 


� DB2のインストールに必要なディスク容量は、選択するインストールのタイプ、 

使用するファイル・システムのタイプに応じて異なる。 

� DB2セットアップ・ウィザードを使用すると、事前に見積もり可能。 

� インストール・タイプ(標準、コンパクト、カスタム)ごとに選択されるコンポーネントに基づいて、 

動的にサイズの見積もりを行う。




80 



③インスタンスの構成とデータベースの分割 

�インスタンスとデータベース 

�インスタンス構成の考慮点 

�サポートされるクライアント&サーバー構成 

�データベース作成の考慮点 


81 





82 



インスタンスとデータベース 

�インスタンス 

� DB2のオブジェクトの最も大きな単位 

� 論理的なデータベース・マネージャー環境 

� Unix環境 

– db2syscプロセスを中心としたプロセ 

ス群 

� Windows環境 

– 「DB2 - インスタンス名」サービス 

– 「DB2 – DB2コピー名 – インスタンス 

名 

– ノード番号」サービス 

� 全てのオブジェクトが含まれる 

� DB2の起動/停止の単位 

� db2startコマンド/db2stopコマンド 

� 1マシンに複数インスタンスの作成が可能 

� db2icrtコマンドで作成 

�データベース 

� 有機的にまとめられた表スペース、表や索引 

の集まり 

� 一つのインスタンスに複数のデータベースを 

作成することが可能 

� create database コマンド 

� 接続(CONNECT)の対象となる 

� バックアップ・リストアの最大単位 


83 

インスタンス 


表スペース(SMS) 

表 

LOB 

索引 

表スペース(DMS) 

索引 



表 


LOB


解説 


84 


� インスタンス 

� 一つのデータベース・マネージャー構成ファイルを使用して稼動する、データベース・マネージャー環境のことです。 

� インスタンスは、DB2を構成するオブジェクト群の中で、最も大きな単位です。 

� db2startで起動し、db2stopで停止するのは、このインスタンスです。(管理サーバーの場合、db2admin start/db2admin stop) 

� データベースのエンジンともいえる、db2syscプロセスが立ち上がる単位ということもできます。 

� インスタンスは、一台のマシン上に複数持たせることができます。しかし、一つのアプリケーション環境から扱えるのは、一つ 

のインスタンス環境のみです。 

� db2startで起動されるインスタンス、およびアプリケーション環境で使用するインスタンスは、以下で決まります。 

� 環境変数 DB2INSTANCE に指定されているインスタンスが現行インスタンスとして使用されます。 

� PC環境では、環境変数｢DB2INSTANCE｣が設定されていない場合があります。 

� その場合、レジストリー変数｢DB2INSTDEF｣に設定されているインスタンス(デフォルトではDB2)が現行インスタンスとして使用さ 

れます。 

� DB2INSTDEFは、グローバル・レベルのレジストリー変数です。 

� これを変更するには以下を実行します。 

� db2set db2instdef=新インスタンス名 -g 

� データベース 

� DB2のデータベースには、様々なオブジェクトが含まれますが、ユーザーから見るときには、表や索引の集合体と言えるでしょ 

う。 

� 一つのインスタンス上に、複数のデータベースを作成することが可能です。 

� データベースは、接続・運用上および許可の単位です。 

� connectコマンドで接続するデータベースの名前を省略した場合、デフォルトでは、DB2DBDFTレジストリー変数に設定されて 

いるデータベース名が使用されます。 

� connect toでデータベースに最初に接続する時には、ログ・ファイルやバッファープールのアロケーションなど初期作業が行な 

われますので、それ以降の接続に比べて時間がかかります。 

� 最初の接続に時間をかけたくない場合には、db2start後にactivate databaseコマンドで初期作業を行なわせて下さい。 

� データベースは、バックアップ取得や、CONNECT特権の単位でもあります。


インスタンス構成の考慮点 


85 


�インスタンスの分け方 

� アプリケーション構成 

� 開発環境用と本番環境用 

� 運用管理面 

� 管理者の権限(SYSADM、SYSCTRL、SYSMAINT)を持つユーザーを分けたいとき 

� インスタンスごとにデータベース・マネージャーの構成を最適化する 

� 起動/停止のタイミングを分けたい(サービス時間、運用時間の違い) 

� 可用性 

� エンジン動作部分に影響を与える様なトラブル発生時に、影響範囲を小さくしたい 

�その他考慮点 

� UNIX環境:作成するインスタンスのビット単位(64ビット/32ビット)指定 

� 同居させる他のプロダクトの要件にも注意 

V9.5 

� V9.5環境では、ほとんどの(下記3つ以外の)プラットフォームにおいて64ビット・イン 

スタンスのみサポート 

– 32ビット・インスタンスがサポートされるのは、以下のプラットフォームのみ 

� x86 用 Linux オペレーティング・システム 

� x86 用 Windows オペレーティング・システム 

� x64 用 Windows オペレーティング・システム (Windows x86 オペレーティング・システム 

用インストール・イメージを使用) 

� 異なるバージョン間でのクライアント&サーバー接続 

� インスタンスホームの容量


V9.5 

解説 


86 


� インスタンスを分ける例としては以下の様な場合があります。 

� 開発用と本番用 

� 管理者の権限(SYSADM、SYSCTRL、SYSMAINT)を持つユーザーを分けたいとき 

� DBMSのエンジン動作をコントロールしたい場合 

� 起動/停止のタイミングを分けたい(運用、サービス時間) 

� 可用性の観点で、エンジン動作部分に影響を与える様なトラブル発生時に、その影響をできるだけ受けさせ 

たくない 

� 1つのマシンに複数インスタンスを作成することが可能ですが、インスタンスごと 

に、追加のシステム・リソース (仮想メモリーとディスク・スペース) が必要になりま 

す。また、追加インスタンスを管理するためにさらに管理が必要になります。 

� インスタンス作成の際は、ビット単位(64ビット/32ビット)を指定しますが、同じマ 

シン上で稼動する他のソフトウェアの稼動要件も考慮する必要があります。(例え 

ば、32ビットカーネルしか対応していないS/Wなど) 

� V9.5では、ACSのモジュールが追加されたため、V9.1よりもインスタンス・ホーム・ 

ディレクトリに必要とされる容量が大きくなっています。参考までに、AIX環境でテ 

ストしたところ、V9.1で約15MBだったものが、V9.5GAで、約210MBに増えていまし 

た。


V9.5 

構成が可能なクライアント・サーバー一覧 

※DB2 UDB V7との構成は、延長サポート契約がある場合のみを対象としております。 

DB2 

Clients 

V7 32-bit 

Server 

UNIX, 

Windows, 

Linux 

V7 64-bit 

Server 

UNIX 

V8 32-bit 

Server 

UNIX, 

Windows, 

Linux 


V8 64-bit 

Server 

UNIX, 

Windows, 

Linux 

87 

V9.1 32-bit 

Server 

Windows, 

Linux 

V7 32-bit Y N Y(6) Y(2,5,8) Y②③④ 

Windowsの 

み 

V9.1 64-bit 

Server 

UNIX, 

Windows, 

Linux 

Y②③④ 

Windowsの 

み 

V7 64-bit N Y N Y(4,5) N Y②③ 

Windows以 

外 

V9.5 32-bit 

Server 

Windows, 

Linux 

N N 

N N 

V8 32-bit Y(1,7) N Y Y Y① Y① Y(I) Y(I) 

V8 64-bit N Y(1,7) Y Y Y① Y① Y(I) Y(I) 

V9.1 32-bit N N Y① Y① Y Y Y(II) Y(II) 

V9.1 64-bit N N Y① Y① Y Y Y(II) Y(II) 

V9.5 32-bit N N Y(I) Y(I) Y(II) Y(II) Y Y 

V9.5 64-bit N N Y(I) Y(I) Y(II) Y(II) Y Y 


V9.5 64-bit 

Server 

UNIX, 

Windows, 

Linux


V9.5 

解説: 構成が可能なクライアント・サーバー一覧 

※DB2 UDB V7との構成は、延長サポート契約がある場合のみを対象としております。 

� 注(V8マニュアルより抜粋): 

1. DB2 V7サーバーはDRDA AS(Application Server)として構成されている必要がある 

2. Windows版 DB2 V8 64bitのみが対象 

3. TCP/IPのみ対象(SNAは対象外) 

4. Windows版以外のDB2 V8 64bitサーバーを対象 

5. SQLのみを対象(ユーティリティー, APIは対象外) 

6. AT NODEを使用した、DB2ユーティリティーは対象外 

7. DB2 V8クライアントとDB2 V7サーバーを併用している場合には、V7サーバーはFixPak8以降を推奨 

8. V7 32bitクライアントとUNIX上のV8 64bitサーバーへの接続を確立したい場合はゲートウェイ(32bit)を使用する 


88 


� 詳細は、下記のDB2 UDBオンラインマニュアル[サポートされているクライアント構成とサポートされていないクライアント構成] 

をご参照ください。 

� http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/start/r0009731. 

htm 

� 注(V9.1マニュアルより抜粋): 

① DB2 V8の機能のみ使用可能 

② SQLのみ対象(管理ツール, ユーティリティー, API対象外) 

③ V7クライアントとV8サーバーへのアクセスと同じ制限事項 

④ Windows以外の他のプラットフォーム上のV9サーバーへの接続を確立したい場合はゲートウェイ(32bit)を使用する 

� 詳細は、下記のDB2オンラインマニュアルをご参照ください。 

� [クライアントとサーバーのバージョンのサポートされている組み合わせ] 

� http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2.udb.uprun.doc/doc/r000 

9731.htm 

� [DB2クライアントの移行に関する重要事項] 

� http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2.udb.uprun.doc/doc/c002 

2579.htm


V9.5 

解説: 構成が可能なクライアント・サーバー一覧 

� 注(V9.5マニュアルより抜粋): 

I. DB2 V8の機能のみ使用可能 

II. DB2 V9.1の機能のみ使用可能 


89 


� 詳細は、下記のDB2オンラインマニュアルをご参照ください。 

� [クライアントとサーバーのバージョンのサポートされている組み合わせ] 

� http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=/com.ibm.db2.luw.qb.clien 

t.doc/doc/r0009731.html 

� [クライアントのマイグレーションに関する重要事項] 

� http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/topic/com.ibm.db2.luw.qb.migration.doc/ 

doc/c0022579.html




90 



データベース作成の考慮点 

�データベースの分割の目安 

� アプリケーション構成(業務内容) 

� 同時に処理する要件があるか 

� パフォーマンスの観点から一つにすることも検討 

� 分割されていると2フェーズ・コミット必要 

� JOIN不可(連合DBを使用の場合は可能) 

� 運用管理(バックアップ/リストア)の面から検討 

� 処理時間 

� 運用時間帯 

� 可用性 

� テスト環境ではフェーズやチーム単位で分割 

� コード・セット別 

� Unicodeデータベース 

V9.5 


91 


– V9 XMLデータタイプを使用する場合、UTF-8のデータベースでなければならない 

– V9.5のデフォルトでは、UTF-8のデータベースとして作成される。 

� 分割する場合、レプリケーション機能の検討も必要か 

� デフォルトのページ・サイズはどのサイズにするか 

� 自動ストレージ・データベースとして作成するか(V8.2.2以降) 

� V9でのデフォルトでは、自動ストレージ・データベースとして作成される 

�作成時のCOLLATE USING句指定 

� 日本語環境でデータを五十音順に照合したい場合はIDENTITYを指定 

� デフォルトはSYSTEM(辞書順) 

� 作成後は変更不可


解説 


92 


� データベースの分け方 

� まずアプリケーションの構成から決定します。業務が全く異なる場合は、別データベースにするべきですが、それぞれに属す 

る表同士に何らかの関連があって同時に処理する必要がある場合は、パフォーマンスの観点からも同じデータベースにして 

しまうことも検討します。 

� バックアップ/リストアといった運用管理の面からも検討します。 

� 複数に分けた場合、1つがダウンしても別のデータベースは使用可能ですので、可用性という点では優位です。 

� このほかに、データベースを分ける例としては以下の様な場合があります。 

� 開発用と本番用 

� 共用する表を持たない異なるシステムの場合(表をJOINしたい場合は通常分けない) 

� Unicodeデータベースなど、コードセットの異なるDBが必要･･･など 

� CHAR、VARCHAR、LONG VARCHARの照合(ソート、比較など)においては、値の重み付けを考 

慮する必要があります。 

� 重み付けは、CREATE DATABASEのCOLLATE USING句で指定する事ができます。 

� SYSTEM(デフォルト):現行のテリトリーに基づいた照合順序 (辞書順) 

� 例:a(X'61')、A(X'41')、b(X'62')、B(X'42')、c(X'63')、C(X'43')、・・・ 

� COMPATIBIRITY:DB2 V2の照合順序に同じ (電話帳順) 

� 例:A、a、B、b、C、c・・・ 

� IDENTITY:バイト単位で比較 (文字コード順) 

� 例:A、B、C、・・・、a、b、c・・・ 

� 日本語などのダブルバイトの文字については、1バイトずつに分割して照合が行われます。 

� SYSTEMの場合の日本語例: 

� ヂ(X'8361')、ア(X'8341')、ッ(X'8362')、ィ(X'8342')、ツ(X'8363')、イ(X'8343')、・・・ 

� COMPATIBIRITYの場合の日本語例: 

� ア(X'8341')、ヂ(X'8361')、ィ(X'8342')、ッ(X'8362')イ(X'8343')、ツ(X'8363')、・・・ 

� IDENTITYの場合の日本語例: 

� ァ(X'8340')、ア(X'8341')、ィ(X'8342')、イ(X'8343')、・・・、チ(X'8360')、ヂ(X'8361')、ッ(X'8362')、ツ(X'8363')、ヅ(X'8364')、・・・ 

� 日本語環境では五十音順にデータを照合したい場合には、COLLATE USING句にIDENTITYを 

指定してデータベースを作成する事をお薦めします。 

� COLLATE USINGに指定した値は、一旦データベースを作成した後に変更する事はできません 

ので注意して下さい。 

� GRAPHICタイプのデータについては、COLLATE USING句の指定に関わらず、文字コード順に 

照合が行われます。



�表スペースとは 

�表スペースの種類と選択 

� DMS表スペースとSMS表スペース 

�複数表スペースの検討 

�一時表スペースの定義 

�検討すべき表スペース属性 


93 





94 



表スペースとは 

� 表スペース 

� 表のデータを格納するための論理的な領域媒体 

� 実際にデータを格納する物理的な媒体をコンテナーという 

� コンテナーの実体はファイルシステムのディレクトリ、ファイル、または論理ボリュームなどの 

ローデバイス 

� 一つの表スペースを1つ以上のコンテナーで構成 

� データベース内に作成される表スペース 

� システム・カタログ表スペース,システム/ユーザー一時表スペース,ユーザーデータ用表ス 

ペース 

� 表スペースはバックアップの最小単位 



コンテナー 

0 


1 


2 


表 


バッファープールバッファープール 

索引表 


3 コンテナー 

4 

95 



解説 


96 


� 表スペースは、表のデータを記憶するための論理的な領域媒体です。 

� 実際に表のデータが物理的に格納されるのは、表スペースに紐付けされたコンテナーになります。 

� コンテナーは、表スペースのタイプにより、ディレクトリーやファイル、デバイスといった形態を取ります。 

� 一つの表スペースに複数のコンテナーを割り当てることができます。 

� データはコンテナー間で平均的に割り振られます。 

� 一つのコンテナーは、一つの表スペースにしか属することはできません。 

� 表スペースへのデータの書き出しは、エクステントと呼ばれる割り当て単位に行われます。(デフォル 

トは32ページ) (詳細は後述) 

� create databaseを実行すると、デフォルトでは3つの表スペースが自動的に生成されます。 

� SYSCATSPACE:システム・カタログ表スペース 

� システム・カタログ表、およびその索引が入っている表スペースです。 

� データベース作成時に作られ、一旦作られた後は、変更や削除することができません。 

� TEMPSPACE1:システム一時表スペース 

� JoinやSort時に一時的にデータが入る表スペースです。 

� USERSPACE1:ユーザー・データ用表スペース 

� ユーザーのデータや索引が入れられる表スペースです。 

� 表スペースを指定せずにcreate tableを実行すると、他のユーザー・データ用表スペースが無い場合は、デフォルトで、この表スペースが使わ 

れます。 

� 既に他のユーザー・データ用表スペースが作られている場合には、最初に作られた表スペースが使われます。 

� 表スペース単位でバックアップ/リストアを行うことも可能です。 

� ロールフォワード回復不可能な場合(循環式ロギング)は、データベース単位のバックアップのみ可能 

です。 

� 循環ロギングの設定 

� LOGRETAIN(DB構成パラメーター)=NO 

� USEREXIT(DB構成パラメーター)= NO 

� LOGARCHMETH1/LOGARCHMETH2 (DB構成パラメーター)=OFF 

� ロールフォワード回復可能な場合(アーカイブ式ロギング)は、表スペース単位のバックアップ/リストア 

が可能です。 

� アーカイブ・ロギングの設定 

� LOGRETAIN=ON またはRECOVERY(V6.1より) 

� USEREXIT=YES 

� LOGARCHMETH1/LOGARCHMETH2でアーカイブ方法を指定


表スペースの種類と選択 

� 適切な表スペースを選択する 

� ファイル管理のタイプによる表スペースの種別 

� SMS:オペレーティング・システムのファイル・システムによるファイル管理 

� DMS:データベース・マネージャーによるファイル管理 


97 


� 保管データのタイプによる表スペースの種別 

� LARGE(V9以降のDMS表スペースのデフォルト) 

– V8以前:LOB、LONGデータ、索引用 

– V9以降:通常のデータ、LOB、LONGデータ、索引用 

� REGULAR(V9以降のSMS表スペースのデフォルト、V8以前のDMS/SMS表スペースのデフォ 

ルト) – 通常のデータ、索引用 

� TEMPORARY 

– 一時表用 



� 表スペースのページ・サイズ 

� 4KB,8KB,16KB,32KB 

� 4KB以外の表スペース作成の場合、事前に同じページ・サイズのバッファープールと一時表ス 

ペースを作成する 

– V8.2.2以降は、データベース作成時にデフォルトのページ・サイズを指定することができる。 

(4KB以外のページ・サイズを使用する場合でも、ページ・サイズを1種類に統一することがで 

きる。)


解説 

� ファイル管理のタイプにより、以下のいずれかのタイプを指定します。 (それぞれの詳細は後述) 

� SMS(System Managed Storage) 

� 各オペレーティング・システムのファイル・システムがファイルを管理します。 

� コンテナーとしては、ディレクトリーを設定します。 

� DMS(Database Managed Storage) 

� データベース・マネージャーがファイルを管理します。 

� コンテナーとしては、ファイル、またはデバイスを設定します。 


98 


� 保管データのタイプにより、以下のいずれかのタイプを指定します。 

� LARGE表スペース 

� すべての永続データを保管します。このタイプは、データベース管理スペース (DMS) 表スペースでのみ使用できます。また、タイプを指定しな 

い場合の、DMS 表スペースのデフォルト・タイプでもあります。 LARGE 表スペースに表を配置すると、以下のようになります。 

– REGULAR 表スペースに配置する表よりもサイズを大きくできます。 

– 表のデータ・ページ当たり、255 を超える行数をサポートできるので、データ・ページのスペース使用効率が向上します。 

– REGULAR 表スペースに配置した表に索引を定義する場合に比べ、索引の 1 つの行項目当たり 2 バイトが追加で必要になります。 

� REGULAR表スペース 

� すべての永続データを保管します。このタイプは、DMS 表スペースと SMS 表スペースのいずれも指定可能です(SMS 表スペースでのデフォ 

ルト・タイプです)。 

� TEMPORARY表スペース 


– JoinやSortで一時的にデータが入る表スペースです。 

– システム一時表スペースは、データベースに最低一つは必要です。一つしかない時には、削除しようとするとエラーとなります。 

– 4KB以外のページを持つ表スペースがある場合、そのページに合せた一時表スペースも作っておいて下さい。 


– 省略時にはデータベース作成の時点で作成されません。Global Temporary Tableが使用する表スペースです。 

� 4KB以外のページを持つ表スペース(表)がある場合、そのページに合せた一時表スペースも作っておいて下さい。 

� V8.2.2からは、データベース作成時にデフォルトのページ・サイズを指定できるようになりました。これにより、4KB以外のペー 

ジ・サイズを使用する場合でも、データベース内の表スペース、バッファープールのページ・サイズを統一することができます。 

� 参考:Global Temporary Table(ユーザー定義一時表) 

� アプリケーションは、データベースに接続している間、一時的な表を作成して使用できます。 

� 一時表を定義するには、DECLARE GLOBAL TEMPORARY TABLE ステートメントを使用します。 

� ユーザー定義一時表が保持されるのは、アプリケーションがデータベースから切断されるまでの間だけです。アプリケーショ 

ンが終了したりデータベースから切断されたりすると、表の中のデータはすべて削除され、表は暗黙的に除去されます。 

� この表の記述は、システム・カタログには現れません。したがって、この表を他のアプリケーションのために保持したり、他の 

アプリケーションと共用したりすることはできません。 

� ユーザー定義一時表は、ロックとログ記録を回避するので、一時表を活用するアプリケーションは大幅なパフォーマンス改善 

を見込めます。


DMS表スペースとSMS表スペース 

�パフォーマンス 

�DMSローデバイス>DMSファイル>SMS 

�表用、索引用、長形式のデータ用の表スペースを別々に作成できる 

�Solaris環境では、パフォーマンス重視のデータにはロー・デバイスを含む 

DMS 表スペースを使用することを推奨 

�管理の容易さ 

�SMS>DMS 

�SMSは、同じファイルシステムに複数表スペースを作成でき、表スペースご 

とに空きスペースの監視を行う必要がない 

�領域のアロケーション 

�SMS: エクステント単位(V8.2以降) 

ページ単位(V8.1まで) 

�DMS: エクステント単位 


99 



解説 


100 


� 3つの表スペースを比較した場合、通常パフォーマンスは以下のようになります。 

� DMSローデバイス>DMSファイル>SMS 

� ローデバイスとファイルDMSの差はそれほど大きくありませんが、DMSとSMSではパフォーマンスに大 

きな差が出る場合があります。 

� Solaris(TM) では、パフォーマンス重視のワークロード用にはロー・デバイスを含む DMS 表スペース 

を使用することが強く勧められています。 

� DMSはSMSに比べて、表用、索引用、長形式のデータ用の表スペースを別々に作成できるため、そ 

れぞれのディスクI/Oを分散させることが可能です。これによってディスクI/Oを効率化し、パフォーマ 

ンスを向上することが可能です。 

� DMSでは、データ挿入時にエクステント単位でデータが書き込まれます。また、そのエクステントは、 

既に容量を確保して作成されたDMSファイルまたはローデバイスの中に書き込みます。この時、DMS 

ファイルやローデバイス自身の大きさは変わりません。 

� SMSでは、表のスペースは要求時に割り振られますので、DMSに比べて特に大量データの挿入に関 

してパフォーマンスが劣ります。一度に割り振られるスペースの量は、multipage_alloc データベース構 

成パラメーターの設定によって左右されます。この構成パラメーターが YES に設定されている場合、 

スペースが必要なときにはエクステント全体 (通常は複数のページで構成される) が割り振られます 

(マルチページ・ファイル割り振り)。それ以外の場合は、一度に 1 ページのスペースが割り振られま 

す。 V8.2以降では、マルチページ・ファイル割り振りはデフォルトで使用可能です。V8.2 より前は、構 

成パラメーターのデフォルト設定が NO であったため、一度に 1 ページしか割り振ることができません 

でした。このデフォルトは、マルチページ・ファイル割り振りを使用できるようにする db2empfa ツール 

を使用して変更できました。 db2empfa を実行すると、multipage_alloc データベース構成パラメーター 

は Yes に設定されます。


参考:エクステント 

� エクステント 

� 表スペースにおけるコンテナ内の領域の割り振り単位(ページ) 

� DMS、V8.2以降のSMSは、一度にエクステント全体をアロケートし、その後でエクステント内のページを使用 

� V8.1までのSMSは、エクステント・サイズの値になるまで一度に1ページずつアロケートする 

� データはラウンド・ロビン方式でコンテナに書き込む 

� DMSのコンテナーで最小限必要なスペース (最初のオブジェクトを作成した時) = 5エクステント + 1ページ 

� エクステント・サイズは、表スペース作成時に指定(デフォルトは32ページ) 

� 多数の小さい表からなる表スペースは、サイズを減らすことも検討 

� 大量の結果行を返す照会を行う表や急激に拡張される表からなる表スペースは、サイズを増やすことも検討 

� 作成後は変更が出来ない 

コンテナ 

0 2 

エクステント 


コンテナエクステントページ 

0 


コンテナ1 

1 3 

A 

4K 

Extent = 32ページ 

(デフォルト) 

101 





102 



SMS表スペース 

�SMS(System Managed Storage)表スペース 

�オペレーティング・システムのファイル・システム・マネージャーが管理 

�表データと索引、Longデータは全て同じ表スペースを共有 

�管理が容易 

�コンテナーはディレクトリー 

�ファイルは動的に拡張し、サイズの上限は以下によって決まる 

�コンテナーの数 

�ファイル・システム/ドライブ/ファイルのOSの限界サイズ 

�コンテナーは動的に追加不可 

�ファイル・システム/ドライブのサイズは増加可能 

�再定義は表スペース復元時に可能(表スペースのリダイレクション) 

�各コンテナーサイズは同じ大きさに 

�一時表スペースに推奨 


103 



解説 


104 


� SMSの特徴 

� SMSでは、表スペースはファイルシステムのディレクトリに相当し、表や索引はそれぞれ別々 

のファイルになります。SMS表スペース(ディレクトリ)を作成したファイルシステムが許す限り、 

表に対してデータを追加することができます。つまり、表スペースの大きさはファイルシステム 

の大きさに依存します。 

� SMSでは表や索引およびLOBやLONG VARCHARなどの長形式のデータを含むロング形式の 

データを全て同じ表スペースに格納する必要があります。 

� 複数のディスクにIOを分散させる為に、1つの表スペースに対してコンテナーを複数定義する 

ことがSMSでも可能ですが、コンテナーの追加や削除を行うことはできません。表スペースを 

作成するときのコンテナー定義を変更する為には、一度削除して再作成する必要があります。 

� 複数コンテナーによってSMS表スペースを作成した場合、どれかのファイルシステムが一杯に 

なると表スペースはそれ以上のデータを追加することができなくなります。


DMS表スペース 

� DMS(Database Managed Storage)表スペース 

�データベース・マネージャーが記憶スペースを管理 

�作成時にスペースを割り当て 

�コンテナーはファイル、デバイス 

�ファイルの操作に対してはファイル・システムI/Oを使用 

�ロー・デバイスの操作に対しては直接I/Oを使用 

�柔軟なデータ配置 

�表用、索引用、および長形式のデータ用の表スペースを別々に作成する 

ことが可能 

�ディスクのIOを複数の物理ディスクに分散させることが可能 

�コンテナの追加/削除/拡張/縮小が可能 

�データは自動的に再バランス(オプションにより再バランスさせないことも 

可) 

�高パフォーマンス 


105 



解説 


106 


� DMSの特徴 

�DMSでは、表スペースは大きな1つのファイルまたはローデバイスに相当します。中をど 

のように使われているのかはOSからは確認できません。表スペースを作成する際に、あら 

かじめ必要な大きさを定義する必要があります。DMSではさらに2つのタイプがあり、1つは 

DMSファイルともう一つはローデバイスです。 

�DMSファイルの場合は、ファイルシステム上に1つの大きなファイルが作成されますが、 

ローデバイスの場合はファイルシステムを経由せずにDB2が直接IOを行います。 

�DMSでは、表用、索引用、および長形式のデータ用の表スペースを別々に作成すること 

が可能です。それによって、ディスクのIOを複数の物理ディスクに分散させることが可能に 

なります。 

�DMSでも複数のコンテナーを1つの表スペースに対して定義でき、さらに動的に追加する 

ことが可能です。表スペースを作成後にコンテナーの大きさを変更することもでき、DB2 

UDB V8以降では小さくすることも可能です。 

�複数コンテナーからDMS表スペースを構成する場合、どれかのコンテナーが一杯になっ 

ても空いているコンテナーを探して書き込もうとします。全てのコンテナーが一杯になった場 

合、それ以上データの追加はできません。 

�V8.2.2からは、ファイルDMS表スペースの自動サイズ変更が可能です。


複数表スペースの検討 

�表スペースの分割の指針 

� パフォーマンスを考慮し、バッファープールの割り当てを検討 

� I/Oの並列処理を考慮し、データの物理配置に合わせて表スペースを構成 

� バックアップの単位、LOADの並行処理等の運用面で検討 


107 


�表をグルーピングし、表スペースを分ける 

� 1.できる限りバッファプールに読み込むことが望ましい表 

� 頻繁に読み書きされるトランザクション系データ 

� 2.バッファプールには読み込む必要が無いデータ 

� アプリケーション活動の履歴的な、一度書いたらほとんど変更/参照されないデータ 

� 3.1と2の中間 

� 4.小さな表はある程度の単位で一つの表スペースにまとめる 

� 5.バックアップ取得の頻度で別の表スペースにする 

� 大量の更新がある表⇒頻繁なバックアップ取得必要 

� 変更が非常に少ない表⇒頻繁なバックアップ取得不要 

�LOADを複数同時に実行するには、別々の表スペースにする(特に 

V7) 

� V7では、LOAD実行中は表スペースをQuiesce(静止)状態にするため、該当の表のみ 

ならず、同一表スペース上の他の表にもアクセス不可


解説 


108 


� 典型的な分け方は以下のようになります。 

� 1.頻繁に読み書きされるトランザクション系データ 

� 2.アプリケーション活動の履歴的な、一度書いたらほとんど変更されないデータ 

� 3.1と2の中間 

� 分類1の表は、アプリケーションのパフォーマンスに大きな影響を与えます。ディスク資源とメモリ資源を十分に割り当てる必 

要があります。 

� 分類2の表は、容量的には大きくなりますが、一度書いた情報をあまり読まないため、メモリ資源は低く抑えることができます。 

このタイプの表を全件検索するようなSQLが実行された場合、ディスクのアクセスが非常に多くなるので、パフォーマンスが常 

時必要な分類1の表とは異なる物理ディスクを割り当てることが理想的です。できればディスクへつながるSCSIやファイバー 

チャネルなどのインターフェースも別であることが理想的と言えます。 

� 分類3は、メモリ資源をそれなりに与える必要がありますが、優先順位では分類1より下になります。 

� 表スペースの分け方には、以下のようなケースもあります。 

� 頻繁に使用される表、それもアクセスされるデータがほぼ決まっている場合には、大き目のバッファープールを持った表スペース 

を割り当てます。 

� このときには、データの表スペースと、索引の表スペースとを分けるのもひとつの方法です。(DMSの場合) 

� 大きな表に、ランダムにデータ・アクセスする場合には、小さいバッファープールを持った表スペースを割り当てます。 

� たまにしか使用されないアプリケーションからアクセスされる表には、小さいバッファープールを持った表スペースを割り当てます。 

このような表は、まとめて一つの表スペースに入れるのもひとつの方法です。 

� 参照制約,トリガーなど関連のある表同士は一つの表スペースにまとめます。 

� 小さな表は全て同じ表スペースにまとめます。 

� バックアップを取得する単位で表スペースを分けます。 

� 表スペース単位のバックアップは時間とリソースの節約になります。 

� 大量の変更がある表スペースは頻繁にバックアップを取り、変更が非常に少ない表スペースは時折バックアップを取ります。 

� V9以降は、データベースの再ビルド機能によりデータベース全体のバックアップを取得していなくても、表スペース・バック 

アップからデータベースを回復することができます。 

� V7では、LOAD実行時、表スペースをQuiesce(静止)状態にし、表スペースと表スペース内の 

表すべてに対してZ-LOCK(超排他)を取得するため、LOADの並行処理を可能にするには表ス 

ペースを分ける必要があります。(V8では、LOAD中も表に照会アクセスが可能であり、同じ表 

スペースの表については、アクセスが自由できます。)


一時表スペースの定義 


109 


�SMS or DMS 

� 一時表スペースとしてはSMSがお勧め(一般) 

� スペースの有効利用 

� 多くのクライアントアプリケーションからのソート要求を処理する場合、DMSよりパ 

フォーマンスが良い 

� 複数のコンテナーを作成して、パフォーマンス向上を計る 

� ファイルシステム上に作成するため、ファイルシステムの制限(ラージイネーブル、 

ulimit)に注意が必要 

� 一時表スペースとしてのDMS(例外) 

� Solarisでは一時表スペースを使用した再編成、ロードや索引作成時などの大量 

データの処理の場合パフォーマンス的に有利な場合がある(ケース・バイ・ケースな 

ので、ベンチマーク・テストが必要) 

� HAのテイクオーバー時間を短くために、fsckの必要になるファイルシステムの代わ 

りにローデバイスDMSを選択する場合がある 

�ページサイズ毎に1つ作成 

� 一時表スペースを使用した再編成の場合、表の存在する表スペースのページサイ 

ズと一時表スペースのページサイズは同じである必要がある。 

� ソート時に使用する一時表スペースは、格納できるページサイズを選択する。 

� 異なるページサイズを持つ別々の一時表は、SMSとして同じファイルシステムに配 

置するとスペースの有効利用ができる 

�後からでも比較的簡単に作成し直せる表スペース


解説 


110 


� 一時表スペースに関しては、DMSよりSMSの方が勧められています。一時表スペースの使われ方は、ソートやジョインに必要なときに 

一時的にシステム一時表が作成され、データが格納されます。つまり、表の作成・削除が内部で行われています。表作成時にSMSでは 

ファイルが作成され、使用後に削除されます。DMSでは表スペース内の空き領域を管理する「スペースマップ」や、各表に対してディス 

クのどの部分を使用しているのかを管理する「エクステントマップ」をメンテナンスする必要があります。多くのユーザーがそれほど大き 

くないソートやジョイン用の一時表を作成する場合、この2つのマップのメンテナンス作業が競合し、パフォーマンスが劣化する場合が 

あるため、DMSは一時表スペースには勧められていません。 

� 例外として、Solarisで比較的大量なデータを一時表スペースに書き出すような場合、索引の作成やロードなどの場合、DMSの一時表の 

方がパフォーマンス的に有利な場合があります。 

� ただし、Solarisでは必ず一時表スペースはDMSにしなければならないという訳ではありません。使用方法によってはSMSが適当なケー 

スも存在します。 

� 一時表スペースでは通常の表スペースとは、データを書き込む単位が異なります。通常の表スペースにおいて、DMSではデータはエク 

ステント単位に書き込まれ、SMSではページ単位に書き込まれます。SMSではページ単位で書き込む上に、ファイルシステム上で、ファ 

イルのサイズを大きくしていく必要があり、これがDMSに比べてオーバーヘッドになり得ます。db2empfaというコマンドがあり、SMSでも 

エクステント単位でディスクに書き出すことが可能になるため、通常の表スペースでは効果がありますが、一時表スペースでは、必要な 

容量を一度にアロケーションするため、db2empfaの効果は期待できません。 

� データベース中に複数のページサイズが存在する場合、一時表スペースをページサイズ毎に作成されることをお勧めします。これは一 

時表スペースを使用した再編成を行う場合には必須です。再編成を行う表が含まれる表スペースのページサイズと同じページサイズを 

持つ一時表スペースがないと一時表スペースを使用した再編成は行えません。 

� 複数の一時表スペースを定義する場合、一時表スペースがSMSであれば、同じファイルシステムに配置することが可能になります。こ 

れによって使用率が低いディスクエリアを共有し、ディスクスペースの有効利用が可能になります。 

� もちろん、複数の再編成を並行で実行する必要があるような場合は、別々のディスクに配置する方が、ディスクI/Oが衝突せずパフォー 

マンス的に有利です。 

� 一時表スペースは比較的簡単に作成し直せる唯一の表スペースです。本番稼働を始めた後でも、データのExport/Loadなどの移行な 

どが必要ではないためです。ただし、一時表スペースを作成し直す場合、データベースに最低限1つの一時表スペースを残さないとエ 

ラーになります。新しい一時表スペースを作成後に、古い一時表スペースを削除すればこのエラーは回避できます。


参考:自動ストレージ表スペース 


111 


� V8.2.2以降、自動ストレージ・データベース、自動ストレージ表スペースが使用可能 

� V9以降、データベースを作成すると、デフォルトで自動ストレージ・データベースとして作成 

される。 

� 自動ストレージ・データベースには、自動ストレージ表スペースを作成可能(通常の自動ストレージでない表ス 

ペースを作成することも可能) 

� 自動ストレージ表スペース 

� 表スペースのコンテナーおよびスペース管理の特性(SMS/DMS)はDB2によって自動的に(以下のように)決 

定されるため、指定しなくてもよい。 

� REGULARまたはLARGE表スペースの場合、DMS(ファイル・コンテナー) 

� TEMPORARY表スペースの場合、SMS 

� データベース作成時に定義された(1つ以上の)ストレージ・パスを使用してDB2がコンテナーを自動的に割り 

振るため、表スペース作成時にコンテナーの明示的なリストを指定する必要が無い。 

� 自動ストレージ表スペースを作成するための指定(CREATE TABLESPACE実行時) 

� MANAGED BY AUTOMATIC STORAGE 文節を指定する、または、MANAGED BY 文節を指定しない 

自動ストレージ･データベース 

自動ストレージ表スペース 


表スペースA 表スペースB 表スペースC 

ストレージ・パス(複数のディレクトリー)


V9.5 

参考:V9.5 新機能-自動ストレージ表スペースのサイズ縮小 


112 


�ユーザーによる自動ストレージ表スペースのサイズ縮小をサ 

ポートする。 

� ALTER TABLESPACE ステートメントをREDUCEオプションを指定して実行することで、 

表スペースの未使用エクステントを解放することができる。 

� 非自動ストレージ表スペースの場合と違い、コンテナー・パスや減少するページ数の指定 

は不要である。DB2が解放する領域を判断する。 

�メリット 

� 解放されたストレージ領域を、同一の自動ストレージ・パス上に存在する他の表スペー 

スで使用できる。 

� Space Map Pagesが残っていることにより最高水準点が下がらない場合でも、当機能を 

使用することで、SMPを削除し最高水準点を下げるため、未使用のストレージ領域を開 

放する 

�注意事項 

� 解放するのは、最高水準点より上の位置にあるフリー・ページで、使用したページで 

データが入っていない空き状態のページ(FPAGESとNPAGESの差分)を解放する機能 

ではない。


V9.5 


113 


参考:V9.5 新機能-コンテナーあたりの最大サイズを設定するレジストリ変数 

�DB2_SET_MAX_CONTAINER_SIZE レジストリ変数 

� AutoResize フィーチャーが有効になった自動ストレージ表スペース用のコンテ 

ナー 1つあたりの最大サイズを制限するレジストリ変数。 

� オペレーティング・システム: すべて 

� デフォルトは、-1(設定しない)。コンテナーのサイズに対する制限はなく、従来と 

同一の動作を行う。 

� 値を設定する場合は、64 MB より大きい正の整数とする。 

�注意事項 

� 表スペースの最大サイズを指定するレジストリー変数ではない。 

� レジストリ変数の設定値まで、コンテナー・サイズが達した場合には、新規にコン 

テナーが追加され、表スペースは拡張される。 

� このレジストリ変数を使用した場合には、V9.1までと異なり、V9.5からは 1つの 

自動ストレージ・パスあたりに、複数のコンテナーが作成される場合がある。


検討すべき表スペース属性 


114 


�ファイルDMS表スペースの自動サイズ変更(V8.2.2以降) 

�ダイレクトI/O 

�DROPPED TABLE RECOVERY属性 

�OVERHEAD/TRANSFERRATE



115 


ファイルDMS表スペースの自動サイズ変更(V8.2.2以降) 

�DMSファイル・コンテナのサイズを自動的に拡張 

� コンテナがいっぱいになる(SQL0289N)前に、追加領域の必要に応じてコンテナを自動的に拡 

張する 

� ファイル・コンテナのみ使用可能 

� ロー・デバイス・コンテナの自動サイズ変更は不可能 

� 表スペースの最後のレンジにあるコンテナが拡張される 

� 自動サイズ変更によってリバランスは発生しない 

� それぞれのコンテナは同じ量だけ拡張される 

� 自動ストレージ・表スペースのDMS、自動ストレージ・表スペースでないDMSのいずれに対して 

も使用可能 

� 自動ストレージ・表スペースでない場合、ユーザーによるコンテナの拡張、削除が可能 

� 従来どおり、ALTER TABLESPACEステートメントを使用する 

� 区分化データベース環境でも使用可能 

�DMSなのでパフォーマンスがよく、自動的にサイズ拡張するので、 

SMS同様管理が容易になる 

�考慮点 

� 自動サイズ変更が行われる場合、表に対する挿入処理のパフォーマンスに影響が出る。 

� 社内実測値では、自動サイズ変更を設定していない環境と比較してimport処理に20%から25%程 

度の性能劣化が見られた。 

� 一時表スペースを使用しないREORGの際にも自動サイズ変更が行われる。 

� REORG完了後もサイズは拡張されたままで、縮小されない。


解説: 


116 


� 自動サイズ変更を使用可能な表スペースでは、既存のスペースがすべて使用され、さらに多く 

のスペースが要求される場合、DB2 は表スペースのサイズの増加を試みます。 

� DB2は、表スペース・マップ (表スペースのストレージ・レイアウト) の最新の範囲(レンジ)に存在 

するコンテナーのみを拡張しますので、リバランス処理は発生しません。 

� 最新の範囲(レンジ)に存在するコンテナーはそれぞれ同じ量だけ拡張されます。最新のレンジ 

に存在するコンテナーのひとつが、ファイル・システムの上限に達すると、自動サイズ変更が停 

止してしまうため、それぞれのコンテナーが使用するファイル・システムのサイズはそろえておく 

ことが重要です。



117 


参考:ファイルDMS表スペースの自動サイズ変更の仕組み 

Stripes 

0 

1 

2 

3 

4 

5 

Containers 

0 1 2 

0 

3 

6 

9 

11 

13 

1 

4 

7 

10 

12 

14 

2 

5 

8 

Range #0 

Range #1 

既存のエクステント(0~12)以上 

のスペースが必要になると、コン 

テナの最後のレンジにエクステン 

トが追加される 

Range 

Number 

Stripe Set #0 

Stripe 

Set 

Max 

Extent 

Start 

Stripe 

End 

Stripe 

Containers 

0 0 8 0 2 3 (0, 1, 2) 

1 0 14 3 5 2 (0, 1) 

レンジ[0]のみを持つコンテナ2は 

拡張されないため、リバランスは 

発生しない。




118 



自動サイズ変更の指定方法 


119 


� CREATE TABLESPACEステートメントおよびALTER TABLESPACEステートメントにて 

指定する。 

.-REGULAR----------. 

>>-CREATE--+-----------------------+----------------------------> 

+-LARGE-----------------+ 

| .-SYSTEM-. | 

'-+--------+--TEMPORARY-' 

'-USER---' 

>--TABLESPACE--tablespace-name----------------------------------> 

(中略) 

.- MANAGED BY-- AUTOMATIC STORAGE-- | size-attributes |---------------------. 

>--+------------------------------------------------------------------------+--> 

'-MANAGED BY--+-SYSTEM--| system-containers |--------------------------+-' 

'-DATABASE--| database-containers |-- | size-attributes |-' 

(中略) 

size-attributes: 

|--+---------------------+--+-----------------------------+-----> 

'- AUTORESIZE--+- NO--+-' '- INITIALSIZE-- integer--+- K-+-' 

'- YES-' +- M-+ 

'- G-' 

>--+------------------------------------+-----------------------> 

'- INCREASESIZE-- integer--+- PERCENT-+-' 

'-+- K-+---' 

+- M-+ 

'- G-' 

>--+-----------------------------+------------------------------| 

'- MAXSIZE--+- integer--+- K-+-+-' 

| +- M-+ | 

| '- G-' | 

'- NONE-------------'


自動サイズ変更の指定方法(続き) 

�AUTORESIZE { NO | YES} 

� 自動サイズ変更機能を使用するかどうかを指定する 

� 自動ストレージ表スペースの場合、デフォルトはYES 

� 自動ストレージ表スペースでない場合、デフォルトはNO 

�INITIALSIZE integer K | M | G 

� 自動ストレージ表スペースの、初期サイズを指定する 

� 自動ストレージ表スペースの場合のみ指定可能 


120 


�INCREASESIZE integer PERCENT または INCREASESIZE 

integer K | M | G 

� 自動サイズ変更される量を指定する (表スペース全体での増加量) 

� パーセントまたは、容量を指定 

� パーセントは、自動サイズ変更が行われる時点の表スペースサイズのパーセンテー 

ジを意味する 

� 指定されていない場合、DB2が自動的に判断する 

�MAXSIZE integer K | M | G または MAXSIZE NONE 

� 自動的に拡張できる最大サイズを指定する 

� 指定されていない場合、NONE


解説: 


121 


� AUTORESIZE 

� DMS 表スペースまたは自動ストレージ表スペースの自動サイズ変更機能を使用可能にするかどうかを指定 

します。自動サイズ変更可能表スペースは、いっぱいになると、自動的にサイズが大きくなります。デフォ 

ルトは、DMS 表スペースの場合は NO、自動ストレージ表スペースの場合は YES です。 

� NO 

� DMS 表スペースまたは自動ストレージ表スペースの自動サイズ変更機能が、使用不可であることを指 

定します。 

� YES 

� DMS 表スペースまたは自動ストレージ表スペースの自動サイズ変更機能が、使用可能であることを指 

定します。 

� INITIALSIZE integer K | M | G 

� 自動ストレージ表スペースの、データベース・パーティションあたりの初期サイズを指定します。このオプショ 

ンは、自動ストレージ表スペースに対してのみ有効です。整数値の後に K (K バイトの場合)、M (M バイトの 

場合)、または G (G バイトの場合) を指定する必要があります。使用される実際の値は、指定されたものよ 

りも若干小さい場合があることにご注意ください。これは、データベース・マネージャーが表スペース内の各コ 

ンテナーのサイズの一貫性を維持しようとするためです。表スペースが自動サイズ変更可能であるものの 

INITIALSIZE 文節が指定されていない場合には、データベース・マネージャーが適切な値を判別します。


解説: 


122 


� INCREASESIZE integer PERCENT または INCREASESIZE integer K | M | G 

� 自動サイズ変更可能な表スペースがいっぱいになって、スペースの要求がなされたとき、どれほどの量だけ 

自動的に大きくするかを、データベース・パーティションごとに指定します。整数値の後に以下のものを指定 

しなければなりません。 

� PERCENT。スペースの要求がなされた時点の表スペース・サイズのパーセンテージとして量を指定し 

ます。 PERCENT を指定する場合、整数値は 0 と 100 の間でなければなりません (SQLSTATE 

42615)。例えば、自動サイズ変更が可能な表スペースが100MBのサイズで定義されており、 

INCREASESIZEが20%と指定されている場合、20MB(100MBの20%), 24MB(120MBの20%), 

28.8MB(144MBの20%),…という風に拡張されていきます。 

� K (K バイト)、M (M バイト)、または G (G バイト)。バイト単位で量を指定します。 

� 使用される実際の値は、指定されたものよりも若干小さかったり大きかったりすることにご注意ください。これ 

は、データベース・マネージャーが表スペース内の各コンテナーの増大の整合性を維持しようとするためです。 

表スペースが自動サイズ変更可能であるものの INCREASESIZE 文節が指定されていない場合には、データ 

ベース・マネージャーが適切な値を判別します。 

� MAXSIZE integer K | M | G または MAXSIZE NONE 

� 自動サイズ変更可能な表スペースを自動的に大きくできる、最大サイズを指定します。表スペースが自動 

サイズ変更可能であるものの MAXSIZE 文節が指定されていない場合、デフォルトは NONE です。 

� integer 

– DMS 表スペースまたは自動ストレージ表スペースを自動的に大きくできる、サイズ上のハード限 

界を、データベース・パーティションごとに指定します。整数値の後に K (K バイトの場合)、M (M 

バイトの場合)、または G (G バイトの場合) を指定する必要があります。使用される実際の値 

は、指定されたものよりも若干小さい場合があることにご注意ください。これは、データベース・マ 

ネージャーが表スペース内の各コンテナーの増大の整合性を維持しようとするためです。 

� NONE 

– 表スペースをファイル・システムの容量まで、または表スペースの最大サイズまで増大できるよ 

うにすることを指定します。


自動サイズ変更を解除する方法 

�ALTER TABLESPACEステートメント 

� AUTORESIZE NOを指定する 

ALTER TABLESPACE 


tablespace-name AUTORESIZE NO 

123 


�注意点 

� 一旦AUTORESIZEをNOにすると、それまでに設定していたINCREASESIZE, 

MAXSIZEの値は保持されない。 

� 自動サイズ拡張が実行されている最中に、自動サイズ拡張を解除しようと 

すると、実行中の自動サイズ拡張が完了するまでALTER TABLESPACEス 

テートメントは待ち状態になる。 

� 実行中の自動サイズ拡張が完了した後、AUTORESIZEがNOに変更される。




124 



ダイレクトI/O 


125 


�利点 

� ファイル・キャッシュとバッファープールでの二重バッファリングを回避 

� 二重バッファリングを行うCPU負荷を軽減 

� ファイル・キャッシュに余分なデータをのせないことによる、本来のファイル・データ 

のヒット率向上 

� 大量にファイル・キャッシュを使用することによって引き起こされるページングを回避 

(システム全体の性能が不安定になることを回避) 

�V8.1FixPak4以降、ダイレクトI/Oサポートが拡張されている


解説 


126 


� コンテナーにファイルを使ったDMS表スペースやSMS表スペースの場合、表や索引のデータはOSが提供す 

るファイル・システムのファイルに格納されます。DB2 for AIXの場合、デフォルトではそれらファイルのアクセ 

スはmmap I/O(Memory Mapped I/O)と呼ばれる方式を使います。mmap I/Oを使用すると、アクセスする 

ファイルはデータベースの共有メモリー(セグメント14)にマップされ、ファイルをアクセスするDB2の各プロセ 

スはこのセグメントをアクセスすることでファイルの入出力を行います。また、DB2_MMAP_READ、 

DB2_MMAP_WRITEをともにOFFに設定すると、DB2は表スペースのファイルアクセスのためにmmap I/Oを使 

わず、JFSのキャッシュにファイルページをコピーして読み書きを行います。この場合、ディスク上のデータを 

DB2エージェントがアクセスできるまでに、ファイルシステム・キャッシュとDB2のバッファー・プールの二重の 

バッファーを使っていることになります。 

� mmap I/Oを使う場合もそうでない場合にも、SMSやDMS(ファイル)の表スペースを使っている限りは直接 

I/Oを行うことはできず、ファイル・システムのためのオーバーヘッドは避けられませんでした。そのため、ハ 

イパフォーマンスが要求されるシステムでは、DMSのローデバイス構成が広く使用されてきました。 

� Windowsプラットフォームについては、DB2NTNOCACHEレジストリー変数の設定によってダイレクトI/Oが使 

用可能でした。その他のプラットフォームに関しても、V8.1のFixPak4以降、DMSのローデバイスを使わなくと 

もダイレクトI/Oが使用できるような機能強化を続けてきました。 

� ダイレクトI/Oの使用により、ファイルシステムを使うことによるオーバーヘッドを削減することができ、CPUコ 

ストの低下が期待できます。 

� また、ダイレクトI/Oを使用することで、ファイルキャッシュに余分なデータが乗らないことになり、本来ファイ 

ルキャッシュを十分に活用すべきファイルデータについてキャッシュヒット率の向上が期待できます。 

� ダイレクトI/Oを使用しない場合のデメリットとして、ファイル・キャッシュを大量に消費し、その結果引き起こさ 

れるページングによってシステム全体の性能が不安定になることが挙げられます。ダイレクトI/Oを使用する 

と、この問題を回避することができます。


ダイレクトI/Oサポートの変遷 

�V8.1.4 (FixPak4) 

� AIXプラットフォームにおけるサポート追加 

� SMS表スペースのみ (LARGE表スペース、一時表スペースは除く) 

� レジストリ変数DB2_DIRECT_IOにて設定 

� db2set DB2_DIRECT_IO=ON 

� AIXのレベルによっては、コンカレント I/Oを使用 

� AIX 5.2(ML01)以降でAPAR IY45707の適用された環境 

�V8.2 (FixPak7) 

� AIXに加え、Solaris、HP-UX、 Linuxのサポート追加 

� DMS表スペース(ファイル)のサポート追加 

� 一時表スペースは対象外 

� CREATE/ALTER TABLESPACEのオプションにて設定 

� 表スペース単位の設定が可能 

� 指定するオプション 

– FILE SYSTEM CACHING :FSキャッシング使用(省略時値) 

– NO FILE SYSTEM CACHING :ダイレクトI/O使用 


127 



解説 


128 


� V8.1.4、すなわちFixPak4によって、AIX環境のSMS表スペースに対してダイレクトI/Oを使用でき 

るようになりました。 

� ただし、LOBやLONGデータ、一時表スペースは対象外です。 

� DB2はJFS2のダイレクトI/Oの機能を使いますが、AIX5.2(ML01)以降ではコンカレント I/Oとい 

う機能を使ってファイルアクセスを行います。(APAR IY45707適用のこと) 

� ダイレクトI/Oを行うためには、新しいレジストリー変数 DB2_DIRECT_IOをONに設定してください。 

これによりSMS表スペースのI/OをダイレクトI/Oで、またAIX5.2(ML01)以降の環境では、コンカ 

レントI/Oにて処理します。 

� なお、DB2_DIRECT_IOがONに設定されていて、かつDB2_MMAP_READやDB2_MMAP_WRITEも 

ONに設定されている場合、MMAP I/Oの方の設定が自動的にOFFにされます。 

� V8.2、すなわちFixPak7では、AIXに加え、Solaris、HP-UX、 Linuxのサポートが追加になりました。 

� V8.1.4ではSMS表スペースのみを対象としていましたが、V8.2では、DMS表スペース(ファイル) 

のサポートが追加になっています。 

� 一時表スペースは依然対象外です。 

� また、ダイレクトI/O (およびコンカレントI/O)使用の設定は、表スペースレベルで可能になりま 

した。 

� CREATE TABLESPACEステートメント、およびALTER TABLESPACEステートメントに、FILE 

SYSTEM CACHING (ファイルシステムのキャッシングを使用する)、およびNO FILE SYSTEM 

CACHING(ダイレクトI/OおよびコンカレントI/Oの使用)の両オプションが追加となり、こちらの設 

定によって表スペース単位にファイルキャッシュを使用するか否かを設定できるようになってい 

ます。


参考: 

�ダイレクトI/O設定方法の例 

CREATE TABLESPACE TS1 MANAGED BY SYSTEM 

USING (‘tspath1’,’tspath2’) 

NO FILE SYSTEM CACHING 

ALTER TABLESPACE TS1 FILE SYSTEM CACHING 


129 


�表スペースのキャッシング使用状態確認は、表スペース 

のスナップショットにて確認可能 

get snapshot for tablespaces 

on sample 

Tablespace name = TS1 

Tablespace ID = 3 

Tablespace Type = System managed space 

Tablespace Content Type = Any data 

Tablespace Page size (bytes) = 4096 

Tablespace Extent size (pages) = 32 

Automatic Prefetch size enabled = Yes 

Buffer pool ID currently in use = 1 

Buffer pool ID next startup = 1 

File system caching = Yes 

Tablespace State = 0x'00000000' 

Detailed explanation: 

Normal


ダイレクトI/Oサポートの変遷(続き) 

�V8.2.2以降 

� 一時表スペースへのダイレクトI/O設定可能 

� 設定方法はV8.2のときと同様 

� CREATE / ALTER TABLESPACEのオプション 

– FILE SYSTEM CACHING 

– NO FILE SYSTEM CACHING 


130 


� ダイレクトI/Oが設定可能になったことにより、フラッシュ・コピー対象とすることができる。


解説 


131 


� V8.2.2では、SMS、およびDMS (File)の一時表スペースに対しても、ダイレクトI/O(およびコンカレントI/O)を行うこと 

ができるようになりました。 

� これにより、従来は避けることのできなかった一時表スペースに読み書きされるページの二重バッファリングを回避 

することができるようになりました。 

� また、大量データを処理する際などに、一時表がファイルキャッシュを大量に使用することによりページングが発生し、 

システム全体の性能が劣化するという問題を避けることができます。これまでは、この問題を回避するために、一時 

表スペースをローデバイスのDMSにする対応が必要でした。SMS一時表スペースのダイレクトI/Oが使用可能になっ 

たことにより、SMSの一時表スペースを使用した場合でもこの問題を回避することができます。 

� 設定の方法については、V8.2のときから変わっていません。すなわち、CREATE TABLESPACEステートメント、また 

はALTER TABLESPACEステートメントをNO FILE SYSTEM CACHINGというオプションをつけて実行することになりま 

す 

� ダイレクトI/Oが一時表スペースにも使用できるようになったことで、FlashCopyを使ってDBのバックアップ取得を行っ 

ていたり、スタンバイDB作成を行う場合に発生していた考慮点が一部緩和されます。 

� こちらの考慮点については、テクニカルフラッシュ「DM05-018 AIXプラットフォームにおけるStorageのFlashCopy機能 

を用いたDB2のバックアップに関するガイド」に詳しい記述があります。 

� ダイレクトI/OをSMSの一時表スペースに使うことのできない従来の構成でFlashCopyを使用する場合には、SMSの 

一時表スペースについて以下のような対応をする必要がありました。 

� AIX JFS2のFreeze/Thaw機能を使って、一時表スペースコンテナーの配置されたファイルシステムをFreeze状態にし 

てからフラッシュコピーを取得する 

� (または) FlashCopy V2のConsistency Group機能を使ったFlashCopyを取得する 

� 上記のいずれの対応も不可能な場合には、SMSの一時表スペースをフラッシュコピー対象外とするか、またはDMS 

の一時表スペースを使用するように設計を変更する必要がありました。 

� 一時表スペースに対するダイレクトI/Oを使用する場合であっても、SMSの一時表スペースに対しては、JFS2の 

Freeze/Thaw機能、FlashCopy V2のConsistency Group機能のいずれかを使用することが推奨されます。 

� しかし、それらが使用できない場合、SMSの一時表スペースをフラッシュコピー対象外とする、またはDMSの一時表 

スペースを使用するように設計を変更する、という従来の対応以外に、SMSの一時表スペースにダイレクトI/Oが使 

用されるように設定する、という手段が増えました。 

� この方式を選択する場合には、SMSの一時表スペースをフラッシュコピー対象とすることができます。


V9.5 

ダイレクトI/Oサポートの変遷(続き) 


132 


�V9.5で新しく表スペースを作成すると、No File System Cachingで作成される 

� 新規作成のみ、V9.5以前から既存の表スペースへは影響なし 

� 但し、以下のものはV9.1の時と同様にFile System Cachingがデフォルト 

This change applies to AIX, LinuxR, Solaris, and Windows with the following exceptions, 

where the default behavior remains to be FILE SYSTEM CACHING: 

AIX JFS 

Solaris non-VxFS 

Linux for System z 

All SMS temporary table space files 

SMS permanent table space files, except for long field (LF) data and large object (LOB) 

data files. 

� DMS FILEの表スペースに、LOBを格納する場合注意が必要。 

� LOBの再読込を行うようなアプリケーションでは、パフォーマンス低下の可能性があるため、明 

示的な「FILE SYSTEM CACHING」の設定を推奨。 

� 特に、WASのセッションDBとして使用している場合、32KBを超えるセッション情報はLOBとして書 

き込まれるため、パフォーマンス低下が懸念される。


DROPPED TABLE RECOVERY属性 


133 


� 表スペースのDROPPED TABLE RECOVERY属性 

� ドロップされた表をリカバリー可能にするための属性 

� 表スペース作成時、または変更時に、DROPPED TABLE RECOVERY属性を指定する(REGULAR表 

スペースにのみ指定可能) 

� V8以降のデフォルトはON 

� DROP TABLE ステートメント実行時 

� DROPされた表を識別するための項目がログ・ファイルとリカバリー履歴ファイルに書き込まれる 

� 表のDROP時に書き込まれる内容 

� ログ・ファイルに書き込まれる情報 

– 表の名前 

– タイム・スタンプ 

– トランザクションID 

– 表ID 

� 回復履歴ファイルに書き込まれる情報 

– 表の名前 

– タイム・スタンプ 

– トランザクションID 

– 表ID 

– DDL 

� 必要がなければOFFにする 

� 影響範囲 

� 誤ってDROPした表の回復を行うしくみを利用できなくなる 

� 定期的に大量に表を作成/削除を繰り返すような業務がない場合には、デフォルトのままでも 

業務パフォーマンスへの支障はない


解説 


134 


� 表スペースのDROPPED TABLE RECOVERY属性 

� 表スペース作成時、または変更時に、DROPPED TABLE RECOVERY属性を指定することで、 

ドロップされた表がリカバリー可能になります(REGULAR表スペースにのみ指定可能)。 

� DROPPED TABLE RECOVERY属性を持つ表スペースに対してDROP TABLE ステートメント 

が実行されると、DROPされた表を識別するための項目がログ・ファイル内に作成されます。ま 

た、この項目はリカバリー履歴ファイルにも追加され、表を再作成する際に使用されます。 

� 必要がなければOFFにする 

� V8以降では、CREATE TABLESPACE時のDROPPED TABLE RECOVERY属性はデフォルトで 

ONになっています。これにより、表のDROPに関する情報の記録が行われることになるため、 

大量に表をDROPした際に、DROP処理のパフォーマンスが劣化する可能性があります。これ 

を回避するため、必要がなければOFFにするようにしてください。 

� OFFにする方法 

� 1. CREATE TABLESPACE文によって表スペースを作成する際、DROPPED TABLE RECOVERYオプ 

ションを明示的にOFFにします。 

� 2. 既に作成されている表スペースについては、ALTER TABLESPACE文により、DROPPED TABLE 

RECOVERYオプションをOFFにします。 

� ONのままにする場合は、PRUNE HISTORYコマンドによって回復履歴ファイルを定期的に削 

除するようにしてください(容量が増大し続けるため)。


OVERHEAD/TRANSFERRATE 


135 


�OVERHEAD/TRANSFERRATEのデフォルトは、バージョンによ 

り異なる 

�OVERHEADの省略時値 

� V8.1 : 24.10ms 

� V8.2 : 12.67ms 

� V9以降 : 7.50ms 

�TRANSFERRATEの省略時値 

� V8.1 : 0.90ms 

� V8.2 : 0.18ms 

� V9以降 : 0.06ms


参考:OVERHEADとTRANSFERRATEの意味 

�OVERHEAD 

�データをメモリーに読み込む前に、コンテナーに関して必要な 

時間(ミリ秒) 

�ディスク待ち時間、コンテナーの入出力コントローラーのオー 

バーヘッド (ディスクのシーク時間を含む)が含まれる 

�TRANSFERRATE 

�1ページのデータをメモリーに読み込むために要する時間(ミ 

リ秒) 


136 




�ユーザー表スペースの配置 

� 索引/長形式データの配置 

�その他の表スペースの配置 


137 





138 



ユーザー表スペースの配置 

� 複数の物理ディスクに表スペースを配置し、DISK I/Oを分散させる 

� 1つの表スペースを複数ディスクに配置理想は同じサイズのコンテナー 

� 索引は別の表スペースに配置 

� 長形式は別の表スペースに配置 


139 


� 基本:Prefetch Size = Extent Size×コンテナー数 

� RAID5などアレイの場合は以下の構成を行う 

� DB2_PARALLEL_IO 

� このレジストリー変数を設定することで、PrefetchSize と ExtentSizeの違いを見て、I/Oを並列 

に行うかを決定する 

表スペース1 

(Prefetch Size = Extent Size × 

4) 

表スペース2 

(Prefetch Size = 

Extent Size × 3)


解説 


140 


� パフォーマンスのためには、各表スペースに対して、6個~10個以上の物理ディスク上に別々 

のコンテナーを作成し、I/Oを分散することが理想的である(と言われています) 

� 複数のコンテナーに配置する場合には、表スペースに対して以下の設定を行い、プリフェッ 

チャーによる並列I/Oを使用可能にする必要があります。 

� Prefetch Size = Extent Size×コンテナー数 

� この設定によって、複数のプリフェッチャー・プロセスを使い、データをバッファプールに読み出 

すことができるようになります。 

� データはラウンドロビンで書き込まれている為、各コンテナーのサイズは同じであることが理想 

的です。それによって、データの分散度合いのばらつきを無くし、ディスクI/Oが特定のコンテ 

ナーにできるだけ集中しないようにします。 

� DB2_PARALLEL_IOを指定した場合は、特にPrefetch Sizeは重要になります。パラレルI/Oを指 

定するような場合は、通常ESSなどのRAIDディスクが使われており、コンテナーが1つでも実際 

は内部では複数のディスクが使われています。このような状態では、コンテナー数は先読みに 

対しては意味を持たず、DB2はPrefetch SizeがExtent Sizeの何倍になっているかによって、プ 

リフェッチャーを起動し先読みを行います。


参考:プリフェッチ・サイズの自動調整機能(V8.2以降) 


141 


�エクステント・サイズ、コンテナ数、およびコンテナあたりの物理ディスク 

数に基づいて、表スペースに適したプリフェッチ・サイズをDB2が自動計 

算する 

� 利点: コンテナの追加・削除に応じ、プリフェッチ・サイズを変更する必要がない 

� 考慮点: コンテナ数、物理スピンドル数が多いほど、多く設定される 

�設定方法 

� データベース構成パラメーターDFT_PREFETCH_SZの値をAUTOMATICに設定する 

� CREATE TABLESPACEステートメントで、 PREFETCHサイズを指定しない 

�算出式 

� プリフェッチ・サイズ= 

(コンテナ数)*(コンテナあたりの物理ディスク数)*エクステント・サイズ


参考:プリフェッチ・サイズの自動調整機能(V8.2以降) 

�DB2_PARALLEL_IOの値との関連 

� DB2_PARALLEL_IOの値は、コンテナあたりの物理ディスク数として使用される 


142 


�例 � (例1)DB2_PARALLEL_IO=* 

� 全ての表スペースは、デフォルトで、各コンテナあたり6個の物理ディスクをもつと仮定して計算され 

る 

� 全ての表スペースに対して、パラレルI/Oが有効となる。プリフェッチ要求は、プリフェッチサイズをエ 

クステント・サイズで割った数に分割されて、パラレルに実行される 

� (例2) DB2_PARALLEL_IO=*:3 

� 全ての表スペースは、コンテナあたり3個の物理ディスクを持つと仮定して計算される 

� 全ての表スペースに対して、パラレルI/Oが有効となる。 

� (例3) DB2_PARALLEL_IO=*:3,1:1 

� 全ての表スペースは、コンテナあたり3個の物理ディスクを持つと仮定して計算される。 

ただし、表スペース 1 だけは、物理ディスク数は1となる。 

� 全ての表スペースに対して、パラレルI/Oが有効となる。 

�DB2_PARALLEL_IOが設定されていない場合には、物理ディスク数は1


索引/長形式データの配置 


143 


�索引の配置 

� DMS表スペースに表を作成する場合、索引を別の表スペースに格納することが可能。 

� ディスクI/Oの競合を避けたい、または、表と索引のバッファープールを分け、特定の表や索引 

のヒット率を確保したい場合には、表と索引を別の表スペースに格納することを検討する 

表スペース for TABLE 

(Prefetch Size = Extent Size × 4) 

表スペース for INDEX 

(Prefetch Size = Extent Size × 3) 

�長形式データの配置 

� DMS表スペースに表を作成する場合、長形式のデータを別の表スペースに格納することが可 

能。 

� 長形式のデータにはバッファプールは有効ではない 

� ファイルDMSに配置することによって、ファイルキャッシュを有効にすることができる 

� LOBとして格納するデータは、通常それほど頻繁に読み書きが発生しないので、キャッシュが 

効かなくても影響が少ないケースも多い


その他の表スペースの配置 


144 



� ソート、結合、再編成、索引作成時(LOADを含む)等に使用 

� 一時表のI/Oが多く、データ/索引用の表スペースのI/Oと衝突する場合は、別ディスクに配 

置する 

� コンテナーに複数のディレクトリーを指定することが推奨。(SMSの場合) 

� カタログ表スペース 

� 通常、カタログ表のデータは殆どキャッシュ上に読み込まれているため、特にI/O効率を考慮 

したディスク上への配置は不要。(データベース作成時のデフォルトのままでも良い。) 

� SYSTOOLSPACE 

� V8.2以降でデータベースの自動保守(自動統計収集および再編成)を使用する場合に自動作 

成され、自動保守が実行される際に使用される。デフォルトの配置のままでも特に問題はない。 

自動保守機能を使用しない場合は、削除しても良い。



�ログの配置 

� アクティブ・ログとアーカイブ・ログ 

�ワーク/バックアップ領域の配置 

�その他の領域 


145 





146 



ログの配置 


147 


� アクティブログに対する書き込み速度はアプリケーションのレスポンスに直接 

影響する 

� アクティブログは安全性を考えると、二重化した方がよい 

� (アクティブログの障害=データベースの障害) である。 

� DB2の二重ログは両方に書き出して終了なので、どちらか1つのディスクが遅い場合、ログへ 

の書き込みは遅くなる。 

� ディスク容量が許すのであれば 

� アクティブログ専用のディスク上に配置する 

� ESSの場合ランクも別の方が理想的 

� SCSI / Fibreなどのチャネルもできれば別 

� RAID5ではなく、ミラーリングを使用する 

� ストライピングによって書き込みを速くする 

非同期 

書き出し 

変更された 

データ 

データの 

更新処理 

データ 

バッファプール 

コミットしたら更 

新内容を 

必ず書き出す 

ログ


解説 


148 


� ログはDB2にとって重要なオブジェクトです。特にアクティブログは非常に重要で、アクティブログが損傷したことは 

データベース自身が損傷したことを意味します。 

� つまり、アクティブログが壊れたら、データベースが壊れたのと同じです。 

� 何故、アクティブログがそれほど重要なのでしょうか。更新処理を行う時のDB2の動作を考えてみます。 

� データベースが更新された場合、バッファプールと呼ばれるキャッシュのデータが更新されますが、ディスクにはすぐ 

には書き出されません(このようなデータが含まれるページをダーティーページと呼びます)。その更新処理がコミッ 

トされると、必ずログに書き出されます。 

� この状態でもしDBサーバーがクラッシュした場合、次にデータベースが使われる前に、クラッシュリカバリーという処 

理を行う必要があります。クラッシュリカバリーによって、更新されたはずなのにディスクに反映されていない更新を、 

ログを読みながらディスクへ反映します。 

� ここで、重要な点はログがなければクラッシュ前にどのような更新処理が行われていたのかを知ることができないと 

いうことです。DB2はこのクラッシュリカバリーによって、突然のDB2の異常停止などの時でもデータベースに格納さ 

れているデータの論理的な整合性を保証しています。つまり、ログが壊れるということはDB2がデータの整合性を保 

証できないということを意味しています。 

� ログの重要性を理解したところで、そのI/Oパフォーマンスが非常に重要であることも気が付かれたと思います。更 

新処理がコミットされたら必ずログに書き出される訳ですから、ログへの書き出しが終わらないと次の処理へ進むこ 

とができません。 

� 更新処理のボトルネックがログのI/Oにならないようにする為には、他のI/Oとの衝突をできる限り避ける必要があり 

ます。他のI/Oとは表や索引のデータが含まれるディスクへのI/Oが含まれます。つまり、ログは表や索引などとは 

全く別のディスクに配置することが推奨されます。ESSのような1つのアレイが大きな場合でも、できる限り全く別の 

ディスク上に配置し、SCSIやファイバーチャネルなどのインターフェースも別にすることが推奨されます。 

� また、書き込みに対して多少不利なRAID5よりもできればミラーリング(RAID1)などを選択するようにしてください。 

� さらにディスクに余裕がある場合には、ストライピングなどによって高速化できれば更新処理にとって良い結果が期 

待できます。


ログの配置(続き) 


149 


�アーカイブログとアクティブログは別のディスクに配置する 

� アーカイブログ・ディレクトリ(コピー先)とアクティブログ・ディレクトリ(コピー元)は別にした方 

がパフォーマンス的に有利 

� 障害時の危険分散を考えても別の方がよい 

� アクティブログとアーカイブログが壊れた場合、バックアップからのリストアーはできても、最新 

状態へのロールフォワードができなくなる。 

�大量更新を行うバッチ系処理の場合(Importなど) 

� ログに対するキャッシュに相当するログバッファー(LOGBUFSZ)を大きくする 

�ローデバイスロギングは、V9では推奨されない 

� ローデバイスロギングを使用すると、二重ログが使えない 

� USEREXITに何らかの問題があって、ログのコピーに失敗した場合、手動によるコピーが不可 

�ログ・アーカイブ機能(V8.2以降)を使用する場合は、アーカイブ先ディレ 

クトリとして容量と配置に注意する 

� 二つのアーカイブ先ディレクトリ(LOGARCHMETH1, LOGARCHMETH2)を使用する場合 

� 領域は2倍必要 

– 代替ディレクトリ(FAILARCHPATH)を使用する場合は、更に領域が必要 

� それぞれ別のディスクに配置する


解説 


150 


� アクティブログの重要性を説明してきましたが、DB2にはもう一つアーカイブログというログがあります。通常、ログ・ 

アーカイブ機能によって、アクティブログがアーカイブされた時に、そのアーカイブ・ログをアクティブログとは別のディ 

レクトリ(またはテープのような別のメディア)にコピーして保存します。このログファイルをコピーする処理も重要です。 

� コピー先のログファイルは、コピー元やデータベース自身の障害発生時に復元の為に必要になるので、コピー元と 

は全く別のディスクやメディアに保存する必要があります。また、ログ・アーカイブ機能はデータベースが使われてい 

る時に動作しますので、もし同じディスクにコピー先を配置してしまうと、コピー先の書き込みI/Oの為にアクティブロ 

グ自身のI/Oへ影響を与える可能性があります。データベースのパフォーマンスを維持するためには、できる限りこ 

のような影響は排除する必要があります。 

� 1つの作業単位(UOW)によって大量のデータを更新するような場合、コミットとコミットの間隔が非常に長くなります。 

このような場合、データベース構成パラメータのログバッファー(LOGBUFSZ)を大きくするとパフォーマンスに好影響 

を与えます。このような更新処理の場合、ログバッファが小さいと(デフォルトでは32KB)、更新処理がコミットされて 

いなくても、ログを頻繁にディスクに書き出さなければならなくなる為に、パフォーマンスに悪影響があります。 

� ログをローデバイスに配置する機能をDB2はサポートしていますが、V9では推奨されません。ローデバイスロギング 

を使用する場合、何らかの問題があってログ・アーカイブ機能によるログファイルのコピーに失敗し、アクティブログ 

のデバイス中に特定のログファイルが残ってしまったようなケースでは、手動でコピーすることができません。障害時 

の復旧作業は、通常時とは異なり、多種の問題が発生している可能性があり、手動で復旧できないということは、安 

全性が低いとも言えます。 

� また、DB2の二重ログの機能はローデバイスで使用することはできません。


ワーク/バックアップ領域の配置 


151 


� バックアップ時間の短縮が必要な場合、バックアップ領域のパフォーマンスを 

考慮する 

� ディスクへのバックアップの場合、バックアップ元のあるディスクとは別にする 

� 1つのディスクでは要求が満たせない場合、複数のディスクへのバックアップを検討 

� テープへのバックアップは、TSMがサポートしていれば、複数テープへの同時書き込みによっ 

て高速化が可能 

� ロードの処理時間短縮が必要な場合 

� ロード元のデータを格納するファイルシステムのパフォーマンスを考慮する 

� AIXでは、以下のパラメータがパフォーマンスに影響する場合がある 

� vmtuneのminpgahead, maxpgahead(ファイルシステムの先読み) 

� 一時表スペースと同居できるか 

� ロード時の入力ファイルと、ソート用の一時表スペースのI/Oが競合するとロードのパフォーマ 

ンスに悪影響が考えられる 

� 通常は、再編成時にはロードやバックアップなどの処理は行わない。


その他の領域 

� DB2診断情報格納ディレクトリー 


152 


� インスタンス・ホーム・ディレクトリー(デフォルト)、または、データベース・マネージャ構成パラ 

メーターDIAGPATHにて指定した場所に格納される 

� 管理通知ログ、db2diag.log、ダンプ・ファイル、トラップ・ファイル、コア・ファイル (UNIX のみ)を 

格納する 

� V8.2以降は、db2diag.logへ書かれる内容が増えているため、V8.1以前より容量が増 

える可能性がある。 

� データベース・ディレクトリー 

� バッファープール情報、表スペース情報、データベース構成情報、リカバリ履歴ファイル、ログ 

制御ファイル




153 


�スレッドモデルへの変更 

�メモリーモデルの変更 

�バッファープール関連のパラメーター 

� プリフェッチャー 

� ページクリーナー 

�その他最低限構成すべきパラメーター 

�自己チューニングメモリー(Self Tuning Memory Manager)




154 



V9.5 

スレッドモデルへの変更 


155 


�V9.5からは、 UNIX、Linux プラットフォームにおいて、従来のようなプロセス・ 

モデルではなく、db2syscプロセスが 1つ存在し、残りのEDUは db2syscプロセ 

ス配下にスレッドとして存在するアーキテクチャーに変わった。 

Idle Agent Pool 

Instance Level 

db2agent (idle) 

Database Level 

Logging 

db2loggr 

db2loggw 

db2agntp 

Subsystem Log Buffer 

Log 

Disks 

Write Log Requests 

Victim Notifications 

Shared Mem & Semaphores, TCPIP, Named Pipes,… 

db2agntp 

Active 

UDB Client Library 

db2tcpcm db2agent 

db2ipccm 

Deadlock 

Detector 

db2dlock 

Buffer Pool(s) 

Async IO Prefetch Requests 

Idle 

Parallel, Big-block, 

Read Requests 

Parallel, Page 

Write Requests 

db2pfchr 

db2pclnr 

Common 

Client 

UDB Server 

Listeners 

Coordinator 

Agents 

Subagents 

Prefet 

chers 

Page 

Cleaners 

Data Disks 

Process/Thread Organization 

Per-instance 

Per-application 

Per-database 

Idle, pooled agent or 

subagent 

V9.5からは、点線 

枠で囲まれた部分 

は、1つのプロセス 

となる。各EDUは、 

スレッドとして存在 

して、 db2syscプロ 

セスに紐づく。 

Health Monitor 

FMP 

db2acd 

db2fmp 

db2wdog


V9.5 

スレッドエンジンのメリット 


156 


�リソースの節約 

� EDUがプロセスだった際には、個別のプロセスで保持していたファイル・ハンドル情報を、 

db2syscプロセスが持つメモリー空間で共有するので、情報の二重持ちがなくなる。 

� システムスレッドのオペレーションはプロセスほどコンテキストを要求しない 

� アドレススペースとコンテキスト情報を共有する 

�パフォーマンスの向上 

� スレッド間でのコンテキストスイッチは、プロセス間でのやり取りに比べれば、一般的に 

速い。 

�使いやすさの向上 

� インスタンス全体で消費されるメモリー量の把握が、従来より容易になる。 

� AUTOMATICに設定、動的に変更可能な構成パラメーターが増える。 

� エージェント間で情報が共有されるため、アプリケーション・グループ共用メモリーが不 

要になる。 

� 上記に伴い、以下の構成パラメータは廃止される。 

– APP_GROUP_MEM_SZ 

– GROUPHEAP_RATIO 

– APP_CTL_HEAP_SZ


V9.5 

メモリー・モデルの変更(DB2 V9.5) 

APPL_MEMORY 

データベースエージェントが割り振るアプ 

リケーションメモリーの最大量を制御 

DATABASE_MEMORY 

データベース共用メモリー領域に 

予約されるメモリー量を指定する 


157 

INSTANCE_MEMORY 


1つのデータベースパーティションに 

割り振ることができるメモリー最大量


V9.5 

Automatic管理となったヒープ(メモリー関連) 

�V9.1でautonomic管理となっているヒープ(=STMMが管理) 

� buffer pools 

� lock list 

� max locks 

� package cache 

� sort heap 

�V9.5でautonomic管理となるヒープ 

� application heap 

� dbheap 

� monitor heap 

� statement heap 

� statistics heap 

Information Center「いくつかの構成パラメーターは単純化されたメモリー構成によって影響を受ける」より抜粋 


https://publib.boulder.ibm.com/infocenter/db2luw/v9r5/topic/com.ibm.db2.luw.wn.doc/doc/i0052504.html?resultof=%22%64%62%68%65%61%70%22%20 


158


V9.5 

メモリー構成単純化のメリット 


159 


�構成の簡素化 

� V9.1において、パフォーマンスに影響を与える一部のヒープが自動管理(=STMM)となり、 

V9.5では、その他のヒープも自動管理となりDBAによる手動構成が不要となる 

� V9.1でSTMM機能によりautonomic管理となったヒープ 

– buffer pools, lock list, max locks, package cache, sort heap 

� V9.5でautonomic管理となるヒープ 

– application heap, dbheap, monitor heap, statement heap, statistics heap 

� 各データベースパーティションで使用可能な合計メモリーサイズの上限を 

INSTANCE_MEMORYに設定可能 

� 消費される合計メモリーサイズがINSTANCE_MEMORYのサイズ内であれば、各ヒープはメ 

モリーサイズを増加させることが可能となる 

� 新しく作成されるDBでは、メモリー関連(一部例外あり)のパラメーターはデフォルトで 

AUTOMATICと設定され必要に応じてDB2が自動調整する 

– 例外)utility heap, catalog cache, audit buffer, java heap, etc 

�メモリー不足によるエラーの削減 

� 各構成パラメーターをAUTOMATICと設定することで、必要に応じてメモリーサイズを調 

整する


V9.5 

INSTANCE_MEMORY1/2 


160 


�1つのデータベースパーティションに割り当てることが可能な最 

大メモリーサイズを指定する 

� デフォルト値(=AUTOMATIC) 

� 実際の設定値は、db2start時にサーバーの実メモリーの75% - 95%の間で割り当てられる 

� 実メモリーが割り当てられるわけではなく構成パラメーター値に上限値がセットされる 

�V9.1までとは意味が異なる 

� インスタンス管理用として予約する必要のあるメモリーサイズを指定(V9.1) 

�INSTANCE_MEMORYの更新 

� INSTANCE_MEMORYの動的増加は成功し、動的減少の場合は、現在使用されているメ 

モリー量よりも大きい場合に成功する 

� サーバーの実メモリーより大きい値がINSTANCE_MEMORYに設定された場合、db2start 

はSQL1220Nで失敗する 

� インスタンス稼動中に、実メモリーよりも大きい値にINSTANCE_MEMORYが更新された 

場合、更新要求は据え置かれ、次回のdb2startがSQL1220Nで失敗する


V9.5 

INSTANCE_MEMORY2/2 


161 


�INSTANCE_MEMORYサイズに達した状態で、特定ヒープに対してメモリー拡 

張要求が来た場合 

1.DB2は全ての共有メモリー、プライベートメモリーから要求されたメモリー量を削減しようと試みる 

2.上記対応後も十分な空きINSTANCE_MEMORY領域を確保できなかった場合、拡張要求は失敗す 

る 

�(例外)DB2の稼動に致命的な影響を与えるメモリーに対して拡張要求が来た 

場合 

� 致命的な影響 

� メモリー拡張要求が失敗することで、DBが無効とみなされる 

� インスタンスがシャットダウンしてしまう 

1.データベースパーティションで使用している現在の使用メモリーサイズの削減を試みる 

2.上記対応後も十分な空きINSTANCE_MEMORY領域を確保できなかった場合、DB2はOSにメモリー 

要求を出し、OSからメモリーを確保する 

� OSからメモリーを確保できた場合、INSTANCE_MEMORYのサイズが構成値を上回ることがある 

�考慮点 

� 同一サーバー上で、別ミドルウェアも並行稼動する場合、もしくは複数のインスタンスが並行稼動す 

る場合には、INSTANCE_MEMORYに適切な値を設定することで効率良いメモリー配分が可能とな 

る


V9.5 

APPL_MEMORY 


162 


�アプリケーションを実行するために割り当てることが可能な最大 

メモリーサイズを指定する 

� DBで消費されるアプリケーションメモリーの合計量をこのパラメーターで制限することが 

できる 

�デフォルト値(=AUTOMATIC) 

� DB活動化の時点で、最少のメモリーが割り当てられる 

�APPL_MEMORYに数値が設定された場合 

� DB活動化の時点で、設定されたメモリーサイズが割り当てられ、APPL_MEMORYサイズ 

の増減は発生しない 

� 初期設定値のメモリーをサーバーから取得できなかった場合、もしくは、 

INSTANCE_MEMORYの値を超えた場合、DBの活動化はSQL1084Cで失敗する 

�考慮点 

� DATABASE_MEMORYに一定量のメモリーサイズを確保しておきたい場合には、 

APPL_MEMORYで使用可能なメモリーサイズを制限する


バッファープール関連のパラメーター 


163 


� バッファプールの構成 

�表スペースのディスクに対する入出力のキャッシュ 

�LOBに対してバッファプールは効果が無い 

� プリフェッチャー(NUM_IOSERVERS)を十分に構成する 

�このパラメータは必要より大きく構成しても、ほんの少しメモリを消費するだけで他の悪影 

響は考えられない 

�物理ディスクの数+2 程度が推奨 

� ページクリーナー(NUM_IOCLEANERS)も十分に構成する 

�このパラメータは大きく構成し過ぎると、CPUの負荷を必要以上に大きくする可能性があ 

る �CPUの数を初期値に、最大で物理ディスク数迄


解説 

� パフォーマンスに最も影響を与えるパラメータがバッファプールと言われています。DB2が使 

用するメモリー領域の中で通常、最も大量にメモリーを使用します。 

� バッファプールは表及び索引・データのキャッシュに相当します。 

� バッファプールはデータベースが活動化時(通常最初の接続が行われた時)にアロケーショ 

ンされ、非活動化時(最後の接続が切断された時)に解放されます。 

� バッファプールのみを大きくしても、物理ディスクのIOを行うプリフェッチャーとページクリー 

ナーが少なければ、効果が上がらない可能性があります。 

� プリフェッチャーの初期値は、表及び索引を配置している物理ディスクの数+2(物理ディスク 

数はRAID5ディスクの場合、パリティ・スペアを除く)と一般的に言われています。 

� ページクリーナーはCPUの数から物理ディスクの数の間で調整します。初期値はCPUの数 

(物理ディスク数はRAID5ディスクの場合、パリティ・スペアを除く)。 

� RAID5等ストライピングされたディスクを表スペースに使用する場合、プリフェッチャー及び 

ページクリーナーは通常ディスクと同様に調整する必要がありますが、さらにdb2setコマンド 

で設定する環境変数:db2_parallel_ioに*(全ての表スペース)また特定の表スペースIDを指 

定する必要があります。 

� バッファプールのサイズは、スナップショットによってバッファープールヒット率((論理読出数 

-物理読出数)/論理読出数×100)を計算して通常評価します。通常80%から90%以上が 

目安ですが、システムの性格によってはそれ以下でも問題がない場合もあります。 


164 



プリフェッチャー(NUM_IOSERVERS) 

� プリフェッチャーは先読みを行う時に使用される。 

� データベース構成パラメーター「NUM_IOSERVERS」にて数を指定。 

�V9以降、デフォルト値はAUTOMATIC(V8以前のデフォルト値は「3」) 

�AUTOMATICの場合、データベース活動化時点で、適正値を計算 

page page page page page page page page 

cont 

Bufferpool 

page page 

page page 

Prefetcher Prefetcher Prefetcher 

Prefetcher 

Prefetcher 

Prefetcher 

Extent Extent Extent 

cont 


cont 


165 

必要のないプリフェッチャ 

ーは使用されない 

Prefetch単位 



解説 


166 


� バッファプールに表スペースからデータを読み込む時に、小さなデータを読み込むのであれば、通常はエージェント 

が直接読み出して、バッファプールに格納します。しかし、連続したデータを読み込むような場合は、DB2が判断し、 

プリフェッチ(Pre-Fetch:先読み)を行います。このプリフェッチは、プリフェッチャーと呼ばれるプロセスによって行わ 

れます。プリフェッチャーの数はデータベース毎に指定できます。データベース構成パラメータ:NUM_IOSERVERSで 

す。 

� プリフェッチャーが効率よく動作するためにはもう一つ構成が必要です。それは表スペースの属性である、 

PrefetchSizeです。各プリフェッチャーはそれぞれ1回の読み込みで、ExtentSize分のページを読み込みます。 

PrefetchSizeはExtentSizeの何倍になっているかによって、幾つのプリフェッチャーが必要なのかが決まります。ここ 

で重要なのは、PrefetchSizeはExtentSizeの倍数である必要があるという点です。何倍かは、コンテナー数倍を基本 

とします。 

� 上記の図の例で考えてみましょう。表スペースは、物理ディスク3つから構成されています。表スペースのExtentSize 

はデフォルトの32ページとします。この場合、この表スペースの最適なPrefetchSizeは、ExtentSize×表スペースを 

構成する物理ディスク数となり、96ページということになります。 

� この構成によって、プリフェッチャーはこの表スペースを先読みする際には、3つ使用され、それぞれのディスクを 

別々のプリフェッチャー・プロセスがIOし、ディスクIOの効率化を図ります。 

� この際、表スペースは、各ディスクに1つずつ合計3つのコンテナーから構成する必要があります。OSのストライピン 

グによって複数のディスクから単一のコンテナーを構成することも可能ですが、DB2に複数ディスクから構成されて 

いることを明確にし、ディスクの入出力をDB2によって効率化する為にも、OSのストライピングよりDB2のストライピン 

グの方が推奨されます。 

� 最近の物理ディスクは、飛躍的に速度が速くなっているので、PrefetchSizeは必ずしもExtentSize×物理ディスク数 

でなくても、その倍程度でも効果があることが確認されています。物理ディスク装置へのSCSI またはファイバーチャ 

ネルの速度などにもよるので、一概には言えませんが、倍、3倍、4倍程度を試してみて効果があればその 

PrefetchSizeが、最もパフォーマンス的に優れているということになります。 

� プリフェッチャーの構成(NUM_IOSERVERS)は、大きすぎても使われないプロセスが起動されているだけなので、多 

少のメモリを余分に消費するのみのため、多少多めに構成しても、ほとんど問題がありません。


ページ・クリーナー(NUM_IOCLEANERS) 

� ページクリーナーは以下の時に呼び出される 

�ソフトチェックポイント 

�ページ変更しきい値(chngpgs_thresh)に達したとき 

� データベース構成パラメーター「NUM_IOCLEANERS」にて数を指定。 

�V9以降、デフォルト値はAUTOMATIC(V8以前のデフォルト値は「1」) 

�AUTOMATICの場合、データベース活動化時点で、適正値を計算 

① 

LOGFILSZ 

(A)が(B)と比較してログ 

ファイルのSOFTMAX(%) 

よりも古い場合 

(A)バッファー・プール 

内の最も古いページに 

含まれている更新内容 

のログ・レコード 

(B)最新の更新内容 

ログファイル 

db2agent 


データ更新 

167 

② 

db2pclnr 

更新済みページが 

CHNGPGS_THRESの値(%)を超えた場合 

更新済みページ 

バッファープール 

db2pclnr 

cont1 cont2 cont3 


db2pclnr 

NUM_IOCLEANERSデータベース 

構成パラメータの値 



解説 


168 


� これに対して、バッファプールから表スペースに対してデータを書き出すプロセスを、ページ・クリーナーと呼びます。 

プリフェッチャーと同様に、データベース構成パラメータ:NUM_IOCLEANERSによって構成します。 

� ページ・クリーナーがプリフェッチャーと異なる点は、多く構成しすぎると、CPUへのオーバーヘッドになる可能性があ 

るという点です。ページ・クリーナーは幾つかの事象によって起動されますが、ページ・クリーナーが起動される時は、 

構成されているクリーナーが全て起動されます。必要な数よりも多く構成されていた場合、多くのクリーナーが起動 

されることになり、それがCPUの負荷を必要以上に高める可能性があります。 

� ページ・クリーナーの初期値がCPUの数と言われているのはこのためです。プリフェッチャーの数は物理ディスクの 

数+2程度と言われています。 

� このように、バッファプールはそれだけを大きくしても、バッファプール-ディスク間のデータのやりとりを行うプリ 

フェッチャーおよびページ・クリーナーを表スペースのPrefetchSizeおよびExtentSizeと共に正しく構成しないと、ディ 

スクへの入出力を効率化し、パフォーマンス向上を図ることは難しくなります。 

� ページ・クリーナーが呼び出されるタイミング 

� ページ・クリーナーが呼び出されるタイミングに影響を与えるパラメータが以下の構成パラメータです。 

� ページ変更しきい値(chngpgs_thresh) 

� softmaxおよびlogfilsiz 

� ページ変更しきい値は、バッファプール中のこのパラメータで指定した比率がダーティページ(データが更新され、 

バッファプール上では更新されているが、ディスクには反映されていないページのこと)になったら、ディスクにダー 

ティページを書き出そうとします。 

� また、logfilsizとsoftmaxによって、ソフト・チェックポイントを発生させ、ダーティページをディスクに書き出すことも可能 

です。ソフト・チェックポイントの正確な意味を考えると多少混乱するかもしれませんが、大体、ログが切り替わるタイ 

ミングでソフト・チェックポイントによって、ダーティページをディスクに書き出すと考えてよいでしょう。Softmaxはデ 

フォルトでは100%で、logfilsizと同じですが、softmaxを小さくするかlogfilsiz自身を小さくすることによって、頻繁に発生 

させることができます。 

� このダーティページの量は、クラッシュ・リカバリーと呼ばれるDB2によるリカバリー処理に大きな影響を与えます。


AUTOMATIC値の算出 


169 


�算出方法 

� 以下の3つの値の中で、最も大きな値を設定値とする 

� 1.V8でのデフォルト値(3) 

� 2.SMS表スペースで、(「コンテナ数」*「DB2_PARALLEL_IOで設定された並行処 

理物理ディスク数」) の、全SMS表スペースでの最大値 

� 3.DMS表スペースで、(「表スペースのストライプセットにあるコンテナの最大数」 * 

「DB2_PARALLEL_IOで設定された並行処理物理ディスク数」)の、全DMS表スペー 

スでの最大値 

�最低でも、3つのプリフェッチャーが起動 

�算出値に影響する項目 

� 表スペースのコンテナ数 

� DB2_PARALLEL_IOレジストリー変数で指定された、 

並行処理物理ディスク数


AUTOMATIC値の算出 

�算出方法 

� 以下の値のうち、大きな方の値を設定値とする 

� 1.V8でのデフォルト値(1) 

– 最低でも1つのページクリーナーが起動 

� 2.CPU数 -1 

– DPFの場合 

CEIL(CPU数÷同一サーバー上のDBパーティション数)-1 

*CEIL=少数部分を切り上げ 

� 各DBパーティションに配布されるページクリーナー数がほぼ均等、 

かつCPU数を超えないように算出 

�算出値に影響する項目 

� CPU数 

� DPFの場合、DBパーティション数 


170 



その他最低限構成すべきパラメーター 

� ログ関連 

� logfilsiz, logprimary, logsecond 

� ロック関連 

� locklst, maxlocks 

� ソート関連 

� sortheap, sheapthres 

� エージェント関連 

� maxappls, maxagents, num_poolagents, num_init_agents 

� num_poolagentsはV7とV8で仕様が異なる。 

ソフトウェア製品のサポート技術情報「NUM_POOLAGENTS DBM構成パラメーターの変更について(DM-05-021)」 

http://www.ibm.com/jp/domino01/mkt/cnpages1.nsf/page/default-000A5CD1 

� その他 

� applheapsz, dbheap, intra_parallel, maxfilop 


171 


� よくわからない場合は、構成アドバイザーで初期値を設定 

� V9では、データベース作成時に、システムリソース(メモリー、CPU、等)を考慮し、構成パラメーターをデフォルト 

で自動設定する 

� 構成アドバイザーの機能によってパラメーターが決定される。 

� V8.2までは、構成パラメーター(DBM, DB)のデフォルト値は固定 

� V9では、自己チューニング・メモリー(STMM)機能がデフォルトで稼動 

� STMMでのチューニング対象になっているメモリー領域は、デフォルト値がAUTOMATICになっている


解説 


172 


� ログ関連 

� logfilsiz,logprimary,logsecond 

� ログは、最大のトランザクション(通常大量更新を行うバッチジョブなど)で使用されるログ容量をスナップ 

ショットより測定し、その数値を元に(データ件数などの増加率などを含めて)見積もり、 

LOGFILSIZ,LOGPRIMARY,LOGSECONDパラメータを調整します。 

� ログ容量=LOGFILSIZ×(LOGPRIMARY+LOGSECOND)×4096(バイト) 

� ファイルサイズ(LOGFILSIZ)をあまり大きくすると、ログ・ファイルの切り替えの際にディスクIOの負荷が大きく 

なり、あまり小さくすると頻繁にログ・ファイルが切り替えられるために(ログ・ファイル切り替え時には、バッ 

ファプール中の更新されてディスクに書かれていないダーティ・ページが、ディスクに書き出される)、バッファ 

プールが有効に利用されない場合があります。 

� 活動ログに使用するファイルシステムは、ログ容量の約2倍用意する必要があります。これは、1時点で大量 

のログが使用された場合にアロケーションされる、次のログファイルの為の領域です。ディスクに余裕がある 

場合は、64GB(V.7の最大ログ32GBの倍)用意しておくと活動ログのファイルシステムが不足することが無くな 

ります。ローデバイスのログは、管理が難しいので使用しないことを推奨します。 

� ロック関連 

� locklst,maxlocks 

� ロックの為のメモリー領域(locklist)は、クライアント数や1つの更新単位(1つのCOMMITまでに 

INSERT,UPDATE,DELETEによって更新される行の数)にあわせて調整する必要があります。 

� Locklistが不足していると、ロックエスカレーション(通常ロックは行単位ですが、ロック用メモリーが不足した 

場合、表単位のロックに自動的に変わること)が発生し、長時間のロック待ちやデッドロックなどが発生する可 

能性があります。 

� 但し、通常夜間などに実行される大量更新の為のバッチジョブ等に関しては、ロックエスカレーションが問題 

にならない場合もあります。 

� スナップショットの、locklist使用量およびLock Escalationの頻度などによって調整します。通常Lock 

Escalationは、オンライン系トランザクションではできるだけ発生させないように、メモリーサイズを大きくします。


解説 


173 


� ソート関連 

� sortheap,sheapthres 

� ORDER BYを使用したSQLなどで使用するソート(分類)用のメモリー領域(SORTHEAP) 

� ここで定義したメモリー領域では容量不足の場合、一時表スペースがソートのために使用されます。この場合、ディス 

ク上でソートを行うので、メモリー上の場合よりパフォーマンスが悪化する可能性があります。 

� 各接続に対してアロケーションされるSORTHEAPを大きくした場合、インスタンス全体で使用できるソートヒープを制限 

するDBM構成パラメータSHEAPTHRESも調整する必要があります。SHEAPTHRESの理想的なサイズは、インスタンス 

配下の(SORTHEAP×同時接続数)です。 

� エージェント関連 

� maxappls,maxagents,num_poolagents,num_init_agents 

� クライアントからDBサーバーに接続すると、サーバープロセスのバックエンドでエージェントが起動されます。 

� エージェントの起動はサーバーへの負荷が非常に高い為、あらかじめサーバー上にエージェントを起動しておく 

num_initagentsパラメータ(db2start時に起動)、または1回使用されたエージェントを解放せずに次回の接続時に再利 

用するnum_poolagentsパラメータによって調整することができます。 

� エージェントはデータベースの非活動化によっては解放されません。num_initagentsおよびnum_poolagentsによって保 

持されているエージェントはdb2stopによって解放されます。 

� WAS等のアプリケーションサーバーを使用し、接続プールなどの機能によって接続数が固定されている場合、パフォー 

マンスにあまり影響を与えませんが、接続・切断を繰り返すようなアプリケーションが存在する場合は、応答時間およ 

V9.5 

V9.5 

びサーバー負荷に大きな影響を与えるため、調整する必要があります。 

� V9.5では、NUM_POOLAGENTSの意味合いが変更されました。 

– V8,V9.1:アクティブなエージェントとプールされるエージェントの合計数をNUM_POOLAGENTSとして設定 

– V9.5:プールされるエージェントの最大数を設定 

� MAXAGENTSパラメーターはV9.5で廃止されました。クライアントアプリケーションの最大数を制限したい場合は、 

MAX_CONNECTIONSで制限をかけます。 

� DB2ではSMPサーバーのCPUを効果的に利用する為、intra_parallelの機能がありますが、これをONにした場合、エー 

ジェントの数は接続数×並列度まで増加することになります。Intra_parallelはクライアント数が多いオンライントランザク 

ション系のサーバーでは使用しないことが推奨されています。 

� エージェントによって使用されるメモリー容量を見積もる場合、最低限1.5MB/接続、大きい場合(複雑なSQL等を実行 

する場合)では32MB/接続まで実メモリーの空き容量を見積もる必要があります。


解説 


174 


� その他 

� applheapsz 

� 複雑なSQL文の実行 

より複雑なSQL文を処理する場合、アプリケーション・ヒープ(applheapsz)およびステートメント・ヒープ(stmtheap)が不 

足する可能性があります。 

特に、アプリケーション・ヒープは、Websphere Application ServerのPrepared Statement Cacheのように1つの接続上 

でステートメントを複数同時に実行するような場合に、大きくする必要があります。ただし、applheapszはデフォルトの 

128ページでは不足するケースがよくありますが、512または1024ページを指定すれば、かなり複雑なSQL文を処理で 

き、ほとんどのケースでは十分なはずです。 

V9.5 V9.5では、このパラメーターの意味合いが変更されています。以前の1つの接続のために設定されるパラメーターでは 

なく、アプリケーション全体で消費されるアプリケーションメモリーの総量に変更になりました。 

V9.5 

� アプリケーション・ヒープ不足 

もし、あなたが担当しているシステムで、applheapszに10MBを超えるような値(2500ページ以上)にしないと、「アプリ 

ケーション・ヒープ不足です」というエラーが発生する場合、そこで動作しているアプリケーション・プログラムが宣言し 

て使った資源(ステートメント・ハンドルなど)を確実にクローズしているかを確認してください。 

そのような接続上にゴミを残すようなアプリケーションを動かしている場合、applheapszを極端に大きな値にしなければ、 

動かしている途中でエラーが発生します。 

� applheapszを大きくするということは、その接続数分だけメモリ上にゴミが残るということになります。そのようなシステ 

ムでは、長時間の連続稼働によって、メモリの使用量が増加し、システムが不安定になる場合があります。 

そのようなケースでは、アプリケーション・ヒープを増やして対応せずに、アプリケーション・プログラムを直して、接続上 

にゴミを残さないようにしてください。 

� dbheap 

� バッファプールを大きくするとデータベースヒープが不足する場合があります。この場合、データベースヒープも大きく 

する必要があります。 

� データベース・ヒープにはログ・バッファー、カタログ・キャッシュ(V8では別)が含まれます。これらを大きくする場合も 

データベース・ヒープを大きくする必要があります。 

� intra_parallel 

� このパラメータは情報系のシステムの為のものなので、OLTP系のシステムではデフォルトのOFFのままにし、YESに 

設定しないようにしてください。 

� maxfilop 

� このパラメーターは、データベースに対して同時に開くことのできるファイル・ハンドルの最大数を表すように 

変更されました。 

� 以前のリリースでは、各データベース・エージェントに対して、同時に開くことのできるファイル・ハンドルの最 

大数を示していました。



175 


自己チューニングメモリー(Self Tuning Memory Manager) 

�DB2が自動的にメモリーチューニングを実施 

� 管理者がメモリーチューニングを実施する必要なし 

� 予期しないワークロードを検知し、必要に応じてチューニング 

� メモリーの再分配を必要とするワークロードの変化に対応 

� メモリーチューニングに労する時間を節約可能 

� 情報収集→分析→設定→テスト→情報収集・・・・ 

�対象 � データベース構成パラメーター 

� SORTHEAP 

� SHEAPTHRES_SHR 

� LOCKLIST(MAXLOCKS) 

� PCKCACHESZ 

� DATABASE_MEMORY 

� バッファープール 

�データベース構成パラメーターSELF_TUNING_MEMにて設定 

� デフォルト値はON(=STMM稼動) 

� この値をOFFに設定することで、下位パラメーターがAUTOMATICに設定されてい 

てもSTMMは停止 

�検証段階でSTMMを稼動させ、最適な設定値になった時点で、STMM 

を停止する、という使い方も可能


解説: 


176 


� V9の新機能であるメモリーの自己チューニング機能(STMM)を使用すると、DB2によって自動的にメ 

モリー･チューニングが行われます。 

� STMMは、ワークロードの大きな変化に対応し、構成パラメーターの値およびバッファー・プールのサ 

イズを調整してパフォーマンスを最適化します。 

� 対象となるメモリー領域は以下の通りです。 

� SORTHEAP 

� SHEAPTHRES_SHR 

� LOCKLIST(MAXLOCKS) 

� PCKCACHESZ 

� DATABASE_MEMORY 

� バッファープール


STMM使用時のDATABASE_MEMORY設定方法 


177 


�DATABASE_MEMORY=AUTOMATIC(デフォルト) 

� 必要に応じてOSよりメモリー取得、解放を行いチューニングを行う 

� STMMが増加すべきと判断した場合、メモリーを無制限に割り当てる 

� DB2_MEM_TUNING_RANGEで設定したminfreeの値を残す 

� DB2_PINNED_BP=YES, DB2_LARGE_PAGE_MEM=DB設定時は、 

AUTOMATIC指定不可 

� AIX(64bit), Windows(32bit & 64bit)のみで設定可能 

�DATABASE_MEMORY=数値 

� 指定した数値の範囲内で、メモリーチューニングを行う 

�DATABASE_MEMORY=COMPUTED 

� STMMは稼動しない 

� V8のAUTOMATICの動作 

� DB起動時の各パラメーターの初期値に基づき総容量を算出 

� V8からの移行時は、設定値AUTOMATICは、COMPUTEDに変更され 

る 

� AIX, Windows以外のOSのデフォルト値



178 


STMM使用時のDATABASE_MEMORY設定方法(続き) 

�DB2_MEM_TUNING_RANGEレジストリー変数 

�AUTOMATIC設定時、フリーメモリーを一定量確保し、それ以外のメモリー 

を使用 

�確保するメモリー量の設定方法 

�db2set DB2_MEM_TUNING_RANGE =minfree, maxfree 

�minfree、maxfreeを定義 

�AIX, Windows環境のみ適用可能 

�設定値と意味 

�minfree 

�インスタンスが追加メモリーを必要としたときに、”minfree”で指定された%に達 

するまでシステムの空き物理メモリーを割り振る 

�maxfree 

�インスタンスはフリーにしておく物理メモリー量を”maxfree”で指定された%で 

維持する 

�未設定(デフォルト) 

�DB2が物理メモリー量より算出 

�注意 �STMM = ON & DATABASE_MEMORY = AUTOMATICの環境で、空き物理メモ 

リー量不足の問題が起きていなければ、特にチューニングに必要なし


解説: 


179 


� チューナーは、database_memory 構成パラメーターによって定義されたメモリー制限内で作動します。 

Windows® および AIX® 上では、database_memory の値自体を自動的に調整することができます。 

database_memory のセルフチューニングが使用可能である (AUTOMATIC に設定されている) 場合、 

チューナーはデータベースの全体的なメモリー要件を判別し、現在のデータベース要求量に従って 

データベース共用メモリーに割り振られるメモリーの量を増減します。たとえば、現行データベース要 

求量が高く、システムに十分の空きメモリーがある場合、さらに多くのメモリーがデータベース共用メ 

モリーによって消費されます。データベース・メモリー要求量が下げられるか、またはシステムの空き 

メモリー量が過度に減ると、データベース共用メモリーの一部が解放されます。 

� database_memory パラメーターが自己チューニングで使用できない (AUTOMATIC に設定されていな 

い) 場合、データベース全体は指定されたメモリー量を使用し、必要に応じてデータベースのメモリー・ 

コンシューマー間でそれを分配します。 database_memory が自己チューニングで使用できない場合、 

データベースによって使用されるメモリーの量は 2 つの方法 (database_memory を数値に設定するか、 

COMPUTED に設定する) で指定できます。 COMPUTEDは、V8以前のAUTOMATICに相当し、メモ 

リーの合計量は、データベース起動時のデータベース・メモリー・ヒープの初期値の合計に基づいて 

計算されます。




180 



STMM使用時のその他のパラメーター設定方法 


181 


�LOCKLIST, PCKCACHESZ, SORTHEAP, 

xxxは各パラメーター名 

SHEAPTHRES_SHR 

yyは設定値 

� 現在の設定値からチューニングを開始 

� db2 update db cfg for DB using xxx automatic 

� 設定値をyyに変更し、その値からチューニングを開始 

� db2 update db cfg for DB using xxx yy automatic 

� 現在の設定値でチューニングを停止 

� db2 update db cfg for DB using xxx manual 

� 設定値をyyに変更し、その値でチューニングを停止 

� db2 update db cfg for DB using xxx yy


バージョンによるソートの違い 


182 


�V8.2までのソート 

� プライベートソートの場合(エージェントプライベートメモリーを使用) 

� SORTHEAP(DB CFG) & SHEAPTHRES(DBM CFG)で設定 

� 専用ソートによって使用されるメモリーの合計量におけるソフトリミット 

� 共有ソートの場合(データベース共有メモリーを使用) 

� SORTHEAP(DB CFG) & SHEAPTHRES_SHR(DB CFG)で設定 

– SHEAPTHRES_SHR=0の場合、SHEAPTHRESの値が使用される 

� SHEAPTHRES_SHRは1時点にソート用として使用できるデータベース共有メモ 

リーの合計量に対するハードリミット 

� 条件 

– intra_parallel=yes 

– max_connections > max_cordagents 

�V9.1からのソート 

� すべてのソートはデータベース共有メモリーを使用 

� SORTHEAP(DB CFG) & SHEAPTHRES_SHR(DB CFG)で設定 

– デフォルトでSHEAPTHRES(DBM CFG)=0 

– SORTHEAP, SHEAPTHRES_SHRの自動チューニングはSHEAPTHRES=0 

の場合のみ可能 

� データベース共有メモリーの合計量に対するソフトリミット 

� SHEAPTHRES > 0と設定することで、V8.2のメモリーモデルを使用可能


STMM使用時のバッファープールサイズ設定方法 

�作成 

� バッファープールサイズを指定し作成、その値からSTMMによる 

チューニング開始 

� db2 create bufferpool BPNAME (immediate/deferred) size yy automatic 

– yyは初期サイズ 

� バッファープールを作成し、STMMによるチューニング開始 

サイズ未指定でバッファープールを作成すると、1000ページで作成 

� db2 create bufferpool BPNAME (immediate/deferred) 

� db2 create bufferpool BPNAME (immediate/deferred) size automatic 

�変更 

� 設定値をyyに変更し、その値からチューニングを開始 

� db2 alter bufferpool BPNAME (immediate/deferred) size yy automatic 

� 現在の設定値からチューニングを開始 

� db2 alter bufferpool BPNAME (immediate/deferred) size automatic 

� 設定値をyyに変更し、その値でチューニングを停止 

� db2 alter bufferpool BPNAME size yy 


183 





184 




�データベース構築に必要なシェル/コマンド 


185 





186 



データベース構築に必要なシェル/コマンド 

�以下のような操作を行うシェルやコマンドを用意する 

� 論理ボリューム,ファイルシステムの作成、権限の変更 

� OS上の操作でDB2が使用する資源を準備する 

AIX Volume Group(VG) Physical Volume(PV) Logical Volume(LV) 

Veritas Disk Group(DG) subdisk volume 

plex(ストライプ時など) 


187 


� WindowsではファイルDMSが一般的


解説 

� 論理ボリューム・ファイルシステム作成、権限の変更 

� AIXの例 

論理ボリューム作成 mklv -y lv_name vg_name pp数 hdiskxx 

ローデバイス用論理ボリュームの権限変更 chown user:group /dev/rlv_name 

ファイルシステム作成 crfs -v jfs -m /mount_point -l lv_name -A yes 

� データベース作成例(/databaseをDBのホーム・ディレクトリとして作成) 

� db2 create database DB_NAME on /database 

� バッファプール作成例(100MB) 

� db2 create BP01 size 25000 pagesize 4K not extended storage 

� 表スペース作成例(DMS Raw Device) 

� db2 "create tablespace TBS_NAME managed by database using (device '/dev/rlv_name1' 

1G,device '/dev/rlv_name2' 1G) extentsize 32 prefetchsize 64 bufferpool bp01" 


188 



OS特有の設定 


189 


�AIX 

� AIO(非同期I/O) 

� V8以降、設定は必須(ページクリーナーが使用) 

– db2_installを使用してDB2を導入する場合は、手動で設定する必要があ 

る。(db2setupを使用すると、導入時に自動設定される。) 

� 最大サーバー数の目安 = 物理ディスクの数 × 10 

� vmtune(AIX5.1以前), vmo(AIX5.2以降) 

� JFSのファイルキャッシュを抑えるために使用(minperm,maxperm) 

� JFS2の場合、maxclient(ハードリミット)によって制限 

�Linux 


� V8.2.2では、レジストリー変数DB2LINUXAIOにて設定。 

– db2set DB2LINUXAIO=true 

� V9では、デフォルトで使用可能。(明示的な設定は不要。) 

– レジストリー変数DB2LINUXAIOは、V9では推奨されない。(将来削除 

される予定。)


解説 


190 


� AIX � AIO(非同期I/O) 

� DB2 V8以降では、非同期I/Oを使用します。その為、OS上では非同期I/Oが使用可能になっている 

必要があります。 

� 非同期I/Oの最大サーバー数は、デフォルトでは10となっていますが、ディスク数の10倍を目安にしま 

す。 

� 最小サーバー数はデフォルトの1のままで問題ありません。 

� vmtune,vmo(AIX5.2) 

� maxperm,minpermによってJFSキャッシュのサイズを調整することができます。デフォルトの設定は 

80%,20%ですが、データベース専用サーバーでは通常20%,20%の様な設定が多く使われています。 

� また、LOADなどに対する入力ファイルのI/Oのために、minpgahead,maxpgaheadの数を増やすと、パ 

フォーマンスに対する効果が期待できます。 

� Linux 


� V8.2.2では、Linuxで非同期I/Oを使用可能にするために、DB2LINUXAIOレジストリー変数を使用していました 

が、V9.1ではデフォルトで使用可能になりました。V9ではこの変数は必要ではなくなったため、将来のリリー 

スで廃止される可能性があります。

hUZ6T

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?