データベース物理設計【DB2 9.5 対応版】 - IBM...DB2デザイン・ガイドデータベース物理設計 ©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株)

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

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

データベース物理設計【DB2 9.5 対応版】

＜第１．００版２０１０年１０月＞

データベース物理設計DB2デザイン・ガイド

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

ブランク・ページです



目次

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

①表／索引定義の作成②データ容量の見積もり③インスタンスの構成とデータベースの分割④表の分類と表スペースの構成⑤表スペースの配置⑥表スペース以外のオブジェクトの配置⑦構成パラメーターの設定⑧シェル／コマンドの作成

OS特有の設定






物理設計の流れ

②データ容量の見積もり

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

・ページ・サイズの決定

・表、（索引）サイズの見積もり

①表／索引定義の作成

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

・主キー（１次索引）

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

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

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

⑤表スペースの配置

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

・コンテナーの設計

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

⑥表スペース以外のオブジェクトの配置・ログ、バックアップ用、ワークスペースの配置

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

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

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

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



解説

データベースの物理設計を行う場合、ディスクおよびサーバーを含むハードウェア構成が決まっている必要があります。また、表の論理設計も既に終了していることが前提です。表の論理設計を実際のハードウェア上にどのように構築するかを決定することが、「物理設計」ということになります。純粋な論理設計では、まだどのデータベース製品を使うかにはあまり依存しません。しかし、どのようにディスク上に配置し、メモリを割り振るかを決定する物理設計はデータベース製品に特化した作業になります。

①DBMSに特化しない論理設計では、カラムの属性・長さなどが決まりません。物理設計の初にまずこれらのDBMSに特化した表定義を決定します。例えば、データは日付なのですが、格納方法はDATEにするかTIMESTAMP,CHARまたはVARCHARにするかなどの選択肢があります。

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

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

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

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

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

⑧ 後に行うのは、これらの設計に基づいたファイルシステムや論理ボリュームなどを作成するシェル・スクリプトの作成と、これらの上に表スペースおよび表、索引を作成するDDLの作成です。

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



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

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

論理データベース仕様の後からの変更は困難アプリケーション開発作業に多大な手戻りを発生させる可能性がある

論理設計で決めた表をDB2データベースの表として定義作成したデータベース仕様をシステム上の物理記憶域にマッピングDB2の製品仕様に依存する作業であるため、DB2の製品知識が必要使用するオペレーティング・システム毎の知識も要求される

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

時代の変化に伴う多様な要求の出現に対応できる安定したデータベースを構築する各種要件（アプリケーション、性能、運用等）を適に実装するデータベースを検討する

運用設計、障害回復設計とも同期を取りながら進めて行くパフォーマンス・チューニングや運用の効率化のため適宜物理設計の見直しも必要

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



解説

物理設計作業開始にあたっては、論理データベース設計作業がきちんと完了していることが必要です。論理設計完了後の変更は、アプリケーション開発作業に多大な手戻りを発生させる可能性があります。物理設計作業は、表の論理設計で決められた表を、DB2のデータベースの表として定義することです。実際に、物理記憶域のどこにどのように表スペースや表、索引といった各オブジェクトを配置するかのマッピングを行ないます（論理設計で作られた論理モデルの｢実装｣を行なうことになります。）DB2の製品仕様に依存する作業であるため、DB2の製品知識が必要とされます。また、ファイル・システムなど使用するオペレーティング・システム毎の知識が要求されることもあります。

データベースの設計の目標となるのは、自分の環境を、理解しやすくしかも将来の拡張の基礎となるよう表現したものを作ることです。また、データの一貫性や整合性を保ちやすいデータベース設計が望ましいと言えます。そのためには、設計の段階で冗長性を少なくし、データベースの更新時に生じ得る異常をなくす必要があります。また、アプリケーション要件や、性能、運用要件等を適に実装するものでなければいけません。運用設計、障害回復設計とも同期を取りながら進めて行く必要があります。データベースの設計は、一度で終了するものではありません。多くの場合、何度かやり直すことが必要になります。パフォーマンス・チューニングや運用の効率化のため適宜物理設計の見直しも必要になるのです。



①表／索引定義の作成

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

主キーと外部キー制約

固有制約参照制約表検査制約

表の設計索引の設計



解説

表、および索引定義の作成にあたっては、事前にDBMSに特化した仕様を考慮して、様々な項目を決定する必要があります。ページサイズは、データの容量やディスク容量、DB2の制限値を考慮して、適切なものを決定します。主に以下のような点について、DBMSに特化した表定義を決定していきます。

列の設計（データ・タイプと長さなど）主キーと外部キー制約

固有制約参照制約表検査制約

索引設計（１次、２次）

変更により適用業務に大きな影響を与えるものとして、例えば以下のものがあります。（V9では、以下の変更はALTER TABLEステートメントで行うことができます。）

データ・タイプの変更データの長さの変更NOT NULL指定の変更

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

CATALOG DATABASEで別名設定表名の変更

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

視点の作成により対応列の順序変更

視点の作成により対応



列の設計

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

開発言語環境による生産性の観点での考慮なども必要文字列（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のための２０バイトが行データ中にとられる。上限値にほとんど差異はない。LONG VARCHAR,LONG VARGRAPHICよりも、VARCHAR,VARGRAPHICを使用する。LOBについても、他の表データとは別の場所に保管され、各列の情報（ポインター）のみを他データと共に持つデータが4KB以下の場合、LONGはなるべく使用しない

拡張マークアップ言語（XML）XML文書を格納する。単一パーティションで、コード・セットUTF-8のデータベースの場合のみ使用可能。

V9.5



解説

数値・文字列（固定長・可変長）・日付・XMLなどのうちどれを選択するか、データ長や、とり得る値の制限値により適したデータ・タイプを選択します。また、開発言語環境によって扱い易いデータ・タイプであるのか、生産性の観点などからの考慮も必要です。

文字列可変長か固定長か決定する必要がありますが、まずは固定長を検討します。可変長の場合は、長さとオフセット情報を入れる領域が列あたり4バイト分余計に必要になります。可変長の場合は、該当列の位置は先頭からたどらなければならないため、CPUの負荷が該当列の位置がわかっている固定長よりも余計にかかります。列長の差が大きい（列あたり平均２０バイト以上）時には可変長を採用することで、DISKスペースは削減されます。GRAPHICはダブルバイト文字列のためのものですが、主にホスト系（EBCDIC）環境のDBとの互換のために使用されます。

日付／時刻のデータ日付計算、時間計算、関数の使用が可能になるように、DATE/TIME/TIMESTAMPを使用してください。また、その方が、CHARデータタイプとして格納するよりもDISKスペースは軽減されます。

数値算術に使用するのであれば、通常は数値型で格納すべきです。該当の項目の大取り得る値によって、データ・タイプを選択します。また、文字列で格納するよりもDISKスペースは軽減されます。

LONG型LONGタイプは表データ・ページに実際の列のデータは含まれません。別の表オブジェクトとして表スペースに格納されます。行データ中にはそれらの列の２０バイトの記述子（descriptor）は含まれます。LONGタイプのデータをLONG専用の表スペースに格納させることも、CREATE TABLE時の指定で可能です。４KB以下の文字データについては、上述のような特異な扱いを避けるためにもLONGタイプは使用しないようにするなど、データ長の制限値により、適したデータタイプを選択してください。

XMLXML文書は、階層構造を持つデータとして格納されます。LOB 列と同様に、XML列は列の記述子であるXMLデータ指定子（XDS）のみを保持します。XMLデータ自体は、別個にXDAと呼ばれるストレージ構造保管されます。XML文書のサイズの上限は、2GBです。



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

Extensible Markup

Language

符号付数値ストリング日付/時刻

日付タイム・

スタンプ時刻

可変長固定長可変長固定長

文字グラフィック可変長

バイナリー

倍精度単精度

浮動

小数点数

概算値正確な値

パック

６４ビット３２ビット１６ビット

１０進２進整数

XML

TIME TIMESTAMP DATE

BLOB

CHAR GRAPHIC

VARCHAR CLOB VARGRAPHIC DBCLOB

SMALLINT INTEGER BIGINT

DECIMAL

REAL DOUBLE

10進浮動小数点数

DECFLOAT

V9.5




データタイプ説明制限値

CHAR（ｎ）ｎバイトの固定長文字列１＜＝ｎ＜＝２５４

VARCHAR（ｎ）最大ｎバイトの可変長文字列１＜＝ｎ＜＝３２６７２

LONG VARCHAR（ｎ）長可変長文字列最大３２７００バイト

GRAPHIC（ｎ）ｎ文字の固定長漢字ストリング１＜＝ｎ＜＝１２７

VARGRAPHIC（ｎ）最大ｎ文字の可変長漢字ストリング１＜＝ｎ＜＝１６３３６

LONG VARGRAPHIC 長可変長漢字ストリング最大１６３５０文字

・文字タイプ


SMALLINT 短精度整数－３２７６８～＋３２７６７

INTEGER 長精度整数－２，１４７，４８３，６４８～＋２，１４７，４８３，６４７

BIGINT ６４ビット整数－９，２２３，３７２，０３６，８５４，７７５，８０８～＋９，２２３，３７２，０３６，８５４，７７５，８０７

REAL 単精度浮動小数点数－３．４０２E＋３８～－１．１７５E－３７もしくは１．１７５E－３７～３．４０２E＋３８

DOUBLE、FLOAT 倍精度浮動小数点数－１．７９７６９E＋３０８～－２．２２５E－３０７もしくは２．２２５E－３０７～１．７９７６９E＋３０８

DECIMAL（ｍ、ｎ）、NUMERIC １０進数（精度桁数、小数点以下桁数）１＜＝ｍ＜＝３１、０＜＝ｎ＜＝ｍ

・数値タイプ

・日付／時刻タイプ


DATE 日付０００１－０１－０１～９９９９－１２－３１

TIME 時刻００：００：００～２４：００：００

TIMESTAMP タイム・スタンプ０００１－０１－０１－００．００．００．００００００～９９９９－１２－３１－２４．００．００．００００００

DECFLOAT(16),DECFLOAT(34) １０進浮動小数点数 10-383 ～ 10+384 , 10-6143 ～ 10+6144V9.5





CLOB（ｎ K|M|G）文字ラージ・オブジェクトストリング２，１４７，４８３，６４７バイト

DBCLOB（ｎ K|M|G）２バイト文字ラージ・オブジェクト１，０７３，７４１，８２３文字

BLOB（ｎ K|M|G）２進ラージ・オブジェクト２，１４７，４８３，６４７バイト

・ラージ・オブジェクト

LOBの最大長 LOB Descriptor長

１，０２４７２

８，１９２９６

６５，５３６１２０

５２４，０００１４４

４，１９０，０００１６８

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

・XML


XML XML文書２ギガバイト

LOBの最大長 LOB Descriptor長

１３４，０００，０００２００

５３６，０００，０００２２４

１，０７０，０００，０００２５６

１，４７０，０００，０００２８０

２，１４７，４８３，６４７３１６



参考： Decimal Floating Point

16桁または34桁の大精度を持つ10進浮動小数点数より大きな数、より精度の高い演算が可能

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

Type DECFLOAT(16) DECFLOAT(34)

Size 8 Bytes 16 Bytes

指数範囲 10-383 ～ 10+384 10-6143 ～ 10+6144

精度 16 34

DECFLOAT(16):負の値: -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

V9.5



列の設計（続き）

その他設計上の考慮点NOT NULLの指定

NULL可能にした場合、列毎に１バイトのNULLフラグが必要であり、CPU負荷が増加するNULL標識変数を準備しなければならず、プログラムが煩雑になる

比較、結合、UNIONの処理がある列はデータ・タイプを揃えるデータ変換負荷の軽減

パフォーマンスを考慮した列の順序可変長列は、自動的に全ての固定長列の後ろに配置される更新される列は可能であれば近くに並べる適用業務には列の指定順序は影響しない（順序にこだわる場合、視点(View)で対応も可）

圧縮効率を考慮した列の順序データ行圧縮を使用する場合、複数列に跨って繰り返されるパターンのデータがあれば、それらの列は隣接して並べる（圧縮効果が高くなる）

VARCHAR列：適当なデータ・タイプかどうか要検討読み取りに２ステップ要：長さ→データVARCHAR列への変更：長くなった場合、Tombstoneが発生する場合あり更新がある場合、データのフラグメンテーションを招く ⇒ REORG運用が必要となる可能性が高い

列の自動生成生成列（GENERATED COLUMN）の利用

– 指定されたルールに従い、列の値が動的に生成される列– 列の値を事前に加工して入れておくことにより、SQL実行時のパフォーマンスを向上させる

識別列（IDENTITY COLUMN）の利用– DB2が列の値として、固有の数値を生成する列– 固有の値を取得するために別途表を用意したり、MAX関数を使用して取得したりする必要がない– 行をユニークに識別可能な、列の値を事前に入れておくことにより、識別列を使用した照会処理が可能– シーケンス・オブジェクトの利用も検討



解説

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

列毎に1バイトのNULLフラグが必要NULLか否か調べるCPU負荷の増加NULLフラグによるDISKスペースの増加プログラムではNULL標識変数の準備が必要

比較、結合、UNIONの処理がある列は、列同士のデータタイプをそろえることでデータ変換負荷を軽減させることができます。パフォーマンスを考慮した場合、更新される列は近くに並べて下さい。更新時のログは、先頭の更新列から、後の更新列まで取得される為、更新列が離れているとログデータが増加します。

update testtab set c5=50 ・・・・・・・・・ログは、c5のみupdate testtab set c3=20, c9=90 ・・・ログはc3～c9までただし、可変長列でその列長が変更されるような更新がおこなわれた場合、行全体（新旧）がログとして取得されます。

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

C1 C2 C3 C4 C5 C6 C7 C8 C9 C10

LL VARCHAR CHAR INTEGER

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

CHAR INTEGER LL VARCHAR

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



解説

データ行圧縮を使用する場合、複数列に跨って特定のパターンの値が繰り返されるようなデータがあれば、それらの列を続けて定義すると圧縮効率が良くなります。

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

圧縮後

圧縮前

……

Plano, TX, 24355

02

50001

……

Plano, TX, 24355

02

50001

24355TXPlano10000500Fred24355TXPlano20000500John

ZipCodeStateCitySalaryDeptName

24355TXPlano10000500Fred24355TXPlano20000500John

ZipCodeStateCitySalaryDeptName

…24355TXPlano20000500John24355TXPlano10000500Fred …24355TXPlano20000500John24355TXPlano10000500Fred

…(02)20000(01)John(02)10000(01)Fred …(02)20000(01)John(02)10000(01)Fred

Dictionary



解説

VARCHAR/VARGRAPHIC列を使用する場合には、可変長であるメリットとデメリットを考慮した上で、使用して下さい。

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

可変長データを読み込む場合、まずデータの長さを読み取り、次にデータをその長さ分読み取るという2段階を経るため、パフォーマンスに影響が出ます。また、可変長データに変更が発生した場合、元データより長くなると同じページに収まらなくなってしまう可能性があります。その場合、移動先の情報を持ったTombstoneが元のデータ位置に残されます。その為、そのレコードを取得するために、ページを2段階経なければならなくなる可能性があります。

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

データの長さの範囲がまちまちで、ほとんどの列は短いデータの長さの範囲がまちまちで、全ての範囲でほぼ均等に分布

VARCHAR列を使うべきでない場合：データの長さの範囲はまちまちだが、ほとんどの列は範囲の上の方にあるVARCHAR列にすることによって、ディスク・スペースが余計にかかり、パフォーマンスが低下するケース

C1 C3 C2Len C2 DataOS0OS1OS2

BPS header

3

Record 1

Record 2

Rec 0

新しいページTombstone



解説（生成列）

生成列とは、各行の値を挿入操作または更新操作からではなく、定義した式によって定めることができる列です。更新トリガーおよび挿入トリガーを組み合わせて使用すると同様のことが行えますが、生成列を使用すると、派生した値が式と一貫したものであることを保証できます。表で特定の式や述部を頻繁に使用することがわかっている場合、生成列を使用してあらかじめ値を生成しておくことにより照会の際のパフォーマンスを向上させることが可能です。表で生成列を作成するには、ALTER TABLEまたはCREATE TABLE時にGENERATED ALWAYS AS 文節を使用して、列の値を定義する式を含んだ列を指定します。生成列には検査制約やユニーク索引/基本キーが使用できない、生成列を持つ表に対してRENAME TABLE ができない等の制約事項があるので使用にあたっては考慮が必要です。生成列の例

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

C1 C2 C3 C4

C1 + C2

C1 > C2 の時は1

それ以外は 0t1表

INSERT t1 (C1, C2)

VALUES (10, 3)

10 3 13 1

10 + 3 = 13

10 > 3 なので1

INSERT

データベース

マネージャーが

値を生成

t1表

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)

);

C1 C2 C3 C4



解説（IDENTITYE列とSEQUENCE）

IDENTITY列（識別列）は生成列の中の一つで、表の各行に対して固有な基本キー値を自動的に生成します。

識別列では、アプリケーションがデータベースの外に独自のカウンターを生成する際に生じる、並行性およびパフォーマンス上の問題を回避することが可能です。固有な基本キーを自動生成する際に識別列を使用しない場合には、単一行の表にカウンターを保管するのが一般的な設計方法です。各トランザクションはこの表をロックして、数を増分してからトランザクションをコミットして、カウンターのロックを解除します。しかし、残念ながら、この設計では、カウンターを増分できるのは一度に 1 つのトランザクションのみです。一方、識別列を使用して基本キーを自動的に生成すると、アプリケーションでより高度なレベルの並行性を実現できます。

SEQUENCE（シーケンス）とは、値の自動生成を可能にするデータベース・オブジェクトです。シーケンスを使用すると、固有キー値を生成することが可能です。IDENTITY列と同様アプリケーションはシーケンスを使用することで、データベースの外部に固有カウンターを生成したことによって発生する可能性のある、並列性およびパフォーマンスの問題を回避することができます。識別列属性とは異なり、シーケンスは特定の表列に関連付けられていないデータベースオブジェクトです。シーケンス・オブジェクトはどのアプリケーションでも使用できるため、NEXTVALおよびPREVALの二つの値を返す式が定められています。

C1 C2 C3 C4

IDENTITY列

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

C1 C2 C3 C4

SEQUENCE

オブジェクト

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

NEXTVAL

IDENTITY列 SEQUENC E

t1表 t1表

create table t1

(c1 int generated always as identity

(start with 10, increment by 2),

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

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



主キーと外部キー

主キー（Primary Key）主キーは表の保全性を保証する

格納されるデータの値は、ユニークでなければならないNOT NULL指定必須

主キーを付与するとユニーク索引（１次索引）は自動的に作成される（固有制約）参照制約を使用しない場合は基本キーではなく、別途ユニーク索引を定義しても可

外部キー（Foreign Key）親表と従属表の間の親子関係を示す働きをする

別の表の主キーが、その表のデータ項目になっている時、そのキーは外部キーとなりうる結合操作の結合列になる ⇒ 索引の候補外部キーは参照の整合性を保証するために、主キーに存在しない値を持ってはいけない（参照制約）参照制約を使用しない場合、あくまでも論理的なものであって、物理定義する必要はない

定義時には、CONSTRAINTにより制約名をつける管理が容易

部門番号部門名

１００営業部

２００電算部

３００総務部

＜部門表＞

社員番号社員名部門番号

A111 田中１００

B222 山田２００

C333 鈴木２００

＜社員表＞

外部キー

主キー



解説

主キー表の固有キーとは、それぞれの値が固有の行を識別する、１つの列または複数の列の順序集合のことです。たとえば、社員番号の列の各値は一人の社員だけを指すものなので、これを固有キーとして定義することができます。二人の社員が同じ社員番号を共有することはできません。表の主キーは、１つの表上に定義された固有キーの１つですが、その表上で1番目に重要なキーとして選択されたものです。１つの表上には１つだけの基本キーが可能で、そのエンティティ内で行を唯一無二のものとして識別できるデータ項目です。主キーはエンティティの保全性を保証するために、ユニークであり、空白値は許されません。

外部キー表の外部キーは、親表の固有キーまたは主キーを参照する、表内の１つの列または1組の列のことです。外部キーは表（親表）と表（従属表）の間の参照の整合性を保証するために、基本キーに存在しない値を持ってはならず、結合操作時には結合列になります。

参照制約を使用しないのであれば、親表と従属表の間の親子関係を示すあくまでも論理的な意味合いのものであり、主キーと外部キーの物理的な設定は必須ではありません。

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

CREATE TABLE 親表名（主キー列名・・・ NOT NULL,・・・・・・・,・・・・・・・,CONSTRAINT 制約名 PRIMARY KEY（主キー列名))

外部キーの定義CREATE TABLE 従属表名（・・・・・・・,外部キー列名・・・ NOT NULL,・・・・・・・,CONSTRAINT 制約名 FOREIGN KEY（外部キー列名)REFERENCES 親表名ON DELETE 規則)



制約

データの保護や、データ間の相互関係の定義をDBMSに行わせるアプリケーション・ロジックとしてコードを作成する必要がない

事前に制約を使用するか否かの方針決めが必要使用する場合は、制約違反エラーのハンドリング・ロジックが必要

データ格納時にDB2により厳格にチェックされるバッチによる大量の更新時や、テスト環境でのテスト・データ作成時に、格納順番やデータの値を考慮する必要あり

３種類の制約を提供固有制約

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

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

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

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

col1 col2

1 A1

1INSERT

固有？

col1 col2

1 A1

c1

A1

A2'A3'INSERT

親表に存在する？

col3 col2

10 A1

20INSERT

col3 < 20？



解説

制約を利用すると、データの保護や、データ間の相互関係の定義をデータベース・システムに行わせることが可能です。これにより、アプリケーションでコードを作成し、これらの規則を施行する必要がなくなります。事前に制約を使用するか否かの方針決めを初に確定させる必要があり、使用するのであれば、制約違反エラーのハンドリング・ロジックは必要となります。データ格納時に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文を使用して、表の列に対して定義します。



解説

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

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

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

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

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

create table t1 (col1 int not null,

col2 char(10) not null,

col3 int,

constraint t1_uniq UNIQUE (col1))



col3 int,

constraint col3check CHECK (col3 < 20));



col3 int,

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






表の設計

1行のレコードがページをまたがることはできないLONGデータを除く

適なページ・サイズの決定（4KB/8KB/16KB/32KB）

行の削除によるスペース解放はない削除してもDiskの使用率は変わらない再利用はされる

APPENDモードの指定により再利用させないことも可能REORGなどの運用が必要

ページの空き領域の設定予め、ページ内にフリー・スペースを残す設定設定が必要か否かの検討が必要

離れたページにデータが挿入されると、パフォーマンスに影響を与える– クラスター索引を持つ表– 可変長列の更新がある表

ALTER TABLEによるPCTFREE指定LOAD、REORG時に指定されたフリー・スペースを確保



解説

1行のレコードが複数のページにまたがることはできません。1レコードの長さがページ内に収まらない場合は、ページサイズを大きくして下さい。

4KB → 8KB → 16KB → 32KB

データの削除が行われたとき、そのレコードのあった場所は解放されません。(再利用はされます。)削除のフラグが立つのみです。Diskの使用率は変わりません。削除されたスペースを解放させるためには、reorg tableを実行して下さい。

APPENDモードINSERT時に表内の空きページを検索することなく、終ページにレコードを追加する機能。（APPENDモード ON）レコードが単調増加していく特性の表にINSERTする場合、パフォーマンスが向上しますが、DELETEによる削除レコードの空き領域は再利用されないため、別途、表自体の再作成（もしくは、0件）、または再編成などの運用により、表容量を適正に保つ仕組みの検討が必要とななります。クラスター索引のある表には適用不可。

ページの空き領域(PCTFREE）離れたページにデータが挿入されると、パフォーマンスに影響を与える為、予めページ内にフリー・スペースを残す様に設定することができます。ALTER TABLE 表名 PCTFREE 数値

PCTFREE：0～99 (デフォルト:-1)データのロード、およびREORG TABLE時に、指定されたサイズのフリー・スペースをページ内に残します。

PCTFREEの設定が必要な例クラスター索引を持つ表（データの挿入時に、索引順とデータの並び順を同じにするようにデータを格納しようと試みる）に対して、業務上の観点から、データの追加、削除処理の頻度にも留意し、ページの空き領域（ＰＣＴＦＲＥＥ）の設定の検討が必要です。データの挿入が多い場合、索引順序にデータを配置しようとしても、ページ内に収まらない場合があります。また、可変長の属性の列項目を持つ表において、その列項目に対して更新がある場合、空き領域を設けることを検討する。オンライン中の更新がない、または、クラスター索引を持たない列項目の属性が固定長のみで定義されている表については、空き容量は特に必要ありません。



ページ・サイズの決定

表を格納するページサイズを決定するデータの行長・カラム数の制限表容量の制限

LARGE RID（V9）が使用可能な表スペース（LARGE DMS表スペース、一時表スペース）の場合、制限値が異なる。（下表参照。）

格納効率も考慮する必要があるLARGE RIDを使用しない表スペースでは、ページ・サイズにかかわらず１ページに格納できる行数は大255行まで。LARGE RIDを使用する表スペースでは、1ページに255行以上格納可能。（下表参照。）

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

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

表の分割、パーティション表（V9）も検討するUNION ALL VIEWに対する参照（V6,V7でも可）UNION ALL VIEWに対する更新、INSERTも可（V8）パーティション表（V9）

ページ・サイズ

行長（bytes）

列数非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



解説

ページ・サイズ表に必要となるディスク容量を計算する時に、どのページサイズを使用するかが非常に重要な要素になります。DB2では、4K/8K/16K/32Kバイトの４種類のページサイズをサポートします。1行のレコードが複数のページにまたがることはできません。1レコードの長さがページ内に収まらない場合は、ページサイズを大きくして下さい。

表の大容量の制限V8までは、表の大容量は64/128/256/512GB(それぞれのページサイズは4/8/16/32KB)でしたが、V9以降では、LARGE RIDを使用することにより、大容量が2/4/8/16TB (ページサイズは4/8/16/32KB)に拡張されました。

格納効率LARGE RIDを使用しない表スペースの場合、１ページに格納できるのは大255行までという制限があります。１行のサイズが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

初期表スペースSYSCATSPACE, TEMPSPACE1, USERSPACE1、デフォルト・バッファープールIBMDEFAULTBPは、データベース作成時に指定されたページ・サイズで作成される。

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

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

バッファープールに読まれるときの領域の無駄– 特に、データにランダムにアクセスするOLTPアプリケーションの場合

1ページあたりの行数の制限– ページ・サイズに関わらず255行まで

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






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

UNION ALLビューとは複数の結果表を組み合わせて新たな結果表として定義されたViewUNION ALLを指定すると結果は該当表のすべての行から構成される

表分割の目的表スペースサイズの制限による分割履歴データ等のレンジ・パーティションを実現データ削除を分割された表単位のIMPORT REPLACEなどで実行できるREORGなどの運用を表毎に個別に行える

VIEW定義の方法CREATE VIEW文中のSELECT文で、WHERE文節によって値を制限

このVIEWに対するINSERTは不可表に対するCONSTRAINTによって値を制限

INSERTを使うためにはCONSTRAINTが必要（V8以降）



解説

ORDER MONT H

ITEM

2003-01-01 1 ｘｘｘｘ

2003-02-01 2 ｘｘｘｘ

2003-03-01 3 xxxx

ORDER MONTH ITEM

2003-01-01 1 ｘｘｘｘ

2003-02-01 2 ｘｘｘｘ

2003-03-01 3 ｘｘｘｘ

2003-04-01 4 xxxx

2003-05-01 5 ｘｘｘｘ

2003-06-01 6 ｘｘｘｘ

2003-07-01 7 ｘｘｘｘ

2003-08-01 8 ｘｘｘｘ

2003-09-01 9 ｘｘｘｘ

2003-10-01 10 ｘｘｘｘ

2003-11-01 11 ｘｘｘｘ

2003-12-01 12 ｘｘｘｘ

ビュー VIEW_YEAR

CREATE VIEW VIEW_YEAR(order, month,item) AS SELECT * FROM Q1

UNION ALLSELECT * FROM Q2UNION ALLSELECT * FROM Q3UNION ALL SELECT * FROM Q4;ORDER MONT

HITEM

2003-04-01 4 ｘｘｘｘ

2003-05-01 5 ｘｘｘｘ

2003-06-01 6 xxxx

ORDER MONT H

ITEM

2003-07-01 7 ｘｘｘｘ

2003-08-01 8 ｘｘｘｘ

2003-09-01 9 xxxx

ORDER MONT H

ITEM

2003-10-01 10 ｘｘｘｘ

2003-11-01 11 ｘｘｘｘ2003-12-01 12 xxxx

表 Q1

表 Q4

表 Q3

表 Q2

CREATE TABLE Q1(order DATE,month SMALLINT,item VARCHAR(10));ALTER TABLE Q1 ADD CONSTRAINT q1ckc1 CHECK (MONTH BETWEEN 1 AND 3);

CREATE TABLE Q2(order DATE, month SMALLINT,item VARCHAR(10));ALTER TABLE Q2 ADD CONSTRAINT q2ckc1 CHECK (MONTH BETWEEN 4 AND 6);



UNION ALLビューの例



参考：UNION ALL VIEWによる表分割（続き）

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 allselect * from Q2_2 union allselect * from Q3_2 union allselect * 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)

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

Create Table Q1_1(Order Date,month smallint,item varchar(10));alter table q1_1 add constraint q1chck1 check (MONTH(order) between 1 and 3);




Create view VIEW_YEAR1(order,month,item) as select * from Q1_1 union allselect * from Q2_1 union allselect * from Q3_1 union allselect * 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" FROM ADMINISTRATOR.Q2_1 AS Q3 WHERE (Q3."MONTH" = 1) UNION ALL SELECT Q5."ORDER", Q5."MONTH", Q5."ITEM" FROM ADMINISTRATOR.Q3_1 AS Q5 WHERE (Q5."MONTH" = 1) UNION ALL SELECT Q7."ORDER", Q7."MONTH", Q7."ITEM" FROM ADMINISTRATOR.Q4_1 AS Q7 WHERE (Q7."MONTH" = 1) ) AS Q9



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

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

CREATE TABLEステートメントのPARTITION BY文節で指定されたパーティション・キー列の値に従って、表を複数のパーティションに分割するそれぞれのパーティションは、異なる表スペースにも、同じ表スペース内にも配置することができる

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

履歴表A

JAN01

区分のデタッチ

JAN05

JAN05

区分のアタッチ

JAN01 JAN02 JAN03 JAN04



参考：パーティション表による表分割（続き）

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

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

大規模データベースの実現巨大な表

高速なデータアクセス

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

DBパーティショﾝ0

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

CREATE TABLE T1

( COL1 INT, COL2 DATE )

PARTITION BY RANGE (COL2)

（ STARTING FROM (‘2006-01-01’)

ENDING (‘2006-12-31’)

EVERY (3 MONTH) ）

表 T1

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

データ・パーティショﾝ0






参考：パーティション表による表分割（続き）

パーティション表のメリット1. 保存期間を過ぎた行の高速な削除

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

2. 新規データのオンライン高速ロードあらかじめLOADしておいた表を、既存のパーティション表にアタッチする

3. データアクセスの性能向上指定された条件によって、特定パーティションのみにアクセスする

4. 故障範囲の局所化（各パーティションを異なる表スペースへ配置）各パーティションを異なる表スペースへ配置しておけば、ある表スペースがアクセス不能になっても、その他の表スペースに配置されたパーティションへのアクセスは可能

5. バックアップ性能の向上各パーティションを異なる表スペースへ配置し、並列でバックアップを実行する（BACKUPコマンドのPARALLELISMオプションを使用）






索引の設計

索引の目的照会処理の処理効率を高める

アクセス・パスにおける索引の使用による効率のよいデータへのアクセス行のユニーク性を維持する

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

クラスター索引

設計手順パフォーマンス改善を目的とし、繰り返し行う必要がある索引候補の検討索引数の検討索引候補の取捨選択

索引の物理定義と検証索引が有効に利用され適なアクセスパスになっているか意図した索引を使用しているかメンテナンス負荷を軽減するため、使用されていない場合にはDROPSYSCAT.PACKAGES（静的SQL）、または、EXPLAINツールで確認



解説

表に作成する索引は、本の索引と同様の機能を果たします。索引の第一の目的は、データをアクセスする際の処理効率を向上させることです。余計な入出力をすることなく、短の方法で目的のデータにたどりつくには、索引は非常に有効です。ユニーク索引を作成した際には、索引のキー列のユニーク性を保証する機能を使用可能です。クラスター索引

クラスター索引を作成すると、データの挿入時に、索引順とデータの並び順を同じにするようにデータを格納しようと試みます。データを索引の列項目の値順に読み込む場合、Ｉ／Ｏ回数が軽減され、処理効率が向上します。クラスター索引を作成する場合、データが格納されるページに空きスペースを準備する必要があります。索引の列項目の値が更新される（更新があった場合、索引順に再格納は行わないため、再編成の必要性を検討する必要がある）場合や、検索結果が常に１件となる照会処理が頻繁に行われる場合は、作成してもメリットはありません。

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

主キーや外部キーなどは、データの意味から索引候補として決定可能であるため、外部設計後に可能な作業です。一方、その他の２次索引については、具体的なSQL文を元にアクセス・プランを検討し、候補の洗い出しを行います。

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

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

索引の物理定義と検証索引が有効に活用されているかを確認し、使用されていない場合には、DROPする必要があります。索引が存在することによるメンテナンス負荷を軽減するためです。静的SQLプログラムについては、SYSCAT.PACKAGESで確認できます。また、動的SQLプログラムについては、EXPLAINツールで確認します。



索引候補の検討

ユニーク索引が必要かユニーク性の維持が必要な場合：ユニーク索引参照の整合性が必要な場合：主キー

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

– 索引名： SQL+タイムスタンプ+番号– 索引スキーマ： SYSIBM– CONSTRAINTで制約名をつけると管理が容易

外部キーに索引をつける結合列になる可能性が高い列に索引があると、処理効率は良い

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

結合列探索条件の列

ANDで結ばれた等号述語範囲指定の述語（ＢＥＴＷＥＥＮ，不等号述語）

ソート列（DISTINCT、ORDER BY、GROUP BYで指定された列）索引のみのアクセスを目的とした索引

INCLUDE列つきのユニーク索引



解説

基本的な索引候補まず、ユニーク索引が必要かどうかを検討します。ユニーク性を維持しなければならない列が存在するのであれば、ユニーク索引が必要です。主キーの必要性を検討します。他の表の列と整合性を保たなければならない、マスターとなる列が存在するのであれば、表に主キーを設定します。基本キーの設定は、表の作成（ＣＲＥＡＴＥＴＡＢＬＥ）時に指定するか、または、表の変更（ＡＬＴＥＲＴＡＢＬＥ）で指定します。外部キーがある場合、検索条件の結合列となる可能性が高いため、索引の候補になります。

さらに、その他の２次索引候補を検討します。候補になる列は、条件節での登場回数が多い列です。また、ソートの対象となる列も候補になります。FOREIGN KEY（外部キー）が定義されている列項目レコードの探索条件として、「=」述部に指定されることのも多い列項目、もしくは、初のキーとしての個別の値がも多い列表を結合するときに使用するすべての列

INCLUDE列つきのユニーク索引ユニーク索引の列として、ユニークではない列を含むことが可能目的：索引のみのアクセスによるパフォーマンス向上冗長な索引を作成しない

表にアクセスすることなく、索引のみで照会処理要求を満たすことができます。これをindex-only accessといいます。INCLUDE列を指定してユニーク索引を作成することにより、データページのアクセス頻度が軽減されます。索引キーの一部の列については、ユニーク性を保持するユニークではない列については、ユニーク性の検査が発生しない

作成方法： CREATE UNIQUE INDEX 索引名 ON 表名（列名） INCLUDE (列名）複数列の指定が可能ユニークではない列については、索引順（ASC，DESC）の指定は無効



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

処理するＳＱＬステートメントの例：（employee_idに主キーがある）SELECT employee_id, mgr_id FROM my_employee WHERE employee_id = 78379 ;

INCLUDE列を使用しない例：２つの索引を作成・維持する必要あり１．表の作成

CREATE TABLE my_employee ( employee_id integer not null, mgr_id integer, phone_no integer, hire_date date, PRIMARY KEY (employee_id) );

– DB2は主キーには自動的にユニーク索引を作成する２．索引のみのアクセスのために、索引を作成する

CREATE INDEX col_index ON my_employee (employee_id, mgr_id) ;

INCLUDE列を使用する例：１つの索引だけで INDEX ONLY ACCESS１．表の作成

CREATE TABLE my_employee ( employee_id integer not null, mgr_id integer, phone_no integer, hire_date date) ;

２．INCLUDE列つき索引の作成CREATE UNIQUE INDEX my_index on my_employee (employee_id) INCLUDE (mgr_id) ;

３．主キーの作成ALTER TABLE my_employee add PRIMARY KEY (employee_id);

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



索引候補の取捨選択

索引の作成を避けた方がよい列可変長列

索引のメンテナンスの負荷が高い統計情報のCOLCARDの値が小さい（重複値の多い）列

（例）フラグ（0 or 1）や区分などSYSCA.COLUMNSのCOLCARD列：ユニークな値の数オプティマイザ-が索引を選択しない

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

複合列索引の考慮点複合列索引の全ての列が等号で使用されるものは有効索引列は、も頻繁に等号で指定される列か、もユニーク性の高い列から順に指定する

初の索引列で結果行を大幅に絞り込める索引は使用されやすい完全にマッチングする索引を優先する

（例）索引１（col1,col2,col3) と索引２（col1,col2）がある場合で、条件がcol1=x and col2=x であれば索引２を優先

– 索引２はFULLKEYCARDが有効であり、かつ、キー長が短いのでバッファーヒット率が高い統計情報でFULLKEYCARDが大きいものは有効

SYSCAT.INDEXES（FULLKEYCARD）：列全体でユニークな値の数



索引数の検討

索引数の目安：表あたり５個以下が望ましいむやみに索引を作成することは、ディスクを無駄に消費し、負荷を増やすことになる

オンラインでの更新処理環境：１－２個照会のみの環境：５個以上作成してもよいオンラインの更新処理と照会処理の混在した環境：２－５個

更新処理時には索引のメンテナンスが必要となり、負荷が発生するINSERT処理では、索引列の追加処理が発生DELETE処理では、索引列の削除処理が発生索引列に対するUPDATE処理では、索引列の変更処理索引のスプリット処理

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

その他の負荷クラスター索引がある表へのINSERTは、索引順を極力保持するようにデータを格納するディスク・スペース使用量の増加LOAD、REORG時の索引の再作成の負荷索引の追加によりプログラムのPREPARE時間が増加

静的SQLではＢＩＮＤ時、動的SQLでは実行時の時間が増加する検討すべきアクセスパスの組み合わせが増加する

前方スキャン、逆方向スキャンの両方が必要な場合、ALLOW REVERSE SCANSオプションを指定して索引を作成する（二つの異なる索引を作成する必要はない）

V9以降、新規で作成される主キー、ユニーク・キー、または索引(拡張索引は除く)は、デフォルトでALLOW REVERSE SCANS設定になる。



解説

索引数が増えると、照会のパフォーマンスは向上する可能性がある一方で、索引のメンテナンス負荷が高くなり、更新の際の処理効率が低下します。従って、トランザクションの内容により、索引数を制限して作成する必要があります。複数の索引を作成する前には、ディスク・スペースや処理時間への影響も留意し検討する必要があります。

索引のスプリット処理索引のリーフ・ページが満杯になった時点で、さらにそのページにデータが格納される必要があったとき、索引ページは分割され、２つのリーフ・ページになります。分割されるデータの割合は、満杯になった索引ページが索引構造内でどの場所にあったかにより異なります。

索引ページのフリースペース（PCTFREE）表にランダムにデータをＩＮＳＥＲＴするようなアプリケーションにより、索引のリーフページが頻繁にスプリットされてしまうのを防ぐために有効です。CREATE INDEX ステートメントのオプションです。また、LOAD時にMODIFIED BY INDEXFREESPACE=xにより、再指定することも可能です。フリースペースが確保されるタイミングはLOADおよびREORG時です。

以下の場合には、フリースペースは必要ありません。INSERT,DELETEがない索引キーの更新がなく、固定長列のみなので更新による行のネスティングが発生しない照会のみである

LOADに関する考慮点ＬＯＡＤの前に索引作成を行っておいたほうが、ＬＯＡＤ後に索引を作成した場合と比較すると、合計時間が短くてすみます。また、事前にユニーク索引を作成しておいた場合には、ＬＯＡＤ時にユニーク性の検査が行われます。

ＬＯＡＤの前に索引を作成しておく場合には、索引を作成するための一時領域を確保しておく必要があります。メモリー領域としては、DB構成パラメーターSORTHEAPに設定された容量のソート領域が使用されます。また、ディスク領域としては、一時表スペースが使用されます。



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

索引用の表スペース索引用の表スペースを作成する（DMSのみ）

表データとは別の物理ディスクに配置することによる並列Ｉ／Ｏが期待できる索引だけ早いディスクに格納することができる

索引用の表スペースに対するバッファープールを作成する索引をメモリー上に保持し、バッファーヒットさせたい場合

索引用の表スペースはＤＭＳファイル表スペースにすることも検討？ＡＩＸファイルシステムのキャッシュが使用可能

索引が有効利用され、適なアクセスパスを得るために索引順を維持する

クラスター索引により索引順を維持するREORGにより定期的に索引順を維持するユニーク索引の列による１件検索の場合には、クラスター率が低くても問題はない

ＲＵＮＳＴＡＴＳの実行による統計情報更新とBIND実行実行タイミング

– 表のデータがLOADされ、適切な索引が作成された時– 表のデータがREORGされた時やアプリケーションをBINDする時– 表および索引のデータの10%－20%がUPDATE/DELETE/INSERTされた時

現時点の統計情報に更新することにより、現状で適なアクセス・パスが選択される（動的ＳＱＬの場合）RUNSTATS実行後、BINDを実行する（静的SQLの場合）

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

V9.5



解説

索引データを索引用の表スペースに格納するためには、表の作成（ＣＲＥＡＴＥＴＡＢＬＥ）時に、その表に対して作成された索引のデータをどの表スペースに格納するかを明示的に指定します。

CREATE TABLE 表名 (COL1 INTEGER, .......) IN 表の表スペース名ＩＮＤＥＸＩＮ索引の表スペース名

索引が作成されている索引用の表スペースをDROPすることはできません。DROP時に、関連するデータベース・オブジェクトが存在するためにDROPが不可能である旨のエラー･メッセージが戻されます。この場合、索引を全てDROP後に、表スペースをDROPするか、または、DROP TABLESPACE文で、関連する表スペースを全て指定することにより、表スペースをDROPすることが可能です。

RUNSTATSは、表のデータが大きく変化した場合に、統計情報を新の状態に更新するために実行します。動的SQLは動的にＢＩＮＤを実行するため、ＲＵＮＳＴＡＴＳで統計情報を変更することによりアクセス・パスが変わる可能性があります。静的SQLの場合は、RUNSTATS実行後、より適なアクセス・パスを得るには、BINDを実行する必要があります。ＲＵＮＳＴＡＴＳはＡＮＤＩＮＤＥＸＥＳオプションつきで実行します。また、必要に応じて、WITH DISTRIBUTIONオプションつきで実行し、非一様分布統計情報を収集してみます。



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

索引列の大数と索引キーの大長は、V8以前とV9で異なる。（V9で拡張された。）

バージョンページ・サイズ

索引列の大数索引キーの大長（bytes）

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

V9 4KB 64 1024

8KB 64 2048

16KB 64 4096

32KB 64 8192






②データ容量の見積もり

表/索引の見積もり表スペースの見積もり

カタログ表スペースユーザー表スペース一時表スペース

ログ領域の見積もりアクティブ・ログ領域アーカイブ・ログ領域

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






表／索引の見積もり

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

各表のレコード件数を見積もる上で必要な数値の収集– コード類、マスター類の件数、１日あたりの処理件数– データの保持期間、データ増加率．．．etc.

お客様にAuthorizeされた前提の数値であることが重要– 前提に変更があれば、都度再見積もり可能なようにワークシートにまと

めておく

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



解説

論理設計のアウトプットである表を作成した場合に、どれだけのディスク容量が必要となるかを見積もる必要があります。この容量見積もりは、表に含まれるデータだけではなく、索引のデータも含まれます。後段階でパフォーマンスチューニングを行う際に索引が追加されることも考慮し、索引を作成する表スペースの容量には余裕を持たせる必要があります。

見積もり作業を開始するにあたっては、表や索引の定義が決定していることは言うまでもありませんが、見積もりの基礎となる前提の数値（コード類、マスター類の件数、１日あたりの処理件数、データの保持期間、データ増加率．．．etc）や算定根拠を明確にする必要があります。各表のレコード件数を見積もる上で必要な数値の収集は、お客様にAuthorizeされた前提の数値であることが重要です。前提に変更があれば、都度再見積もりが必要となりますので、再見積もりが容易になるようにワークシートにまとめておきましょう。

データベース・オブジェクトのサイズは、正確に見積もることができません。サイズの見積もりを難しくする原因は、ディスクのフラグメント化によって発生するオーバーヘッド、フリー・スペース、および可変長列の使用などです。これは、列タイプや行の長さが広い範囲で異なる可能性があるためです。まずデータベースのサイズを見積もってから、テスト・データベースを作成し、それに標準的なデータを入れてみてください。



表／索引の見積もり

表容量概算：（論理レコード長＋10）×レコード件数×安全率論理レコード長

各データ項目のデータ・タイプ、桁数から各項目の物理サイズを算出。可変長の場合は、平均長を採用。NULL値を許す場合１バイト、可変長の場合4バイトを各該当の列項目あたり加算すべてを合計したのが1行あたりの論理レコード長

レコード件数保存期間、データ増加率も加味

安全率（余裕率）PCTFREEの割合やAPPENDモードであるかも考慮するオーバーヘッド分（フラグメンテーションやオーバー・フロー・レコードの有無）

Long列データは他の表データとは別のところに保管LONG VARCHAR、LONG VARGRAPHICは24バイト、LOBは各列の情報(ポインターなど)のみを他データと共に持つ

必要なディスク容量表スペースのページ・サイズを決定し、１ページあたりの行数から必要ページ数を導く（後述）

索引容量概算：(平均索引キー・サイズ＋９）×行数×安全率基本的な算出方法の考え方は表と同等

LARGE表スペースに作成した表に定義する索引の場合（LARGE RIDを使用する場合）索引の1つの行項目当たり 2 バイトが追加で必要。

– (平均索引キー・サイズ＋９＋２）×行数×安全率

LARGE表スペースに作成したパーティション表に定義する索引の場合、LARGE RID分の2バイトと、パーティションID用の2バイトが追加で必要。

– (平均索引キー・サイズ＋９＋２＋２）×行数×安全率

安全率ノンリーフ・ページやフリー・スペースなどのオーバーヘッドのため、少なくとも２倍は必要索引の作成時のソートに必要な一時スペースの領域は、上記の式の安全率を３．２として見積もる

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



解説

ここで、レコード長を計算する場合、ヌルが可の場合1バイト、可変長の場合4バイトを加える必要があります。論理レコード長は、各データ項目のデータ・タイプ、桁数から各項目の物理サイズを算出して、可変長の場合は、平均長を採用します。NULL値を許す場合１バイト、可変長の場合4バイトを各該当の列項目あたり加算し、これらをすべて合計したのが１行のレコード長となります。レコード件数は、保存期間、データ増加率も加味します。また、安全率としてPCTFREEの割合やAPPENDモードであるかの考慮や、オーバーヘッド分（フラグメンテーションやオーバー・フロー・レコードの有無）も考慮します。索引のキー長も算出方法は基本的には表と同等です。

V9からサポートされたLARGE RID（6バイト）は、通常のRID（4バイト）より2バイト拡張されているため、LARGE表スペースに作成した表に対して定義する索引の場合、索引の1つの行項目あたり追加で2バイト必要です。更に、その表がパーティション表である場合、索引キーにパーティションIDが含まれますので、その分の2バイトが追加で必要になります。

後段階でパフォーマンスチューニングを行う際に索引が追加されることも考慮し、索引を作成する表スペースの容量には余裕を持たせる必要があります。

終的に必要なディスク容量は、表スペースのページ・サイズを決定し、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

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



解説

LONG列データlong varchar, long vargraphic のデータです。ファイル名は、SQLxxxx.LFです。32KB + 4KB(アロケーションとフリースペース情報)32KBのデータエリアの中は 512×2の累乗のセグメントにわかれています。

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

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

1024、2048、・・・、64MBSQLXXXX.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の累乗<1024バイト、2048バイト、4096バイト...>

compactオプション<CREATE TABLE>データが格納されないままのディスク・スペースを有効に活用できる

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

再編成(REORG)に注意する

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

ある

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

1MBLOBデータ

1.1MBバイトLOBデータ



参考：LOBデータ

LOBデータオブジェクトCREATE TABLE時のLOB 大サイズはディスク使用量に影響しない

LOB割り振りオブジェクト64GBごとに4Kページ1個＋ 8MBごとに4Kページ1個

LOB記述子

LOBデータオブジェクト

LOB割り振りオブジェクト

LOB記述子

REGULAR表スペース

LONG表スペース

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記述子サイズ * レコード件数



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

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

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

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

deptID (int) … deptdoc (XML)

1 … XML データ指定子(XDS)

… … …

create table dept (deptID int,…, deptdoc xml)XDA (XML Data Area)



ID … DOC (XML)

PR27 …

PR28 … XML記述子

ACC …

Regions Index

索引オブジェクトデータ・オブジェクト

XDAオブジェクト(XML Data)

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

DB2 V9.5では、指定したサイズ以下のXMLデータを基礎表に保持可能基礎表に保持させたいXML列を定義する際に「INLINE LENGTH <integer>」キーワードを付加する。表の作成時に、カラムオプションとして指定下記の例では、10000バイト以下のXMLデータを、ベース表に保持する。

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

V9.5



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

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

SELECT/INSERT/UPDATE全般の性能向上XMLデータを処理する際にReagions IndexやXDAの参照が不要になる

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

考慮点通常データとXMLデータを別テーブルスペースに配置する場合、基礎表とXDAの容量バランスに注意する。

XMLデータの基礎表への保管を行う場合、基礎表のページサイズを大きくした上で、基礎表とXDAを同じ表スペースへ格納することも検討する。

リレーショナルデータへのアクセスが主たる表に、XML列を追加する場合XMLデータを基礎表に保管する場合、1ページ当たりに格納可能なレコード数が減少する。特に既存のアプリケーション、SQLが存在する場合、1ページ当たりのレコード数減少が処理性能に影響する可能性があるため、パフォーマンス検証を行うことを推奨。

V9.5



参考：ＮULLとシステム・デフォルト値のデータ圧縮

V8からの新機能

目的格納スペースの節約

新しいレコードフォーマットでNULL値の場合には実際のデータページを節約NULL値でないSYSTEM Default値の場合にも実際のデータをページを節約実際の領域を確保しない結果として1 page上に入る行数を増やすことが可能

– １page 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が圧縮可能

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

カラムのオフセット情報等で各列２バイト確保される圧縮したことにより、オーバーフローが発生する可能性があるので、メリットがあるかを充分検討する必要がある



解説

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 4SMALLINT 4 2BIGINT 10 8REAL 6 4DOUBLE 10 8DECIMAL The integral part of (p/2)+3, where p is the precisionThe integral part of (p/2)+1, where p is

the precision

CHAR(n) n+2 nVARCHAR(n) n+2 n+4LONG VARCHAR 22 24

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

LONG VARGRAPHIC 22 24

DATE 6 4TIME 5 3

TIMESTAMP 12 10DATALINK(n) n+52 n+54Maximum LOB length 1024 70 72

Maximum LOB length 8192 94 96











参考：データ行圧縮

V9からの新機能

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

特に、繰り返しデータがあるような場合はお奨めI/O負荷の削減

トレード・オフとして、CPU使用率の増加（圧縮、解凍のため）バッファー・プールの使用率向上

圧縮された状態でバッファープールに読み込まれるログ書き出し量の削減（例外有り）

Insert/Delete は圧縮されたイメージでロギングUpdate についてはログ量が増える可能性有り

圧縮指定方法1. CREATE/ALTER TABLEで表に対する「COMPRESS YES」の定義2. オフライン再編成の実施

辞書を作成するために「REORG … KEEPDICTIONARY（もしくはRESETDICTIOANRY）」コマンドの実行辞書作成フェーズを経て、表データの圧縮が行われる

圧縮率の見積もりINSPECTコマンドを使用

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

使用方法1. 見積もり対象表に対してINSPECTコマンドを実行する

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

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

考慮点XML列、LONG/LOB列、索引は圧縮の対象にならないデータ行圧縮機能を利用するためには、ESEかつ「Storage Optimization Feature」を導入する必要がある



参考：データ行圧縮

Lempel Ziv アルゴリズム（LZ78,静的辞書圧縮法）を応用した圧縮方法特定のフレーズを辞書に登録し、辞書にあるデータを基に実データを圧縮していく

A B U R A K A T A B U R A圧縮前

‘UR’3

‘BU’2

‘AB’１

文字列番号

LZ78辞書

■LZ78の例

1 3 A K A T A 2 R A 圧縮後

辞書を作成

辞書を元にデータを圧縮

圧縮前「１３文字」あったのが、圧縮後に「１０文字」になっている



表スペースの見積もり

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

DMSの場合、各表オブジェクトについて低 2つのエクステントが割り当てられる。この未使用のスペースを削減するために、カタログ表スペースをDMSで作成する場合は、エクステント・サイズを小さくすることを(2 から 4 ページ) を検討する。

データベース作成時、デフォルトでは自動サイズ拡張が使用可能なDMS（ファイル）表スペースとして作成される（初期サイズはDB2が自動決定）ため、表スペース容量が不足する前に自動的にサイズが拡張される。

ファイル・システムがいっぱいになると自動拡張が失敗するため、余裕をもって作成しておく。（通常、数百MB～1GB程度あれば問題なし。）自動ストレージ表スペースであるため、ALTER TABLESPACEによる拡張はできない。

ユーザー表スペース既に決まっているページ・サイズと平均行サイズから、１ページに格納できる行数を算出予想される行数を格納するために必要となるページ数を算出

ROUND DOWN(ページ・サイズ/(論理レコード長)) = １ページあたりの行数(レコード件数/１ページあたりの行数) * 安全率 = 必要ページ数

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

一時表スペース一番大きく使用すると思われるケースで検討するシステム一時表スペース

JoinやSortを行うアプリケーションやREORG、LOADなどの運用次第で大きく変わるSMS表スペースの使用が望ましい

– DMSでは一時表の作成時に多くのオーバーヘッドがある– SMSではディスク・スペースを動的に割り当てるが、DMSでは事前に割り当てられてしまうため、領域

を有効活用できないユーザー一時表スペース

宣言済み一時表を使用する場合デフォルトのユーザー一時表スペースはないため、作成する必要がある

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



解説

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

表の再編成実行時に表スペースの名前を指定しない場合、再編成しようとする表を含む表スペースにその表の作業コピーを保管します。一時表スペースを使って表を再編成する場合、一時表スペースのページ・サイズは表のページ・サイズと一致しなければなりません。宣言済み一時表は、独自のユーザー一時表スペース・タイプの中にのみ作成されます。デフォルトのユーザー一時表スペースはありません。一時表スペースの必要なスペースの量は照会および戻される表のサイズや照会アプリケーション、REORG、LOADなどの運用に依存するため、正確に見積もることは難しいため、事前にテストで確認することが必要です。

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

表スペースのヘッダー

スペース・マップ

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

3 エクステント + 1 ページ

表スペースメタデータ

表(オブジェクト)の作成エクステント・マップ

データのエクステント

5 エクステント + 1 ページコンテナーで最小限必要なスペース =(最初のオブジェクトを作成した時)

EXTENTSIZE = 32 ページなら、 5*32＋1＝161ページがコンテナーに必要

1 エクステント






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

自動保守用表スペース（SYSTOOLSPACE）

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

動作成される表スペース

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

SYSTOOLS表スペース作成時、約700KB通常、SYSTOOLSPACEに必要な容量は、データベース中の表の数に比例し、1つの表に対して約1KB として計算する






ログ領域の見積もり

アクティブ・ログ領域の見積もり

低限必要なサイズ：(logprimary + logsecond) * (logfilsiz + 2 ) * 4096

循環ロギングの場合

– 上記の式で求めた値に余裕を持たせたサイズを用意する

アーカイブ・ロギングの場合

– アーカイブ処理の失敗によりログ・ファイルが再利用されない場合や、ロールフォワード時にログがリトリーブされる領域を考慮し、余裕を持たせる（上記の式で求めた値の2倍程度）

アクティブ・ログの二重化を行う場合、2倍の容量が必要。

アーカイブ・ログ領域の見積もり

一日にアーカイブされるログ容量と保持期間を掛け合わせて必要な容量を算出する。更に、

アーカイブ・ログの削除や退避が行われなかった事態に備え、余裕を持たせて用意する。

複数パスへのアーカイブを行う場合（LOGARCHMETH1とLOGARCHMETH2を使用）、2倍の容

量が必要。（FAILARCHPATHを使用する場合は、その分の容量も必要。）



参考：ログ・アーカイブ機能（V8.2以降）

内容アクティブ・ログのアーカイブ機能をDB2の標準機能として提供する

V8.1までのログのUSER EXITの機能の代替機能を提供するアーカイブ方法を2つまで指定することができる

大で2つの別個のロケーションにアーカイブ・ログ・ファイルを保管できるアーカイブが失敗した場合の代替ディレクトリーを指定できる

アーカイブ先が使用可能になると、ログ・ファイルは自動的に移動される

方法次のデータベース構成パラメーターにアーカイブ方法を指定する

LOGARCHMETH1LOGARCHMETH2

次のデータベース構成パラメーターにアーカイブ・ログ・ファイル用の代替ディレクトリーを指定するFAILARCHPATH

データベースアクティブ・ログ

ミラー・ログ

DISK

TSM

VENDOR

db2tapemgrコマンド

テープ

LOGARCHMETH1

LOGARCHMETH2

FAILARCHPATH

アーカイブに失敗した場合



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

DB2のインストールに必要なディスク容量は、選択するインストールのタイプ、使用するファイル・システムのタイプに応じて異なる。

DB2セットアップ・ウィザードを使用すると、事前に見積もり可能。インストール・タイプ（標準、コンパクト、カスタム）ごとに選択されるコンポーネントに基づいて、動的にサイズの見積もりを行う。






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

インスタンスとデータベースインスタンス構成の考慮点サポートされるクライアント＆サーバー構成データベース作成の考慮点






インスタンスとデータベース

インスタンスDB2のオブジェクトのも大きな単位論理的なデータベース・マネージャー環境

Unix環境– db2syscプロセスを中心としたプロセ

ス群Windows環境

– 「DB2 - インスタンス名」サービス– 「DB2 – DB2コピー名 – インスタンス

名 – ノード番号」サービス全てのオブジェクトが含まれるDB2の起動／停止の単位

db2startコマンド／db2stopコマンド１マシンに複数インスタンスの作成が可能

db2icrtコマンドで作成

データベース有機的にまとめられた表スペース、表や索引の集まり一つのインスタンスに複数のデータベースを作成することが可能

create database コマンド接続(CONNECT)の対象となるバックアップ・リストアの大単位

インスタンス

データベース

表スペース(SMS)

表

LOB

索引

表スペース(DMS)

表


索引


LOB



解説

インスタンス一つのデータベース・マネージャー構成ファイルを使用して稼動する、データベース・マネージャー環境のことです。インスタンスは、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特権の単位でもあります。



インスタンス構成の考慮点

インスタンスの分け方アプリケーション構成開発環境用と本番環境用運用管理面

管理者の権限(SYSADM、SYSCTRL、SYSMAINT)を持つユーザーを分けたいときインスタンスごとにデータベース・マネージャーの構成を適化する起動/停止のタイミングを分けたい（サービス時間、運用時間の違い）

可用性エンジン動作部分に影響を与える様なトラブル発生時に、影響範囲を小さくしたい

その他考慮点UNIX環境：作成するインスタンスのビット単位（64ビット／32ビット）指定

同居させる他のプロダクトの要件にも注意

V9.5環境では、ほとんどの（下記3つ以外の）プラットフォームにおいて64ビット・インスタンスのみサポート

– 32ビット・インスタンスがサポートされるのは、以下のプラットフォームのみx86 用 Linux オペレーティング・システムx86 用 Windows オペレーティング・システムx64 用 Windows オペレーティング・システム (Windows x86 オペレーティング・システム用インストール・イメージを使用)

異なるバージョン間でのクライアント＆サーバー接続インスタンスホームの容量V9.5



解説

インスタンスを分ける例としては以下の様な場合があります。開発用と本番用管理者の権限(SYSADM、SYSCTRL、SYSMAINT)を持つユーザーを分けたいときDBMSのエンジン動作をコントロールしたい場合起動/停止のタイミングを分けたい（運用、サービス時間）可用性の観点で、エンジン動作部分に影響を与える様なトラブル発生時に、その影響をできるだけ受けさせたくない

１つのマシンに複数インスタンスを作成することが可能ですが、インスタンスごとに、追加のシステム・リソース (仮想メモリーとディスク・スペース) が必要になります。また、追加インスタンスを管理するためにさらに管理が必要になります。

インスタンス作成の際は、ビット単位（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 ServerUNIX

V8 32-bit ServerUNIX, Windows, Linux

V8 64-bit ServerUNIX, Windows, Linux

V9.1 32-bit ServerWindows, Linux

V9.1 64-bit ServerUNIX, Windows, Linux

V9.5 32-bitServerWindows,Linux

V9.5 64-bitServerUNIX,Windows,Linux

V7 32-bit Y N Y(6) Y(2,5,8) Y②③④Windowsのみ

Y②③④Windowsのみ

N N

V7 64-bit N Y N Y(4,5) N Y②③Windows以外

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



解説: 構成が可能なクライアント・サーバー一覧 ※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)を使用する

詳細は、下記の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/r0009731.htm[DB2クライアントの移行に関する重要事項]http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2.udb.uprun.doc/doc/c0022579.htm

V9.5



http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2.udb.uprun.doc/doc/r0009731.htm

http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2.udb.uprun.doc/doc/r0009731.htm

http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2.udb.uprun.doc/doc/c0022579.htm

http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2.udb.uprun.doc/doc/c0022579.htm



解説: 構成が可能なクライアント・サーバー一覧

注(V9.5マニュアルより抜粋):I. DB2 V8の機能のみ使用可能II. DB2 V9.1の機能のみ使用可能

詳細は、下記のDB2オンラインマニュアルをご参照ください。

[クライアントとサーバーのバージョンのサポートされている組み合わせ]http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=/com.ibm.db2.luw.qb.client.doc/doc/r0009731.html[クライアントのマイグレーションに関する重要事項]http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/topic/com.ibm.db2.luw.qb.migration.doc/doc/c0022579.html

V9.5

http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=/com.ibm.db2.luw.qb.client.doc/doc/r0009731.html

http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=/com.ibm.db2.luw.qb.client.doc/doc/r0009731.html






データベース作成の考慮点

データベースの分割の目安アプリケーション構成（業務内容）同時に処理する要件があるか

パフォーマンスの観点から一つにすることも検討分割されていると２フェーズ・コミット必要JOIN不可(連合DBを使用の場合は可能）

運用管理（バックアップ／リストア）の面から検討処理時間運用時間帯

可用性テスト環境ではフェーズやチーム単位で分割コード・セット別

Unicodeデータベース– V9 XMLデータタイプを使用する場合、UTF-8のデータベースでなければならない– V9.5のデフォルトでは、UTF-8のデータベースとして作成される。

分割する場合、レプリケーション機能の検討も必要かデフォルトのページ・サイズはどのサイズにするか自動ストレージ・データベースとして作成するか（V8.2.2以降）

V9でのデフォルトでは、自動ストレージ・データベースとして作成される

作成時のCOLLATE USING句指定日本語環境でデータを五十音順に照合したい場合はIDENTITYを指定

デフォルトはSYSTEM（辞書順）作成後は変更不可

V9.5



解説

データベースの分け方まずアプリケーションの構成から決定します。業務が全く異なる場合は、別データベースにするべきですが、それぞれに属する表同士に何らかの関連があって同時に処理する必要がある場合は、パフォーマンスの観点からも同じデータベースにしてしまうことも検討します。バックアップ/リストアといった運用管理の面からも検討します。複数に分けた場合、１つがダウンしても別のデータベースは使用可能ですので、可用性という点では優位です。このほかに、データベースを分ける例としては以下の様な場合があります。開発用と本番用共用する表を持たない異なるシステムの場合（表を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表スペース

複数表スペースの検討一時表スペースの定義検討すべき表スペース属性






表スペースとは

表スペース表のデータを格納するための論理的な領域媒体実際にデータを格納する物理的な媒体をコンテナーという

コンテナーの実体はファイルシステムのディレクトリ、ファイル、または論理ボリュームなどのローデバイス

一つの表スペースを１つ以上のコンテナーで構成データベース内に作成される表スペース

システム・カタログ表スペース，システム/ユーザー一時表スペース，ユーザーデータ用表スペース

表スペースはバックアップの小単位

コンテナー０

コンテナー１

コンテナー２

コンテナー３コンテナー

４

表

表スペース

データベース

表スペースバッファープールバッファープール

索引表



解説

表スペースは、表のデータを記憶するための論理的な領域媒体です。実際に表のデータが物理的に格納されるのは、表スペースに紐付けされたコンテナーになります。コンテナーは、表スペースのタイプにより、ディレクトリーやファイル、デバイスといった形態を取ります。一つの表スペースに複数のコンテナーを割り当てることができます。

データはコンテナー間で平均的に割り振られます。

一つのコンテナーは、一つの表スペースにしか属することはできません。表スペースへのデータの書き出しは、エクステントと呼ばれる割り当て単位に行われます。(デフォルトは32ページ) (詳細は後述)create databaseを実行すると、デフォルトでは３つの表スペースが自動的に生成されます。

SYSCATSPACE：システム・カタログ表スペースシステム・カタログ表、およびその索引が入っている表スペースです。データベース作成時に作られ、一旦作られた後は、変更や削除することができません。

TEMPSPACE1：システム一時表スペースJoinやSort時に一時的にデータが入る表スペースです。

USERSPACE1：ユーザー・データ用表スペースユーザーのデータや索引が入れられる表スペースです。表スペースを指定せずにcreate tableを実行すると、他のユーザー・データ用表スペースが無い場合は、デフォルトで、この表スペースが使われます。既に他のユーザー・データ用表スペースが作られている場合には、初に作られた表スペースが使われます。

表スペース単位でバックアップ/リストアを行うことも可能です。ロールフォワード回復不可能な場合(循環式ロギング)は、データベース単位のバックアップのみ可能です。

循環ロギングの設定LOGRETAIN（DB構成パラメーター）=NOUSEREXIT（DB構成パラメーター）= NOLOGARCHMETH1/LOGARCHMETH2 （DB構成パラメーター）=OFF

ロールフォワード回復可能な場合(アーカイブ式ロギング)は、表スペース単位のバックアップ/リストアが可能です。

アーカイブ・ロギングの設定LOGRETAIN=ON またはRECOVERY（V6.1より）USEREXIT=YESLOGARCHMETH1/LOGARCHMETH2でアーカイブ方法を指定



表スペースの種類と選択

適切な表スペースを選択するファイル管理のタイプによる表スペースの種別

SMS：オペレーティング・システムのファイル・システムによるファイル管理DMS：データベース・マネージャーによるファイル管理

保管データのタイプによる表スペースの種別LARGE（V9以降のDMS表スペースのデフォルト）

– V8以前：LOB、LONGデータ、索引用– V9以降：通常のデータ、LOB、LONGデータ、索引用

REGULAR（V9以降のSMS表スペースのデフォルト、V8以前のDMS/SMS表スペースのデフォルト）

– 通常のデータ、索引用TEMPORARY

– 一時表用システム一時表スペースユーザー一時表スペース

表スペースのページ・サイズ4KB，8KB，16KB，32KB4KB以外の表スペース作成の場合、事前に同じページ・サイズのバッファープールと一時表スペースを作成する

– V8.2.2以降は、データベース作成時にデフォルトのページ・サイズを指定することができる。（4KB以外のページ・サイズを使用する場合でも、ページ・サイズを1種類に統一することができる。）



解説ファイル管理のタイプにより、以下のいずれかのタイプを指定します。 (それぞれの詳細は後述)

SMS(System Managed Storage)各オペレーティング・システムのファイル・システムがファイルを管理します。コンテナーとしては、ディレクトリーを設定します。

DMS(Database Managed Storage)データベース・マネージャーがファイルを管理します。コンテナーとしては、ファイル、またはデバイスを設定します。

保管データのタイプにより、以下のいずれかのタイプを指定します。ＬＡＲＧＥ表スペース

すべての永続データを保管します。このタイプは、データベース管理スペース (DMS) 表スペースでのみ使用できます。また、タイプを指定しない場合の、DMS 表スペースのデフォルト・タイプでもあります。 LARGE 表スペースに表を配置すると、以下のようになります。

– REGULAR 表スペースに配置する表よりもサイズを大きくできます。– 表のデータ・ページ当たり、255 を超える行数をサポートできるので、データ・ページのスペース使用効率が向上します。– REGULAR 表スペースに配置した表に索引を定義する場合に比べ、索引の 1 つの行項目当たり 2 バイトが追加で必要になります。

ＲＥＧＵＬＡＲ表スペースすべての永続データを保管します。このタイプは、DMS 表スペースと SMS 表スペースのいずれも指定可能です（SMS 表スペースでのデフォルト・タイプです）。

ＴＥＭＰＯＲＡＲＹ表スペースシステム一時表スペース

– 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: エクステント単位



解説

３つの表スペースを比較した場合、通常パフォーマンスは以下のようになります。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は、エクステント・サイズの値になるまで一度に１ページずつアロケートする

データはラウンド・ロビン方式でコンテナに書き込む

DMSのコンテナーで小限必要なスペース ( 初のオブジェクトを作成した時) = 5エクステント + 1ページ

エクステント・サイズは、表スペース作成時に指定(デフォルトは32ページ）

多数の小さい表からなる表スペースは、サイズを減らすことも検討

大量の結果行を返す照会を行う表や急激に拡張される表からなる表スペースは、サイズを増やすことも検討

作成後は変更が出来ない

4K

Extent = 32ページ(デフォルト)

コンテナ 0

0 2

コンテナ1

1 3

表スペース Aエクステント

コンテナコンテナエクステントエクステントページページ






SMS表スペース

SMS(System Managed Storage)表スペースオペレーティング・システムのファイル・システム・マネージャーが管理表データと索引、Longデータは全て同じ表スペースを共有管理が容易コンテナーはディレクトリーファイルは動的に拡張し、サイズの上限は以下によって決まる

コンテナーの数ファイル・システム/ドライブ/ファイルのOSの限界サイズ

コンテナーは動的に追加不可ファイル・システム/ドライブのサイズは増加可能再定義は表スペース復元時に可能（表スペースのリダイレクション）各コンテナーサイズは同じ大きさに

一時表スペースに推奨



解説

SMSの特徴SMSでは、表スペースはファイルシステムのディレクトリに相当し、表や索引はそれぞれ別々のファイルになります。SMS表スペース（ディレクトリ）を作成したファイルシステムが許す限り、表に対してデータを追加することができます。つまり、表スペースの大きさはファイルシステムの大きさに依存します。SMSでは表や索引およびLOBやLONG VARCHARなどの長形式のデータを含むロング形式のデータを全て同じ表スペースに格納する必要があります。複数のディスクにIOを分散させる為に、１つの表スペースに対してコンテナーを複数定義することがSMSでも可能ですが、コンテナーの追加や削除を行うことはできません。表スペースを作成するときのコンテナー定義を変更する為には、一度削除して再作成する必要があります。複数コンテナーによってSMS表スペースを作成した場合、どれかのファイルシステムが一杯になると表スペースはそれ以上のデータを追加することができなくなります。



DMS表スペース

DMS(Database Managed Storage)表スペースデータベース・マネージャーが記憶スペースを管理作成時にスペースを割り当てコンテナーはファイル、デバイス

ファイルの操作に対してはファイル・システムI/Oを使用ロー・デバイスの操作に対しては直接I/Oを使用

柔軟なデータ配置表用、索引用、および長形式のデータ用の表スペースを別々に作成する

ことが可能ディスクのIOを複数の物理ディスクに分散させることが可能

コンテナの追加/削除/拡張/縮小が可能データは自動的に再バランス（オプションにより再バランスさせないことも

可）高パフォーマンス



解説

DMSの特徴DMSでは、表スペースは大きな１つのファイルまたはローデバイスに相当します。中をど

のように使われているのかはOSからは確認できません。表スペースを作成する際に、あらかじめ必要な大きさを定義する必要があります。DMSではさらに２つのタイプがあり、１つはDMSファイルともう一つはローデバイスです。

DMSファイルの場合は、ファイルシステム上に１つの大きなファイルが作成されますが、ローデバイスの場合はファイルシステムを経由せずにＤＢ2が直接IOを行います。

DMSでは、表用、索引用、および長形式のデータ用の表スペースを別々に作成することが可能です。それによって、ディスクのIOを複数の物理ディスクに分散させることが可能になります。

DMSでも複数のコンテナーを１つの表スペースに対して定義でき、さらに動的に追加することが可能です。表スペースを作成後にコンテナーの大きさを変更することもでき、DB2 UDB V8以降では小さくすることも可能です。

複数コンテナーからDMS表スペースを構成する場合、どれかのコンテナーが一杯になっても空いているコンテナーを探して書き込もうとします。全てのコンテナーが一杯になった場合、それ以上データの追加はできません。

V8.2.2からは、ファイルDMS表スペースの自動サイズ変更が可能です。



複数表スペースの検討

表スペースの分割の指針パフォーマンスを考慮し、バッファープールの割り当てを検討I/Oの並列処理を考慮し、データの物理配置に合わせて表スペースを構成バックアップの単位、LOADの並行処理等の運用面で検討

表をグルーピングし、表スペースを分ける１．できる限りバッファプールに読み込むことが望ましい表

頻繁に読み書きされるトランザクション系データ２．バッファプールには読み込む必要が無いデータ

アプリケーション活動の履歴的な、一度書いたらほとんど変更／参照されないデータ３．１と２の中間４．小さな表はある程度の単位で一つの表スペースにまとめる５．バックアップ取得の頻度で別の表スペースにする

大量の更新がある表⇒頻繁なバックアップ取得必要変更が非常に少ない表⇒頻繁なバックアップ取得不要

LOADを複数同時に実行するには、別々の表スペースにする（特にV7）

V7では、LOAD実行中は表スペースをQuiesce（静止）状態にするため、該当の表のみならず、同一表スペース上の他の表にもアクセス不可



解説

典型的な分け方は以下のようになります。１．頻繁に読み書きされるトランザクション系データ２．アプリケーション活動の履歴的な、一度書いたらほとんど変更されないデータ３．１と２の中間分類１の表は、アプリケーションのパフォーマンスに大きな影響を与えます。ディスク資源とメモリ資源を十分に割り当てる必要があります。分類２の表は、容量的には大きくなりますが、一度書いた情報をあまり読まないため、メモリ資源は低く抑えることができます。このタイプの表を全件検索するようなSQLが実行された場合、ディスクのアクセスが非常に多くなるので、パフォーマンスが常時必要な分類１の表とは異なる物理ディスクを割り当てることが理想的です。できればディスクへつながるSCSIやファイバーチャネルなどのインターフェースも別であることが理想的と言えます。分類３は、メモリ資源をそれなりに与える必要がありますが、優先順位では分類１より下になります。表スペースの分け方には、以下のようなケースもあります。

頻繁に使用される表、それもアクセスされるデータがほぼ決まっている場合には、大き目のバッファープールを持った表スペースを割り当てます。このときには、データの表スペースと、索引の表スペースとを分けるのもひとつの方法です。(DMSの場合)大きな表に、ランダムにデータ・アクセスする場合には、小さいバッファープールを持った表スペースを割り当てます。たまにしか使用されないアプリケーションからアクセスされる表には、小さいバッファープールを持った表スペースを割り当てます。このような表は、まとめて一つの表スペースに入れるのもひとつの方法です。参照制約，トリガーなど関連のある表同士は一つの表スペースにまとめます。小さな表は全て同じ表スペースにまとめます。バックアップを取得する単位で表スペースを分けます。

表スペース単位のバックアップは時間とリソースの節約になります。大量の変更がある表スペースは頻繁にバックアップを取り、変更が非常に少ない表スペースは時折バックアップを取ります。Ｖ９以降は、データベースの再ビルド機能によりデータベース全体のバックアップを取得していなくても、表スペース・バックアップからデータベースを回復することができます。

V７では、LOAD実行時、表スペースをQuiesce（静止）状態にし、表スペースと表スペース内の表すべてに対してZ-LOCK(超排他)を取得するため、LOADの並行処理を可能にするには表スペースを分ける必要があります。（V8では、LOAD中も表に照会アクセスが可能であり、同じ表スペースの表については、アクセスが自由できます。）



一時表スペースの定義

SMS or DMS一時表スペースとしてはSMSがお勧め（一般）

スペースの有効利用多くのクライアントアプリケーションからのソート要求を処理する場合、DMSよりパフォーマンスが良い複数のコンテナーを作成して、パフォーマンス向上を計るファイルシステム上に作成するため、ファイルシステムの制限（ラージイネーブル、ulimit）に注意が必要

一時表スペースとしてのDMS（例外）Solarisでは一時表スペースを使用した再編成、ロードや索引作成時などの大量データの処理の場合パフォーマンス的に有利な場合がある（ケース・バイ・ケースなので、ベンチマーク・テストが必要）HAのテイクオーバー時間を短くために、fsckの必要になるファイルシステムの代わりにローデバイスDMSを選択する場合がある

ページサイズ毎に１つ作成一時表スペースを使用した再編成の場合、表の存在する表スペースのページサイズと一時表スペースのページサイズは同じである必要がある。ソート時に使用する一時表スペースは、格納できるページサイズを選択する。

異なるページサイズを持つ別々の一時表は、SMSとして同じファイルシステムに配置するとスペースの有効利用ができる

後からでも比較的簡単に作成し直せる表スペース



解説

一時表スペースに関しては、DMSよりSMSの方が勧められています。一時表スペースの使われ方は、ソートやジョインに必要なときに一時的にシステム一時表が作成され、データが格納されます。つまり、表の作成・削除が内部で行われています。表作成時にSMSではファイルが作成され、使用後に削除されます。DMSでは表スペース内の空き領域を管理する「スペースマップ」や、各表に対してディスクのどの部分を使用しているのかを管理する「エクステントマップ」をメンテナンスする必要があります。多くのユーザーがそれほど大きくないソートやジョイン用の一時表を作成する場合、この２つのマップのメンテナンス作業が競合し、パフォーマンスが劣化する場合があるため、DMSは一時表スペースには勧められていません。

例外として、Solarisで比較的大量なデータを一時表スペースに書き出すような場合、索引の作成やロードなどの場合、DMSの一時表の方がパフォーマンス的に有利な場合があります。ただし、Solarisでは必ず一時表スペースはDMSにしなければならないという訳ではありません。使用方法によってはSMSが適当なケースも存在します。

一時表スペースでは通常の表スペースとは、データを書き込む単位が異なります。通常の表スペースにおいて、DMSではデータはエクステント単位に書き込まれ、SMSではページ単位に書き込まれます。SMSではページ単位で書き込む上に、ファイルシステム上で、ファイルのサイズを大きくしていく必要があり、これがDMSに比べてオーバーヘッドになり得ます。db2empfaというコマンドがあり、SMSでもエクステント単位でディスクに書き出すことが可能になるため、通常の表スペースでは効果がありますが、一時表スペースでは、必要な容量を一度にアロケーションするため、db2empfaの効果は期待できません。

データベース中に複数のページサイズが存在する場合、一時表スペースをページサイズ毎に作成されることをお勧めします。これは一時表スペースを使用した再編成を行う場合には必須です。再編成を行う表が含まれる表スペースのページサイズと同じページサイズを持つ一時表スペースがないと一時表スペースを使用した再編成は行えません。

複数の一時表スペースを定義する場合、一時表スペースがSMSであれば、同じファイルシステムに配置することが可能になります。これによって使用率が低いディスクエリアを共有し、ディスクスペースの有効利用が可能になります。もちろん、複数の再編成を並行で実行する必要があるような場合は、別々のディスクに配置する方が、ディスクI/Oが衝突せずパフォーマンス的に有利です。

一時表スペースは比較的簡単に作成し直せる唯一の表スペースです。本番稼働を始めた後でも、データのExport/Loadなどの移行などが必要ではないためです。ただし、一時表スペースを作成し直す場合、データベースに低限１つの一時表スペースを残さないとエラーになります。新しい一時表スペースを作成後に、古い一時表スペースを削除すればこのエラーは回避できます。



参考：自動ストレージ表スペース

V8.2.2以降、自動ストレージ・データベース、自動ストレージ表スペースが使用可能V9以降、データベースを作成すると、デフォルトで自動ストレージ・データベースとして作成される。

自動ストレージ・データベースには、自動ストレージ表スペースを作成可能（通常の自動ストレージでない表スペースを作成することも可能）

自動ストレージ表スペース表スペースのコンテナーおよびスペース管理の特性（SMS/DMS）はDB2によって自動的に（以下のように）決定されるため、指定しなくてもよい。

REGULARまたはLARGE表スペースの場合、DMS（ファイル・コンテナー）TEMPORARY表スペースの場合、SMS

データベース作成時に定義された（１つ以上の）ストレージ・パスを使用してDB2がコンテナーを自動的に割り振るため、表スペース作成時にコンテナーの明示的なリストを指定する必要が無い。

自動ストレージ表スペースを作成するための指定（CREATE TABLESPACE実行時）MANAGED BY AUTOMATIC STORAGE 文節を指定する、または、MANAGED BY 文節を指定しない

自動ストレージ･データベースデータベース

表スペースA 表スペースB 表スペースC

ストレージ・パス（複数のディレクトリー）

自動ストレージ表スペース



参考：V9.5 新機能-自動ストレージ表スペースのサイズ縮小

ユーザーによる自動ストレージ表スペースのサイズ縮小をサポートする。

ALTER TABLESPACE ステートメントをREDUCEオプションを指定して実行することで、表スペースの未使用エクステントを解放することができる。

非自動ストレージ表スペースの場合と違い、コンテナー・パスや減少するページ数の指定は不要である。DB2が解放する領域を判断する。

メリット解放されたストレージ領域を、同一の自動ストレージ・パス上に存在する他の表スペースで使用できる。Space Map Pagesが残っていることにより高水準点が下がらない場合でも、当機能を使用することで、SMPを削除し高水準点を下げるため、未使用のストレージ領域を開放する

注意事項解放するのは、高水準点より上の位置にあるフリー・ページで、使用したページでデータが入っていない空き状態のページ（FPAGESとNPAGESの差分）を解放する機能ではない。

V9.5



参考：V9.5 新機能-コンテナーあたりの大サイズを設定するレジストリ変数

DB2_SET_MAX_CONTAINER_SIZE レジストリ変数AutoResize フィーチャーが有効になった自動ストレージ表スペース用のコンテナー 1つあたりの大サイズを制限するレジストリ変数。

オペレーティング・システム: すべてデフォルトは、-1（設定しない）。コンテナーのサイズに対する制限はなく、従来と同一の動作を行う。値を設定する場合は、64 MB より大きい正の整数とする。

注意事項表スペースの大サイズを指定するレジストリー変数ではない。

レジストリ変数の設定値まで、コンテナー・サイズが達した場合には、新規にコンテナーが追加され、表スペースは拡張される。

このレジストリ変数を使用した場合には、V9.1までと異なり、V9.5からは 1つの自動ストレージ・パスあたりに、複数のコンテナーが作成される場合がある。

V9.5



検討すべき表スペース属性

ファイルDMS表スペースの自動サイズ変更（V8.2.2以降）ダイレクトI/ODROPPED TABLE RECOVERY属性OVERHEAD/TRANSFERRATE



ファイルDMS表スペースの自動サイズ変更（V8.2.2以降）

DMSファイル・コンテナのサイズを自動的に拡張

コンテナがいっぱいになる（SQL0289N）前に、追加領域の必要に応じてコンテナを自動的に拡張するファイル・コンテナのみ使用可能

ロー・デバイス・コンテナの自動サイズ変更は不可能表スペースの後のレンジにあるコンテナが拡張される

自動サイズ変更によってリバランスは発生しないそれぞれのコンテナは同じ量だけ拡張される

自動ストレージ・表スペースのDMS、自動ストレージ・表スペースでないDMSのいずれに対しても使用可能自動ストレージ・表スペースでない場合、ユーザーによるコンテナの拡張、削除が可能

従来どおり、ALTER TABLESPACEステートメントを使用する区分化データベース環境でも使用可能

DMSなのでパフォーマンスがよく、自動的にサイズ拡張するので、SMS同様管理が容易になる

考慮点自動サイズ変更が行われる場合、表に対する挿入処理のパフォーマンスに影響が出る。

社内実測値では、自動サイズ変更を設定していない環境と比較してimport処理に20%から25%程度の性能劣化が見られた。

一時表スペースを使用しないREORGの際にも自動サイズ変更が行われる。REORG完了後もサイズは拡張されたままで、縮小されない。



解説：

自動サイズ変更を使用可能な表スペースでは、既存のスペースがすべて使用され、さらに多くのスペースが要求される場合、DB2 は表スペースのサイズの増加を試みます。DB2は、表スペース・マップ (表スペースのストレージ・レイアウト) の新の範囲（レンジ）に存在するコンテナーのみを拡張しますので、リバランス処理は発生しません。

新の範囲（レンジ）に存在するコンテナーはそれぞれ同じ量だけ拡張されます。新のレンジに存在するコンテナーのひとつが、ファイル・システムの上限に達すると、自動サイズ変更が停止してしまうため、それぞれのコンテナーが使用するファイル・システムのサイズはそろえておくことが重要です。



参考：ファイルDMS表スペースの自動サイズ変更の仕組み

Range #0

Range #1

0 1 2

012345

Containers

Stripes

Range Number

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

3

6

9

11

13

1

4

7

10

12

14

2

5

8Stripe Set #0

既存のエクステント（0~12）以上のスペースが必要になると、コンテナの後のレンジにエクステン

トが追加される

レンジ[0]のみを持つコンテナ2は拡張されないため、リバランスは発生しない。






自動サイズ変更の指定方法

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自動ストレージ表スペースの、初期サイズを指定する自動ストレージ表スペースの場合のみ指定可能

INCREASESIZE integer PERCENT または INCREASESIZE integer K | M | G

自動サイズ変更される量を指定する（表スペース全体での増加量）パーセントまたは、容量を指定パーセントは、自動サイズ変更が行われる時点の表スペースサイズのパーセンテージを意味する

指定されていない場合、DB2が自動的に判断する

MAXSIZE integer K | M | G または MAXSIZE NONE 自動的に拡張できる大サイズを指定する指定されていない場合、NONE



解説：

AUTORESIZE DMS 表スペースまたは自動ストレージ表スペースの自動サイズ変更機能を使用可能にするかどうかを指定します。自動サイズ変更可能表スペースは、いっぱいになると、自動的にサイズが大きくなります。デフォルトは、DMS 表スペースの場合は NO、自動ストレージ表スペースの場合は YES です。NO

DMS 表スペースまたは自動ストレージ表スペースの自動サイズ変更機能が、使用不可であることを指定します。

YES DMS 表スペースまたは自動ストレージ表スペースの自動サイズ変更機能が、使用可能であることを指定します。

INITIALSIZE integer K | M | G 自動ストレージ表スペースの、データベース・パーティションあたりの初期サイズを指定します。このオプションは、自動ストレージ表スペースに対してのみ有効です。整数値の後に K (K バイトの場合)、M (M バイトの場合)、または G (G バイトの場合) を指定する必要があります。使用される実際の値は、指定されたものよりも若干小さい場合があることにご注意ください。これは、データベース・マネージャーが表スペース内の各コンテナーのサイズの一貫性を維持しようとするためです。表スペースが自動サイズ変更可能であるもののINITIALSIZE 文節が指定されていない場合には、データベース・マネージャーが適切な値を判別します。



解説：

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を指定する

注意点一旦AUTORESIZEをNOにすると、それまでに設定していたINCREASESIZE, MAXSIZEの値は保持されない。

自動サイズ拡張が実行されている中に、自動サイズ拡張を解除しようとすると、実行中の自動サイズ拡張が完了するまでALTER TABLESPACEステートメントは待ち状態になる。

実行中の自動サイズ拡張が完了した後、AUTORESIZEがNOに変更される。

ALTER TABLESPACE tablespace-name AUTORESIZE NO






ダイレクトI/O

利点ファイル・キャッシュとバッファープールでの二重バッファリングを回避

二重バッファリングを行うCPU負荷を軽減ファイル・キャッシュに余分なデータをのせないことによる、本来のファイル・データのヒット率向上大量にファイル・キャッシュを使用することによって引き起こされるページングを回避（システム全体の性能が不安定になることを回避）

V8.1FixPak4以降、ダイレクトI/Oサポートが拡張されている



解説

コンテナーにファイルを使った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=ONAIXのレベルによっては、コンカレント 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使用



解説

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設定方法の例

表スペースのキャッシング使用状態確認は、表スペースのスナップショットにて確認可能

get snapshot for tablespaces on sample

Tablespace name = TS1Tablespace ID = 3Tablespace Type = System managed spaceTablespace Content Type = Any dataTablespace Page size (bytes) = 4096Tablespace Extent size (pages) = 32Automatic Prefetch size enabled = YesBuffer pool ID currently in use = 1Buffer pool ID next startup = 1File system caching = YesTablespace State = 0x'00000000'Detailed explanation:

Normal

CREATE TABLESPACE TS1 MANAGED BY SYSTEM USING (‘tspath1’,’tspath2’) NO FILE SYSTEM CACHING

ALTER TABLESPACE TS1 FILE SYSTEM CACHING



ダイレクトI/Oサポートの変遷（続き）

V8.2.2以降一時表スペースへのダイレクトI/O設定可能

設定方法はV8.2のときと同様CREATE / ALTER TABLESPACEのオプション

– FILE SYSTEM CACHING– NO FILE SYSTEM CACHING

ダイレクトI/Oが設定可能になったことにより、フラッシュ・コピー対象とすることができる。



解説

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の一時表スペースをフラッシュコピー対象とすることができます。



ダイレクトI/Oサポートの変遷（続き）

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-VxFSLinux for System zAll 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として書き込まれるため、パフォーマンス低下が懸念される。

V9.5



DROPPED TABLE RECOVERY属性

表スペースのDROPPED TABLE RECOVERY属性ドロップされた表をリカバリー可能にするための属性

表スペース作成時、または変更時に、DROPPED TABLE RECOVERY属性を指定する（REGULAR表スペースにのみ指定可能）V8以降のデフォルトはON

DROP TABLE ステートメント実行時DROPされた表を識別するための項目がログ・ファイルとリカバリー履歴ファイルに書き込まれる

表のDROP時に書き込まれる内容ログ・ファイルに書き込まれる情報

– 表の名前– タイム・スタンプ– トランザクションID– 表ID

回復履歴ファイルに書き込まれる情報– 表の名前– タイム・スタンプ– トランザクションID– 表ID– DDL

必要がなければOFFにする影響範囲

誤ってDROPした表の回復を行うしくみを利用できなくなる

定期的に大量に表を作成/削除を繰り返すような業務がない場合には、デフォルトのままでも業務パフォーマンスへの支障はない



解説

表スペースの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

OVERHEAD/TRANSFERRATEのデフォルトは、バージョンにより異なる

OVERHEADの省略時値V8.1 ： 24.10msV8.2 ： 12.67msV9以降： 7.50ms

TRANSFERRATEの省略時値V8.1 ： 0.90msV8.2 ： 0.18msV9以降： 0.06ms



参考：OVERHEADとTRANSFERRATEの意味

OVERHEADデータをメモリーに読み込む前に、コンテナーに関して必要な

時間（ミリ秒）ディスク待ち時間、コンテナーの入出力コントローラーのオー

バーヘッド (ディスクのシーク時間を含む)が含まれる

TRANSFERRATE1ページのデータをメモリーに読み込むために要する時間（ミ

リ秒）



⑤表スペースの配置

ユーザー表スペースの配置索引／長形式データの配置

その他の表スペースの配置






ユーザー表スペースの配置

複数の物理ディスクに表スペースを配置し、DISK I/Oを分散させる１つの表スペースを複数ディスクに配置理想は同じサイズのコンテナー索引は別の表スペースに配置長形式は別の表スペースに配置

基本：Prefetch Size = Extent Size×コンテナー数RAID5などアレイの場合は以下の構成を行う

DB2_PARALLEL_IOこのレジストリー変数を設定することで、PrefetchSize と ExtentSizeの違いを見て、I/Oを並列に行うかを決定する

表スペース１

(Prefetch Size = Extent Size × 4)

表スペース２

(Prefetch Size =

Extent Size × 3)



解説

パフォーマンスのためには、各表スペースに対して、６個～１０個以上の物理ディスク上に別々のコンテナーを作成し、I/Oを分散することが理想的である（と言われています）複数のコンテナーに配置する場合には、表スペースに対して以下の設定を行い、プリフェッチャーによる並列I/Oを使用可能にする必要があります。

Prefetch Size = Extent Size×コンテナー数この設定によって、複数のプリフェッチャー・プロセスを使い、データをバッファプールに読み出すことができるようになります。

データはラウンドロビンで書き込まれている為、各コンテナーのサイズは同じであることが理想的です。それによって、データの分散度合いのばらつきを無くし、ディスクI/Oが特定のコンテナーにできるだけ集中しないようにします。

DB2_PARALLEL_IOを指定した場合は、特にPrefetch Sizeは重要になります。パラレルI/Oを指定するような場合は、通常ESSなどのRAIDディスクが使われており、コンテナーが１つでも実際は内部では複数のディスクが使われています。このような状態では、コンテナー数は先読みに対しては意味を持たず、DB2はPrefetch SizeがExtent Sizeの何倍になっているかによって、プリフェッチャーを起動し先読みを行います。



参考：プリフェッチ・サイズの自動調整機能（V8.2以降）

エクステント・サイズ、コンテナ数、およびコンテナあたりの物理ディスク

数に基づいて、表スペースに適したプリフェッチ・サイズをDB2が自動計

算する利点：コンテナの追加・削除に応じ、プリフェッチ・サイズを変更する必要がない

考慮点：コンテナ数、物理スピンドル数が多いほど、多く設定される

設定方法データベース構成パラメーターDFT_PREFETCH_SZの値をAUTOMATICに設定する

CREATE TABLESPACEステートメントで、 PREFETCHサイズを指定しない

算出式プリフェッチ・サイズ＝（コンテナ数）*（コンテナあたりの物理ディスク数）*エクステント・サイズ



参考：プリフェッチ・サイズの自動調整機能（V8.2以降）

DB2_PARALLEL_IOの値との関連DB2_PARALLEL_IOの値は、コンテナあたりの物理ディスク数として使用される

例（例１）DB2_PARALLEL_IO=*

全ての表スペースは、デフォルトで、各コンテナあたり６個の物理ディスクをもつと仮定して計算される全ての表スペースに対して、パラレルI/Oが有効となる。プリフェッチ要求は、プリフェッチサイズをエクステント・サイズで割った数に分割されて、パラレルに実行される

（例２） DB2_PARALLEL_IO=*:3

全ての表スペースは、コンテナあたり３個の物理ディスクを持つと仮定して計算される全ての表スペースに対して、パラレルI/Oが有効となる。

（例３） DB2_PARALLEL_IO=*:3,1:1

全ての表スペースは、コンテナあたり３個の物理ディスクを持つと仮定して計算される。ただし、表スペース１だけは、物理ディスク数は１となる。全ての表スペースに対して、パラレルI/Oが有効となる。

DB2_PARALLEL_IOが設定されていない場合には、物理ディスク数は１



索引／長形式データの配置

索引の配置DMS表スペースに表を作成する場合、索引を別の表スペースに格納することが可能。ディスクI/Oの競合を避けたい、または、表と索引のバッファープールを分け、特定の表や索引のヒット率を確保したい場合には、表と索引を別の表スペースに格納することを検討する

長形式データの配置DMS表スペースに表を作成する場合、長形式のデータを別の表スペースに格納することが可能。長形式のデータにはバッファプールは有効ではないファイルDMSに配置することによって、ファイルキャッシュを有効にすることができる

LOBとして格納するデータは、通常それほど頻繁に読み書きが発生しないので、キャッシュが効かなくても影響が少ないケースも多い

表スペース for TABLE


表スペース for INDEX




その他の表スペースの配置

一時表スペースソート、結合、再編成、索引作成時（LOADを含む）等に使用一時表のI/Oが多く、データ／索引用の表スペースのI/Oと衝突する場合は、別ディスクに配置するコンテナーに複数のディレクトリーを指定することが推奨。（SMSの場合）

カタログ表スペース通常、カタログ表のデータは殆どキャッシュ上に読み込まれているため、特にI/O効率を考慮したディスク上への配置は不要。（データベース作成時のデフォルトのままでも良い。）

SYSTOOLSPACEV8.2以降でデータベースの自動保守（自動統計収集および再編成）を使用する場合に自動作成され、自動保守が実行される際に使用される。デフォルトの配置のままでも特に問題はない。自動保守機能を使用しない場合は、削除しても良い。



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

ログの配置アクティブ・ログとアーカイブ・ログ

ワーク/バックアップ領域の配置その他の領域






ログの配置

アクティブログに対する書き込み速度はアプリケーションのレスポンスに直接影響するアクティブログは安全性を考えると、二重化した方がよい

（アクティブログの障害＝データベースの障害）である。DB2の二重ログは両方に書き出して終了なので、どちらか１つのディスクが遅い場合、ログへの書き込みは遅くなる。

ディスク容量が許すのであればアクティブログ専用のディスク上に配置する

ESSの場合ランクも別の方が理想的SCSI / Fibreなどのチャネルもできれば別

RAID5ではなく、ミラーリングを使用するストライピングによって書き込みを速くする

ログ

バッファプール

データの

更新処理

データ

変更されたデータ

非同期

書き出し

コミットしたら更新内容を

必ず書き出す



解説

ログはDB2にとって重要なオブジェクトです。特にアクティブログは非常に重要で、アクティブログが損傷したことはデータベース自身が損傷したことを意味します。つまり、アクティブログが壊れたら、データベースが壊れたのと同じです。何故、アクティブログがそれほど重要なのでしょうか。更新処理を行う時のDB2の動作を考えてみます。データベースが更新された場合、バッファプールと呼ばれるキャッシュのデータが更新されますが、ディスクにはすぐには書き出されません（このようなデータが含まれるページをダーティーページと呼びます）。その更新処理がコミットされると、必ずログに書き出されます。この状態でもしDBサーバーがクラッシュした場合、次にデータベースが使われる前に、クラッシュリカバリーという処理を行う必要があります。クラッシュリカバリーによって、更新されたはずなのにディスクに反映されていない更新を、ログを読みながらディスクへ反映します。ここで、重要な点はログがなければクラッシュ前にどのような更新処理が行われていたのかを知ることができないということです。DB2はこのクラッシュリカバリーによって、突然のDB2の異常停止などの時でもデータベースに格納されているデータの論理的な整合性を保証しています。つまり、ログが壊れるということはDB2がデータの整合性を保証できないということを意味しています。

ログの重要性を理解したところで、そのI/Oパフォーマンスが非常に重要であることも気が付かれたと思います。更新処理がコミットされたら必ずログに書き出される訳ですから、ログへの書き出しが終わらないと次の処理へ進むことができません。更新処理のボトルネックがログのI/Oにならないようにする為には、他のI/Oとの衝突をできる限り避ける必要があります。他のI/Oとは表や索引のデータが含まれるディスクへのI/Oが含まれます。つまり、ログは表や索引などとは全く別のディスクに配置することが推奨されます。ESSのような１つのアレイが大きな場合でも、できる限り全く別のディスク上に配置し、SCSIやファイバーチャネルなどのインターフェースも別にすることが推奨されます。また、書き込みに対して多少不利なRAID5よりもできればミラーリング（RAID1）などを選択するようにしてください。さらにディスクに余裕がある場合には、ストライピングなどによって高速化できれば更新処理にとって良い結果が期待できます。



ログの配置（続き）

アーカイブログとアクティブログは別のディスクに配置するアーカイブログ・ディレクトリ（コピー先）とアクティブログ・ディレクトリ（コピー元）は別にした方がパフォーマンス的に有利障害時の危険分散を考えても別の方がよい

アクティブログとアーカイブログが壊れた場合、バックアップからのリストアーはできても、新状態へのロールフォワードができなくなる。

大量更新を行うバッチ系処理の場合(Importなど)ログに対するキャッシュに相当するログバッファー(LOGBUFSZ)を大きくする

ローデバイスロギングは、V9では推奨されないローデバイスロギングを使用すると、二重ログが使えないUSEREXITに何らかの問題があって、ログのコピーに失敗した場合、手動によるコピーが不可

ログ・アーカイブ機能（V8.2以降）を使用する場合は、アーカイブ先ディレクトリとして容量と配置に注意する

二つのアーカイブ先ディレクトリ（LOGARCHMETH1, LOGARCHMETH2）を使用する場合領域は2倍必要

– 代替ディレクトリ（FAILARCHPATH）を使用する場合は、更に領域が必要それぞれ別のディスクに配置する



解説

アクティブログの重要性を説明してきましたが、DB2にはもう一つアーカイブログというログがあります。通常、ログ・アーカイブ機能によって、アクティブログがアーカイブされた時に、そのアーカイブ・ログをアクティブログとは別のディレクトリ（またはテープのような別のメディア）にコピーして保存します。このログファイルをコピーする処理も重要です。コピー先のログファイルは、コピー元やデータベース自身の障害発生時に復元の為に必要になるので、コピー元とは全く別のディスクやメディアに保存する必要があります。また、ログ・アーカイブ機能はデータベースが使われている時に動作しますので、もし同じディスクにコピー先を配置してしまうと、コピー先の書き込みI/Oの為にアクティブログ自身のI/Oへ影響を与える可能性があります。データベースのパフォーマンスを維持するためには、できる限りこのような影響は排除する必要があります。

１つの作業単位（UOW）によって大量のデータを更新するような場合、コミットとコミットの間隔が非常に長くなります。このような場合、データベース構成パラメータのログバッファー（LOGBUFSZ）を大きくするとパフォーマンスに好影響を与えます。このような更新処理の場合、ログバッファが小さいと（デフォルトでは32KB）、更新処理がコミットされていなくても、ログを頻繁にディスクに書き出さなければならなくなる為に、パフォーマンスに悪影響があります。

ログをローデバイスに配置する機能をDB2はサポートしていますが、V9では推奨されません。ローデバイスロギングを使用する場合、何らかの問題があってログ・アーカイブ機能によるログファイルのコピーに失敗し、アクティブログのデバイス中に特定のログファイルが残ってしまったようなケースでは、手動でコピーすることができません。障害時の復旧作業は、通常時とは異なり、多種の問題が発生している可能性があり、手動で復旧できないということは、安全性が低いとも言えます。また、DB2の二重ログの機能はローデバイスで使用することはできません。



ワーク／バックアップ領域の配置

バックアップ時間の短縮が必要な場合、バックアップ領域のパフォーマンスを考慮する

ディスクへのバックアップの場合、バックアップ元のあるディスクとは別にする１つのディスクでは要求が満たせない場合、複数のディスクへのバックアップを検討テープへのバックアップは、TSMがサポートしていれば、複数テープへの同時書き込みによって高速化が可能

ロードの処理時間短縮が必要な場合ロード元のデータを格納するファイルシステムのパフォーマンスを考慮するAIXでは、以下のパラメータがパフォーマンスに影響する場合がある

vmtuneのminpgahead, maxpgahead（ファイルシステムの先読み）

一時表スペースと同居できるかロード時の入力ファイルと、ソート用の一時表スペースのI/Oが競合するとロードのパフォーマンスに悪影響が考えられる通常は、再編成時にはロードやバックアップなどの処理は行わない。



その他の領域

DB2診断情報格納ディレクトリー

インスタンス・ホーム・ディレクトリー（デフォルト）、または、データベース・マネージャ構成パラ

メーターDIAGPATHにて指定した場所に格納される

管理通知ログ、db2diag.log、ダンプ・ファイル、トラップ・ファイル、コア・ファイル (UNIX のみ)を

格納する

V8.2以降は、db2diag.logへ書かれる内容が増えているため、V8.1以前より容量が増

える可能性がある。

データベース・ディレクトリー

バッファープール情報、表スペース情報、データベース構成情報、リカバリ履歴ファイル、ログ

制御ファイル



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

スレッドモデルへの変更メモリーモデルの変更バッファープール関連のパラメーター

プリフェッチャーページクリーナー

その他低限構成すべきパラメーター自己チューニングメモリー(Self Tuning Memory Manager)






スレッドモデルへの変更

V9.5からは、 UNIX、Linux プラットフォームにおいて、従来のようなプロセス・モデルではなく、db2syscプロセスが 1つ存在し、残りのEDUは db2syscプロセス配下にスレッドとして存在するアーキテクチャーに変わった。

UDB Client Library

Active

db2agntp

Write Log Requests

Victim

Not

ificat

ions

Parallel, Page

Write Requests

Shared Mem & Semaphores, TCPIP, Named Pipes,…

Process/Thread Organization

Instance Level

Per-instance

Idle, pooled agent or subagent

db2tcpcm db2ipccmdb2agent (idle)

Per-application

db2agent

db2pclnr

db2pfchr

db2loggwdb2dlock

db2agntp

db2loggr

Per-database

Data Disks

CommonClient

Subagents

UDB Server

Listeners

CoordinatorAgents

Prefet chersPage

Cleaners

Buffer Pool(s)DeadlockDetector

Log Disks

Idle Agent Pool

LoggingSubsystem Log Buffer

Database Level

Idle

Async IO Prefetch Requests

Parallel, B

ig-block,

Read Requests

V9.5からは、点線枠で囲まれた部分は、1つのプロセスとなる。各EDUは、スレッドとして存在して、 db2syscプロセスに紐づく。

db2fmp

db2acd

FMP

Health Monitor

db2wdog

V9.5



スレッドエンジンのメリット

リソースの節約EDUがプロセスだった際には、個別のプロセスで保持していたファイル・ハンドル情報を、db2syscプロセスが持つメモリー空間で共有するので、情報の二重持ちがなくなる。システムスレッドのオペレーションはプロセスほどコンテキストを要求しない

アドレススペースとコンテキスト情報を共有する

パフォーマンスの向上スレッド間でのコンテキストスイッチは、プロセス間でのやり取りに比べれば、一般的に速い。

使いやすさの向上インスタンス全体で消費されるメモリー量の把握が、従来より容易になる。AUTOMATICに設定、動的に変更可能な構成パラメーターが増える。エージェント間で情報が共有されるため、アプリケーション・グループ共用メモリーが不要になる。

上記に伴い、以下の構成パラメータは廃止される。– APP_GROUP_MEM_SZ– GROUPHEAP_RATIO– APP_CTL_HEAP_SZ

V9.5



メモリー・モデルの変更(DB2 V9.5)

DATABASE_MEMORYデータベース共用メモリー領域に予約されるメモリー量を指定する

APPL_MEMORYデータベースエージェントが割り振るアプリケーションメモリーの大量を制御

INSTANCE_MEMORY1つのデータベースパーティションに割り振ることができるメモリー大量

V9.5



Automatic管理となったヒープ(メモリー関連)

V9.1でautonomic管理となっているヒープ(=STMMが管理)buffer poolslock listmax lockspackage cachesort heap

V9.5でautonomic管理となるヒープapplication heapdbheapmonitor heapstatement heapstatistics 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

V9.5



メモリー構成単純化のメリット

構成の簡素化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

１つのデータベースパーティションに割り当てることが可能な大メモリーサイズを指定する

デフォルト値(=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

INSTANCE_MEMORYサイズに達した状態で、特定ヒープに対してメモリー拡張要求が来た場合１．DB2は全ての共有メモリー、プライベートメモリーから要求されたメモリー量を削減しようと試みる２．上記対応後も十分な空きINSTANCE_MEMORY領域を確保できなかった場合、拡張要求は失敗す

る

(例外)DB2の稼動に致命的な影響を与えるメモリーに対して拡張要求が来た場合

致命的な影響メモリー拡張要求が失敗することで、DBが無効とみなされるインスタンスがシャットダウンしてしまう

１．データベースパーティションで使用している現在の使用メモリーサイズの削減を試みる２．上記対応後も十分な空きINSTANCE_MEMORY領域を確保できなかった場合、DB2はOSにメモリー

要求を出し、OSからメモリーを確保するOSからメモリーを確保できた場合、INSTANCE_MEMORYのサイズが構成値を上回ることがある

考慮点同一サーバー上で、別ミドルウェアも並行稼動する場合、もしくは複数のインスタンスが並行稼動する場合には、INSTANCE_MEMORYに適切な値を設定することで効率良いメモリー配分が可能となる

V9.5



APPL_MEMORY

アプリケーションを実行するために割り当てることが可能な大メモリーサイズを指定する

DBで消費されるアプリケーションメモリーの合計量をこのパラメーターで制限することができる

デフォルト値(=AUTOMATIC)DB活動化の時点で、少のメモリーが割り当てられる

APPL_MEMORYに数値が設定された場合DB活動化の時点で、設定されたメモリーサイズが割り当てられ、APPL_MEMORYサイズの増減は発生しない初期設定値のメモリーをサーバーから取得できなかった場合、もしくは、INSTANCE_MEMORYの値を超えた場合、DBの活動化はSQL1084Cで失敗する

考慮点DATABASE_MEMORYに一定量のメモリーサイズを確保しておきたい場合には、APPL_MEMORYで使用可能なメモリーサイズを制限する

V9.5



バッファープール関連のパラメーター

バッファプールの構成表スペースのディスクに対する入出力のキャッシュLOBに対してバッファプールは効果が無い

プリフェッチャー（NUM_IOSERVERS）を十分に構成するこのパラメータは必要より大きく構成しても、ほんの少しメモリを消費するだけで他の悪影

響は考えられない物理ディスクの数＋２程度が推奨

ページクリーナー（NUM_IOCLEANERS）も十分に構成するこのパラメータは大きく構成し過ぎると、CPUの負荷を必要以上に大きくする可能性があ

るCPUの数を初期値に、大で物理ディスク数迄



解説

パフォーマンスにも影響を与えるパラメータがバッファプールと言われています。DB2が使用するメモリー領域の中で通常、も大量にメモリーを使用します。バッファプールは表及び索引・データのキャッシュに相当します。バッファプールはデータベースが活動化時（通常初の接続が行われた時）にアロケーションされ、非活動化時（後の接続が切断された時）に解放されます。バッファプールのみを大きくしても、物理ディスクのIOを行うプリフェッチャーとページクリーナーが少なければ、効果が上がらない可能性があります。プリフェッチャーの初期値は、表及び索引を配置している物理ディスクの数+2（物理ディスク数はRAID5ディスクの場合、パリティ・スペアを除く）と一般的に言われています。ページクリーナーはCPUの数から物理ディスクの数の間で調整します。初期値はCPUの数（物理ディスク数はRAID5ディスクの場合、パリティ・スペアを除く）。RAID5等ストライピングされたディスクを表スペースに使用する場合、プリフェッチャー及びページクリーナーは通常ディスクと同様に調整する必要がありますが、さらにdb2setコマンドで設定する環境変数：db2_parallel_ioに＊（全ての表スペース）また特定の表スペースIDを指定する必要があります。バッファプールのサイズは、スナップショットによってバッファープールヒット率（（論理読出数－物理読出数）／論理読出数×１００）を計算して通常評価します。通常80%から90%以上が目安ですが、システムの性格によってはそれ以下でも問題がない場合もあります。



プリフェッチャー（NUM_IOSERVERS）

プリフェッチャーは先読みを行う時に使用される。

データベース構成パラメーター「NUM_IOSERVERS」にて数を指定。V9以降、デフォルト値はAUTOMATIC（V8以前のデフォルト値は「3」）

AUTOMATICの場合、データベース活動化時点で、適正値を計算

cont contcont

Bufferpool

Prefetcher PrefetcherPrefetcher

Prefetcher

必要のないプリフェッチャーは使用されない

page page page page page page page page

pagepage page page

Prefetcher Prefetcher

Prefetch単位

Extent Extent Extent

表スペース



解説

バッファプールに表スペースからデータを読み込む時に、小さなデータを読み込むのであれば、通常はエージェントが直接読み出して、バッファプールに格納します。しかし、連続したデータを読み込むような場合は、DB2が判断し、プリフェッチ（Pre-Fetch：先読み）を行います。このプリフェッチは、プリフェッチャーと呼ばれるプロセスによって行われます。プリフェッチャーの数はデータベース毎に指定できます。データベース構成パラメータ：NUM_IOSERVERSです。

プリフェッチャーが効率よく動作するためにはもう一つ構成が必要です。それは表スペースの属性である、PrefetchSizeです。各プリフェッチャーはそれぞれ１回の読み込みで、ExtentSize分のページを読み込みます。PrefetchSizeはExtentSizeの何倍になっているかによって、幾つのプリフェッチャーが必要なのかが決まります。ここで重要なのは、PrefetchSizeはExtentSizeの倍数である必要があるという点です。何倍かは、コンテナー数倍を基本とします。

上記の図の例で考えてみましょう。表スペースは、物理ディスク３つから構成されています。表スペースのExtentSizeはデフォルトの32ページとします。この場合、この表スペースの適なPrefetchSizeは、ExtentSize×表スペースを構成する物理ディスク数となり、96ページということになります。

この構成によって、プリフェッチャーはこの表スペースを先読みする際には、３つ使用され、それぞれのディスクを別々のプリフェッチャー・プロセスがIOし、ディスクIOの効率化を図ります。この際、表スペースは、各ディスクに１つずつ合計３つのコンテナーから構成する必要があります。OSのストライピングによって複数のディスクから単一のコンテナーを構成することも可能ですが、DB2に複数ディスクから構成されていることを明確にし、ディスクの入出力をDB2によって効率化する為にも、OSのストライピングよりDB2のストライピングの方が推奨されます。

近の物理ディスクは、飛躍的に速度が速くなっているので、PrefetchSizeは必ずしもExtentSize×物理ディスク数でなくても、その倍程度でも効果があることが確認されています。物理ディスク装置へのSCSI またはファイバーチャネルの速度などにもよるので、一概には言えませんが、倍、3倍、4倍程度を試してみて効果があればそのPrefetchSizeが、もパフォーマンス的に優れているということになります。

プリフェッチャーの構成（NUM_IOSERVERS）は、大きすぎても使われないプロセスが起動されているだけなので、多少のメモリを余分に消費するのみのため、多少多めに構成しても、ほとんど問題がありません。



ページ・クリーナー（NUM_IOCLEANERS）

ページクリーナーは以下の時に呼び出されるソフトチェックポイントページ変更しきい値（chngpgs_thresh）に達したとき

データベース構成パラメーター「NUM_IOCLEANERS」にて数を指定。V9以降、デフォルト値はAUTOMATIC（V8以前のデフォルト値は「1」）

AUTOMATICの場合、データベース活動化時点で、適正値を計算

② 更新済みページがCHNGPGS_THRESの値（％）を超えた場合

db2pclnr

表スペース

cont1 cont3

NUM_IOCLEANERSデータベース

構成パラメータの値

更新済みページ

バッファープール

ログファイル

LOGFILSZ

① （A）が（B)と比較してログファイルのSOFTMAX（％）よりも古い場合

（A）バッファー・プール内のも古いページに含まれている更新内容のログ・レコード

（B) 新の更新内容

db2agent

データ更新

db2pclnr

cont2

db2pclnr



解説

これに対して、バッファプールから表スペースに対してデータを書き出すプロセスを、ページ・クリーナーと呼びます。プリフェッチャーと同様に、データベース構成パラメータ：NUM_IOCLEANERSによって構成します。

ページ・クリーナーがプリフェッチャーと異なる点は、多く構成しすぎると、CPUへのオーバーヘッドになる可能性があるという点です。ページ・クリーナーは幾つかの事象によって起動されますが、ページ・クリーナーが起動される時は、構成されているクリーナーが全て起動されます。必要な数よりも多く構成されていた場合、多くのクリーナーが起動されることになり、それがCPUの負荷を必要以上に高める可能性があります。

ページ・クリーナーの初期値がCPUの数と言われているのはこのためです。プリフェッチャーの数は物理ディスクの数＋２程度と言われています。このように、バッファプールはそれだけを大きくしても、バッファプール－ディスク間のデータのやりとりを行うプリフェッチャーおよびページ・クリーナーを表スペースのPrefetchSizeおよびExtentSizeと共に正しく構成しないと、ディスクへの入出力を効率化し、パフォーマンス向上を図ることは難しくなります。

ページ・クリーナーが呼び出されるタイミング

ページ・クリーナーが呼び出されるタイミングに影響を与えるパラメータが以下の構成パラメータです。ページ変更しきい値（chngpgs_thresh）softmaxおよびlogfilsiz

ページ変更しきい値は、バッファプール中のこのパラメータで指定した比率がダーティページ（データが更新され、バッファプール上では更新されているが、ディスクには反映されていないページのこと）になったら、ディスクにダーティページを書き出そうとします。また、logfilsizとsoftmaxによって、ソフト・チェックポイントを発生させ、ダーティページをディスクに書き出すことも可能です。ソフト・チェックポイントの正確な意味を考えると多少混乱するかもしれませんが、大体、ログが切り替わるタイミングでソフト・チェックポイントによって、ダーティページをディスクに書き出すと考えてよいでしょう。Softmaxはデフォルトでは100%で、logfilsizと同じですが、softmaxを小さくするかlogfilsiz自身を小さくすることによって、頻繁に発生させることができます。このダーティページの量は、クラッシュ・リカバリーと呼ばれるDB2によるリカバリー処理に大きな影響を与えます。



AUTOMATIC値の算出<NUM_IOSERVERS>

算出方法以下の3つの値の中で、も大きな値を設定値とする

1.V8でのデフォルト値(3)2．SMS表スペースで、(「コンテナ数」*「DB2_PARALLEL_IOで設定された並行処理物理ディスク数」) の、全SMS表スペースでの大値3．DMS表スペースで、(「表スペースのストライプセットにあるコンテナの大数」 * 「DB2_PARALLEL_IOで設定された並行処理物理ディスク数」)の、全DMS表スペースでの大値

低でも、3つのプリフェッチャーが起動

算出値に影響する項目表スペースのコンテナ数DB2_PARALLEL_IOレジストリー変数で指定された、並行処理物理ディスク数



AUTOMATIC値の算出<NUM_IOCLEANERS>

算出方法以下の値のうち、大きな方の値を設定値とする

1.V8でのデフォルト値(1)– 低でも1つのページクリーナーが起動

2.ＣＰＵ数 -1– ＤＰＦの場合

CEIL(CPU数÷同一サーバー上のDBパーティション数)－1*CEIL=少数部分を切り上げ

各DBパーティションに配布されるページクリーナー数がほぼ均等、かつCPU数を超えないように算出

算出値に影響する項目CPU数ＤＰＦの場合、DBパーティション数



その他低限構成すべきパラメーター

ログ関連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

よくわからない場合は、構成アドバイザーで初期値を設定V9では、データベース作成時に、システムリソース(メモリー、CPU、等)を考慮し、構成パラメーターをデフォルトで自動設定する

構成アドバイザーの機能によってパラメーターが決定される。V8.2までは、構成パラメーター(DBM, DB)のデフォルト値は固定

V9では、自己チューニング・メモリー（STMM)機能がデフォルトで稼動STMMでのチューニング対象になっているメモリー領域は、デフォルト値がAUTOMATICになっている

http://www.ibm.com/jp/domino01/mkt/cnpages1.nsf/page/default-000A5CD1



解説

ログ関連logfilsiz,logprimary,logsecond

ログは、大のトランザクション（通常大量更新を行うバッチジョブなど）で使用されるログ容量をスナップショットより測定し、その数値を元に（データ件数などの増加率などを含めて）見積もり、LOGFILSIZ,LOGPRIMARY,LOGSECONDパラメータを調整します。ログ容量＝LOGFILSIZ×（LOGPRIMARY＋LOGSECOND）×4096（バイト）ファイルサイズ（LOGFILSIZ）をあまり大きくすると、ログ・ファイルの切り替えの際にディスクIOの負荷が大きくなり、あまり小さくすると頻繁にログ・ファイルが切り替えられるために（ログ・ファイル切り替え時には、バッファプール中の更新されてディスクに書かれていないダーティ・ページが、ディスクに書き出される）、バッファプールが有効に利用されない場合があります。活動ログに使用するファイルシステムは、ログ容量の約２倍用意する必要があります。これは、１時点で大量のログが使用された場合にアロケーションされる、次のログファイルの為の領域です。ディスクに余裕がある場合は、64GB(V.7の大ログ32GBの倍)用意しておくと活動ログのファイルシステムが不足することが無くなります。ローデバイスのログは、管理が難しいので使用しないことを推奨します。

ロック関連locklst,maxlocks

ロックの為のメモリー領域(locklist)は、クライアント数や１つの更新単位（１つのCOMMITまでにINSERT,UPDATE,DELETEによって更新される行の数）にあわせて調整する必要があります。Locklistが不足していると、ロックエスカレーション（通常ロックは行単位ですが、ロック用メモリーが不足した場合、表単位のロックに自動的に変わること）が発生し、長時間のロック待ちやデッドロックなどが発生する可能性があります。但し、通常夜間などに実行される大量更新の為のバッチジョブ等に関しては、ロックエスカレーションが問題にならない場合もあります。スナップショットの、locklist使用量およびLock Escalationの頻度などによって調整します。通常Lock Escalationは、オンライン系トランザクションではできるだけ発生させないように、メモリーサイズを大きくします。



解説

ソート関連sortheap,sheapthres

ORDER BYを使用したSQLなどで使用するソート（分類）用のメモリー領域(SORTHEAP)ここで定義したメモリー領域では容量不足の場合、一時表スペースがソートのために使用されます。この場合、ディスク上でソートを行うので、メモリー上の場合よりパフォーマンスが悪化する可能性があります。各接続に対してアロケーションされるSORTHEAPを大きくした場合、インスタンス全体で使用できるソートヒープを制限するDBM構成パラメータSHEAPTHRESも調整する必要があります。SHEAPTHRESの理想的なサイズは、インスタンス配下の（SORTHEAP×同時接続数）です。

エージェント関連maxappls,maxagents,num_poolagents,num_init_agents

クライアントからＤＢサーバーに接続すると、サーバープロセスのバックエンドでエージェントが起動されます。エージェントの起動はサーバーへの負荷が非常に高い為、あらかじめサーバー上にエージェントを起動しておくnum_initagentsパラメータ（db2start時に起動）、または１回使用されたエージェントを解放せずに次回の接続時に再利用するnum_poolagentsパラメータによって調整することができます。エージェントはデータベースの非活動化によっては解放されません。num_initagentsおよびnum_poolagentsによって保持されているエージェントはdb2stopによって解放されます。WAS等のアプリケーションサーバーを使用し、接続プールなどの機能によって接続数が固定されている場合、パフォーマンスにあまり影響を与えませんが、接続・切断を繰り返すようなアプリケーションが存在する場合は、応答時間およびサーバー負荷に大きな影響を与えるため、調整する必要があります。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／接続まで実メモリーの空き容量を見積もる必要があります。

V9.5

V9.5



解説

その他applheapsz

複雑なSQL文の実行より複雑なSQL文を処理する場合、アプリケーション・ヒープ（applheapsz）およびステートメント・ヒープ（stmtheap）が不足する可能性があります。特に、アプリケーション・ヒープは、Websphere Application ServerのPrepared Statement Cacheのように１つの接続上でステートメントを複数同時に実行するような場合に、大きくする必要があります。ただし、applheapszはデフォルトの 128ページでは不足するケースがよくありますが、512または1024ページを指定すれば、かなり複雑なSQL文を処理でき、ほとんどのケースでは十分なはずです。V9.5では、このパラメーターの意味合いが変更されています。以前の1つの接続のために設定されるパラメーターではなく、アプリケーション全体で消費されるアプリケーションメモリーの総量に変更になりました。

アプリケーション・ヒープ不足もし、あなたが担当しているシステムで、applheapszに10MBを超えるような値（2500ページ以上）にしないと、「アプリケーション・ヒープ不足です」というエラーが発生する場合、そこで動作しているアプリケーション・プログラムが宣言して使った資源（ステートメント・ハンドルなど）を確実にクローズしているかを確認してください。

そのような接続上にゴミを残すようなアプリケーションを動かしている場合、applheapszを極端に大きな値にしなければ、動かしている途中でエラーが発生します。

applheapszを大きくするということは、その接続数分だけメモリ上にゴミが残るということになります。そのようなシステムでは、長時間の連続稼働によって、メモリの使用量が増加し、システムが不安定になる場合があります。そのようなケースでは、アプリケーション・ヒープを増やして対応せずに、アプリケーション・プログラムを直して、接続上にゴミを残さないようにしてください。

dbheapバッファプールを大きくするとデータベースヒープが不足する場合があります。この場合、データベースヒープも大きくする必要があります。データベース・ヒープにはログ・バッファー、カタログ・キャッシュ（V8では別）が含まれます。これらを大きくする場合もデータベース・ヒープを大きくする必要があります。

intra_parallelこのパラメータは情報系のシステムの為のものなので、OLTP系のシステムではデフォルトのOFFのままにし、YESに設定しないようにしてください。

maxfilopこのパラメーターは、データベースに対して同時に開くことのできるファイル・ハンドルの大数を表すように変更されました。以前のリリースでは、各データベース・エージェントに対して、同時に開くことのできるファイル・ハンドルの大数を示していました。

V9.5

V9.5



自己チューニングメモリー(Self Tuning Memory Manager)

DB2が自動的にメモリーチューニングを実施管理者がメモリーチューニングを実施する必要なし予期しないワークロードを検知し、必要に応じてチューニング

メモリーの再分配を必要とするワークロードの変化に対応メモリーチューニングに労する時間を節約可能

情報収集→分析→設定→テスト→情報収集・・・・

対象データベース構成パラメーター

SORTHEAPSHEAPTHRES_SHRLOCKLIST(MAXLOCKS)PCKCACHESZDATABASE_MEMORY

バッファープール

データベース構成パラメーターSELF_TUNING_MEMにて設定デフォルト値はON(=STMM稼動)この値をOFFに設定することで、下位パラメーターがAUTOMATICに設定されていてもSTMMは停止

検証段階でSTMMを稼動させ、適な設定値になった時点で、STMMを停止する、という使い方も可能



解説：

V9の新機能であるメモリーの自己チューニング機能（STMM）を使用すると、DB2によって自動的にメモリー･チューニングが行われます。STMMは、ワークロードの大きな変化に対応し、構成パラメーターの値およびバッファー・プールのサイズを調整してパフォーマンスを適化します。対象となるメモリー領域は以下の通りです。

SORTHEAPSHEAPTHRES_SHRLOCKLIST(MAXLOCKS)PCKCACHESZDATABASE_MEMORYバッファープール



STMM使用時のDATABASE_MEMORY設定方法

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=COMPUTEDSTMMは稼動しないV8のAUTOMATICの動作

DB起動時の各パラメーターの初期値に基づき総容量を算出

V8からの移行時は、設定値AUTOMATICは、COMPUTEDに変更されるAIX, Windows以外のOSのデフォルト値



STMM使用時のDATABASE_MEMORY設定方法（続き）

DB2_MEM_TUNING_RANGEレジストリー変数AUTOMATIC設定時、フリーメモリーを一定量確保し、それ以外のメモリー

を使用確保するメモリー量の設定方法

db2set DB2_MEM_TUNING_RANGE =minfree, maxfreeminfree、maxfreeを定義

AIX, Windows環境のみ適用可能

設定値と意味minfree

インスタンスが追加メモリーを必要としたときに、”minfree”で指定された％に達するまでシステムの空き物理メモリーを割り振る

maxfreeインスタンスはフリーにしておく物理メモリー量を”maxfree”で指定された％で

維持する未設定（デフォルト）

DB2が物理メモリー量より算出注意

STMM = ON & DATABASE_MEMORY = AUTOMATICの環境で、空き物理メモリー量不足の問題が起きていなければ、特にチューニングに必要なし



解説：

チューナーは、database_memory 構成パラメーターによって定義されたメモリー制限内で作動します。Windows® および AIX® 上では、database_memory の値自体を自動的に調整することができます。database_memory のセルフチューニングが使用可能である (AUTOMATIC に設定されている) 場合、チューナーはデータベースの全体的なメモリー要件を判別し、現在のデータベース要求量に従ってデータベース共用メモリーに割り振られるメモリーの量を増減します。たとえば、現行データベース要求量が高く、システムに十分の空きメモリーがある場合、さらに多くのメモリーがデータベース共用メモリーによって消費されます。データベース・メモリー要求量が下げられるか、またはシステムの空きメモリー量が過度に減ると、データベース共用メモリーの一部が解放されます。

database_memory パラメーターが自己チューニングで使用できない (AUTOMATIC に設定されていない) 場合、データベース全体は指定されたメモリー量を使用し、必要に応じてデータベースのメモリー・コンシューマー間でそれを分配します。 database_memory が自己チューニングで使用できない場合、データベースによって使用されるメモリーの量は 2 つの方法 (database_memory を数値に設定するか、COMPUTED に設定する) で指定できます。 COMPUTEDは、V8以前のAUTOMATICに相当し、メモリーの合計量は、データベース起動時のデータベース・メモリー・ヒープの初期値の合計に基づいて計算されます。






STMM使用時のその他のパラメーター設定方法

LOCKLIST, PCKCACHESZ, SORTHEAP, SHEAPTHRES_SHR

現在の設定値からチューニングを開始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

xxxは各パラメーター名

yyは設定値



バージョンによるソートの違い

V8.2までのソートプライベートソートの場合（エージェントプライベートメモリーを使用）

SORTHEAP(DB CFG) & SHEAPTHRES(DBM CFG)で設定専用ソートによって使用されるメモリーの合計量におけるソフトリミット

共有ソートの場合（データベース共有メモリーを使用）SORTHEAP(DB CFG) & SHEAPTHRES_SHR(DB CFG)で設定

– SHEAPTHRES_SHR=0の場合、SHEAPTHRESの値が使用されるSHEAPTHRES_SHRは１時点にソート用として使用できるデータベース共有メモリーの合計量に対するハードリミット条件

– 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






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

データベース構築に必要なシェル／コマンド






データベース構築に必要なシェル／コマンド

以下のような操作を行うシェルやコマンドを用意する論理ボリューム，ファイルシステムの作成、権限の変更

OS上の操作でDB2が使用する資源を準備する

WindowsではファイルDMSが一般的 <- MSCSではローデバイスが使用できないことも要因

データベース作成データベースのホームディレクトリーログの配置変更(newlogpath)デフォルト表スペースやページ・サイズの変更

バッファプール・表スペース作成prefetchsize , extentsizeを正しく設定（extentsizeは後から変更できないので特に注意）

表・索引作成その他

構築時に使用したシェルは、事前にテスト環境で十分に検証を行う。また、再構築などで使用する場合に備えてきちんと管理しておく。

AIX Volume Group(VG) Physical Volume(PV) Logical Volume(LV)

Veritas Disk Group(DG) subdisk volumeplex(ストライプ時など)



解説

論理ボリューム・ファイルシステム作成、権限の変更AIXの例

データベース作成例（/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"

論理ボリューム作成 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



OS特有の設定

AIXAIO（非同期I/O）

V8以降、設定は必須（ページクリーナーが使用）– db2_installを使用してDB2を導入する場合は、手動で設定する必要があ

る。（db2setupを使用すると、導入時に自動設定される。）大サーバー数の目安 = 物理ディスクの数 × 10

vmtune（AIX5.1以前）, vmo（AIX5.2以降）JFSのファイルキャッシュを抑えるために使用(minperm,maxperm)JFS2の場合、maxclient（ハードリミット）によって制限

LinuxAIO（非同期I/O）

V8.2.2では、レジストリー変数DB2LINUXAIOにて設定。– db2set DB2LINUXAIO=true

V9では、デフォルトで使用可能。（明示的な設定は不要。）– レジストリー変数DB2LINUXAIOは、V9では推奨されない。（将来削除

される予定。）



解説

AIXAIO(非同期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の数を増やすと、パフォーマンスに対する効果が期待できます。

LinuxAIO(非同期I/O）

V8.2.2では、Linuxで非同期I/Oを使用可能にするために、DB2LINUXAIOレジストリー変数を使用していましたが、V9.1ではデフォルトで使用可能になりました。V9ではこの変数は必要ではなくなったため、将来のリリースで廃止される可能性があります。

Documents

データベース物理設計【DB2 9.5 対応版】 - IBM...DB2デザイン・ガイド データベース物理設計 ©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株)

データベース物理設計【DB2 9.5 対応版】 - IBM...DB2デザイン・ガイドデータベース物理設計 ©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株)