データベース物理設計【DB2 9.7 対応版】 ©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部＜第１．００版

by user

on 15 сентября 2016

Category: Documents

>> Downloads: 100

733

views

Report

Comments

Description

Download データベース物理設計【DB2 9.7 対応版】 ©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部＜第１．００版

Transcript

データベース物理設計【DB2 9.7 対応版】 ©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部＜第１．００版

データベース物理設計
【DB2 9.7 対応版】
＜第１．００版２０１1年 7月＞
お断り：当資料は、DB2 for Linux, UNIX and Windows V9.1をベースに作成されています。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
データベース物理設計
DB2デザイン・ガイド
ブランク・ページです
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
2
データベース物理設計
DB2デザイン・ガイド
目次
物理設計の流れ
物理設計作業開始にあたって
①表／索引定義の作成
②データ容量の見積もり
③インスタンスの構成とデータベースの分割
④表の分類と表スペースの構成
⑤表スペースの配置
⑥表スペース以外のオブジェクトの配置
⑦構成パラメーターの設定
⑧シェル／コマンドの作成
OS特有の設定
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
3
データベース物理設計
DB2デザイン・ガイド
ブランク・ページです
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
4
データベース物理設計
DB2デザイン・ガイド
物理設計の流れ
①表／索引定義の作成
・表の分割／参照整合や制約／属性、長さの決定
・主キー（１次索引）
・検索やジョインのパターンによって２次索引作成
②データ容量の見積もり
・データ項目、長さ、索引などは既に決まっている前提
・ページ・サイズの決定
・表、（索引）サイズの見積もり
③ インスタンスの構成とデータベースの
分割
・インスタンスの分割も検討
・バックアップ単位であるデータベースの分割を検討
④表の分類と表スペースの構成
・表の分類と表スペース構成の決定
・表スペースのタイプ、その他の属性の決定
⑤表スペースの配置
・物理ディスク上への表スペースの配置
・コンテナーの設計
⑥表スペース以外のオブジェクトの配置
⑦構成パラメーターの設定
⑧シェル／コマンドの作成
・ログ、バックアップ用、ワークスペースの配置
・物理設計にあわせた構成パラメーターの変更
・これまでに設計したオブジェクトを作成するコマンドおよびシェルを作成
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
5
データベース物理設計
DB2デザイン・ガイド
解説
データベースの物理設計を行う場合、ディスクおよびサーバーを含むハードウェア構成が決まっている必要がありま
す。また、表の論理設計も既に終了していることが前提です。
表の論理設計を実際のハードウェア上にどのように構築するかを決定することが、「物理設計」ということになります。
純粋な論理設計では、まだどのデータベース製品を使うかにはあまり依存しません。しかし、どのようにディスク上に
配置し、メモリを割り振るかを決定する物理設計はデータベース製品に特化した作業になります。
①DBMSに特化しない論理設計では、カラムの属性・長さなどが決まりません。物理設計の最初にまずこれらの
DBMSに特化した表定義を決定します。例えば、データは日付なのですが、格納方法はDATEにするか
TIMESTAMP,CHARまたはVARCHARにするかなどの選択肢があります。
②データ容量を見積もります。論理設計によってできあがった表のレイアウトとレコード数から容量を見積もり、必要
となるディスク容量を計算します。
④次にそれらの表を幾つかのグループに分類します。そしてそれらの表を配置する表スペースの定義を決めていき
ます。
⑤物理ディスクへの表スペースの配置を決定します。
⑥⑤で配置した表スペース以外のオブジェクトの配置を決定します。
⑦物理設計に関連した構成パラメーターを設定します。
⑧最後に行うのは、これらの設計に基づいたファイルシステムや論理ボリュームなどを作成するシェル・スクリプトの
作成と、これらの上に表スペースおよび表、索引を作成するDDLの作成です。
データベースの物理設計は基本的には以上の作業を行い、ドキュメントを作成し、実際のハードウェア上に構築する
ところで終了します。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
6
データベース物理設計
DB2デザイン・ガイド
物理設計作業開始にあたって
論理データベース設計作業が完了していることが前提
z 論理データベース仕様の後からの変更は困難
z
z
z
z
¾
アプリケーション開発作業に多大な手戻りを発生させる可能性がある
論理設計で決めた表をDB2データベースの表として定義
作成したデータベース仕様をシステム上の物理記憶域にマッピング
DB2の製品仕様に依存する作業であるため、DB2の製品知識が必要
使用するオペレーティング・システム毎の知識も要求される
データベース設計の最終目標
z 時代の変化に伴う多様な要求の出現に対応できる安定したデータベースを構築す
る
z 各種要件（アプリケーション、性能、運用等）を最適に実装するデータベースを検討
する
¾
運用設計、障害回復設計とも同期を取りながら進めて行く
¾
充分にテストを実施して、データベース設計が最適に実装されているかを検証する
必要がある
z パフォーマンス・チューニングや運用の効率化のため適宜物理設計の見直しも必要
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
7
データベース物理設計
DB2デザイン・ガイド
解説
物理設計作業開始にあたっては、論理データベース設計作業がきちんと完了していることが必要です。論理設計完
了後の変更は、アプリケーション開発作業に多大な手戻りを発生させる可能性があります。
物理設計作業は、表の論理設計で決められた表を、DB2のデータベースの表として定義することです。
実際に、物理記憶域のどこにどのように表スペースや表、索引といった各オブジェクトを配置するかのマッピングを
行ないます（論理設計で作られた論理モデルの｢実装｣を行なうことになります。）
DB2の製品仕様に依存する作業であるため、DB2の製品知識が必要とされます。
また、ファイル・システムなど使用するオペレーティング・システム毎の知識が要求されることもあります。
データベースの設計の目標となるのは、自分の環境を、理解しやすくしかも将来の拡張の基礎となるよう表現したも
のを作ることです。また、データの一貫性や整合性を保ちやすいデータベース設計が望ましいと言えます。そのため
には、設計の段階で冗長性を少なくし、データベースの更新時に生じ得る異常をなくす必要があります。
また、アプリケーション要件や、性能、運用要件等を最適に実装するものでなければいけません。
運用設計、障害回復設計とも同期を取りながら進めて行く必要があります。
データベースの設計は、一度で終了するものではありません。多くの場合、何度かやり直すことが必要になります。
パフォーマンス・チューニングや運用の効率化のため適宜物理設計の見直しも必要になるのです。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
8
データベース物理設計
DB2デザイン・ガイド
①表／索引定義の作成
列の設計
z データ・タイプと長さの決定
主キーと外部キー
制約
z 固有制約
z 参照制約
z 表検査制約
表の設計
索引の設計
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
9
データベース物理設計
DB2デザイン・ガイド
解説
表、および索引定義の作成にあたっては、事前にDBMSに特化した仕様を考慮して、様々
な項目を決定する必要があります。
ページサイズは、データの容量やディスク容量、DB2の制限値を考慮して、適切なものを
決定します。
主に以下のような点について、DBMSに特化した表定義を決定していきます。
z
z
z
z
列の設計（データ・タイプと長さなど）
主キーと外部キー
制約
¾
¾
¾
固有制約
参照制約
表検査制約
索引設計（１次、２次）
変更により適用業務に大きな影響を与えるものとして、例えば以下のものがあります。（V9
では、以下の変更はALTER TABLEステートメントで行うことができます。）
z
z
z
データ・タイプの変更
データの長さの変更
NOT NULL指定の変更
以下のものは、変更があっても適用業務に影響しないよう回避する方法はあります。
z
データベース名の変更
z
表名の変更
z
列名の変更
z
列の順序変更
¾
CATALOG DATABASEで別名設定
¾
RENAME TABLEで表名の変更、視点の作成により対応
¾
視点の作成により対応
¾
視点の作成により対応
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
10
データベース物理設計
DB2デザイン・ガイド
列の設計
列のデータ・タイプと長さの決定
z
データ長やとり得る値の制限値により、最適なデータ・タイプを選択する
z
文字列（CHAR/VARCHAR/GRAPHIC/VARGRAPHIC）
z
z
z
z
¾
開発言語環境による生産性の観点での考慮なども必要
¾
可変長 or 固定長？ ⇒ 原則、固定長を使用することを推奨
¾
UNICODEデータベースではGRAPHICはNCHAR/NVARCHARも使用可
¾
¾
CHARで保持するより、格納サイズが小さい
YEAR , MONTH , DAY などの日付計算、時間計算関数が使用可能。DB2が計算・値のチェックを
行える
– 可変長（VARCHAR）は固定長（CHAR)に比べて4バイト分余計に必要
– 可変長は、該当列の位置を認識するためにCPU負荷が増加
– 固定長は定義した長さ分の領域を必ず使用する（圧縮を採用した場合はこの限りでない）
日付／時刻形式（DATE/TIME/TIMESTAMP）
数値（SMALLINT/INTEGER/BIGINT/REAL/DOUBLE/DECIMAL/DECFLOAT）
V9.5
¾
¾
¾
算術に使用するのであれば、通常は数値型。最大取り得る値によって、データ・タイプを選択する
CHARで保持するより、格納サイズが小さい
V9.7
小数点以下がある場合はDECIMALを検討
¾
¾
LOBについても、他の表データとは別の場所に保管され、各列の情報（ポインター）のみを他データ
と共に持つ
データが4KB以下の場合、LOBはなるべく使用しない
¾
¾
XML文書を格納する。
コード・セットUTF-8以外のデータベースでも使用可能。（ただし、XML列はUTF-8で格納される）
LOB型（CLOB/DBCLOB/BLOB) ※LONG VARCHAR/LONG VARGRAPHICは9.7より非推奨
拡張マークアップ言語（XML）
V9.5
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
11
データベース物理設計
DB2デザイン・ガイド
解説
数値・文字列（固定長・可変長）・日付・XMLなどのうちどれを選択するか、データ長や、
とり得る値の制限値により適したデータ・タイプを選択します。
また、開発言語環境によって扱い易いデータ・タイプであるのか、生産性の観点など
からの考慮も必要です。
文字列
z
z
z
z
z
可変長か固定長か決定する必要がありますが、まずは固定長を検討します。
可変長の場合は、長さとオフセット情報を入れる領域が列あたり4バイト分余計に必要になります。
可変長の場合は、該当列の位置は先頭からたどらなければならないため、CPUの負荷が該当列の位置がわかっている固定
長よりも余計にかかります。
列長の差が大きい（列あたり平均２０バイト以上）時には可変長を採用することで、DISKスペースは削減されます。
UNICODEデータベースにおいては、GRAPHICをNCHARやNVARCHARとして指定することができます。
日付／時刻のデータ
z
数値
z
日付計算、時間計算、関数の使用が可能になるように、DATE/TIME/TIMESTAMPを使用してください。また、その方が、
CHARデータタイプとして格納するよりもDISKスペースは軽減されます。
算術に使用するのであれば、通常は数値型で格納すべきです。該当の項目の最大取り得る値によって、データ・タイプを選択
します。また、文字列で格納するよりもDISKスペースは軽減されます。
LOB型
z
z
z
XML
z
z
z
z
z
LOBタイプは表データ・ページに実際の列のデータは含まれません。別の表オブジェクトとして表スペースに格納されます。行
データ中にはそれらの列の２０バイトの記述子（descriptor）は含まれます。
LOBタイプのデータをLOB専用の表スペースに格納させることも、CREATE TABLE時の指定で可能です。
４KB以下の文字データについては、上述のような特異な扱いを避けるためにもLOBタイプは使用しないようにするなど、デー
タ長の制限値により、適したデータタイプを選択してください。
XML文書は、階層構造を持つデータとして格納されます。
LOB 列と同様に、XML列は列の記述子であるXMLデータ指定子（XDS）のみを保持します。XMLデータ自体は、別個にXDAと
呼ばれるストレージ構造保管されます。
XML文書のサイズの上限は、2GBです。
V9.7
DPF/MDC/パーティション表もサポート
XDA/XML索引の圧縮機能サポート（XML Region Index、XML Indexのみ）
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
12
データベース物理設計
DB2デザイン・ガイド
参考：DB2がサポートするデータ･タイプ
日付/時刻
Extensible
Markup
Language
符号付数値
ストリング
XML
時刻
TIME
タイム・
スタンプ
正確な値
日付
TIMESTAMP
概算値
DATE
浮動
小数点数
文字
グラフィック
可変長
バイナリー
V9.5
BLOB
単精度
固定長
可変長
固定長
可変長
REAL
GRAPHIC
CHAR
VARCHAR CLOB
VARGRAPHIC
DBCLOB
２進整数
１０進
パック
１６ビット
３２ビット
６４ビット
DECIMAL
SMALLINT
INTEGER
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
BIGINT
13
倍精度
DOUBLE
10進浮動小数
点数
DECFLOAT
データベース物理設計
DB2デザイン・ガイド
参考：DB2がサポートするデータ･タイプ
・文字タイプ
データタイプ
説明
制限値
CHAR（ｎ）
ｎバイトの固定長文字列
１＜＝ｎ＜＝２５４
VARCHAR（ｎ）
最大ｎバイトの可変長文字列
１＜＝ｎ＜＝３２６７２
LONG VARCHAR（ｎ）
長可変長文字列
最大３２７００バイト
GRAPHIC（ｎ）
ｎ文字の固定長漢字ストリング
１＜＝ｎ＜＝１２７
VARGRAPHIC（ｎ）
最大ｎ文字の可変長漢字ストリング
１＜＝ｎ＜＝１６３３６
LONG VARGRAPHIC
長可変長漢字ストリング
最大１６３５０文字
データタイプ
説明
制限値
SMALLINT
短精度整数
－３２７６８～＋３２７６７
INTEGER
長精度整数
－２，１４７，４８３，６４８～＋２，１４７，４８３，６４７
BIGINT
６４ビット整数
REAL
単精度浮動小数点数
DOUBLE、FLOAT
倍精度浮動小数点数
DECIMAL（ｍ、ｎ）、NUMERIC
１０進数（精度桁数、小数点以下桁数）
１＜＝ｍ＜＝３１、０＜＝ｎ＜＝ｍ
DECFLOAT(16),DECFLOAT(34)
１０進浮動小数点数
10-383 ～ 10+384 , 10-6143 ～ 10+6144
データタイプ
説明
制限値
DATE
日付
０００１－０１－０１～９９９９－１２－３１
TIME
時刻
００：００：００～２４：００：００
TIMESTAMP
タイム・スタンプ
０００１－０１－０１－００．００．００．００００００～
９９９９－１２－３１－２４．００．００．００００００
・数値タイプ
V9.5
－９，２２３，３７２，０３６，８５４，７７５，８０８～
＋９，２２３，３７２，０３６，８５４，７７５，８０７
－３．４０２E＋３８～－１．１７５E－３７もしくは
１．１７５E－３７～３．４０２E＋３８
－１．７９７６９E＋３０８～－２．２２５E－３０７もしくは
２．２２５E－３０７～１．７９７６９E＋３０８
・日付／時刻タイプ
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
14
データベース物理設計
DB2デザイン・ガイド
参考：DB2がサポートするデータ･タイプ
・ラージ・オブジェクト
データタイプ
説明
制限値
CLOB（ｎ K|M|G）
文字ラージ・オブジェクトストリング
２，１４７，４８３，６４７バイト
DBCLOB（ｎ K|M|G）
２バイト文字ラージ・オブジェクト
１，０７３，７４１，８２３文字
BLOB（ｎ K|M|G）
２進ラージ・オブジェクト
２，１４７，４８３，６４７バイト
・ラージ・オブジェクトのディスクリプタ
LOBの最大長
LOB Descriptor長
LOBの最大長
LOB Descriptor長
１，０２４
７２
１３４，０００，０００
２００
８，１９２
９６
５３６，０００，０００
２２４
６５，５３６
１２０
１，０７０，０００，０００
２５６
５２４，０００
１４４
１，４７０，０００，０００
２８０
４，１９０，０００
１６８
２，１４７，４８３，６４７
３１６
・XML
データタイプ
説明
制限値
XML
XML文書
２ギガバイト
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
15
データベース物理設計
DB2デザイン・ガイド
V9.5
参考： Decimal Floating Point
16桁または34桁の最大精度を持つ10進浮動小数点数
z より大きな数、より精度の高い演算が可能
¾
従来の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
z DECFLOAT(16):
¾
¾
負の値: -9.999999999999999 x 10+384 ～ -1.000000000000000 x 10-383
正の値: 1.000000000000000 x 10-383 ～ 9.999999999999999 x 10+384
z DECFLOAT(34):
¾
¾
負の値: -9.999999999999999999999999999999999 x 10+6144 ～
1.000000000000000000000000000000000 x 10-6143
正の値: 1.000000000000000000000000000000000 x 10-6143 ～
9.999999999999999999999999999999999x 10+6144
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
16
データベース物理設計
DB2デザイン・ガイド
列の設計（続き）
その他設計上の考慮点
z
NOT NULLの指定
¾
¾
z
比較、結合、UNIONの処理がある列はデータ・タイプを揃える
¾
z
データ行圧縮を使用する場合、複数列に跨って繰り返されるパターンのデータがあれば、それらの列は隣接
して並べる（圧縮効果が高くなる）
VARCHAR列：適当なデータ・タイプかどうか要検討
¾
¾
¾
z
可変長列は、自動的に全ての固定長列の後ろに配置される
更新される列は可能であれば近くに並べる
適用業務には列の指定順序は影響しない（順序にこだわる場合、視点(View)で対応も可）
圧縮効率を考慮した列の順序
¾
z
データ変換負荷の軽減
パフォーマンスを考慮した列の順序
¾
¾
¾
z
NULL可能にした場合、列毎に１バイトのNULLフラグが必要であり、CPU負荷が増加する
NULL標識変数を準備しなければならず、プログラムが煩雑になる
読み取りに２ステップ要：長さ→データ
VARCHAR列への変更：長くなった場合、Tombstoneが発生する場合あり
更新がある場合、データのフラグメンテーションを招く ⇒ REORG運用が必要となる可能性が高い
列の自動生成
¾
¾
生成列（GENERATED COLUMN）の利用
–
–
指定されたルールに従い、列の値が動的に生成される列
列の値を事前に加工して入れておくことにより、SQL実行時のパフォーマンスを向上させる
–
–
–
–
DB2が列の値として、固有の数値を生成する列
固有の値を取得するために別途表を用意したり、MAX関数を使用して取得したりする必要がない
行をユニークに識別可能な、列の値を事前に入れておくことにより、識別列を使用した照会処理が可能
シーケンス・オブジェクトの利用も検討
識別列（IDENTITY COLUMN）の利用
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
17
データベース物理設計
DB2デザイン・ガイド
解説
列にNULLデータが入る可能性がなければ、以下の理由からNOT NULLを指定してください。
z
NOT NULLでない場合
¾
¾
¾
¾
列毎に1バイトのNULLフラグが必要
NULLか否か調べるCPU負荷の増加
NULLフラグによるDISKスペースの増加
プログラムではNULL標識変数の準備が必要
比較、結合、UNIONの処理がある列は、列同士のデータタイプをそろえることでデータ変換負荷を
軽減させることができます。
パフォーマンスを考慮した場合、更新される列は近くに並べて下さい。
更新時のログは、先頭の更新列から、最後の更新列まで取得される為、更新列が離れているとロ
グデータが増加します。
C1
z
z
z
C2
C3
C4
C5
C6
C7
C8
C9
C10
update testtab set c5=50 ・・・・・・・・・ログは、c5のみ
update testtab set c3=20, c9=90 ・・・ログはc3～c9まで
ただし、可変長列でその列長が変更されるような更新がおこなわれた場合、行全体（新旧）がログとして取得されます。
可変長列は、全ての固定長列の後ろに配列されます。
z
DB2は、データの保存時に固定長列、可変長列、LONG VARCHARポインター(20バイト)の順で自動的に格納しています。
INTEGER
VARCHAR
CHAR
LL
固定長のinteger列を得るためにはその前のVARCHAR列からたどらなければならない
CHAR
INTEGER
LL
VARCHAR
integer列は行の先頭からの相対位置が変わらないので直接得ることができる
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
18
データベース物理設計
DB2デザイン・ガイド
解説
データ行圧縮を使用する場合、複数列に跨って特定のパターンの値が繰り返されるようなデー
タがあれば、それらの列を続けて定義すると圧縮効率が良くなります。
z
圧縮は列単位ではなく行単位で行われますので、列を跨ったパターンで辞書が作成されることもあります。
Name
Dept
Salary
City
State
ZipCode
Fred
500
10000
Plano
TX
24355
John
500
20000
Plano
TX
24355
圧縮前
Fred
500
10000
Plano
TX
24355
John
500
20000
Plano
TX
24355
…
Dictionary
圧縮後
Fred
(01)
10000
(02)
John
(01)
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
20000
(02)
19
…
01
500
02
Plano, TX,
24355
…
…
データベース物理設計
DB2デザイン・ガイド
解説
VARCHAR/VARGRAPHIC列を使用する場合には、可変長であるメリットとデメリットを考慮し
た上で、使用して下さい。
z
可変長列は、2種類の情報を持っています。
z
可変長データを読み込む場合、まずデータの長さを読み取り、次にデータをその長さ分読み取るという2段階を経るため、
パフォーマンスに影響が出ます。
また、可変長データに変更が発生した場合、元データより長くなると同じページに収まらなくなってしまう可能性がありま
す。
その場合、移動先の情報を持ったTombstoneが元のデータ位置に残されます。
その為、そのレコードを取得するために、ページを2段階経なければならなくなる可能性があります。
z
z
z
C1
¾
¾
C3
データの長さ
データ
BPS header
C2Len C2 Data
3 OS0 OS1OS2
Record 2
Record 1
Rec 0
z
z
新しいページ
Tombstone
更新がある場合、データのフラグメンテーションを招き、 REORG運用が必要となる可能性が高くなります。
VARCHAR列を使用するのが望ましい場合：
z
VARCHAR列を使うべきでない場合：
¾
¾
¾
¾
データの長さの範囲がまちまちで、ほとんどの列は短い
データの長さの範囲がまちまちで、全ての範囲でほぼ均等に分布
データの長さの範囲はまちまちだが、ほとんどの列は範囲の上の方にある
VARCHAR列にすることによって、ディスク・スペースが余計にかかり、パフォーマンスが低下するケース
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
20
データベース物理設計
DB2デザイン・ガイド
解説（生成列）
生成列とは、各行の値を挿入操作または更新操作からではなく、定義した式によって定めることが
できる列です。更新トリガーおよび挿入トリガーを組み合わせて使用すると同様のことが行えます
が、生成列を使用すると、派生した値が式と一貫したものであることを保証できます。
表で特定の式や述部を頻繁に使用することがわかっている場合、生成列を使用してあらかじめ値
を生成しておくことにより照会の際のパフォーマンスを向上させることが可能です。
表で生成列を作成するには、ALTER TABLEまたはCREATE TABLE時にGENERATED ALWAYS
AS 文節を使用して、列の値を定義する式を含んだ列を指定します。
生成列には検査制約やユニーク索引/基本キーが使用できない、生成列を持つ表に対して
RENAME TABLE ができない等の制約事項があるので使用にあたっては考慮が必要です。
生成列の例
z
"c1" および "c2" という通常の 2 つの列と、表の通常の列から派生した "c3" および "c4" という 2 つの生成された列の入った表
を作成します。
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
C1 + C2
INSERT t1 (C1,
C2)
VALUES (10, 3)
t1表
INSERT
C1
C2
C3
C4
10
3
13
1
10 + 3 = 13
10 > 3 なので1
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
C1 > C2 の時は1
それ以外は 0
21
データベース
マネージャーが
値を生成
データベース物理設計
DB2デザイン・ガイド
解説（IDENTITYE列とSEQUENCE）
IDENTITY列（識別列）は生成列の中の一つで、表の各行に対して固有な基本キー値を自動
的に生成します。
z
z
識別列では、アプリケーションがデータベースの外に独自のカウンターを生成する際に生じる、並行性およびパフォーマ
ンス上の問題を回避することが可能です。
固有な基本キーを自動生成する際に識別列を使用しない場合には、単一行の表にカウンターを保管するのが一般的な
設計方法です。各トランザクションはこの表をロックして、数を増分してからトランザクションをコミットして、カウンターの
ロックを解除します。しかし、残念ながら、この設計では、カウンターを増分できるのは一度に 1 つのトランザクションのみ
です。一方、識別列を使用して基本キーを自動的に生成すると、アプリケーションでより高度なレベルの並行性を実現で
きます。
SEQUENCE（シーケンス）とは、値の自動生成を可能にするデータベース・オブジェクトです。
z
z
z
シーケンスを使用すると、固有キー値を生成することが可能です。IDENTITY列と同様アプリケーションはシーケンスを使
用することで、データベースの外部に固有カウンターを生成したことによって発生する可能性のある、並列性およびパ
フォーマンスの問題を回避することができます。
識別列属性とは異なり、シーケンスは特定の表列に関連付けられていないデータベースオブジェクトです。
シーケンス・オブジェクトはどのアプリケーションでも使用できるため、NEXTVALおよびPREVALの二つの値を返す式が定
められています。
t1表
C1
IDENTITY列
IDENTITY列
C2
C3
t1表
C1
C4
create table t1
(c1 int generated always as
identity
(start with 10, increment by 2),
c2 char(10), c3 double, c4 int)
列内で固有な値を自動生成
SEQUENC
E
C2
C3
C4
SEQUENCE
オブジェクト
NEXTVAL
insert into t1 (c1,c2) values (nextval for seq1, 100)
シーケンス・オブジェクト内で固有な値を自動生成
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
22
データベース物理設計
DB2デザイン・ガイド
主キーと外部キー
主キー（Primary Key）
z
z
主キーは表の保全性を保証する
¾
¾
格納されるデータの値は、ユニークでなければならない
NOT NULL指定必須
¾
参照制約を使用しない場合は基本キーではなく、別途ユニーク索引を定義しても可
主キーを付与するとユニーク索引（１次索引）は自動的に作成される（固有制約）
＜部門表＞
部門番号部門名
１００
営業部
２００
電算部
３００
総務部
主キー
外部キー（Foreign Key）
z
¾
部門番号
A111
田中
１００
B222
山田
２００
C333
鈴木
２００
別の表の主キーが、その表のデータ項目になっている時、そのキーは外部キーとなりうる
結合操作の結合列になる ⇒ 索引の候補
外部キーは参照の整合性を保証するために、主キーに存在しない値を持ってはいけない（参照制
約）
参照制約を使用しない場合、あくまでも論理的なものであって、物理定義する必要はない
定義時には、CONSTRAINTにより制約名をつける
z
社員番号社員名
外部キー
親表と従属表の間の親子関係を示す働きをする
¾
¾
¾
＜社員表＞
管理が容易
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
23
データベース物理設計
DB2デザイン・ガイド
解説
主キー
z
z
z
表の固有キーとは、それぞれの値が固有の行を識別する、１つの列または複数の列の順序集合のことです。たとえば、社員
番号の列の各値は一人の社員だけを指すものなので、これを固有キーとして定義することができます。二人の社員が同じ社
員番号を共有することはできません。
表の主キーは、１つの表上に定義された固有キーの１つですが、その表上で1番目に重要なキーとして選択されたものです。
１つの表上には１つだけの基本キーが可能で、そのエンティティ内で行を唯一無二のものとして識別できるデータ項目です。
主キーはエンティティの保全性を保証するために、ユニークであり、空白値は許されません。
外部キー
z
z
表の外部キーは、親表の固有キーまたは主キーを参照する、表内の１つの列または1組の列のことです。
外部キーは表（親表）と表（従属表）の間の参照の整合性を保証するために、基本キーに存在しない値を持ってはならず、結
合操作時には結合列になります。
参照制約を使用しないのであれば、親表と従属表の間の親子関係を示すあくまでも論理的な
意味合いのものであり、主キーと外部キーの物理的な設定は必須ではありません。
主キー、外部キーの定義時には、CONSTRAINTにより制約名をつけたほうが管理しやすくなり
ます。
主キーの定義
CREATE TABLE 親表名
（主キー列名・・・ NOT NULL,
・・・・・・・,
・・・・・・・,
CONSTRAINT 制約名 PRIMARY KEY（主キー列名))
外部キーの定義
CREATE TABLE 従属表名
（・・・・・・・,
外部キー列名・・・ NOT NULL,
・・・・・・・,
CONSTRAINT 制約名 FOREIGN KEY（外部キー列名)
REFERENCES 親表名
ON DELETE 規則)
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
24
データベース物理設計
DB2デザイン・ガイド
制約
データの保護や、データ間の相互関係の定義をDBMSに行わせる
z
z
アプリケーション・ロジックとしてコードを作成する必要がない
¾
¾
事前に制約を使用するか否かの方針決めが必要
使用する場合は、制約違反エラーのハンドリング・ロジックが必要
¾
バッチによる大量の更新時や、テスト環境でのテスト・データ作成時に、格納順番やデータの値を考
慮する必要あり
データ格納時にDB2により厳格にチェックされる
３種類の制約を提供
z
固有制約
¾
表の 1 つまたは複数の列に重複する値を指定することを禁止する規則
1
z
表検査制約
¾
z
1
A1
col2
A1
INSERT
外部キーの値が親キーの値として現れる場合、または外部キーの構成要素の一部がヌル値の場合
のみ有効とする規則
（情報制約）
¾
col2
col3
col3 < 20？
10
20
'A3'
z
col1
INSERT
表の各行の1つ以上の列について可能な値を指定する規則
参照制約
¾
固有？
col2
1
A1
親表に存在する？
25
c1
A1
A2
INSERT
DB2による制約情報チェックの適用/非適用の設定が可能な制約（V8）
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
col1
データベース物理設計
DB2デザイン・ガイド
解説
制約を利用すると、データの保護や、データ間の相互関係の定義をデータベース・システ
ムに行わせることが可能です。これにより、アプリケーションでコードを作成し、これらの規
則を施行する必要がなくなります。
事前に制約を使用するか否かの方針決めを最初に確定させる必要があり、使用するので
あれば、制約違反エラーのハンドリング・ロジックは必要となります。
データ格納時にDB2により厳格にチェックされるため、バッチによる大量の更新時や、特に
テスト環境でのテスト・データ作成時に、格納順番やデータの値を考慮するが必要ありま
す。例えば、参照制約が定義されている表については、データのINSERTは必ず親表を先
にする必要があります。
DB2は以下の種類の制約を提供しています。
z
固有制約
z
表検査制約
z
参照制約
z
¾
表の 1 つまたは複数の列に重複する値を指定することを禁止する規則
¾
表の各行の1つ以上の列について可能な値を指定する規則のことです。
¾
外部キーの値が親キーの値として現れる場合、または外部キーの構成要素の一部がヌル値の場合のみ有効とする
規則
（情報制約）
¾
¾
¾
V8から、情報制約（Informational Constraint）と呼ばれる新しいタイプの制約により、DB2による制約情報チェックの適
用/非適用が設定可能になりました。
制約情報を非適用とすることにより、ビジネス・アプリケーションのロジックによってチェックされ、この場合、データベー
ス・マネージャーによってチェックされることはありません。また、オプティマイザーによる制約の利用を活動化、または
非活動化させる指定も可能です。
下記のオプションを CREATE または ALTER TABLE で指定します。
–
–
z
–
–
ENFORCED：DB によって更新操作時、常に制約をチェックさせる。
NOT ENFORCED：DB に制約をチェックさせない。また、SET INTEGRITY を使用しても、チェックされません。この場合、
実際に制約に違反するデータが入る可能性あるため、アプリケーションでのチェックする必要があります。
ENABLE QUERY OPTIMIZATION：オプティマイザーのQuery Rewriteを活動化する。
DISABLE QUERY OPTIMIZATION：オプティマイザーのQuery Rewriteを非活動化する。
制約は、CREATE TABLE文およびALTER TABLE文を使用して、表の列に対して定義します。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
26
データベース物理設計
DB2デザイン・ガイド
解説
固有制約の例
z
表t1 には、列 (col1, col2, col3) があり、col1 の各データは表で固有でなくてはならない場合、例えば次のように定
義します。
create table t1 (col1 int not null,
col2 char(10) not null,
col3 int,
constraint t1_uniq UNIQUE (col1))
z
このcol1列に重複した値をINSERTすると、SQL0803Nのエラーとなります。
表検査制約の例
z
t1のcol3には、かならず20未満でなくてはならない場合は、以下のように表を定義します。
create table t1 (col1 int not null,
col2 char(10) not null,
col3 int,
constraint col3check CHECK (col3 < 20));
z
col3に20以上の値をINSERTしようとすると、SQL0545Nのエラーになります。
情報制約の例
z
上記で定義した表検査制約と同等ですが、アプリケーションで保証することとし、DB2はチェックしません。
create table t1 (col1 int not null,
col2 char(10) not null,
col3 int,
constraint col3check CHECK (col3 < 20) NOT ENFORCED ENABLE QUERY OPTIMIZATION);
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
27
データベース物理設計
DB2デザイン・ガイド
ブランク・ページです
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
28
データベース物理設計
DB2デザイン・ガイド
表の設計
1行のレコードがページをまたがることはできない
z
z
LONGデータを除く
最適なページ・サイズの決定（4KB/8KB/16KB/32KB）
行の削除によるスペース解放はない
削除してもDiskの使用率は変わらない
再利用はされる
¾ APPENDモードの指定により再利用させないことも可能
z REORGなどの運用が必要
z
z
ページの空き領域の設定
予め、ページ内にフリー・スペースを残す設定
設定が必要か否かの検討が必要
¾ 離れたページにデータが挿入されると、パフォーマンスに影響を与える
– クラスター索引を持つ表
– 可変長列の更新がある表
z ALTER TABLEによるPCTFREE指定
z LOAD、REORG時に指定されたフリー・スペースを確保
z
z
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
29
データベース物理設計
DB2デザイン・ガイド
解説
1行のレコードが複数のページにまたがることはできません。
1レコードの長さがページ内に収まらない場合は、ページサイズを大きくして下さい。
z
4KB → 8KB → 16KB → 32KB
データの削除が行われたとき、そのレコードのあった場所は解放されません。(再利用はされま
す。)削除のフラグが立つのみです。Diskの使用率は変わりません。
削除されたスペースを解放させるためには、reorg tableを実行して下さい。
APPENDモード
z
z
z
INSERT時に表内の空きページを検索することなく、最終ページにレコードを追加する機能。（APPENDモード ON）
レコードが単調増加していく特性の表にINSERTする場合、パフォーマンスが向上しますが、DELETEによる削除レコードの空
き領域は再利用されないため、別途、表自体の再作成（もしくは、0件）、または再編成などの運用により、表容量を適正に保
つ仕組みの検討が必要とななります。
クラスター索引のある表には適用不可。
ページの空き領域(PCTFREE）
z
離れたページにデータが挿入されると、パフォーマンスに影響を与える為、予めページ内にフリー・スペースを残す様に設定
することができます。
ALTER TABLE 表名 PCTFREE 数値
z
データのロード、およびREORG TABLE時に、指定されたサイズのフリー・スペースをページ内に残します。
z
クラスター索引を持つ表（データの挿入時に、索引順とデータの並び順を同じにするようにデータを格納しようと試みる）に対し
て、業務上の観点から、データの追加、削除処理の頻度にも留意し、ページの空き領域（ＰＣＴＦＲＥＥ）の設定の検討が必要
です。データの挿入が多い場合、索引順序にデータを配置しようとしても、ページ内に収まらない場合があります。
また、可変長の属性の列項目を持つ表において、その列項目に対して更新がある場合、空き領域を設けることを検討する。
オンライン中の更新がない、または、クラスター索引を持たない列項目の属性が固定長のみで定義されている表については、
空き容量は特に必要ありません。
z
¾
PCTFREE：0～99 (デフォルト:-1)
PCTFREEの設定が必要な例
z
z
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
30
データベース物理設計
DB2デザイン・ガイド
ページ・サイズの決定
表を格納するページサイズを決定する
z
z
データの行長・カラム数の制限
表容量の制限
¾
z
格納効率も考慮する必要がある
¾
¾
z
LARGE RID（V9）が使用可能な表スペース（LARGE DMS表スペース、一時表スペース）の場合、
制限値が異なる。（下表参照。）
LARGE RIDを使用しない表スペースでは、ページ・サイズにかかわらず１ページに格納できる行数
は最大255行まで。
LARGE RIDを使用する表スペースでは、1ページに255行以上格納可能。（下表参照。）
アプリケーションの特性（OLTP or DSS）や管理面も考慮する
ページ・サイズによる制限値
ページ・
サイズ
行長
（bytes）
列数
非LARGE表スペース
表容量
LARGE表スペース
行数/ページ
表容量
行数/ページ
V9.7
LARGE表スペース(DMS)/
一時表スペース（SYSTEM,USER)
表容量
4KB
4005
500
64GB
255
2TB
287
8TB
8KB
8101
1012
128GB
255
4TB
580
16TB
16KB
16293
1012
256GB
255
8TB
1165
32TB
32KB
32677
1012
512GB
255
16TB
2335
64TB
z
V9.7からLARGE表スペース（DMS）と一時表スペース（SYSTEM,USER)の上限が拡張された
表の分割、パーティション表（V9）も検討する
z
z
z
UNION ALL VIEWに対する参照（V6,V7でも可）
UNION ALL VIEWに対する更新、INSERTも可（V8）
パーティション表（V9）
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
31
データベース物理設計
DB2デザイン・ガイド
解説
ページ・サイズ
z
z
z
表に必要となるディスク容量を計算する時に、どのページサイズを使用するかが非常に重要な要素になります。
DB2では、4K/8K/16K/32Kバイトの４種類のページサイズをサポートします。
1行のレコードが複数のページにまたがることはできません。1レコードの長さがページ内に収まらない場合は、ペー
ジサイズを大きくして下さい。
z
表の最大容量の制限
z
格納効率
¾
¾
¾
¾
¾
z
z
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アプリケーションは、指定された数の行を読み取るのに必要な入出力
要求の数を減らすように大きなページサイズを使用するようにしてください。
異なるページ・サイズによる考慮点
z
z
z
z
バッファプール、一時表スペースはページサイズ毎に必要
USEオプションを使用した再編成では、一時表スペースは表スペースと同じページサイズである必要がある
拡張ストレージは大きなページサイズに合わせる
バックアップを異なるページサイズに復元することは出来ない
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
32
データベース物理設計
DB2デザイン・ガイド
参考：デフォルト・ページ・サイズの変更（V8.2.2以降）
V8.2.2以降では、データベース作成時に4KB以外（8,16,32KB）のデフォルト・
ページ・サイズを指定可能。
z 指定方法
¾ CREATE DATABASEコマンドのPAGESIZEオプション
– 4096, 8192, 16384, 32768または、4 K, 8 K, 16 K, 32 Kを指定可能
¾
sqlecrea()APIの引数pDbDescriptorExt
z 初期表スペースSYSCATSPACE, TEMPSPACE1, USERSPACE1、デフォルト・バッファー
プールIBMDEFAULTBPは、データベース作成時に指定されたページ・サイズで作成され
る。
z 明示的にページ・サイズを指定して表スペース、バッファープールを作成することも可能。
考慮点
z 不必要に大きいページ・サイズを使用すると、領域が無駄になることがある。
¾ バッファープールに読まれるときの領域の無駄
– 特に、データにランダムにアクセスするOLTPアプリケーションの場合
¾
1ページあたりの行数の制限
– ページ・サイズに関わらず255行まで
z データベース作成時に指定したデフォルト・ページ・サイズは後から変更できない。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
33
データベース物理設計
DB2デザイン・ガイド
V9.7
参考：表スペース・サイズの上限の緩和
LARGE表スペース（DMS)、一時表スペース（SYSTEM, USER)の最大サイズ
を64TBまで拡張
•旧バージョンからV9.7への移行に際して、変更処理は不要。
4KB
8TB
8KB
16TB
16KB
32TB
32KB
64TB
表スペース・サイズ
ページ・サイズ
※ Row ID （RID：6バイト(ページ番号4byte＋スロット番号2byte)）は
V9.5 から変更はなく、索引サイズやロギング量は変わらない。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
34
データベース物理設計
DB2デザイン・ガイド
V9.7
参考：各バージョンにおける表スペース・サイズの上限
ページサイズ
V8
V9 ～
V9.7
4KB
8KB
16KB
32KB
64GB
128GB
256GB
512GB
2TB
4TB
8TB
16TB
8TB
16TB
32TB
64TB
・V8までは、Regular、一時、DMS、SMSの全ての表スペースは、上記の制限
・V9, V9,7においては、LARGE表スペース(DMS)、一時表スペース
(SYSTEM,USER) で上記の上限
・SMS表スペース・サイズ上限は、V9以降も変わらない(64GＢ～512GB)
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
35
データベース物理設計
DB2デザイン・ガイド
ブランク・ページです
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
36
データベース物理設計
DB2デザイン・ガイド
参考：UNION ALL VIEWによる表分割
UNION ALLビューとは
z 複数の結果表を組み合わせて新たな結果表として定義されたView
z UNION ALLを指定すると結果は該当表のすべての行から構成される
表分割の目的
z
z
z
z
表スペースサイズの制限による分割
履歴データ等のレンジ・パーティションを実現
データ削除を分割された表単位のIMPORT REPLACEなどで実行できる
REORGなどの運用を表毎に個別に行える
VIEW定義の方法
z CREATE VIEW文中のSELECT文で、WHERE文節によって値を制限
¾
このVIEWに対するINSERTは不可
z 表に対するCONSTRAINTによって値を制限
¾
INSERTを使うためにはCONSTRAINTが必要（V8以降）
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
37
データベース物理設計
DB2デザイン・ガイド
解説
UNION
ALLビューの例
CREATE TABLE Q1(order DATE,month SMALLINT,item VARCHAR(10));
ALTER TABLE Q1 ADD CONSTRAINT q1ckc1 CHECK (MONTH BETWEEN 1 AND 3);
ORDER
MONT ITEM
2003-01-01 H
1 ｘｘｘｘ
2003-02-01
2 ｘｘｘｘ
2003-03-01
3 xxxx
表 Q1
CREATE TABLE Q2(order DATE, month SMALLINT,item VARCHAR(10));
ALTER TABLE Q2 ADD CONSTRAINT q2ckc1 CHECK (MONTH BETWEEN 4 AND 6);
ORDER
MONT ITEM
2003-04-01 H
4 ｘｘｘｘ
2003-05-01
5 ｘｘｘｘ
2003-06-01
6 xxxx
ビュー
VIEW_YEAR
表 Q2
ORDER
CREATE TABLE Q3(order DATE, month SMALLINT,item VARCHAR(10));
ALTER TABLE Q3 ADD CONSTRAINT q3ckc1 CHECK (MONTH BETWEEN 7 AND 9);
ORDER
MONT ITEM
2003-07-01 H
7 ｘｘｘｘ
2003-08-01
8 ｘｘｘｘ
2003-09-01
9 xxxx
表 Q3
CREATE TABLE Q4(order DATE, month SMALLINT,item VARCHAR(10));
ALTER TABLE Q4 ADD CONSTRAINT q4ckc1 CHECK (MONTH BETWEEN 10 AND 12);
ORDER
MONT
2003-10-01 H
10
2003-11-01
11
2003-12-01
12
ITEM
ｘｘｘｘ
ｘｘｘｘ
xxxx
CREATE VIEW VIEW_YEAR(order,
month,item) AS SELECT * FROM Q1
UNION ALL
SELECT * FROM Q2
UNION ALL
SELECT * FROM Q3
UNION ALL
SELECT * FROM Q4;
表 Q4
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
38
2003-01-01
2003-02-01
2003-03-01
2003-04-01
2003-05-01
2003-06-01
2003-07-01
2003-08-01
2003-09-01
2003-10-01
2003-11-01
2003-12-01
MONTH ITEM
1
2
3
4
5
6
7
8
9
10
11
12
ｘｘｘｘ
ｘｘｘｘ
ｘｘｘｘ
xxxx
ｘｘｘｘ
ｘｘｘｘ
ｘｘｘｘ
ｘｘｘｘ
ｘｘｘｘ
ｘｘｘｘ
ｘｘｘｘ
ｘｘｘｘ
データベース物理設計
DB2デザイン・ガイド
参考：UNION ALL VIEWによる表分割（続き）
UNION ALL VIEW 使用上の注意点
z アクセス・パスを充分確認した上で使用する
z VIEWへのSELECTを表へのSELECTに変換するのはオプティマイザーであ
る。
¾
¾
オプティマイザーが解らない場合は、表を特定できない。その場合、全て
の表にアクセスしてしまう
表を特定できない例
– 照会の条件が、CHECK制約やVIEW定義のWHERE条件に合致しない
– CHECK制約にMONTHなどの関数を使用．．．等
z オプティマイザーはVIEW中のSQL文を展開してから評価するので、展開後
のSQL文が長くなる可能性がある
¾
¾
¾
ステートメント・ヒープ、アプリケーション・ヒープがより多く必要
SQL文の長さの制限(64K)を超える可能性がある
長すぎるSQL文でオプティマイザーがあきらめて、単純なアクセスパスに
走る可能性がある
z UNION ALL VIEWへの更新系処理はオーバーヘッドが生じる
¾
¾
各表へのチェック処理
更新処理は、なるべく実体の表に対して直接処理を行う
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
39
データベース物理設計
DB2デザイン・ガイド
解説
オプティマイザ-によって表が特定される例
オプティマイザ-によって表が特定されない例
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 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 Table Q2_2(Order Date,month smallint,item varchar(10));
alter table q2_2 add constraint q2chck2 check (month between 4 and 6);
Create Table Q2_1(Order Date,month smallint,item varchar(10));
alter table q2_1 add constraint q2chck1 check (MONTH(order) between 4 and 6);
Create Table Q3_2(Order Date,month smallint,item varchar(10));
alter table q3_2 add constraint q3chck2 check (month between 7 and 9);
Create Table Q3_1(Order Date,month smallint,item varchar(10));
alter table q3_1 add constraint q3chck1 check (MONTH(order) between 7 and 9);
Create Table Q4_2(Order Date,month smallint,item varchar(10));
alter table q4_2 add constraint q4chck2 check (month between 10 and 12);
Create Table Q4_1(Order Date,month smallint,item varchar(10));
alter table q4_1 add constraint q4chck1 check (MONTH(order) between 10 and 12);
Create view VIEW_YEAR2(order,month,item) as
select * from Q1_2 union all
select * from Q2_2 union all
select * from Q3_2 union all
select * from Q4_2;
Create view VIEW_YEAR1(order,month,item) as
select * from Q1_1 union all
select * from Q2_1 union all
select * from Q3_1 union all
select * from Q4_1;
Original Statement:
-----------------select * from view_year2 where month = 1
Original Statement:
-----------------select * from view_year1 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)
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
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
40
データベース物理設計
DB2デザイン・ガイド
参考：パーティション表による表分割
データの範囲によって、ひとつの表を複数のパーティションに物理的に分割し
て保存する
z CREATE TABLEステートメントのPARTITION BY文節で指定されたパーティション・キー列の値
に従って、表を複数のパーティションに分割する
z それぞれのパーティションは、異なる表スペースにも、同じ表スペース内にも配置することがで
きる
新しいパーティションのアタッチ/デタッチが可能
履歴表A
JAN01
JAN02
JAN03
JAN04
JAN05
区分の
アタッチ
区分の
デタッチ
JAN05
JAN01
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
41
データベース物理設計
DB2デザイン・ガイド
参考：パーティション表による表分割（続き）
表を分割
z区分化された単位は「データ・パーティション」、または「レンジ」と呼ばれる
キーレンジによるデータ分散
大規模データベースの実現
z巨大な表
z高速なデータアクセス
z高速なロールイン/ロールアウト
キーレンジによるデータ分散
CREATE TABLE T1
表 T1
( COL1 INT, COL2 DATE )
PARTITION BY RANGE (COL2)
JAN-MAR
APR-JUN JUL-SEP
データ・
パーティショﾝ0
データ・
パーティショﾝ1
OCT-DEC
（ STARTING FROM (‘2006-01-01’)
ENDING (‘2006-12-31’)
データ・
パーティショﾝ2
EVERY (3 MONTH) ）
DBパーティショﾝ0
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
42
データ・
パーティショﾝ3
データベース物理設計
DB2デザイン・ガイド
参考：パーティション表による表分割（続き）

パーティション表のメリット
1.
保存期間を過ぎた行の高速な削除
¾
2.
新規データのオンライン高速ロード
¾
3.
指定された条件によって、特定パーティションのみにアクセスする
故障範囲の局所化（各パーティションを異なる表スペースへ配置）
¾
5.
あらかじめLOADしておいた表を、既存のパーティション表にアタッチする
データアクセスの性能向上
¾
4.
保存期間の過ぎた行を含むパーティションをデタッチし、デタッチした表をDROPする
各パーティションを異なる表スペースへ配置しておけば、ある表スペースがアクセス
不能になっても、その他の表スペースに配置されたパーティションへのアクセスは可
能
バックアップ性能の向上
¾
各パーティションを異なる表スペースへ配置し、並列でバックアップを実行する
（BACKUPコマンドのPARALLELISMオプションを使用）
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
43
データベース物理設計
DB2デザイン・ガイド
ブランク・ページです
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
44
データベース物理設計
DB2デザイン・ガイド
索引の設計
索引の目的
z
z
z
照会処理の処理効率を高める
¾
アクセス・パスにおける索引の使用による効率のよいデータへのアクセス
¾
ユニーク索引
¾
クラスター索引
行のユニーク性を維持する
データの並び順を索引順に維持することにより、データ・アクセスの効率を向上させる
設計手順
z
z
z
z
パフォーマンス改善を目的とし、繰り返し行う必要がある
索引候補の検討
索引数の検討
索引候補の取捨選択
索引の物理定義と検証
z
z
z
z
索引が有効に利用され最適なアクセスパスになっているか
意図した索引を使用しているか
メンテナンス負荷を軽減するため、使用されていない場合にはDROP
SYSCAT.PACKAGES（静的SQL）、または、EXPLAINツールで確認
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
45
データベース物理設計
DB2デザイン・ガイド
解説
表に作成する索引は、本の索引と同様の機能を果たします。
索引の第一の目的は、データをアクセスする際の処理効率を向上させることです。余計な
入出力をすることなく、最短の方法で目的のデータにたどりつくには、索引は非常に有効
です。
ユニーク索引を作成した際には、索引のキー列のユニーク性を保証する機能を使用可能
です。
クラスター索引
z
z
z
z
クラスター索引を作成すると、データの挿入時に、索引順とデータの並び順を同じにするようにデータを格納しようと
試みます。
データを索引の列項目の値順に読み込む場合、Ｉ／Ｏ回数が軽減され、処理効率が向上します。
クラスター索引を作成する場合、データが格納されるページに空きスペースを準備する必要があります。
索引の列項目の値が更新される（更新があった場合、索引順に再格納は行わないため、再編成の必要性を検討す
る必要がある）場合や、検索結果が常に１件となる照会処理が頻繁に行われる場合は、作成してもメリットはありま
せん。
索引の設計手順
z
z
パフォーマンス改善を目的とし、内部設計から統合テストの局面まで、繰り返し行う必要があります。
索引候補の検討
z
索引数の検討
z
索引候補の取捨選択
¾
¾
¾
主キーや外部キーなどは、データの意味から索引候補として決定可能であるため、外部設計後に可能な作業です。一
方、その他の２次索引については、具体的なSQL文を元にアクセス・プランを検討し、候補の洗い出しを行います。
索引数が増えると、索引のメンテナンス負荷が高くなり、処理効率が低下します。従って、トランザクションの内容によ
り、索引数を制限して作成する必要があります。
どの列に索引を付与するか、最適なアクセス・プランを検討し、本当に必要と思われる索引を選択します。
索引の物理定義と検証
z
索引が有効に活用されているかを確認し、使用されていない場合には、DROPする必要があります。索引が存在す
ることによるメンテナンス負荷を軽減するためです。静的SQLプログラムについては、SYSCAT.PACKAGESで確認で
きます。また、動的SQLプログラムについては、EXPLAINツールで確認します。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
46
データベース物理設計
DB2デザイン・ガイド
索引候補の検討
ユニーク索引が必要か
z ユニーク性の維持が必要な場合：ユニーク索引
z 参照の整合性が必要な場合：主キー
¾
CREATE TABLE実行時に、自動的に主キーに対する昇順のユニーク索引が作成
される
– 索引名
： SQL+タイムスタンプ+番号
– 索引スキーマ： SYSIBM
– CONSTRAINTで制約名をつけると管理が容易
外部キーに索引をつける
z 結合列になる可能性が高い列に索引があると、処理効率は良い
条件句(WHERE句に現れる述語)の中で頻繁に使用される列を
検討
z 結合列
z 探索条件の列
¾
¾
ANDで結ばれた等号述語
範囲指定の述語（ＢＥＴＷＥＥＮ，不等号述語）
¾
INCLUDE列つきのユニーク索引
z ソート列（DISTINCT、ORDER BY、GROUP BYで指定された列）
z 索引のみのアクセスを目的とした索引
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
47
データベース物理設計
DB2デザイン・ガイド
解説
基本的な索引候補
z
z
z
まず、ユニーク索引が必要かどうかを検討します。ユニーク性を維持しなければならない列が存在するので
あれば、ユニーク索引が必要です。
主キーの必要性を検討します。他の表の列と整合性を保たなければならない、マスターとなる列が存在す
るのであれば、表に主キーを設定します。基本キーの設定は、表の作成（ＣＲＥＡＴＥＴＡＢＬＥ）時に指定す
るか、または、表の変更（ＡＬＴＥＲＴＡＢＬＥ）で指定します。
外部キーがある場合、検索条件の結合列となる可能性が高いため、索引の候補になります。
さらに、その他の２次索引候補を検討します。
z
z
z
z
z
候補になる列は、条件節での登場回数が多い列です。
また、ソートの対象となる列も候補になります。
FOREIGN KEY（外部キー）が定義されている列項目
レコードの探索条件として、「=」述部に指定されることの最も多い列項目、もしくは、最初のキーとしての個
別の値が最も多い列
表を結合するときに使用するすべての列
INCLUDE列つきのユニーク索引
z
z
z
ユニーク索引の列として、ユニークではない列を含むことが可能
目的：索引のみのアクセスによるパフォーマンス向上
冗長な索引を作成しない
¾
¾
¾
表にアクセスすることなく、索引のみで照会処理要求を満たすことができます。これをindex-only accessとい
います。
INCLUDE列を指定してユニーク索引を作成することにより、データページのアクセス頻度が軽減されます。
索引キーの一部の列については、ユニーク性を保持する
ユニークではない列については、ユニーク性の検査が発生しない
¾
¾
複数列の指定が可能
ユニークではない列については、索引順（ASC，DESC）の指定は無効
¾
z
作成方法： CREATE UNIQUE INDEX 索引名 ON 表名（列名） INCLUDE (列名）
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
48
データベース物理設計
DB2デザイン・ガイド
参考：INCLUDE列つきのユニーク索引の使用例
処理するＳＱＬステートメントの例：（employee_idに主キーがある）
¾
SELECT employee_id, mgr_id FROM my_employee WHERE employee_id = 78379 ;
INCLUDE列を使用しない例：２つの索引を作成・維持する必要あり
z
１．表の作成
¾
z
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
z
１．表の作成
¾
z
z
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);
３．主キーの作成
– 既存の索引が主キーになる
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
49
データベース物理設計
DB2デザイン・ガイド
索引候補の取捨選択
索引の作成を避けた方がよい列
z
z
z
可変長列
¾
索引のメンテナンスの負荷が高い
¾
¾
¾
（例）フラグ（0 or 1）や区分など
SYSCA.COLUMNSのCOLCARD列：ユニークな値の数
オプティマイザ-が索引を選択しない
¾
アクセス・パスの決定時に索引が有効とみなされず、表スキャンになる可能性が高い
統計情報のCOLCARDの値が小さい（重複値の多い）列
サイズがごく小さい表の列
複合列索引の考慮点
z
z
複合列索引の全ての列が等号で使用されるものは有効
索引列は、最も頻繁に等号で指定される列か、最もユニーク性の高い列から順に指定する
z
完全にマッチングする索引を優先する
z
¾
最初の索引列で結果行を大幅に絞り込める索引は使用されやすい
¾
（例）索引１（col1,col2,col3) と索引２（col1,col2）がある場合で、条件がcol1=x and col2=x であ
れば索引２を優先
– 索引２はFULLKEYCARDが有効であり、かつ、キー長が短いのでバッファーヒット率が高い
統計情報でFULLKEYCARDが大きいものは有効
¾
SYSCAT.INDEXES（FULLKEYCARD）：列全体でユニークな値の数
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
50
データベース物理設計
DB2デザイン・ガイド
索引数の検討
索引数の目安：表あたり５個以下が望ましい
z
むやみに索引を作成することは、ディスクを無駄に消費し、負荷を増やすことになる
¾
¾
¾
オンラインでの更新処理環境：１－２個
照会のみの環境：５個以上作成してもよい
オンラインの更新処理と照会処理の混在した環境：２－５個
更新処理時には索引のメンテナンスが必要となり、負荷が発生する
z
z
z
z
INSERT処理では、索引列の追加処理が発生
DELETE処理では、索引列の削除処理が発生
索引列に対するUPDATE処理では、索引列の変更処理
索引のスプリット処理
¾
行のランダムな追加を予想し、事前にページにフリースペースを確保しておく（PCTFREE）
その他の負荷
z
z
z
z
クラスター索引がある表へのINSERTは、索引順を極力保持するようにデータを格納する
ディスク・スペース使用量の増加
LOAD、REORG時の索引の再作成の負荷
索引の追加によりプログラムのPREPARE時間が増加
¾
¾
静的SQLではＢＩＮＤ時、動的SQLでは実行時の時間が増加する
検討すべきアクセスパスの組み合わせが増加する
前方スキャン、逆方向スキャンの両方が必要な場合、ALLOW REVERSE
SCANSオプションを指定して索引を作成する（二つの異なる索引を作成する
必要はない）
z
V9以降、新規で作成される主キー、ユニーク・キー、または索引(拡張索引は除く)は、デフォル
トでALLOW REVERSE SCANS設定になる。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
51
データベース物理設計
DB2デザイン・ガイド
解説
索引数が増えると、照会のパフォーマンスは向上する可能性がある一方で、索引のメンテナン
ス負荷が高くなり、更新の際の処理効率が低下します。従って、トランザクションの内容により、
索引数を制限して作成する必要があります。
複数の索引を作成する前には、ディスク・スペースや処理時間への影響も留意し検討する必要
があります。
索引のスプリット処理
z
索引のリーフ・ページが満杯になった時点で、さらにそのページにデータが格納される必要があったとき、索引ページは分割
され、２つのリーフ・ページになります。分割されるデータの割合は、満杯になった索引ページが索引構造内でどの場所にあっ
たかにより異なります。
索引ページのフリースペース（PCTFREE）
z
表にランダムにデータをＩＮＳＥＲＴするようなアプリケーションにより、索引のリーフページが頻繁にスプリットされてしまうのを
防ぐために有効です。
CREATE INDEX ステートメントのオプションです。また、LOAD時にMODIFIED BY INDEXFREESPACE=xにより、再指定するこ
とも可能です。
フリースペースが確保されるタイミングはLOADおよびREORG時です。
z
z
z
INSERT,DELETEがない
索引キーの更新がなく、固定長列のみなので更新による行のネスティングが発生しない
照会のみである
z
z
以下の場合には、フリースペースは必要ありません。
LOADに関する考慮点
z
ＬＯＡＤの前に索引作成を行っておいたほうが、ＬＯＡＤ後に索引を作成した場合と比較すると、合計時間が短くてすみます。ま
た、事前にユニーク索引を作成しておいた場合には、ＬＯＡＤ時にユニーク性の検査が行われます。
z
ＬＯＡＤの前に索引を作成しておく場合には、索引を作成するための一時領域を確保しておく必要があります。メモリー領域と
しては、DB構成パラメーターSORTHEAPに設定された容量のソート領域が使用されます。また、ディスク領域としては、一時
表スペースが使用されます。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
52
データベース物理設計
DB2デザイン・ガイド
索引に関するその他の検討事項
索引用の表スペース
z
索引用の表スペースを作成する（DMSのみ）
¾
¾
表データとは別の物理ディスクに配置することによる並列Ｉ／Ｏが期待できる
索引だけ早いディスクに格納することができる
¾
索引をメモリー上に保持し、バッファーヒットさせたい場合
¾
ＡＩＸファイルシステムのキャッシュが使用可能
z
索引用の表スペースに対するバッファープールを作成する
z
索引用の表スペースはＤＭＳファイル表スペースにすることも検討？
索引が有効利用され、最適なアクセスパスを得るために
z
z
索引順を維持する
¾
¾
¾
クラスター索引により索引順を維持する
REORGにより定期的に索引順を維持する
ユニーク索引の列による１件検索の場合には、クラスター率が低くても問題はない
¾
実行タイミング
– 表のデータがLOADされ、適切な索引が作成された時
– 表のデータがREORGされた時やアプリケーションをBINDする時
– 表および索引のデータの10%－20%がUPDATE/DELETE/INSERTされた時
現時点の統計情報に更新することにより、現状で最適なアクセス・パスが選択される（動的ＳＱＬの場合）
RUNSTATS実行後、BINDを実行する（静的SQLの場合）
ＲＵＮＳＴＡＴＳの実行による統計情報更新とBIND実行
¾
¾
V9.7
索引のTYPE
z
DB2 V9.7 から、タイプ 1 索引は廃止されました。
索引の圧縮の使用
V9.7
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
53
データベース物理設計
DB2デザイン・ガイド
解説
索引データを索引用の表スペースに格納するためには、表の作成（ＣＲＥＡＴＥＴＡＢＬＥ）時に、
その表に対して作成された索引のデータをどの表スペースに格納するかを明示的に指定しま
す。
z
CREATE TABLE 表名 (COL1 INTEGER, .......) IN 表の表スペース名ＩＮＤＥＸＩＮ索引の表スペース名
索引が作成されている索引用の表スペースをDROPすることはできません。DROP時に、関連す
るデータベース・オブジェクトが存在するためにDROPが不可能である旨のエラー･メッセージが
戻されます。この場合、索引を全てDROP後に、表スペースをDROPするか、または、DROP
TABLESPACE文で、関連する表スペースを全て指定することにより、表スペースをDROPするこ
とが可能です。
RUNSTATSは、表のデータが大きく変化した場合に、統計情報を最新の状態に更新するために
実行します。動的SQLは動的にＢＩＮＤを実行するため、ＲＵＮＳＴＡＴＳで統計情報を変更するこ
とによりアクセス・パスが変わる可能性があります。
静的SQLの場合は、RUNSTATS実行後、より最適なアクセス・パスを得るには、BINDを実行す
る必要があります。
ＲＵＮＳＴＡＴＳはＡＮＤＩＮＤＥＸＥＳオプションつきで実行します。また、必要に応じて、WITH
DISTRIBUTIONオプションつきで実行し、非一様分布統計情報を収集してみます。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
54
データベース物理設計
DB2デザイン・ガイド
参考：索引列の最大数と索引キーの最大長
索引列の最大数と索引キーの最大長は、V8以前とV9で異なる。
（V9で拡張された。）
バージョン
ページ・
サイズ
V8まで
4/8/16/32KB
16
1024
4KB
64
1024
8KB
64
2048
16KB
64
4096
32KB
64
8192
V9
索引列の最大数
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
55
索引キーの最大長
（bytes）
データベース物理設計
DB2デザイン・ガイド
ブランク・ページです
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
56
データベース物理設計
DB2デザイン・ガイド
②データ容量の見積もり
表/索引の見積もり
表スペースの見積もり
z カタログ表スペース
z ユーザー表スペース
z 一時表スペース
ログ領域の見積もり
z アクティブ・ログ領域
z アーカイブ・ログ領域
製品インストール・ディレクトリーの見積もり
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
57
データベース物理設計
DB2デザイン・ガイド
ブランク・ページです
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
58
データベース物理設計
DB2デザイン・ガイド
表／索引の見積もり
前提：
z 見積もりの基礎となる前提の数値、算定根拠を明確にする
¾
各表のレコード件数を見積もる上で必要な数値の収集
– コード類、マスター類の件数、１日あたりの処理件数
– データの保持期間、データ増加率
¾
．．．etc.
お客様にAuthorizeされた前提の数値であることが重要
– 前提に変更があれば、都度再見積もり可能なようにワークシートにまと
めておく
z あくまでも見積もりであり、テスト環境のDBでデータを格納し確認
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
59
データベース物理設計
DB2デザイン・ガイド
解説
論理設計のアウトプットである表を作成した場合に、どれだけのディスク容量が必要となるかを見積もる必要があり
ます。
この容量見積もりは、表に含まれるデータだけではなく、索引のデータも含まれます。後段階でパフォーマンス
チューニングを行う際に索引が追加されることも考慮し、索引を作成する表スペースの容量には余裕を持たせる必
要があります。
見積もり作業を開始するにあたっては、表や索引の定義が決定していることは言うまでもありませんが、見積もりの
基礎となる前提の数値（コード類、マスター類の件数、１日あたりの処理件数、データの保持期間、データ増加率．．．
etc）や算定根拠を明確にする必要があります。
各表のレコード件数を見積もる上で必要な数値の収集は、お客様にAuthorizeされた前提の数値であることが重要
です。
前提に変更があれば、都度再見積もりが必要となりますので、再見積もりが容易になるようにワークシートにまとめ
ておきましょう。
データベース・オブジェクトのサイズは、正確に見積もることができません。サイズの見積もりを難しくする原因は、
ディスクのフラグメント化によって発生するオーバーヘッド、フリー・スペース、および可変長列の使用などです。これ
は、列タイプや行の長さが広い範囲で異なる可能性があるためです。まずデータベースのサイズを見積もってから、
テスト・データベースを作成し、それに標準的なデータを入れてみてください。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
60
データベース物理設計
DB2デザイン・ガイド
表／索引の見積もり
表容量概算：（論理レコード長＋10）×レコード件数×安全率
z
z
z
z
z
論理レコード長
¾
¾
¾
各データ項目のデータ・タイプ、桁数から各項目の物理サイズを算出。可変長の場合は、平均長を採用。
NULL値を許す場合１バイト、可変長の場合4バイトを各該当の列項目あたり加算
すべてを合計したのが1行あたりの論理レコード長
¾
保存期間、データ増加率も加味
¾
¾
PCTFREEの割合やAPPENDモードであるかも考慮する
オーバーヘッド分（フラグメンテーションやオーバー・フロー・レコードの有無）
¾
¾
LONG VARCHAR、LONG VARGRAPHICは24バイト、LOBは各列の情報(ポインターなど)のみを他データと共
に持つ
V9.7より指定サイズ以下のLOBは、他データと同じ場所に保存可能 V9.7
¾
表スペースのページ・サイズを決定し、１ページあたりの行数から必要ページ数を導く（後述）
レコード件数
安全率（余裕率）
Long列データは他の表データとは別のところに保管
必要なディスク容量
索引容量概算：(平均索引キー・サイズ＋９）×行数×安全率
z
基本的な算出方法の考え方は表と同等
z
LARGE表スペースに作成した表に定義する索引の場合（LARGE RIDを使用する場合）
¾
索引の1つの行項目当たり 2 バイトが追加で必要。
–
¾
LARGE表スペースに作成したパーティション表に定義する索引の場合、LARGE RID分の2バイトと、パーティ
ションID用の2バイトが追加で必要。
–
z
z
(平均索引キー・サイズ＋９＋２）×行数×安全率
(平均索引キー・サイズ＋９＋２＋２）×行数×安全率
安全率
¾
¾
ノンリーフ・ページやフリー・スペースなどのオーバーヘッドのため、少なくとも２倍は必要
索引の作成時のソートに必要な一時スペースの領域は、上記の式の安全率を３．２として見積もる
後にパフォーマンスチューニングで索引が追加されることも考慮し余裕を見ておく
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
61
データベース物理設計
DB2デザイン・ガイド
解説
ここで、レコード長を計算する場合、ヌルが可の場合1バイト、可変長の場合4バイトを加える必要があります。
論理レコード長は、各データ項目のデータ・タイプ、桁数から各項目の物理サイズを算出して、可変長の場合は、平
均長を採用します。NULL値を許す場合１バイト、可変長の場合4バイトを各該当の列項目あたり加算し、これらをす
べて合計したのが１行のレコード長となります。
レコード件数は、保存期間、データ増加率も加味します。また、安全率としてPCTFREEの割合やAPPENDモードであ
るかの考慮や、オーバーヘッド分（フラグメンテーションやオーバー・フロー・レコードの有無）も考慮します。
索引のキー長も算出方法は基本的には表と同等です。
V9からサポートされたLARGE RID（6バイト）は、通常のRID（4バイト）より2バイト拡張されているため、LARGE表ス
ペースに作成した表に対して定義する索引の場合、索引の1つの行項目あたり追加で2バイト必要です。
更に、その表がパーティション表である場合、索引キーにパーティションIDが含まれますので、その分の2バイトが追
加で必要になります。
後段階でパフォーマンスチューニングを行う際に索引が追加されることも考慮し、索引を作成する表スペースの容量
には余裕を持たせる必要があります。
最終的に必要なディスク容量は、表スペースのページ・サイズを決定し、1行の長さから１ページあたりの行数を算出
し、全データ件数をその１ページあたりの行数で割ることにより、必要ページ数を導きます。（後述）
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
62
データベース物理設計
DB2デザイン・ガイド
解説
各データ・タイプ毎のサイズ
データ・タイプ
バイト
INTEGER
4
SMALLINT
2
DOUBLE
8
DECIMAL(n,m)
(n/2 + 1)
CHARACTER(n)
n
VARCHAR(n)
n+4
GRAPHIC
n*2
VARGRAPHIC
(n*2)+4
DATE
4
TIME
3
TIMESTAMP
10
XML
96
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
63
データベース物理設計
DB2デザイン・ガイド
解説
LOBデータ
z SQLXXXX.LB 1024*2の累乗のセグメントずつ増えます。
z
1024、2048、・・・、64MB
z SQLXXXX.LBA アロケーションとフリー・スペース情報
z
64GB毎に4KBページ 1個 + 8MB毎に4KBページ1個。
z 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バイトずつとります
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
64
データベース物理設計
DB2デザイン・ガイド
参考：LOBデータ
セグメント(1024)単位でデータを格納
z 1024バイト*2の累乗<1024バイト、2048バイト、4096バイト...>
1MBセグメント
1MB
LOBデータ
2MBセグメント
1.1MBバイト
LOBデータ
compactオプション<CREATE TABLE>
z データが格納されないままのディスク・スペースを有効に活用できる
z パフォーマンスは低下する可能性がある
z 再編成(REORG)に注意する
¾
compactオプションを使用しない場合、再編成でサイズが大きくなる可能性が
ある
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
65
データベース物理設計
DB2デザイン・ガイド
参考：LOBデータ
LOBデータオブジェクト
z CREATE TABLE時のLOB最大サイズはディスク使用量に影響しない
LOB割り振りオブジェクト
z 64GBごとに4Kページ1個＋ 8MBごとに4Kページ1個
LOB記述子
LOB最大サイズ(バイト)
REGULAR表スペース
LOB記述子
LONG表スペース
LOBデータオブジェクト
LOB割り振りオブジェクト
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
66
LOB記述子サイズ
1K
72
8K
96
64K
120
512K
144
4M
168
128M
200
512M
224
1G
256
1.5G
280
2G
316
データベース物理設計
DB2デザイン・ガイド
参考：LOBデータの表スペース計算
LOBデータオブジェクト:
z 実際に格納されるデータのセグメント * レコード件数
LOB割り振りオブジェクト:
z ROUNDUP(LOBデータオブジェクトサイズ/64GB) * 4KB
+
ROUNDUP(LOBデータオブジェクトサイズ/8MB) * 4KB
LOB記述子
z LOB記述子サイズ * レコード件数
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
67
データベース物理設計
DB2デザイン・ガイド
V9.7
参考：LOBデータの基礎表への格納（LOB Inline）
インライン格納とは
z LOBデータをLOBオブジェクトではなく、基礎表へ格納する保持形態
z 表の作成時に基礎表へ格納するサイズの上限を指定する。
通常のLOB保持形態
LOBオブジェクト
データ・オブジェクト
ID
…
IMAGE(LOB)
PR27
…
LOB記述子
PR28
…
LOB記述子
ACC
…
LOB記述子
インライン格納を使用したLOB保持形態
データ・オブジェクト
ID
…
PR27
…
PR28
…
ACC
…
LOBオブジェクト
IMAGE(LOB)
LOB記述子
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
LOBデータが基礎表
に格納されている
68
データベース物理設計
DB2デザイン・ガイド
V9.7
参考：LOBデータの基礎表への格納のメリットと考慮点
インライン格納のメリット
z バッファープールへの格納対象になるため、READ/WRITEとも飛躍的に高速化さ
れる
z レコード本体への1回のアクセスで処理が完了するため、I/O回数の削減が見込
める
z インライン格納されたLOBデータは行圧縮の対象とすることが可能
考慮点
z 基礎表に入りきらないLOBデータは今までどおりLOBオブジェクトに格納される
¾
各InlineLOBには4バイトのストレージオーバーヘッドが取られる
– よって、InlineLOBの行最大長は32kページを使用している場合32673バイト
z LOBをINLINE化することにより、1ページ内に格納できる行数が少なくなるため、
LOB列を照会結果に含めない場合は今までよりもパフォーマンスが劣化する可
能性がある
z INLINE化されたLOBデータはロギングの対照となる
z INLINE化されたLOBデータを含む表のデータ再編成の処理時間はINLINE化しな
い場合よりも延びる傾向がある
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
69
データベース物理設計
DB2デザイン・ガイド
参考：XMLデータの容量見積もり
XML部分はRelationalデータとは別に保管される(XDA)
zRelationalデータ部分には、XMLデータ指定子(XDS)と呼ばれるポインターが格納される。
zLOBと同様、inlineの指定も可能。
zSMS表スペースにXMLデータを保管する場合、拡張子.xdaのファイルとして格納される。
XML文書をXML列に格納すると、XML文書サイズの1.5-2.5倍になる
zさらに大きくなることもあるため、余裕を見てXML文書サイズの3倍程度用意する。
XDA (XML Data Area)
create table dept (deptID int,…, deptdoc xml)
deptID (int)
…
deptdoc (XML)
1
…
XML データ指定子(XDS)
…
…
…
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
70
データベース物理設計
DB2デザイン・ガイド
V9.5
参考：DB2 V9.5でのXMLデータの基礎表への格納(inline格納)
DB2 V9.5では、指定したサイズ以下のXMLデータを基礎表に保持可能
z 基礎表に保持させたいXML列を定義する際に「INLINE LENGTH <integer>」キーワードを付加する。
z 表の作成時に、カラムオプションとして指定
z 下記の例では、10000バイト以下のXMLデータを、ベース表に保持する。
create table dept (deptID char(8),...,doc XML inline length 10000)
データ・オブジェクト
ID
…
PR27
…
PR28
…
ACC
…
索引オブジェクト
DOC (XML)
Regions
Index
XML記述子
XDAオブジェクト(XML Data)
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
71
データベース物理設計
DB2デザイン・ガイド
V9.5
参考：XMLデータの基礎表への格納のメリット
メリット
z XMLデータを参照する際に必要なI/Oリクエスト削減
SELECT/INSERT/UPDATE全般の性能向上
¾ XMLデータを処理する際にReagions IndexやXDAの参照が不要になる
¾
z 行圧縮の対象にすることが可能
考慮点
z 通常データとXMLデータを別テーブルスペースに配置する場合、基礎表と
XDAの容量バランスに注意する。
¾
XMLデータの基礎表への保管を行う場合、基礎表のページサイズを大きくした
上で、基礎表とXDAを同じ表スペースへ格納することも検討する。
z リレーショナルデータへのアクセスが主たる表に、XML列を追加する場合
XMLデータを基礎表に保管する場合、1ページ当たりに格納可能なレコード数
が減少する。
¾ 特に既存のアプリケーション、SQLが存在する場合、1ページ当たりのレコード
数減少が処理性能に影響する可能性があるため、パフォーマンス検証を行うこ
とを推奨。
¾
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
72
データベース物理設計
DB2デザイン・ガイド
参考：データ行圧縮

V9からの新機能

目的
z
z
z
z

データ・ページ使用量の削減
¾
特に、繰り返しデータがあるような場合はお奨め
¾
トレード・オフとして、CPU使用率の増加（圧縮、解凍のため）
¾
圧縮された状態でバッファープールに読み込まれる
¾
¾
Insert/Delete は圧縮されたイメージでロギング
Update についてはログ量が増える可能性有り
I/O負荷の削減
バッファー・プールの使用率向上
ログ書き出し量の削減（例外有り）
圧縮指定方法
1.
2.
CREATE/ALTER TABLEで表に対する「COMPRESS YES」の定義
オフライン再編成の実施
¾
¾

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

辞書を作成するために「REORG … KEEPDICTIONARY（もしくはRESETDICTIOANRY）」コマンドの実行
辞書作成フェーズを経て、表データの圧縮が行われる
指定した表のデータのサンプルを基に辞書を作成し、この辞書を使用して圧縮テストを行うことで、圧縮率を
見積もる
使用方法
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
考慮点
z
z
XML列、LONG/LOB列、索引は圧縮の対象にならない
データ行圧縮機能を利用するためには、ESEかつ「Storage Optimization Feature」を導入する必要がある
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
73
データベース物理設計
DB2デザイン・ガイド
参考：データ行圧縮
Lempel Ziv アルゴリズム（LZ78,静的辞書圧縮法）を応用した圧
縮方法
特定のフレーズを辞書に登録し、辞書にあるデータを基に実
データを圧縮していく
■LZ78の例
圧縮前
辞書を作成
番号
文字列
１
‘AB’
2
‘BU’
3
‘UR’
LZ78辞書
ABURAKATABURA
圧縮前「１３文字」あったのが、圧
縮後に「１０文字」になっている
圧縮後
13AKATA2RA
辞書を元にデータを圧縮
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
74
データベース物理設計
DB2デザイン・ガイド
V9.7
参考：V9.7 圧縮機能の拡張
圧縮対象オブジェクトが増えた
z
z
索引
Inline LOB
z
（一時表）
z
XMLのXDAオブジェクト
索引圧縮指定方法
圧縮表上に作成する索引は自動的に圧縮される
明示的にCREATE/ALTER INDEXで索引に対する「COMPRESS YES/NO」の定義をする
のも可能
z 既存の索引の圧縮・非圧縮の状態をALTER INDEXで変更した場合は、オフライン再編
成の実施が必要
z
z
圧縮率・圧縮後のスペースの見積もり
z
z
ADMIN_GET_INDEX_COMPRESS_INFO表関数で確認可能
ADMIN_GET_INDEX_INFO表関数
考慮点
z
z
MDCブロック索引、カタログ表の索引、index specifications,XMLメタ索引、XMLパス索引は対象外
データ行圧縮機能を利用するためには、AESEを購入するか、ESEかつ「Storage Optimization
Feature」を導入する必要がある
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
75
データベース物理設計
DB2デザイン・ガイド
V9.7
参考：V9.7 圧縮機能の拡張（解説）

圧縮対象オブジェクト
z
索引
¾
¾
z
z
z

データ行圧縮とは異なり、複数のアルゴリズムを組み合わせて実現している
索引効率が高いものに使用する
–
–
–
索引のカーディなりティーが低いもの（非ユニーク索引）
重複データが前方のキー列に多いもの（ＤＡＴＥ列など）
クラスター率の高い索引
Inline LOB
¾
Compress yesと指定された表にあるInline LOBは自動的に圧縮
¾
基礎表に入っているLOBのみ
XMLのXDAオブジェクト
V9.5までは、基礎表に含まれたXMLデータのみが対象
9.7からはCompress Yesと定義された表に関連したXDAオブジェクトも圧縮される
（一時表）
¾
オプティマイザーが圧縮を行うか否かを判断
¾
¾
圧縮率の見積もり
z
ADMIN_GET_INDEX_COMPRESS_INFO表関数の使用例
$db2 "select substr(indname,1,5) as indname,substr(tabname,1,10) as
tabname,compress_attr,index_compressed,pct_pages_saved,num_leaf_pages_saved from table
(admin_get_index_compress_info('I',‘db2v97','ID1','-2','-2')) as t"
INDNAME TABNAME
COMPRESS_ATTR INDEX_COMPRESSED PCT_PAGES_SAVED NUM_LEAF_PAGES_SAVED
------- ---------- ------------- ---------------- --------------- -------------------ID1
LINEITEM1 N
N
48
599
z
ADMIN_GET_INDEX_INFO表関数の使用例
$ db2 "select substr(tabname,1,10) as tabname,substr(indname,1,5) as indname,INDEX_OBJECT_P_SIZE from
table(admin_get_index_info('',‘db2v97','LINEITEM1')) as t"
TABNAME
INDNAME INDEX_OBJECT_P_SIZE
---------- ------- -------------------LINEITEM1 ID1
10240
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
76
データベース物理設計
DB2デザイン・ガイド
表スペースの見積もり
システム・カタログ表スペース
z
システム・カタログ表が使用する容量は、表スペースのタイプ（SMS or DMS）とエクステント・サイズによって
異なる。
¾
z
DMSの場合、各表オブジェクトについて最低 2つのエクステントが割り当てられる。この未使用のスペースを
削減するために、カタログ表スペースをDMSで作成する場合は、エクステント・サイズを小さくすることを(2 か
ら 4 ページ) を検討する。
データベース作成時、デフォルトでは自動サイズ拡張が使用可能なDMS（ファイル）表スペースとして作成さ
れる（初期サイズはDB2が自動決定）ため、表スペース容量が不足する前に自動的にサイズが拡張される。
¾
¾
ファイル・システムがいっぱいになると自動拡張が失敗するため、余裕をもって作成しておく。（通常、数百MB
～1GB程度あれば問題なし。）
自動ストレージ表スペースであるため、ALTER TABLESPACEによる拡張はできない。
ユーザー表スペース
z
z
既に決まっているページ・サイズと平均行サイズから、１ページに格納できる行数を算出
予想される行数を格納するために必要となるページ数を算出
¾
¾
ROUND DOWN(ページ・サイズ/(論理レコード長)) = １ページあたりの行数
(レコード件数/１ページあたりの行数) * 安全率 = 必要ページ数
– 安全率：オーバーヘッド分、PCTFREEの分や、同じ表スペース内でREORGする場合なども考慮
一時表スペース
z
z
一番大きく使用すると思われるケースで検討する
システム一時表スペース
¾
¾
z
z
JoinやSortを行うアプリケーションやREORG、LOADなどの運用次第で大きく変わる
SMS表スペースの使用が望ましい
– DMSでは一時表の作成時に多くのオーバーヘッドがある
– SMSではディスク・スペースを動的に割り当てるが、DMSでは事前に割り当てられてしまうため、領域
を有効活用できない
ユーザー一時表スペース
¾
¾
宣言済み一時表を使用する場合
デフォルトのユーザー一時表スペースはないため、作成する必要がある
一時表スペースの見積もりは最終的には事前に入念なテストを行って確認する
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
77
データベース物理設計
DB2デザイン・ガイド
解説
DMS表スペース - 必要な最小ページ値
表スペースの作成
表スペース
メタデータ
コンテナー・タグ
1 ページ/コンテナー
表スペースのヘッダー
1 エクステント
スペース・マップ
1 エクステント
オブジェクト表データ
1 エクステント
3 エクステント + 1 ページ
表(オブジェクト)の作成
エクステント・マップ
1 エクステント
データのエクステント
1 エクステント
コンテナーで最小限必要なスペース = 5 エクステント + 1 ページ
(最初のオブジェクトを作成した時)
EXTENTSIZE = 32 ページなら、 5*32＋1＝161ページがコンテナーに必要
表の再編成実行時に表スペースの名前を指定しない場合、再編成しようとする表を含む表スペースにその表の作業コピーを保管しま
す。
一時表スペースを使って表を再編成する場合、一時表スペースのページ・サイズは表のページ・サイズと一致しなければなりません。
宣言済み一時表は、独自のユーザー一時表スペース・タイプの中にのみ作成されます。デフォルトのユーザー一時表スペースはありま
せん。
一時表スペースの必要なスペースの量は照会および戻される表のサイズや照会アプリケーション、REORG、LOADなどの運用に依存
するため、正確に見積もることは難しいため、事前にテストで確認することが必要です。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
78
データベース物理設計
DB2デザイン・ガイド
自動保守用表スペースの見積もり（V8.2以降）
自動保守用表スペース（SYSTOOLSPACE）
z
V8.2の新機能、データベースの自動保守（自動統計収集および再編成）を使用する場合に自
動作成される表スペース
z
自動統計収集および再編成の作業データを、SYSTOOLSPACE表スペース中の表に格納する
z
z
SYSTOOLS表スペース作成時、約700KB
通常、SYSTOOLSPACEに必要な容量は、データベース中の表の数に比例し、1つの表に対し
て約1KB として計算する
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
79
データベース物理設計
DB2デザイン・ガイド
ブランク・ページです
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
80
データベース物理設計
DB2デザイン・ガイド
ログ領域の見積もり
アクティブ・ログ領域の見積もり
z
最低限必要なサイズ：(logprimary + logsecond) * (logfilsiz + 2 ) * 4096
¾
循環ロギングの場合
– 上記の式で求めた値に余裕を持たせたサイズを用意する
¾
アーカイブ・ロギングの場合
– アーカイブ処理の失敗によりログ・ファイルが再利用されない場合や、ロールフォワード時にロ
グがリトリーブされる領域を考慮し、余裕を持たせる（上記の式で求めた値の2倍程度）
z
アクティブ・ログの二重化を行う場合、2倍の容量が必要。
アーカイブ・ログ領域の見積もり
z
一日にアーカイブされるログ容量と保持期間を掛け合わせて必要な容量を算出する。更に、
アーカイブ・ログの削除や退避が行われなかった事態に備え、余裕を持たせて用意する。
z
複数パスへのアーカイブを行う場合（LOGARCHMETH1とLOGARCHMETH2を使用）、2倍の容
量が必要。（FAILARCHPATHを使用する場合は、その分の容量も必要。）
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
81
データベース物理設計
DB2デザイン・ガイド
参考：ログ・アーカイブ機能（V8.2以降）
内容
z
アクティブ・ログのアーカイブ機能をDB2の標準機能として提供する
z
アーカイブ方法を2つまで指定することができる
z
アーカイブが失敗した場合の代替ディレクトリーを指定できる
方法
z
z
¾
V8.1までのログのUSER EXITの機能の代替機能を提供する
¾
最大で2つの別個のロケーションにアーカイブ・ログ・ファイルを保管できる
¾
アーカイブ先が使用可能になると、ログ・ファイルは自動的に移動される
次のデータベース構成パラメーターにアーカイブ方法を指定する
¾
¾
LOGARCHMETH1
LOGARCHMETH2
¾
FAILARCHPATH
次のデータベース構成パラメーターにアーカイブ・ログ・ファイル用の代替ディレクトリーを指定する
LOGARCHMETH1
データベース
DISK
アクティブ・
ログ
TSM
ミラー・ログ
LOGARCHMETH2
テープ
VENDOR
アーカイブに失敗した場合
FAILARCHPATH
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
82
db2tapemgr
コマンド
データベース物理設計
DB2デザイン・ガイド
製品インストール・ディレクトリーの見積もり
DB2のインストールに必要なディスク容量は、選択するインストールのタイプ、
使用するファイル・システムのタイプに応じて異なる。
z
DB2セットアップ・ウィザードを使用すると、事前に見積もり可能。
¾
インストール・タイプ（標準、コンパクト、カスタム）ごとに選択されるコンポーネントに基づいて、
動的にサイズの見積もりを行う。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
83
データベース物理設計
DB2デザイン・ガイド
ブランク・ページです
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
84
データベース物理設計
DB2デザイン・ガイド
③インスタンスの構成とデータベースの分割
インスタンスとデータベース
インスタンス構成の考慮点
サポートされるクライアント＆サーバー構成
データベース作成の考慮点
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
85
データベース物理設計
DB2デザイン・ガイド
ブランク・ページです
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
86
データベース物理設計
DB2デザイン・ガイド
インスタンスとデータベース
インスタンス
z DB2のオブジェクトの最も大きな単位
z 論理的なデータベース・マネージャー環境
Unix環境
– db2syscプロセスを中心としたプロセ
ス群
¾ Windows環境
– 「DB2 - インスタンス名」サービス
– 「DB2 – DB2コピー名 – インスタンス
名 – ノード番号」サービス
¾
z 全てのオブジェクトが含まれる
z DB2の起動／停止の単位
¾
db2startコマンド／db2stopコマンド
¾
db2icrtコマンドで作成
インスタンス
データベース
表スペース(SMS)
表
索引
表スペース(DMS)
表
LOB
z １マシンに複数インスタンスの作成が可能
表スペース(DMS)
データベース
z 有機的にまとめられた表スペース、表や索引
の集まり
z 一つのインスタンスに複数のデータベースを
作成することが可能
¾
create database コマンド
z 接続(CONNECT)の対象となる
z バックアップ・リストアの最大単位
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
87
索引
表スペース(DMS)
LOB
データベース物理設計
DB2デザイン・ガイド
解説
インスタンス
z
z
z
z
z
z
一つのデータベース・マネージャー構成ファイルを使用して稼動する、データベース・マネージャー環境のことです。
インスタンスは、DB2を構成するオブジェクト群の中で、最も大きな単位です。
db2startで起動し、db2stopで停止するのは、このインスタンスです。(管理サーバーの場合、db2admin start/db2admin stop)
データベースのエンジンともいえる、db2syscプロセスが立ち上がる単位ということもできます。
インスタンスは、一台のマシン上に複数持たせることができます。しかし、一つのアプリケーション環境から扱えるのは、一つ
のインスタンス環境のみです。
db2startで起動されるインスタンス、およびアプリケーション環境で使用するインスタンスは、以下で決まります。
¾
¾
¾
¾
¾
¾
環境変数 DB2INSTANCE に指定されているインスタンスが現行インスタンスとして使用されます。
PC環境では、環境変数｢DB2INSTANCE｣が設定されていない場合があります。
その場合、レジストリー変数｢DB2INSTDEF｣に設定されているインスタンス(デフォルトではDB2)が現行インスタンスとして使用さ
れます。
DB2INSTDEFは、グローバル・レベルのレジストリー変数です。
これを変更するには以下を実行します。
db2set db2instdef=新インスタンス名 -g
データベース
z
z
z
z
z
z
z
DB2のデータベースには、様々なオブジェクトが含まれますが、ユーザーから見るときには、表や索引の集合体と言えるでしょ
う。
一つのインスタンス上に、複数のデータベースを作成することが可能です。
データベースは、接続・運用上および許可の単位です。
connectコマンドで接続するデータベースの名前を省略した場合、デフォルトでは、DB2DBDFTレジストリー変数に設定されて
いるデータベース名が使用されます。
connect toでデータベースに最初に接続する時には、ログ・ファイルやバッファープールのアロケーションなど初期作業が行な
われますので、それ以降の接続に比べて時間がかかります。
最初の接続に時間をかけたくない場合には、db2start後にactivate databaseコマンドで初期作業を行なわせて下さい。
データベースは、バックアップ取得や、CONNECT特権の単位でもあります。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
88
データベース物理設計
DB2デザイン・ガイド
インスタンス構成の考慮点
インスタンスの分け方
z アプリケーション構成
z 開発環境用と本番環境用
z 運用管理面
¾
¾
¾
管理者の権限(SYSADM、SYSCTRL、SYSMAINT)を持つユーザーを分けたいとき
インスタンスごとにデータベース・マネージャーの構成を最適化する
起動/停止のタイミングを分けたい（サービス時間、運用時間の違い）
¾
エンジン動作部分に影響を与える様なトラブル発生時に、影響範囲を小さくしたい
z 可用性
その他考慮点
z UNIX環境：
¾
同居させる他のプロダクトの要件にも注意
¾
V9.5環境では、ほとんどの（下記3つ以外の）プラットフォームにおいて64ビット・イン
スタンスのみサポート
– 32ビット・インスタンスがサポートされるのは、以下のプラットフォームのみ

V9.5
x86 用 Linux オペレーティング・システム
x86 用 Windows オペレーティング・システム
x64 用 Windows オペレーティング・システム (Windows x86 オペレーティング・システム
用インストール・イメージを使用)
z 異なるバージョン間でのクライアント＆サーバー接続
z インスタンスホームの容量
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
89
データベース物理設計
DB2デザイン・ガイド
解説
インスタンスを分ける例としては以下の様な場合があります。
z
z
z
z
z
開発用と本番用
管理者の権限(SYSADM、SYSCTRL、SYSMAINT)を持つユーザーを分けたいとき
DBMSのエンジン動作をコントロールしたい場合
起動/停止のタイミングを分けたい（運用、サービス時間）
可用性の観点で、エンジン動作部分に影響を与える様なトラブル発生時に、その影響をできる
だけ受けさせたくない
１つのマシンに複数インスタンスを作成することが可能ですが、イン
スタンスごとに、追加のシステム・リソース (仮想メモリーとディスク・
スペース) が必要になります。また、追加インスタンスを管理するた
めにさらに管理が必要になります。
V9.5
V9.5では、ACSのモジュールが追加されたため、V9.1よりもインスタ
ンス・ホーム・ディレクトリに必要とされる容量が大きくなっています。
参考までに、AIX環境でテストしたところ、V9.1で約15MBだったもの
が、V9.5GAで、約210MBに増えていました。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
90
データベース物理設計
DB2デザイン・ガイド
V9.7
構成が可能なクライアント・サーバー一覧
※DB2 UDB V8との構成は、延長サポート契約がある場合のみを対象としております。
V8
Server
(32bit)
V8
Server
(64bit)
V9.1
Server
(32bit)
V9.1
Server
(64bit)
V9.5
Server
(32bit)
V9.5
Server
(64bit)
V9.7
Server
(32bit)
V9.7
Server
(64bit)
UNIX,
Windows,
Linux
UNIX,
Windows,
Linux
Windows,
Linux
UNIX,
Windows,
Linux
Windows,
Linux
UNIX,
Windows,
Linux
Windows
UNIX,
Windows,
Linux
V8 Client
(32bit)
YES
YES
YES①
YES①
YES(I)
YES(I)
YES1
YES1
V8 Client
(64bit)
YES
YES
YES①
YES①
YES(I)
YES(I)
YES1
YES1
V9.1 Client
(32bit)
YES①
YES①
YES
YES
YES(II)
YES(II)
YES2
YES2
V9.1 Client
(64bit)
YES①
YES①
YES
YES
YES(II)
YES(II)
YES2
YES2
V9.5 Client
(32bit)
YES(I)
YES(I)
YES(II)
YES(II)
YES
YES
YES3
YES3
V9.5 Client
(64bit)
YES(I)
YES(I)
YES(II)
YES(II)
YES
YES
YES3
YES3
V9.7 Client
(32bit)
YES1
YES1
YES2
YES2
YES3
YES3
YES
YES
V9.7 Client
(64bit)
YES1
YES1
YES2
YES2
YES3
YES3
YES
YES
※注釈が付いている内容については、次ページをご確認下さい
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
91
データベース物理設計
DB2デザイン・ガイド
解説: 構成が可能なクライアント・サーバー一覧
※DB2 UDB V8との構成は、延長サポート契約がある場合のみを対象としております。

注(V9.1マニュアルより抜粋):
①
②
③
④
DB2 V8の機能のみ使用可能
SQLのみ対象(管理ツール, ユーティリティー, API対象外)
V7クライアントとV8サーバーへのアクセスと同じ制限事項
V9サーバーへの接続を確立したい場合はゲートウェイ(32bit)を使用する
z
詳細は、下記のDB2オンラインマニュアルをご参照ください。
¾
¾
¾
¾

[クライアントとサーバーのバージョンのサポートされている組み合わせ]
http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2.udb.uprun.doc/do
c/r0009731.htm
[DB2クライアントの移行に関する重要事項]
http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2.udb.uprun.doc/do
c/c0022579.htm
注(V9.5マニュアルより抜粋):
I.
II.
DB2 V8の機能のみ使用可能
DB2 V9.1の機能のみ使用可能
z
詳細は、下記のDB2オンラインマニュアルをご参照ください。
¾
[クライアントとサーバーのバージョンのサポートされている組み合わせ]
¾
http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=/com.ibm.db2.luw.qb.client.do
c/doc/r0009731.html
¾
[クライアントのマイグレーションに関する重要事項]
¾
http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/topic/com.ibm.db2.luw.qb.migration.doc/doc/
c0022579.html
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
92
データベース物理設計
DB2デザイン・ガイド
V9.7
解説: 構成が可能なクライアント・サーバー一覧

注(V9.7マニュアルより抜粋):
1.
2.
3.
DB2 V8の機能のみ使用可能
DB2 V9.1の機能のみ使用可能
DB2 V9.5の機能のみ使用可能
z
詳細は、下記のDB2オンラインマニュアルをご参照ください。
¾
¾
¾
¾
[クライアントとサーバーのバージョンのサポートされている組み合わせ]
http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=/com.ibm.db2.luw.qb.clie
nt.doc/doc/r0009731.html
[クライアントのアップグレードに関する重要事項]
http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=/com.ibm.db2.luw.qb.upg
rade.doc/doc/c0022579.html
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
93
データベース物理設計
DB2デザイン・ガイド
ブランク・ページです
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
94
データベース物理設計
DB2デザイン・ガイド
データベース作成の考慮点
データベースの分割の目安
z アプリケーション構成（業務内容）
z 同時に処理する要件があるか
¾
¾
¾
パフォーマンスの観点から一つにすることも検討
分割されていると２フェーズ・コミット必要
JOIN不可(連合DBを使用の場合は可能）
¾
¾
処理時間
運用時間帯
¾
Unicodeデータベース
z 運用管理（バックアップ／リストア）の面から検討
z 可用性
z テスト環境ではフェーズやチーム単位で分割
z コード・セット別
V9.5
– V9でXMLデータタイプを使用する場合、UTF-8のデータベースでなければならない
– V9.5のデフォルトでは、UTF-8のデータベースとして作成される。UTF-8のデータベー
スでなくともXMLデータタイプ使用可
z 分割する場合、レプリケーション機能の検討も必要か
z デフォルトのページ・サイズはどのサイズにするか
z 自動ストレージ・データベースとして作成するか（V8.2.2以降）
¾
V9でのデフォルトでは、自動ストレージ・データベースとして作成される
作成時のCOLLATE USING句指定
z 日本語環境でデータを五十音順に照合したい場合はIDENTITYを指定
¾
デフォルトはSYSTEM（辞書順）
z 作成後は変更不可
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
95
データベース物理設計
DB2デザイン・ガイド
解説
データベースの分け方
z
z
z
z
z
z
z
まずアプリケーションの構成から決定します。業務が全く異なる場合は、別データベースにするべきですが、それぞれに属す
る表同士に何らかの関連があって同時に処理する必要がある場合は、パフォーマンスの観点からも同じデータベースにして
しまうことも検討します。
バックアップ/リストアといった運用管理の面からも検討します。
複数に分けた場合、１つがダウンしても別のデータベースは使用可能ですので、可用性という点では優位です。
このほかに、データベースを分ける例としては以下の様な場合があります。
開発用と本番用
共用する表を持たない異なるシステムの場合（表をJOINしたい場合は通常分けない）
Unicodeデータベースなど、コードセットの異なるDBが必要･･･など
CHAR、VARCHAR、LONG VARCHARの照合(ソート、比較など)においては、値の重み付けを考
慮する必要があります。
重み付けは、CREATE DATABASEのCOLLATE USING句で指定する事ができます。
z
SYSTEM(デフォルト)：現行のテリトリーに基づいた照合順序 (辞書順)
z
COMPATIBIRITY：DB2 V2の照合順序に同じ (電話帳順)
z
IDENTITY：バイト単位で比較 (文字コード順)
¾
例：a(X'61')、A(X'41')、b(X'62')、B(X'42')、c(X'63')、C(X'43')、・・・
¾
例：A、a、B、b、C、c・・・
¾
例：A、B、C、・・・、a、b、c・・・
日本語などのダブルバイトの文字については、1バイトずつに分割して照合が行われます。
z
SYSTEMの場合の日本語例：
z
COMPATIBIRITYの場合の日本語例：
z
IDENTITYの場合の日本語例：
¾
ヂ(X'8361')、ア(X'8341')、ッ(X'8362')、ィ(X'8342')、ツ(X'8363')、イ(X'8343')、・・・
¾
ア(X'8341')、ヂ(X'8361')、ィ(X'8342')、ッ(X'8362')イ(X'8343')、ツ(X'8363')、・・・
¾
ァ(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句の指定に関わらず、文字コード順に
照合が行われます。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
96
データベース物理設計
DB2デザイン・ガイド
④表の分類と表スペースの構成
表スペースとは
表スペースの種類と選択
z DMS表スペースとSMS表スペース
複数表スペースの検討
一時表スペースの定義
検討すべき表スペース属性
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
97
データベース物理設計
DB2デザイン・ガイド
ブランク・ページです
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
98
データベース物理設計
DB2デザイン・ガイド
表スペースとは
表スペース
z
z
表のデータを格納するための論理的な領域媒体
実際にデータを格納する物理的な媒体をコンテナーという
¾
z
z
一つの表スペースを１つ以上のコンテナーで構成
データベース内に作成される表スペース
¾
z
コンテナーの実体はファイルシステムのディレクトリ、ファイル、または論理ボリュームなどの
ローデバイス
システム・カタログ表スペース，システム/ユーザー一時表スペース，ユーザーデータ用表ス
ペース
表スペースはバックアップの最小単位
データベース
表スペース
表スペース
バッファープール
表
バッファープール
索引
コンテナー
０
表
コンテナー
３
コンテナー
１
コンテナー
２
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
99
コンテナー
４
データベース物理設計
DB2デザイン・ガイド
解説

表スペースは、表のデータを記憶するための論理的な領域媒体です。
実際に表のデータが物理的に格納されるのは、表スペースに紐付けされたコンテナーになります。
コンテナーは、表スペースのタイプにより、ディレクトリーやファイル、デバイスといった形態を取ります。
一つの表スペースに複数のコンテナーを割り当てることができます。
z
データはコンテナー間で平均的に割り振られます。
z
SYSCATSPACE：システム・カタログ表スペース
一つのコンテナーは、一つの表スペースにしか属することはできません。
表スペースへのデータの書き出しは、エクステントと呼ばれる割り当て単位に行われます。(デフォル
トは32ページ) (詳細は後述)
create databaseを実行すると、デフォルトでは３つの表スペースが自動的に生成されます。
¾
¾
システム・カタログ表、およびその索引が入っている表スペースです。
データベース作成時に作られ、一旦作られた後は、変更や削除することができません。
¾
JoinやSort時に一時的にデータが入る表スペースです。
¾
¾
ユーザーのデータや索引が入れられる表スペースです。
表スペースを指定せずにcreate tableを実行すると、他のユーザー・データ用表スペースが無い場合は、デフォルトで、この表スペースが使わ
れます。
既に他のユーザー・データ用表スペースが作られている場合には、最初に作られた表スペースが使われます。
z
TEMPSPACE1：システム一時表スペース
z
USERSPACE1：ユーザー・データ用表スペース
¾
表スペース単位でバックアップ/リストアを行うことも可能です。
ロールフォワード回復不可能な場合(循環式ロギング)は、データベース単位のバックアップのみ可能
です。
z
循環ロギングの設定
¾
¾
¾
LOGRETAIN（DB構成パラメーター）=NO
USEREXIT（DB構成パラメーター）= NO
LOGARCHMETH1/LOGARCHMETH2 （DB構成パラメーター）=OFF
ロールフォワード回復可能な場合(アーカイブ式ロギング)は、表スペース単位のバックアップ/リストア
が可能です。
z
アーカイブ・ロギングの設定
¾
¾
¾
LOGRETAIN=ON またはRECOVERY（V6.1より）
USEREXIT=YES
LOGARCHMETH1/LOGARCHMETH2でアーカイブ方法を指定
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
100
データベース物理設計
DB2デザイン・ガイド
表スペースの種類と選択
適切な表スペースを選択する
z
ストレージ管理のタイプによる表スペースの種別
¾
¾
¾
z
SMS：オペレーティング・システムのファイル・マネージャーによるファイル管理
DMS：データベース・マネージャーによるファイル管理
自動ストレージ：データベース・マネージャーが必要に応じてコンテナーの作成を制御
保管データのタイプによる表スペースの種別
¾
LARGE（V9以降のDMS表スペースのデフォルト）
¾
REGULAR（V9以降のSMS表スペースのデフォルト、V8以前のDMS/SMS表スペースのデフォ
ルト）
– V8以前：LOB、LONGデータ、索引用
– V9以降：通常のデータ、LOB、LONGデータ、索引用
– 通常のデータ、索引用
¾
TEMPORARY
– 一時表用

z
システム一時表スペース
ユーザー一時表スペース
表スペースのページ・サイズ
¾
¾
4KB，8KB，16KB，32KB
4KB以外の表スペース作成の場合、事前に同じページ・サイズのバッファープールと一時表ス
ペースを作成する
– V8.2.2以降は、データベース作成時にデフォルトのページ・サイズを指定することができる。
（4KB以外のページ・サイズを使用する場合でも、ページ・サイズを1種類に統一することがで
きる。）
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
101
データベース物理設計
DB2デザイン・ガイド
解説
ストレージ管理のタイプにより、以下のいずれかのタイプを指定します。
z
z
z
SMS(System Managed Storage)
¾
¾
各オペレーティング・システムのファイル・システムがファイルを管理します。
コンテナーとしては、ディレクトリーを設定します。
¾
¾
データベース・マネージャーがファイルを管理します。
コンテナーとしては、ファイル、またはデバイスを設定します。
¾
¾
データベース・マネージャーがストレージを管理します。
コンテナーとしてストレージパスを指定。指定しない場合、自動的にデータベースに関連付けられたパスに作成される。
DMS(Database Managed Storage)
自動ストレージ
保管データのタイプにより、以下のいずれかのタイプを指定します。
z
ＬＡＲＧＥ表スペース
¾
z
ＲＥＧＵＬＡＲ表スペース
¾
z
すべての永続データを保管します。このタイプは、データベース管理スペース (DMS) 表スペースでのみ使用できます。また、タイプを指定しな
い場合の、DMS 表スペースのデフォルト・タイプでもあります。 LARGE 表スペースに表を配置すると、以下のようになります。
–
REGULAR 表スペースに配置する表よりもサイズを大きくできます。
–
表のデータ・ページ当たり、255 を超える行数をサポートできるので、データ・ページのスペース使用効率が向上します。
–
REGULAR 表スペースに配置した表に索引を定義する場合に比べ、索引の 1 つの行項目当たり 2 バイトが追加で必要になります。
すべての永続データを保管します。このタイプは、DMS 表スペースと SMS 表スペースのいずれも指定可能です（SMS 表スペースでのデフォ
ルト・タイプです）。
ＴＥＭＰＯＲＡＲＹ表スペース
¾
¾
システム一時表スペース
–
JoinやSortで一時的にデータが入る表スペースです。
–
システム一時表スペースは、データベースに最低一つは必要です。一つしかない時には、削除しようとするとエラーとなります。
–
4KB以外のページを持つ表スペースがある場合、そのページに合せた一時表スペースも作っておいて下さい。
ユーザー一時表スペース
–
省略時にはデータベース作成の時点で作成されません。Global Temporary Tableが使用する表スペースです。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
102
データベース物理設計
DB2デザイン・ガイド
解説
4KB以外のページを持つ表スペース（表）がある場合、そのページに合せた一時表スペースも作っておいて下さい。
z
V8.2.2からは、データベース作成時にデフォルトのページ・サイズを指定できるようになりました。これにより、4KB以外のペー
ジ・サイズを使用する場合でも、データベース内の表スペース、バッファープールのページ・サイズを統一することができます。
参考：Global Temporary Table(ユーザー定義一時表)
z
z
z
z
z
アプリケーションは、データベースに接続している間、一時的な表を作成して使用できます。
一時表を定義するには、DECLARE GLOBAL TEMPORARY TABLE ステートメントを使用します。
ユーザー定義一時表が保持されるのは、アプリケーションがデータベースから切断されるまでの間だけです。アプリケーショ
ンが終了したりデータベースから切断されたりすると、表の中のデータはすべて削除され、表は暗黙的に除去されます。
この表の記述は、システム・カタログには現れません。したがって、この表を他のアプリケーションのために保持したり、他の
アプリケーションと共用したりすることはできません。
ユーザー定義一時表は、ロックとログ記録を回避するので、一時表を活用するアプリケーションは大幅なパフォーマンス改善
を見込めます。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
103
データベース物理設計
DB2デザイン・ガイド
参考：DMS表スペースとSMS表スペース、自動ストレージ表スペースの比較
SMS表スペース
DMS表スペース
自動ストレージ表スペース
作成方法
MANAGED BY
SYSTEM節を使
用して作成
MANAGED BY
DATABASE節を使用して
作成
MANAGED BY AUTOMATIC STORAGE 節を使用して、
または MANAGED BY 節全体を省略して作成
※データベース作成時のAUTOMATIC STORAGEオプ
ションがYES(デフォルト）の場合、作成するすべての表ス
ペースはデフォルトで自動ストレージ表スペースとなる
（別途指定している場合を除く）
初期コンテ
ナーの定
義と場所
ディレクトリー名と
して定義する
ファイルorデバイスとして
定義する
（各コンテナーの初期サ
イズは指定する必要あ
り）
コンテナーのリストを指定する必要なし
データベース・マネージャーがデータベースに関連付けら
れた全ストレージ・パスに自動的にコンテナーを作成
データは、ストレージ・パスが等しく使用されるように、す
べてのコンテナー間で均一にストライプされる
スペース
の初期割
り振り
必要な量だけ割
り振り
表スペース作成時にすべ
て確保される
・非一時表スペースの場合
表スペース作成時に割り振られる。初期サイズはユー
ザーが指定できる
・一時表スペースの場合
必要に応じて割り振られる
表スペー
ス・コンテ
ナーの変
更
作成後は変更で
きない
（新規データ・
パーティション追
加時にコンテナー
の追加はOK）
拡張or追加できる
削減orドロップできる
表スペースサイズが削減された場合、コンテナーをドロッ
プor削減できる
データベースへ新規ストレージ追加またはデータベース
からストレージがドロップされる場合、コンテナー間で
データを均一にするためにリバランスできる
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
104
データベース物理設計
DB2デザイン・ガイド
参考：DMS表スペースとSMS表スペース、自動ストレージ表スペースの比較
SMS表スペース
DMS表スペース
自動ストレージ表スペース
ストレージ増加
要求の処理
ファイルシステム
の上限まで
どれか一つのコ
ンテナーが際大
容量に達すると
表スペースが一
杯とみなされる
ファイルシステムで指定されて
いる上限まで手動or自動で拡張
可能
コンテナーはファイルシステムで指定されて
いる制約の上限まで自動拡張
ストレージパスが追加されると、コンテナー
が自動的に拡張oｒ作成される
異なる表スペー
ス毎にさまざま
なタイプのオブ
ジェクトを配置で
きるか
できない（パー
ティション表の場
合を除く）
表、LOBデータ、索引をそれぞ
れ別の表スペースに配置可能
表、LOBデータ、索引をそれぞれ別の表ス
ペースに配置可能
継続的な保守要
件
なし
コンテナーの追加または拡張
コンテナーのドロップまたは削減
最高水準点の引き下げ
リバランス
表スペースのサイズの削減
最高水準点の引き下げ
リバランス
再定義するため
のリストアの使
用
リダイレクト・リス
トアを使用
リダイレクト・リストアを使用
リダイレクト・リストアで表スペースのコンテ
ナーを再定義する事はできないが、リスト
ア・データベースでストレージパスを変更す
ることは可能
パフォーマンス
一番遅いといわ
れている（特に大
きな表の場合）
SMSより優れている
DMSと同様
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
105
データベース物理設計
DB2デザイン・ガイド
解説
ローデバイスとファイルDMSの差はそれほど大きくありませんが、DMSとSMSではパフォーマンスに大
きな差が出る場合があります。
管理の容易さでは、SMSは、同じファイルシステムに複数表スペースを作成でき、表スペースご
とに空きスペースの監視を行う必要がない
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 に設定されます。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
106
データベース物理設計
DB2デザイン・ガイド
参考：エクステント
エクステント
z
表スペースにおけるコンテナ内の領域の割り振り単位（ページ）
¾ DMS、V8.2以降のSMSは、一度にエクステント全体をアロケートし、その後でエクステント内のページを使用
¾ V8.1までのSMSは、エクステント・サイズの値になるまで一度に１ページずつアロケートする
データはラウンド・ロビン方式でコンテナに書き込む
DMSのコンテナーで最小限必要なスペース (最初のオブジェクトを作成した時) = 5エクステント + 1ページ
エクステント・サイズは、表スペース作成時に指定(デフォルトは32ページ）
z
z
z
多数の小さい表からなる表スペースは、サイズを減らすことも検討
大量の結果行を返す照会を行う表や急激に拡張される表からなる表スペースは、サイズを増やすことも検討
作成後は変更が出来ない
コンテナ
コンテナ
コンテナ 0
0
エクステント
エクステント
コンテナ1
4K
2
1
3
エクステント
表スペース A
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
Extent = 32ページ
(デフォルト)
107
ページ
ページ
データベース物理設計
DB2デザイン・ガイド
ブランク・ページです
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
108
データベース物理設計
DB2デザイン・ガイド
SMS表スペース
SMS(System Managed Storage)表スペース
zオペレーティング・システムのファイル・システム・マネージャーが管理
z表データと索引、Longデータは全て同じ表スペースを共有
z管理が容易
zコンテナーはディレクトリー
zファイルは動的に拡張し、サイズの上限は以下によって決まる
¾コンテナーの数
¾ファイル・システム/ドライブ/ファイルのOSの限界サイズ
zコンテナーは動的に追加不可
¾ファイル・システム/ドライブのサイズは増加可能
¾再定義は表スペース復元時に可能（表スペースのリダイレクション）
¾各コンテナーサイズは同じ大きさに
z一時表スペースに推奨
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
109
データベース物理設計
DB2デザイン・ガイド
解説
SMSの特徴
z
z
z
z
SMSでは、表スペースはファイルシステムのディレクトリに相当し、表や索引はそれぞれ別々のファイルになります。SMS表ス
ペース（ディレクトリ）を作成したファイルシステムが許す限り、表に対してデータを追加することができます。つまり、表スペー
スの大きさはファイルシステムの大きさに依存します。
SMSでは表や索引およびLOBやLONG VARCHARなどの長形式のデータを含むロング形式のデータを全て同じ表スペースに
格納する必要があります。
複数のディスクにIOを分散させる為に、１つの表スペースに対してコンテナーを複数定義することがSMSでも可能ですが、コン
テナーの追加や削除を行うことはできません。表スペースを作成するときのコンテナー定義を変更する為には、一度削除して
再作成する必要があります。
複数コンテナーによってSMS表スペースを作成した場合、どれかのファイルシステムが一杯になると表スペースはそれ以上の
データを追加することができなくなります。
SMSでは、表のスペースは要求時に割り振られますので、DMSに比べて特に大量データの挿入に関
してパフォーマンスが劣ります。一度に割り振られるスペースの量は、multipage_alloc データベース構
成パラメーターの設定によって左右されます。この構成パラメーターが YES に設定されている場合、
スペースが必要なときにはエクステント全体 (通常は複数のページで構成される) が割り振られます
（マルチページ・ファイル割り振り）。それ以外の場合は、一度に 1 ページのスペースが割り振られま
す。 V8.2以降では、マルチページ・ファイル割り振りはデフォルトで使用可能です。V8.2 より前は、構
成パラメーターのデフォルト設定が NO であったため、一度に 1 ページしか割り振ることができません
でした。このデフォルトは、マルチページ・ファイル割り振りを使用できるようにする db2empfa ツール
を使用して変更できました。 db2empfa を実行すると、multipage_alloc データベース構成パラメーター
は Yes に設定されます。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
110
データベース物理設計
DB2デザイン・ガイド
DMS表スペース
DMS(Database Managed Storage)表スペース
zデータベース・マネージャーが記憶スペースを管理
z作成時にスペースを割り当て
zコンテナーはファイル、デバイス
¾ファイルの操作に対してはファイル・システムI/Oを使用
¾ロー・デバイスの操作に対しては直接I/Oを使用
z柔軟なデータ配置
¾表用、索引用、および長形式のデータ用の表スペースを別々に作成する
ことが可能
¾ディスクのIOを複数の物理ディスクに分散させることが可能
zコンテナの追加/削除/拡張/縮小が可能
¾データは自動的に再バランス（オプションにより再バランスさせないことも
可）
z高パフォーマンス
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
111
データベース物理設計
DB2デザイン・ガイド
解説
DMSの特徴
zDMSでは、表スペースは大きな１つのファイルまたはローデバイスに相当します。中をど
のように使われているのかはOSからは確認できません。表スペースを作成する際に、あら
かじめ必要な大きさを定義する必要があります。DMSではさらに２つのタイプがあり、１つは
DMSファイルともう一つはローデバイスです。
zDMSファイルの場合は、ファイルシステム上に１つの大きなファイルが作成されますが、
ローデバイスの場合はファイルシステムを経由せずにＤＢ2が直接IOを行います。
zDMSでは、表用、索引用、および長形式のデータ用の表スペースを別々に作成すること
が可能です。それによって、ディスクのIOを複数の物理ディスクに分散させることが可能に
なります。
zDMSでも複数のコンテナーを１つの表スペースに対して定義でき、さらに動的に追加する
ことが可能です。表スペースを作成後にコンテナーの大きさを変更することもでき、DB2
UDB V8以降では小さくすることも可能です。
z複数コンテナーからDMS表スペースを構成する場合、どれかのコンテナーが一杯になっ
ても空いているコンテナーを探して書き込もうとします。全てのコンテナーが一杯になった場
合、それ以上データの追加はできません。
¾V8.2.2からは、ファイルDMS表スペースの自動サイズ変更が可能です。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
112
データベース物理設計
DB2デザイン・ガイド
複数表スペースの検討
表スペースの分割の指針
z パフォーマンスを考慮し、バッファープールの割り当てを検討
z I/Oの並列処理を考慮し、データの物理配置に合わせて表スペースを構成
z バックアップの単位、LOADの並行処理等の運用面で検討
表をグルーピングし、表スペースを分ける
z １．できる限りバッファプールに読み込むことが望ましい表
¾
頻繁に読み書きされるトランザクション系データ
z ２．バッファプールには読み込む必要が無いデータ
¾
アプリケーション活動の履歴的な、一度書いたらほとんど変更／参照されないデータ
z ３．１と２の中間
z ４．小さな表はある程度の単位で一つの表スペースにまとめる
z ５．バックアップ取得の頻度で別の表スペースにする
¾
¾
大量の更新がある表⇒頻繁なバックアップ取得必要
変更が非常に少ない表⇒頻繁なバックアップ取得不要
LOADを複数同時に実行するには、別々の表スペースにする（特に
V7）
z V7では、LOAD実行中は表スペースをQuiesce（静止）状態にするため、該当の表のみ
ならず、同一表スペース上の他の表にもアクセス不可
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
113
データベース物理設計
DB2デザイン・ガイド
解説
典型的な分け方は以下のようになります。
z
z
z
z
z
z
z
１．頻繁に読み書きされるトランザクション系データ
２．アプリケーション活動の履歴的な、一度書いたらほとんど変更されないデータ
３．１と２の中間
分類１の表は、アプリケーションのパフォーマンスに大きな影響を与えます。ディスク資源とメモリ資源を十分に割り当てる必
要があります。
分類２の表は、容量的には大きくなりますが、一度書いた情報をあまり読まないため、メモリ資源は低く抑えることができます。
このタイプの表を全件検索するようなSQLが実行された場合、ディスクのアクセスが非常に多くなるので、パフォーマンスが常
時必要な分類１の表とは異なる物理ディスクを割り当てることが理想的です。できればディスクへつながるSCSIやファイバー
チャネルなどのインターフェースも別であることが理想的と言えます。
分類３は、メモリ資源をそれなりに与える必要がありますが、優先順位では分類１より下になります。
表スペースの分け方には、以下のようなケースもあります。
¾
¾
¾
¾
¾
¾
¾
頻繁に使用される表、それもアクセスされるデータがほぼ決まっている場合には、大き目のバッファープールを持った表スペース
を割り当てます。
このときには、データの表スペースと、索引の表スペースとを分けるのもひとつの方法です。(DMSの場合)
大きな表に、ランダムにデータ・アクセスする場合には、小さいバッファープールを持った表スペースを割り当てます。
たまにしか使用されないアプリケーションからアクセスされる表には、小さいバッファープールを持った表スペースを割り当てます。
このような表は、まとめて一つの表スペースに入れるのもひとつの方法です。
参照制約，トリガーなど関連のある表同士は一つの表スペースにまとめます。
小さな表は全て同じ表スペースにまとめます。
バックアップを取得する単位で表スペースを分けます。
表スペース単位のバックアップは時間とリソースの節約になります。
z
z
大量の変更がある表スペースは頻繁にバックアップを取り、変更が非常に少ない表スペースは時折バックアップを取ります。
Ｖ９以降は、データベースの再ビルド機能によりデータベース全体のバックアップを取得していなくても、表スペース・バック
アップからデータベースを回復することができます。
V７では、LOAD実行時、表スペースをQuiesce（静止）状態にし、表スペースと表スペース内の
表すべてに対してZ-LOCK(超排他)を取得するため、LOADの並行処理を可能にするには表ス
ペースを分ける必要があります。（V8では、LOAD中も表に照会アクセスが可能であり、同じ表
スペースの表については、アクセスが自由できます。）
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
114
データベース物理設計
DB2デザイン・ガイド
一時表スペースの定義
SMS or DMS
z 一時表スペースとしてはSMSがお勧め（一般）
スペースの有効利用
多くのクライアントアプリケーションからのソート要求を処理する場合、DMSよりパ
フォーマンスが良い
¾ 複数のコンテナーを作成して、パフォーマンス向上を計る
¾ ファイルシステム上に作成するため、ファイルシステムの制限（ラージイネーブル、
ulimit）に注意が必要
¾
¾
z 一時表スペースとしてのDMS（例外）
Solarisでは一時表スペースを使用した再編成、ロードや索引作成時などの大量
データの処理の場合パフォーマンス的に有利な場合がある（ケース・バイ・ケースな
ので、ベンチマーク・テストが必要）
¾ HAのテイクオーバー時間を短くために、fsckの必要になるファイルシステムの代わ
りにローデバイスDMSを選択する場合がある
¾
ページサイズ毎に１つ作成
z 一時表スペースを使用した再編成の場合、表の存在する表スペースのページサイ
ズと一時表スペースのページサイズは同じである必要がある。
z ソート時に使用する一時表スペースは、格納できるページサイズを選択する。
¾
異なるページサイズを持つ別々の一時表は、SMSとして同じファイルシステムに配
置するとスペースの有効利用ができる
後からでも比較的簡単に作成し直せる表スペース
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
115
データベース物理設計
DB2デザイン・ガイド
解説
一時表スペースに関しては、DMSよりSMSの方が勧められています。一時表スペースの使われ方は、ソートやジョインに必要なときに
一時的にシステム一時表が作成され、データが格納されます。つまり、表の作成・削除が内部で行われています。表作成時にSMSでは
ファイルが作成され、使用後に削除されます。DMSでは表スペース内の空き領域を管理する「スペースマップ」や、各表に対してディス
クのどの部分を使用しているのかを管理する「エクステントマップ」をメンテナンスする必要があります。多くのユーザーがそれほど大き
くないソートやジョイン用の一時表を作成する場合、この２つのマップのメンテナンス作業が競合し、パフォーマンスが劣化する場合が
あるため、DMSは一時表スペースには勧められていません。
例外として、Solarisで比較的大量なデータを一時表スペースに書き出すような場合、索引の作成やロードなどの場合、DMSの一時表の
方がパフォーマンス的に有利な場合があります。
ただし、Solarisでは必ず一時表スペースはDMSにしなければならないという訳ではありません。使用方法によってはSMSが適当なケー
スも存在します。
一時表スペースでは通常の表スペースとは、データを書き込む単位が異なります。通常の表スペースにおいて、DMSではデータはエク
ステント単位に書き込まれ、SMSではページ単位に書き込まれます。SMSではページ単位で書き込む上に、ファイルシステム上で、ファ
イルのサイズを大きくしていく必要があり、これがDMSに比べてオーバーヘッドになり得ます。db2empfaというコマンドがあり、SMSでも
エクステント単位でディスクに書き出すことが可能になるため、通常の表スペースでは効果がありますが、一時表スペースでは、必要な
容量を一度にアロケーションするため、db2empfaの効果は期待できません。
データベース中に複数のページサイズが存在する場合、一時表スペースをページサイズ毎に作成されることをお勧めします。これは一
時表スペースを使用した再編成を行う場合には必須です。再編成を行う表が含まれる表スペースのページサイズと同じページサイズを
持つ一時表スペースがないと一時表スペースを使用した再編成は行えません。
複数の一時表スペースを定義する場合、一時表スペースがSMSであれば、同じファイルシステムに配置することが可能になります。こ
れによって使用率が低いディスクエリアを共有し、ディスクスペースの有効利用が可能になります。
もちろん、複数の再編成を並行で実行する必要があるような場合は、別々のディスクに配置する方が、ディスクI/Oが衝突せずパフォー
マンス的に有利です。
一時表スペースは比較的簡単に作成し直せる唯一の表スペースです。本番稼働を始めた後でも、データのExport/Loadなどの移行な
どが必要ではないためです。ただし、一時表スペースを作成し直す場合、データベースに最低限１つの一時表スペースを残さないとエ
ラーになります。新しい一時表スペースを作成後に、古い一時表スペースを削除すればこのエラーは回避できます。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
116
データベース物理設計
DB2デザイン・ガイド
参考：自動ストレージ表スペース
V8.2.2以降、自動ストレージ・データベース、自動ストレージ表スペースが使用可能
V9以降、データベースを作成すると、デフォルトで自動ストレージ・データベースとして作成
される。
z
自動ストレージ・データベースには、自動ストレージ表スペースを作成可能（通常の自動ストレージでない表ス
ペースを作成することも可能）
自動ストレージ表スペース
z
表スペースのコンテナーおよびスペース管理の特性（SMS/DMS）はDB2によって自動的に（以下のように）決
定されるため、指定しなくてもよい。
¾
¾
z
REGULARまたはLARGE表スペースの場合、DMS（ファイル・コンテナー）
TEMPORARY表スペースの場合、SMS
データベース作成時に定義された（１つ以上の）ストレージ・パスを使用してDB2がコンテナーを自動的に割り
振るため、表スペース作成時にコンテナーの明示的なリストを指定する必要が無い。
自動ストレージ表スペースを作成するための指定（CREATE TABLESPACE実行時）
z
MANAGED BY AUTOMATIC STORAGE 文節を指定する、または、MANAGED BY 文節を指定しない
自動ストレージ･データベース
データベース
自動ストレージ表スペース表スペースA
表スペースB
表スペースC
ストレージ・パス（複数のディレクトリー）
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
117
データベース物理設計
DB2デザイン・ガイド
V9.5
参考：自動ストレージ表スペースのサイズ縮小(V9.5～)
ユーザーによる自動ストレージ表スペースのサイズ縮小をサ
ポートする。
z ALTER TABLESPACE ステートメントをREDUCEオプションを指定して実行することで、
表スペースの未使用エクステントを解放することができる。
¾
非自動ストレージ表スペースの場合と違い、コンテナー・パスや減少するページ数の指定
は不要である。DB2が解放する領域を判断する。
メリット
z 解放されたストレージ領域を、同一の自動ストレージ・パス上に存在する他の表スペー
スで使用できる。
z Space Map Pagesが残っていることにより最高水準点が下がらない場合でも、当機能を
使用することで、SMPを削除し最高水準点を下げるため、未使用のストレージ領域を開
放する
注意事項
z 解放するのは、最高水準点より上の位置にあるフリー・ページで、使用したページで
データが入っていない空き状態のページ（FPAGESとNPAGESの差分）を解放する機能
ではない。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
118
データベース物理設計
DB2デザイン・ガイド
V9.5
参考：V9.5 新機能-コンテナーあたりの最大サイズを設定するレジストリ変数
DB2_SET_MAX_CONTAINER_SIZE レジストリ変数
z AutoResize フィーチャーが有効になった自動ストレージ表スペース用のコンテ
ナー 1つあたりの最大サイズを制限するレジストリ変数。
オペレーティング・システム: すべて
¾ デフォルトは、-1（設定しない）。コンテナーのサイズに対する制限はなく、従来と
同一の動作を行う。
¾ 値を設定する場合は、64 MB より大きい正の整数とする。
¾
注意事項
z 表スペースの最大サイズを指定するレジストリー変数ではない。
¾
レジストリ変数の設定値まで、コンテナー・サイズが達した場合には、新規にコン
テナーが追加され、表スペースは拡張される。
z このレジストリ変数を使用した場合には、V9.1までと異なり、V9.5からは 1つの
自動ストレージ・パスあたりに、複数のコンテナーが作成される場合がある。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
119
データベース物理設計
DB2デザイン・ガイド
V9.7
参考：表スペースの縮小と最高水準点の移動
自動ストレージ表スペース、DMS表スペースでエクステントを移動し、最高
水準点を下げ、表スペースの縮小ができる。
ALTER TABLESPACEステートメントのLOWER HIGH WATER MARK / REDUCEオプシション指定
で、表スペースの最高水準点を下げ、表スペースを縮小し、使用したページで
データが入っていない空き状態のフリー・ページを解放することができる。
- V9.5では、自動ストレージ表スペースの縮小ができたが、最高水準点の移動はできなかった。
- （制約事項）
-
-
Ｖ９．５以前のバージョンで作成した表スペースではこの機能は使用できない
RAWデバイスで作成した表スペースでは最高水準点の移動はできるが表スペース領域の開放はできない
自動ストレージ表スペースの場合
ALTER TABLESPACEステートメントをREDUCEオプションと縮小の割合を指定して実行する。
‒縮小可能な限りまで縮小するMAXオプション
‒特定の割合を指定して縮小するSIZEオプション
DMS表スペースの場合
1. ALTER TABLESPACEステートメントをLOWER HIGH WATER MARKオプションを指定して
実行し、最高水準点をさげる。
2. ALTER TABLESPACEステートメントをREDUCEオプションとコンテナを指定して実行し、表
スペースの使用していないエクステントを解放(表スペースの縮小)する。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
120
データベース物理設計
DB2デザイン・ガイド
検討すべき表スペース属性
ファイルDMS表スペースの自動サイズ変更（V8.2.2以降）
ダイレクトI/O
DROPPED TABLE RECOVERY属性
OVERHEAD/TRANSFERRATE
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
121
データベース物理設計
DB2デザイン・ガイド
ブランク・ページです
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
122
データベース物理設計
DB2デザイン・ガイド
ファイルDMS表スペースの自動サイズ変更（V8.2.2以降）
DMSファイル・コンテナのサイズを自動的に拡張
z コンテナがいっぱいになる（SQL0289N）前に、追加領域の必要に応じてコンテナを自動的に拡
張する
z ファイル・コンテナのみ使用可能
¾ ロー・デバイス・コンテナの自動サイズ変更は不可能
z 表スペースの最後のレンジにあるコンテナが拡張される
¾ 自動サイズ変更によってリバランスは発生しない
¾ それぞれのコンテナは同じ量だけ拡張される
z 自動ストレージ・表スペースのDMS、自動ストレージ・表スペースでないDMSのいずれに対して
も使用可能
z 自動ストレージ・表スペースでない場合、ユーザーによるコンテナの拡張、削除が可能
¾
従来どおり、ALTER TABLESPACEステートメントを使用する
z 区分化データベース環境でも使用可能
DMSなのでパフォーマンスがよく、自動的にサイズ拡張するので、
SMS同様管理が容易になる
考慮点
z 自動サイズ変更が行われる場合、表に対する挿入処理のパフォーマンスに影響が出る。
¾
社内実測値では、自動サイズ変更を設定していない環境と比較してimport処理に20%から25%程
度の性能劣化が見られた。
z 一時表スペースを使用しないREORGの際にも自動サイズ変更が行われる。
¾
REORG完了後もサイズは拡張されたままで、縮小されない。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
123
データベース物理設計
DB2デザイン・ガイド
解説：
自動サイズ変更を使用可能な表スペースでは、既存のスペースがすべて使用され、さらに多く
のスペースが要求される場合、DB2 は表スペースのサイズの増加を試みます。
DB2は、表スペース・マップ (表スペースのストレージ・レイアウト) の最新の範囲（レンジ）に存在
するコンテナーのみを拡張しますので、リバランス処理は発生しません。
最新の範囲（レンジ）に存在するコンテナーはそれぞれ同じ量だけ拡張されます。最新のレンジ
に存在するコンテナーのひとつが、ファイル・システムの上限に達すると、自動サイズ変更が停
止してしまうため、それぞれのコンテナーが使用するファイル・システムのサイズはそろえておく
ことが重要です。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
124
データベース物理設計
DB2デザイン・ガイド
参考：ファイルDMS表スペースの自動サイズ変更の仕組み
Containers
Stripes
0
1
2
0
0
1
2
1
3
4
5
2
6
7
8
3
9
10
4
11
12
5
13
14
Range
Number
Range #0
Stripe
Set
Max
Extent
Start
Stripe
End
Stripe
Containers
0
0
8
0
2
3 (0, 1, 2)
1
0
14
3
5
2 (0, 1)
Stripe Set #0
Range #1
レンジ[0]のみを持つコンテナ2は
拡張されないため、リバランスは
発生しない。
既存のエクステント（0~12）以上
のスペースが必要になると、コン
テナの最後のレンジにエクステン
トが追加される
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
125
データベース物理設計
DB2デザイン・ガイド
ブランク・ページです
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
126
データベース物理設計
DB2デザイン・ガイド
自動サイズ変更の指定方法
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-------------'
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
127
データベース物理設計
DB2デザイン・ガイド
自動サイズ変更の指定方法（続き）
AUTORESIZE { NO | YES}
z 自動サイズ変更機能を使用するかどうかを指定する
¾
¾
自動ストレージ表スペースの場合、デフォルトはYES
自動ストレージ表スペースでない場合、デフォルトはNO
INITIALSIZE integer K | M | G
z 自動ストレージ表スペースの、初期サイズを指定する
z 自動ストレージ表スペースの場合のみ指定可能
INCREASESIZE integer PERCENT または INCREASESIZE
integer K | M | G
z 自動サイズ変更される量を指定する（表スペース全体での増加量）
¾
¾
パーセントまたは、容量を指定
パーセントは、自動サイズ変更が行われる時点の表スペースサイズのパーセンテー
ジを意味する
z 指定されていない場合、DB2が自動的に判断する
MAXSIZE integer K | M | G または MAXSIZE NONE
z 自動的に拡張できる最大サイズを指定する
z 指定されていない場合、NONE
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
128
データベース物理設計
DB2デザイン・ガイド
解説：
AUTORESIZE
z
z
z
DMS 表スペースまたは自動ストレージ表スペースの自動サイズ変更機能を使用可能にするかどうかを指定
します。自動サイズ変更可能表スペースは、いっぱいになると、自動的にサイズが大きくなります。デフォ
ルトは、DMS 表スペースの場合は NO、自動ストレージ表スペースの場合は YES です。
NO
¾ DMS 表スペースまたは自動ストレージ表スペースの自動サイズ変更機能が、使用不可であることを指
定します。
YES
¾ DMS 表スペースまたは自動ストレージ表スペースの自動サイズ変更機能が、使用可能であることを指
定します。
INITIALSIZE integer K | M | G
z
自動ストレージ表スペースの、データベース・パーティションあたりの初期サイズを指定します。このオプショ
ンは、自動ストレージ表スペースに対してのみ有効です。整数値の後に K (K バイトの場合)、M (M バイトの
場合)、または G (G バイトの場合) を指定する必要があります。使用される実際の値は、指定されたものよ
りも若干小さい場合があることにご注意ください。これは、データベース・マネージャーが表スペース内の各コ
ンテナーのサイズの一貫性を維持しようとするためです。表スペースが自動サイズ変更可能であるものの
INITIALSIZE 文節が指定されていない場合には、データベース・マネージャーが適切な値を判別します。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
129
データベース物理設計
DB2デザイン・ガイド
解説：
INCREASESIZE integer PERCENT または INCREASESIZE integer K | M | G
z
自動サイズ変更可能な表スペースがいっぱいになって、スペースの要求がなされたとき、どれほどの量だけ
自動的に大きくするかを、データベース・パーティションごとに指定します。整数値の後に以下のものを指定
しなければなりません。
¾ PERCENT。スペースの要求がなされた時点の表スペース・サイズのパーセンテージとして量を指定し
ます。 PERCENT を指定する場合、整数値は 0 と 100 の間でなければなりません (SQLSTATE
42615)。例えば、自動サイズ変更が可能な表スペースが100MBのサイズで定義されており、
INCREASESIZEが20%と指定されている場合、20MB(100MBの20%), 24MB(120MBの20%),
28.8MB(144MBの20%),…という風に拡張されていきます。
¾
z
K (K バイト)、M (M バイト)、または G (G バイト)。バイト単位で量を指定します。
使用される実際の値は、指定されたものよりも若干小さかったり大きかったりすることにご注意ください。これ
は、データベース・マネージャーが表スペース内の各コンテナーの増大の整合性を維持しようとするためです。
表スペースが自動サイズ変更可能であるものの INCREASESIZE 文節が指定されていない場合には、データ
ベース・マネージャーが適切な値を判別します。
MAXSIZE integer K | M | G または MAXSIZE NONE
z
自動サイズ変更可能な表スペースを自動的に大きくできる、最大サイズを指定します。表スペースが自動
サイズ変更可能であるものの MAXSIZE 文節が指定されていない場合、デフォルトは NONE です。
¾
¾
integer
– DMS 表スペースまたは自動ストレージ表スペースを自動的に大きくできる、サイズ上のハード限
界を、データベース・パーティションごとに指定します。整数値の後に K (K バイトの場合)、M (M
バイトの場合)、または G (G バイトの場合) を指定する必要があります。使用される実際の値
は、指定されたものよりも若干小さい場合があることにご注意ください。これは、データベース・マ
ネージャーが表スペース内の各コンテナーの増大の整合性を維持しようとするためです。
NONE
– 表スペースをファイル・システムの容量まで、または表スペースの最大サイズまで増大できるよ
うにすることを指定します。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
130
データベース物理設計
DB2デザイン・ガイド
自動サイズ変更を解除する方法
ALTER TABLESPACEステートメント
z AUTORESIZE NOを指定する
ALTER TABLESPACE tablespace-name AUTORESIZE NO
注意点
z 一旦AUTORESIZEをNOにすると、それまでに設定していたINCREASESIZE,
MAXSIZEの値は保持されない。
z 自動サイズ拡張が実行されている最中に、自動サイズ拡張を解除しようと
すると、実行中の自動サイズ拡張が完了するまでALTER TABLESPACEス
テートメントは待ち状態になる。
¾
実行中の自動サイズ拡張が完了した後、AUTORESIZEがNOに変更される。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
131
データベース物理設計
DB2デザイン・ガイド
ブランク・ページです
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
132
データベース物理設計
DB2デザイン・ガイド
ダイレクトI/O
利点
z ファイル・キャッシュとバッファープールでの二重バッファリングを回避
¾
¾
¾
二重バッファリングを行うCPU負荷を軽減
ファイル・キャッシュに余分なデータをのせないことによる、本来のファイル・データ
のヒット率向上
大量にファイル・キャッシュを使用することによって引き起こされるページングを回避
（システム全体の性能が不安定になることを回避）
V8.1FixPak4以降、ダイレクトI/Oサポートが拡張されている
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
133
データベース物理設計
DB2デザイン・ガイド
解説
コンテナーにファイルを使った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を使用する
と、この問題を回避することができます。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
134
データベース物理設計
DB2デザイン・ガイド
ダイレクトI/Oサポートの変遷
V8.1.4 （FixPak4）
z AIXプラットフォームにおけるサポート追加
z SMS表スペースのみ（LARGE表スペース、一時表スペースは除く）
z レジストリ変数DB2_DIRECT_IOにて設定
¾
db2set DB2_DIRECT_IO=ON
z AIXのレベルによっては、コンカレント I/Oを使用
¾
AIX 5.2（ML01）以降でAPAR IY45707の適用された環境
V8.2 （FixPak7）
z AIXに加え、Solaris、HP-UX、 Linuxのサポート追加
z DMS表スペース（ファイル）のサポート追加
z 一時表スペースは対象外
z CREATE/ALTER TABLESPACEのオプションにて設定
¾
¾
表スペース単位の設定が可能
指定するオプション
– FILE SYSTEM CACHING
：FSキャッシング使用（省略時値)
– NO FILE SYSTEM CACHING ：ダイレクトI/O使用
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
135
データベース物理設計
DB2デザイン・ガイド
解説
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の使用）の両オプションが追加となり、こちらの設
定によって表スペース単位にファイルキャッシュを使用するか否かを設定できるようになってい
ます。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
136
データベース物理設計
DB2デザイン・ガイド
参考：
ダイレクトI/O設定方法の例
CREATE TABLESPACE TS1 MANAGED BY SYSTEM
USING (‘tspath1’,’tspath2’)
NO FILE SYSTEM CACHING
ALTER TABLESPACE TS1 FILE SYSTEM CACHING
表スペースのキャッシング使用状態確認は、表スペース
のスナップショットにて確認可能
get snapshot for tablespaces on sample
Tablespace name
Tablespace ID
Tablespace Type
Tablespace Content Type
Tablespace Page size (bytes)
Tablespace Extent size (pages)
Automatic Prefetch size enabled
Buffer pool ID currently in use
Buffer pool ID next startup
File system caching
Tablespace State
Detailed explanation:
Normal
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
=
=
=
=
=
=
=
=
=
=
=
137
TS1
3
System managed space
Any data
4096
32
Yes
1
1
Yes
0x'00000000'
データベース物理設計
DB2デザイン・ガイド
ダイレクトI/Oサポートの変遷（続き）
V8.2.2以降
z 一時表スペースへのダイレクトI/O設定可能
z 設定方法はV8.2のときと同様
¾
CREATE / ALTER TABLESPACEのオプション
– FILE SYSTEM CACHING
– NO FILE SYSTEM CACHING
z ダイレクトI/Oが設定可能になったことにより、フラッシュ・コピー対象とすることができる。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
138
データベース物理設計
DB2デザイン・ガイド
解説
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の
一時表スペースについて以下のような対応をする必要がありました。
z
z
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の一時表スペースをフラッシュコピー対象とすることができます。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
139
データベース物理設計
DB2デザイン・ガイド
V9.5
ダイレクトI/Oサポートの変遷（続き）
V9.5で新しく表スペースを作成すると、No File System Cachingで作成される
z 新規作成のみ、V9.5以前から既存の表スペースへは影響なし
z 但し、以下のものはV9.1の時と同様にFile System Cachingがデフォルト
This change applies to AIX, LinuxR, Solaris, and Windows with the following exceptions,
where the default behavior remains to be FILE SYSTEM CACHING:
AIX JFS
Solaris non-VxFS
Linux for System z
All SMS temporary table space files
SMS permanent table space files, except for long field (LF) data and large object (LOB)
data files.
z DMS FILEの表スペースに、LOBを格納する場合注意が必要。
¾
¾
LOBの再読込を行うようなアプリケーションでは、パフォーマンス低下の可能性があるため、明
示的な「FILE SYSTEM CACHING」の設定を推奨。
特に、WASのセッションDBとして使用している場合、32KBを超えるセッション情報はLOBとして書
き込まれるため、パフォーマンス低下が懸念される。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
140
データベース物理設計
DB2デザイン・ガイド
DROPPED TABLE RECOVERY属性
表スペースのDROPPED TABLE RECOVERY属性
z
ドロップされた表をリカバリー可能にするための属性
¾
¾
z
DROP TABLE ステートメント実行時
¾
z
表スペース作成時、または変更時に、DROPPED TABLE RECOVERY属性を指定する（REGULAR表
スペースにのみ指定可能）
V8以降のデフォルトはON
DROPされた表を識別するための項目がログ・ファイルとリカバリー履歴ファイルに書き込まれる
表のDROP時に書き込まれる内容
¾
¾
ログ・ファイルに書き込まれる情報
– 表の名前
– タイム・スタンプ
– トランザクションID
– 表ID
回復履歴ファイルに書き込まれる情報
– 表の名前
– タイム・スタンプ
– トランザクションID
– 表ID
– DDL
必要がなければOFFにする
z
影響範囲
¾
z
誤ってDROPした表の回復を行うしくみを利用できなくなる
定期的に大量に表を作成/削除を繰り返すような業務がない場合には、デフォルトのままでも
業務パフォーマンスへの支障はない
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
141
データベース物理設計
DB2デザイン・ガイド
解説
表スペースのDROPPED TABLE RECOVERY属性
表スペース作成時、または変更時に、DROPPED TABLE RECOVERY属性を指定することで、
ドロップされた表がリカバリー可能になります（REGULAR表スペースにのみ指定可能）。
z DROPPED TABLE RECOVERY属性を持つ表スペースに対してDROP TABLE ステートメント
が実行されると、DROPされた表を識別するための項目がログ・ファイル内に作成されます。ま
た、この項目はリカバリー履歴ファイルにも追加され、表を再作成する際に使用されます。
z
必要がなければOFFにする
V8以降では、CREATE TABLESPACE時のDROPPED TABLE RECOVERY属性はデフォルトで
ONになっています。これにより、表のDROPに関する情報の記録が行われることになるため、
大量に表をDROPした際に、DROP処理のパフォーマンスが劣化する可能性があります。これ
を回避するため、必要がなければOFFにするようにしてください。
z OFFにする方法
z
¾
¾
z
1. CREATE TABLESPACE文によって表スペースを作成する際、DROPPED TABLE RECOVERYオプ
ションを明示的にOFFにします。
2. 既に作成されている表スペースについては、ALTER TABLESPACE文により、DROPPED TABLE
RECOVERYオプションをOFFにします。
ONのままにする場合は、PRUNE HISTORYコマンドによって回復履歴ファイルを定期的に削
除するようにしてください（容量が増大し続けるため）。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
142
データベース物理設計
DB2デザイン・ガイド
OVERHEAD/TRANSFERRATE
OVERHEAD/TRANSFERRATEのデフォルトは、バージョンによ
り異なる
OVERHEADの省略時値
z V8.1
z V8.2
z V9以降
： 24.10ms
： 12.67ms
： 7.50ms
TRANSFERRATEの省略時値
z V8.1
z V8.2
z V9以降
： 0.90ms
： 0.18ms
： 0.06ms
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
143
データベース物理設計
DB2デザイン・ガイド
参考：OVERHEADとTRANSFERRATEの意味
OVERHEAD
zデータをメモリーに読み込む前に、コンテナーに関して必要な
時間（ミリ秒）
zディスク待ち時間、コンテナーの入出力コントローラーのオー
バーヘッド (ディスクのシーク時間を含む)が含まれる
TRANSFERRATE
z1ページのデータをメモリーに読み込むために要する時間（ミ
リ秒）
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
144
データベース物理設計
DB2デザイン・ガイド
⑤表スペースの配置
ユーザー表スペースの配置
z 索引／長形式データの配置
その他の表スペースの配置
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
145
データベース物理設計
DB2デザイン・ガイド
ブランク・ページです
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
146
データベース物理設計
DB2デザイン・ガイド
ユーザー表スペースの配置
複数の物理ディスクに表スペースを配置し、DISK I/Oを分散させる
z
z
z
１つの表スペースを複数ディスクに配置理想は同じサイズのコンテナー
索引は別の表スペースに配置
長形式は別の表スペースに配置
基本：Prefetch Size = Extent Size×コンテナー数
RAID5などアレイの場合は以下の構成を行う
z
DB2_PARALLEL_IO
¾
このレジストリー変数を設定することで、PrefetchSize と ExtentSizeの違いを見て、I/Oを並列
に行うかを決定する
表スペース２
(Prefetch Size =
Extent Size × 3)
表スペース１
(Prefetch Size = Extent Size × 4)
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
147
データベース物理設計
DB2デザイン・ガイド
解説
パフォーマンスのためには、各表スペースに対して、６個～１０個以上の物理ディスク上に別々
のコンテナーを作成し、I/Oを分散することが理想的である（と言われています）
複数のコンテナーに配置する場合には、表スペースに対して以下の設定を行い、プリフェッ
チャーによる並列I/Oを使用可能にする必要があります。
z
Prefetch Size = Extent Size×コンテナー数
この設定によって、複数のプリフェッチャー・プロセスを使い、データをバッファプールに読み出
すことができるようになります。
データはラウンドロビンで書き込まれている為、各コンテナーのサイズは同じであることが理想
的です。それによって、データの分散度合いのばらつきを無くし、ディスクI/Oが特定のコンテ
ナーにできるだけ集中しないようにします。
DB2_PARALLEL_IOを指定した場合は、特にPrefetch Sizeは重要になります。パラレルI/Oを指
定するような場合は、通常ESSなどのRAIDディスクが使われており、コンテナーが１つでも実際
は内部では複数のディスクが使われています。このような状態では、コンテナー数は先読みに
対しては意味を持たず、DB2はPrefetch SizeがExtent Sizeの何倍になっているかによって、プ
リフェッチャーを起動し先読みを行います。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
148
データベース物理設計
DB2デザイン・ガイド
参考：プリフェッチ・サイズの自動調整機能（V8.2以降）
エクステント・サイズ、コンテナ数、およびコンテナあたりの物理ディスク
数に基づいて、表スペースに適したプリフェッチ・サイズをDB2が自動計
算する
z 利点：
コンテナの追加・削除に応じ、プリフェッチ・サイズを変更する必要がない
z 考慮点：コンテナ数、物理スピンドル数が多いほど、多く設定される
設定方法
z データベース構成パラメーターDFT_PREFETCH_SZの値をAUTOMATICに設定する
z CREATE TABLESPACEステートメントで、 PREFETCHサイズを指定しない
算出式
z プリフェッチ・サイズ＝
（コンテナ数）*（コンテナあたりの物理ディスク数）*エクステント・サイズ
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
149
データベース物理設計
DB2デザイン・ガイド
参考：プリフェッチ・サイズの自動調整機能（V8.2以降）
DB2_PARALLEL_IOの値との関連
z DB2_PARALLEL_IOの値は、コンテナあたりの物理ディスク数として使用される
例
z （例１）DB2_PARALLEL_IO=*
¾
¾
全ての表スペースは、デフォルトで、各コンテナあたり６個の物理ディスクをもつと仮定して計算され
る
全ての表スペースに対して、パラレルI/Oが有効となる。プリフェッチ要求は、プリフェッチサイズをエ
クステント・サイズで割った数に分割されて、パラレルに実行される
z （例２） DB2_PARALLEL_IO=*:3
¾
¾
全ての表スペースは、コンテナあたり３個の物理ディスクを持つと仮定して計算される
全ての表スペースに対して、パラレルI/Oが有効となる。
z （例３） DB2_PARALLEL_IO=*:3,1:1
¾
¾
全ての表スペースは、コンテナあたり３個の物理ディスクを持つと仮定して計算される。
ただし、表スペース１だけは、物理ディスク数は１となる。
全ての表スペースに対して、パラレルI/Oが有効となる。
DB2_PARALLEL_IOが設定されていない場合には、物理ディスク数は１
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
150
データベース物理設計
DB2デザイン・ガイド
索引／長形式データの配置
索引の配置
z
z
DMS表スペースに表を作成する場合、索引を別の表スペースに格納することが可能。
ディスクI/Oの競合を避けたい、または、表と索引のバッファープールを分け、特定の表や索引
のヒット率を確保したい場合には、表と索引を別の表スペースに格納することを検討する
表スペース for TABLE
(Prefetch Size = Extent Size × 4)
表スペース for INDEX
(Prefetch Size = Extent Size × 3)
長形式データの配置
DMS表スペースに表を作成する場合、長形式のデータを別の表スペースに格納することが可
能。
z 長形式のデータにはバッファプールは有効ではない
z ファイルDMSに配置することによって、ファイルキャッシュを有効にすることができる
z
¾
LOBとして格納するデータは、通常それほど頻繁に読み書きが発生しないので、キャッシュが
効かなくても影響が少ないケースも多い
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
151
データベース物理設計
DB2デザイン・ガイド
その他の表スペースの配置
一時表スペース
ソート、結合、再編成、索引作成時（LOADを含む）等に使用
一時表のI/Oが多く、データ／索引用の表スペースのI/Oと衝突する場合は、別ディスクに配
置する
z コンテナーに複数のディレクトリーを指定することが推奨。（SMSの場合）
z
z
カタログ表スペース
z
通常、カタログ表のデータは殆どキャッシュ上に読み込まれているため、特にI/O効率を考慮
したディスク上への配置は不要。（データベース作成時のデフォルトのままでも良い。）
SYSTOOLSPACE
z
V8.2以降でデータベースの自動保守（自動統計収集および再編成）を使用する場合に自動作
成され、自動保守が実行される際に使用される。デフォルトの配置のままでも特に問題はない。
自動保守機能を使用しない場合は、削除しても良い。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
152
データベース物理設計
DB2デザイン・ガイド
⑥表スペース以外のオブジェクトの配置
ログの配置
z アクティブ・ログとアーカイブ・ログ
ワーク/バックアップ領域の配置
その他の領域
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
153
データベース物理設計
DB2デザイン・ガイド
ブランク・ページです
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
154
データベース物理設計
DB2デザイン・ガイド
ログの配置
アクティブログに対する書き込み速度はアプリケーションのレスポンスに直接
影響する
アクティブログは安全性を考えると、二重化した方がよい
z
z
（アクティブログの障害＝データベースの障害）である。
DB2の二重ログは両方に書き出して終了なので、どちらか１つのディスクが遅い場合、ログへ
の書き込みは遅くなる。
ディスク容量が許すのであれば
z
アクティブログ専用のディスク上に配置する
¾
¾
z
z
ESSの場合ランクも別の方が理想的
SCSI / Fibreなどのチャネルもできれば別
RAID5ではなく、ミラーリングを使用する
ストライピングによって書き込みを速くする
非同期
書き出し
データ
バッファプール
変更された
データ
データの
更新処理
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
155
コミットしたら更
新内容を
必ず書き出す
ログ
データベース物理設計
DB2デザイン・ガイド
解説
ログはDB2にとって重要なオブジェクトです。特にアクティブログは非常に重要で、アクティブログが損傷したことは
データベース自身が損傷したことを意味します。
つまり、アクティブログが壊れたら、データベースが壊れたのと同じです。
何故、アクティブログがそれほど重要なのでしょうか。更新処理を行う時のDB2の動作を考えてみます。
データベースが更新された場合、バッファプールと呼ばれるキャッシュのデータが更新されますが、ディスクにはすぐ
には書き出されません（このようなデータが含まれるページをダーティーページと呼びます）。その更新処理がコミッ
トされると、必ずログに書き出されます。
この状態でもしDBサーバーがクラッシュした場合、次にデータベースが使われる前に、クラッシュリカバリーという処
理を行う必要があります。クラッシュリカバリーによって、更新されたはずなのにディスクに反映されていない更新を、
ログを読みながらディスクへ反映します。
ここで、重要な点はログがなければクラッシュ前にどのような更新処理が行われていたのかを知ることができないと
いうことです。DB2はこのクラッシュリカバリーによって、突然のDB2の異常停止などの時でもデータベースに格納さ
れているデータの論理的な整合性を保証しています。つまり、ログが壊れるということはDB2がデータの整合性を保
証できないということを意味しています。
ログの重要性を理解したところで、そのI/Oパフォーマンスが非常に重要であることも気が付かれたと思います。更
新処理がコミットされたら必ずログに書き出される訳ですから、ログへの書き出しが終わらないと次の処理へ進むこ
とができません。
更新処理のボトルネックがログのI/Oにならないようにする為には、他のI/Oとの衝突をできる限り避ける必要があり
ます。他のI/Oとは表や索引のデータが含まれるディスクへのI/Oが含まれます。つまり、ログは表や索引などとは
全く別のディスクに配置することが推奨されます。ESSのような１つのアレイが大きな場合でも、できる限り全く別の
ディスク上に配置し、SCSIやファイバーチャネルなどのインターフェースも別にすることが推奨されます。
また、書き込みに対して多少不利なRAID5よりもできればミラーリング（RAID1）などを選択するようにしてください。
さらにディスクに余裕がある場合には、ストライピングなどによって高速化できれば更新処理にとって良い結果が期
待できます。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
156
データベース物理設計
DB2デザイン・ガイド
ログの配置（続き）
アーカイブログとアクティブログは別のディスクに配置する
アーカイブログ・ディレクトリ（コピー先）とアクティブログ・ディレクトリ（コピー元）は別にした方
がパフォーマンス的に有利
z 障害時の危険分散を考えても別の方がよい
z
¾
アクティブログとアーカイブログが壊れた場合、バックアップからのリストアーはできても、最新
状態へのロールフォワードができなくなる。
大量更新を行うバッチ系処理の場合(Importなど)
z
ログに対するキャッシュに相当するログバッファー(LOGBUFSZ)を大きくする
ローデバイスロギングは、V9では推奨されない
z
z
ローデバイスロギングを使用すると、二重ログが使えない
USEREXITに何らかの問題があって、ログのコピーに失敗した場合、手動によるコピーが不可
ログ・アーカイブ機能（V8.2以降）を使用する場合は、アーカイブ先ディレ
クトリとして容量と配置に注意する
z
二つのアーカイブ先ディレクトリ（LOGARCHMETH1, LOGARCHMETH2）を使用する場合
¾
¾
領域は2倍必要
– 代替ディレクトリ（FAILARCHPATH）を使用する場合は、更に領域が必要
それぞれ別のディスクに配置する
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
157
データベース物理設計
DB2デザイン・ガイド
解説
アクティブログの重要性を説明してきましたが、DB2にはもう一つアーカイブログというログがあります。通常、ログ・
アーカイブ機能によって、アクティブログがアーカイブされた時に、そのアーカイブ・ログをアクティブログとは別のディ
レクトリ（またはテープのような別のメディア）にコピーして保存します。このログファイルをコピーする処理も重要です。
コピー先のログファイルは、コピー元やデータベース自身の障害発生時に復元の為に必要になるので、コピー元と
は全く別のディスクやメディアに保存する必要があります。また、ログ・アーカイブ機能はデータベースが使われてい
る時に動作しますので、もし同じディスクにコピー先を配置してしまうと、コピー先の書き込みI/Oの為にアクティブロ
グ自身のI/Oへ影響を与える可能性があります。データベースのパフォーマンスを維持するためには、できる限りこ
のような影響は排除する必要があります。
１つの作業単位（UOW）によって大量のデータを更新するような場合、コミットとコミットの間隔が非常に長くなります。
このような場合、データベース構成パラメータのログバッファー（LOGBUFSZ）を大きくするとパフォーマンスに好影響
を与えます。このような更新処理の場合、ログバッファが小さいと（デフォルトでは32KB）、更新処理がコミットされて
いなくても、ログを頻繁にディスクに書き出さなければならなくなる為に、パフォーマンスに悪影響があります。
ログをローデバイスに配置する機能をDB2はサポートしていますが、V9では推奨されません。ローデバイスロギング
を使用する場合、何らかの問題があってログ・アーカイブ機能によるログファイルのコピーに失敗し、アクティブログ
のデバイス中に特定のログファイルが残ってしまったようなケースでは、手動でコピーすることができません。障害時
の復旧作業は、通常時とは異なり、多種の問題が発生している可能性があり、手動で復旧できないということは、安
全性が低いとも言えます。
また、DB2の二重ログの機能はローデバイスで使用することはできません。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
158
データベース物理設計
DB2デザイン・ガイド
ワーク／バックアップ領域の配置
バックアップ時間の短縮が必要な場合、バックアップ領域のパフォーマンスを
考慮する
z
z
z
ディスクへのバックアップの場合、バックアップ元のあるディスクとは別にする
１つのディスクでは要求が満たせない場合、複数のディスクへのバックアップを検討
テープへのバックアップは、TSMがサポートしていれば、複数テープへの同時書き込みによっ
て高速化が可能
ロードの処理時間短縮が必要な場合
z
z
ロード元のデータを格納するファイルシステムのパフォーマンスを考慮する
AIXでは、以下のパラメータがパフォーマンスに影響する場合がある
¾
vmtuneのminpgahead, maxpgahead（ファイルシステムの先読み）
一時表スペースと同居できるか
ロード時の入力ファイルと、ソート用の一時表スペースのI/Oが競合するとロードのパフォーマ
ンスに悪影響が考えられる
z 通常は、再編成時にはロードやバックアップなどの処理は行わない。
z
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
159
データベース物理設計
DB2デザイン・ガイド
その他の領域
DB2診断情報格納ディレクトリー
z
インスタンス・ホーム・ディレクトリー（デフォルト）、または、データベース・マネージャ構成パラ
メーターDIAGPATHにて指定した場所に格納される
z
管理通知ログ、db2diag.log、ダンプ・ファイル、トラップ・ファイル、コア・ファイル (UNIX のみ)を
格納する
¾
V8.2以降は、db2diag.logへ書かれる内容が増えているため、V8.1以前より容量が増
える可能性がある。
データベース・ディレクトリー
z
バッファープール情報、表スペース情報、データベース構成情報、リカバリ履歴ファイル、ログ
制御ファイル
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
160
データベース物理設計
DB2デザイン・ガイド
⑦構成パラメーターの設定
スレッドモデルへの変更
メモリーモデルの変更
バッファープール関連のパラメーター
z プリフェッチャー
z ページクリーナー
その他最低限構成すべきパラメーター
自己チューニングメモリー(Self Tuning Memory Manager)
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
161
データベース物理設計
DB2デザイン・ガイド
ブランク・ページです
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
162
データベース物理設計
DB2デザイン・ガイド
V9.5
スレッドモデルへの変更
V9.5からは、 UNIX、Linux プラットフォームにおいて、従来のようなプロセス・
モデルではなく、db2syscプロセスが 1つ存在し、残りのEDUは db2syscプロセ
ス配下にスレッドとして存在するアーキテクチャーに変わった。
Common
Client
UDB Server
UDB Client Library
Shared Mem & Semaphores, TCPIP, Named Pipes,…
Idle Agent Pool
Instance Level
Listeners
db2tcpcm
db2agent (idle)
db2agent
Database Level
db2loggr
db2loggw
ts
db2agntp
ns
es
tio
im
ct
Log Buffer
o
Vi
Logging
Subsystem
L
ite
r
W
gR
No
t if
i ca
db2agntp
u
eq
Active
Buffer Pool(s)
Deadlock
Detector
db2dlock
Log
Disks
As
db2ipccm
yn
c IO
Pre
fet
ch
Idle
Re
qu
Coordinator
Agents
Subagents
es t
s
Prefet
chers
Page
Cleaners
db2pfchr
k,
c
blo
g- sts
i
l, B e
db2pclnr
lle equ
a
r
R
Pa ad
ge
Re
Pa sts
,
l
e
le
Data
ral Requ
a
P ite
r
W
Disks
Process/Thread Organization
Per-instance
Per-application
Per-database
Idle, pooled agent or
subagent
V9.5からは、点線
枠で囲まれた部分
は、1つのプロセス
となる。各EDUは、
スレッドとして存在
して、 db2syscプロ
セスに紐づく。
db2wdog
Health Monitor
db2acd
FMP
db2fmp
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
163
データベース物理設計
DB2デザイン・ガイド
V9.5
スレッドエンジンのメリット
リソースの節約
z EDUがプロセスだった際には、個別のプロセスで保持していたファイル・ハンドル情報を、
db2syscプロセスが持つメモリー空間で共有するので、情報の二重持ちがなくなる。
z システムスレッドのオペレーションはプロセスほどコンテキストを要求しない
¾
アドレススペースとコンテキスト情報を共有する
パフォーマンスの向上
z スレッド間でのコンテキストスイッチは、プロセス間でのやり取りに比べれば、一般的に
速い。
使いやすさの向上
z インスタンス全体で消費されるメモリー量の把握が、従来より容易になる。
z AUTOMATICに設定、動的に変更可能な構成パラメーターが増える。
z エージェント間で情報が共有されるため、アプリケーション・グループ共用メモリーが不
要になる。
¾
上記に伴い、以下の構成パラメータは廃止される。
– APP_GROUP_MEM_SZ
– GROUPHEAP_RATIO
– APP_CTL_HEAP_SZ
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
164
データベース物理設計
DB2デザイン・ガイド
V9.5
メモリー・モデルの変更(DB2 V9.5)
INSTANCE_MEMORY
APPL_MEMORY
1つのデータベースパーティションに
割り振ることができるメモリー最大量
データベースエージェントが割り振るアプ
リケーションメモリーの最大量を制御
DATABASE_MEMORY
データベース共用メモリー領域に
予約されるメモリー量を指定する
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
165
DB2デザイン・ガイド
データベース物理設計
V9.5
Automatic管理となったヒープ(メモリー関連)
V9.1でautonomic管理となっているヒープ(=STMMが管理)
¾
¾
¾
¾
¾
buffer pools
lock list
max locks
package cache
sort heap
V9.5でautonomic管理となるヒープ
¾
¾
¾
¾
¾
application heap
dbheap
monitor heap
statement heap
statistics heap
Information Center「いくつかの構成パラメーターは単純化されたメモリー構成によって影響を受ける」より抜粋
https://publib.boulder.ibm.com/infocenter/db2luw/v9r5/topic/com.ibm.db2.luw.wn.doc/doc/i0052504.html?resultof=%22%64%62%68%65%61%70%22%20
166
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
データベース物理設計
DB2デザイン・ガイド
V9.5
メモリー構成単純化のメリット
構成の簡素化
z 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
z 各データベースパーティションで使用可能な合計メモリーサイズの上限を
INSTANCE_MEMORYに設定可能
消費される合計メモリーサイズがINSTANCE_MEMORYのサイズ内であれば、各ヒープはメ
モリーサイズを増加させることが可能となる
¾ 新しく作成されるDBでは、メモリー関連(一部例外あり)のパラメーターはデフォルトで
AUTOMATICと設定され必要に応じてDB2が自動調整する
¾
– 例外)utility heap, catalog cache, audit buffer, java heap, etc
メモリー不足によるエラーの削減
z 各構成パラメーターをAUTOMATICと設定することで、必要に応じてメモリーサイズを調
整する
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
167
データベース物理設計
DB2デザイン・ガイド
V9.5
INSTANCE_MEMORY1/2
１つのデータベースパーティションに割り当てることが可能な最
大メモリーサイズを指定する
z デフォルト値(=AUTOMATIC)
¾
¾
実際の設定値は、db2start時にサーバーの実メモリーの75% - 95%の間で割り当てられる
実メモリーが割り当てられるわけではなく構成パラメーター値に上限値がセットされる
V9.1までとは意味が異なる
¾
インスタンス管理用として予約する必要のあるメモリーサイズを指定(V9.1)
INSTANCE_MEMORYの更新
z INSTANCE_MEMORYの動的増加は成功し、動的減少の場合は、現在使用されているメ
モリー量よりも大きい場合に成功する
z サーバーの実メモリーより大きい値がINSTANCE_MEMORYに設定された場合、db2start
はSQL1220Nで失敗する
z インスタンス稼動中に、実メモリーよりも大きい値にINSTANCE_MEMORYが更新された
場合、更新要求は据え置かれ、次回のdb2startがSQL1220Nで失敗する
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
168
データベース物理設計
DB2デザイン・ガイド
V9.5
INSTANCE_MEMORY2/2
INSTANCE_MEMORYサイズに達した状態で、特定ヒープに対してメモリー拡
張要求が来た場合
１．DB2は全ての共有メモリー、プライベートメモリーから要求されたメモリー量を削減しようと試みる
２．上記対応後も十分な空きINSTANCE_MEMORY領域を確保できなかった場合、拡張要求は失敗す
る
(例外)DB2の稼動に致命的な影響を与えるメモリーに対して拡張要求が来た
場合
z 致命的な影響
¾
¾
メモリー拡張要求が失敗することで、DBが無効とみなされる
インスタンスがシャットダウンしてしまう
１．データベースパーティションで使用している現在の使用メモリーサイズの削減を試みる
２．上記対応後も十分な空きINSTANCE_MEMORY領域を確保できなかった場合、DB2はOSにメモリー
要求を出し、OSからメモリーを確保する
¾
OSからメモリーを確保できた場合、INSTANCE_MEMORYのサイズが構成値を上回ることがある
考慮点
z 同一サーバー上で、別ミドルウェアも並行稼動する場合、もしくは複数のインスタンスが並行稼動す
る場合には、INSTANCE_MEMORYに適切な値を設定することで効率良いメモリー配分が可能とな
る
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
169
データベース物理設計
DB2デザイン・ガイド
V9.5
APPL_MEMORY
アプリケーションを実行するために割り当てることが可能な最大
メモリーサイズを指定する
z DBで消費されるアプリケーションメモリーの合計量をこのパラメーターで制限することが
できる
デフォルト値(=AUTOMATIC)
z DB活動化の時点で、最少のメモリーが割り当てられる
APPL_MEMORYに数値が設定された場合
z DB活動化の時点で、設定されたメモリーサイズが割り当てられ、APPL_MEMORYサイズ
の増減は発生しない
z 初期設定値のメモリーをサーバーから取得できなかった場合、もしくは、
INSTANCE_MEMORYの値を超えた場合、DBの活動化はSQL1084Cで失敗する
考慮点
z DATABASE_MEMORYに一定量のメモリーサイズを確保しておきたい場合には、
APPL_MEMORYで使用可能なメモリーサイズを制限する
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
170
データベース物理設計
DB2デザイン・ガイド
バッファープール関連のパラメーター
バッファプールの構成
z表スペースのディスクに対する入出力のキャッシュ
zLOBに対してバッファプールは効果が無い
プリフェッチャー（NUM_IOSERVERS）を十分に構成する
zこのパラメータは必要より大きく構成しても、ほんの少しメモリを消費するだけで他の悪影
響は考えられない
z物理ディスクの数＋２程度が推奨
ページクリーナー（NUM_IOCLEANERS）も十分に構成する
zこのパラメータは大きく構成し過ぎると、CPUの負荷を必要以上に大きくする可能性があ
る
zCPUの数を初期値に、最大で物理ディスク数迄
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
171
データベース物理設計
DB2デザイン・ガイド
解説
パフォーマンスに最も影響を与えるパラメータがバッファプールと言われています。DB2が使
用するメモリー領域の中で通常、最も大量にメモリーを使用します。
バッファプールは表及び索引・データのキャッシュに相当します。
バッファプールはデータベースが活動化時（通常最初の接続が行われた時）にアロケーショ
ンされ、非活動化時（最後の接続が切断された時）に解放されます。
バッファプールのみを大きくしても、物理ディスクのIOを行うプリフェッチャーとページクリー
ナーが少なければ、効果が上がらない可能性があります。
プリフェッチャーの初期値は、表及び索引を配置している物理ディスクの数+2（物理ディスク
数はRAID5ディスクの場合、パリティ・スペアを除く）と一般的に言われています。
ページクリーナーはCPUの数から物理ディスクの数の間で調整します。初期値はCPUの数
（物理ディスク数はRAID5ディスクの場合、パリティ・スペアを除く）。
RAID5等ストライピングされたディスクを表スペースに使用する場合、プリフェッチャー及び
ページクリーナーは通常ディスクと同様に調整する必要がありますが、さらにdb2setコマンド
で設定する環境変数：db2_parallel_ioに＊（全ての表スペース）また特定の表スペースIDを指
定する必要があります。
バッファプールのサイズは、スナップショットによってバッファープールヒット率（（論理読出数
－物理読出数）／論理読出数×１００）を計算して通常評価します。通常80%から90%以上が
目安ですが、システムの性格によってはそれ以下でも問題がない場合もあります。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
172
データベース物理設計
DB2デザイン・ガイド
プリフェッチャー（NUM_IOSERVERS）
プリフェッチャーは先読みを行う時に使用される。
データベース構成パラメーター「NUM_IOSERVERS」にて数を指定。
zV9以降、デフォルト値はAUTOMATIC（V8以前のデフォルト値は「3」）
¾AUTOMATICの場合、データベース活動化時点で、適正値を計算
page
page
page
page
page
page
page
page
Bufferpool
page
Prefetcher
Extent
cont
page
page
Prefetcher
必要のないプリフェッチャ
ーは使用されない
page
Prefetcher
Extent
cont
表スペース
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
Prefetcher
Prefetcher
Prefetcher
Extent
Prefetch単位
cont
173
データベース物理設計
DB2デザイン・ガイド
解説
バッファプールに表スペースからデータを読み込む時に、小さなデータを読み込むのであれば、通常はエージェント
が直接読み出して、バッファプールに格納します。しかし、連続したデータを読み込むような場合は、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）は、大きすぎても使われないプロセスが起動されているだけなので、多
少のメモリを余分に消費するのみのため、多少多めに構成しても、ほとんど問題がありません。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
174
データベース物理設計
DB2デザイン・ガイド
ページ・クリーナー（NUM_IOCLEANERS）
ページクリーナーは以下の時に呼び出される
zソフトチェックポイント
zページ変更しきい値（chngpgs_thresh）に達したとき
データベース構成パラメーター「NUM_IOCLEANERS」にて数を指定。
zV9以降、デフォルト値はAUTOMATIC（V8以前のデフォルト値は「1」）
¾AUTOMATICの場合、データベース活動化時点で、適正値を計算
② 更新済みページが
CHNGPGS_THRESの値（％）を超えた場合
db2agent
① （A）が（B)と比較してログ
ファイルのSOFTMAX（％）
よりも古い場合
データ更新
更新済みページ
LOGFILSZ
ログファイル
バッファープール
db2pclnr
db2pclnr
（A）バッファー・プール
内の最も古いページに
含まれている更新内容
のログ・レコード
NUM_IOCLEANERSデータベース
構成パラメータの値
cont1
（B)最新の更新内容
cont2
表スペース
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
db2pclnr
175
cont3
データベース物理設計
DB2デザイン・ガイド
解説
これに対して、バッファプールから表スペースに対してデータを書き出すプロセスを、ページ・クリーナーと呼びます。
プリフェッチャーと同様に、データベース構成パラメータ：NUM_IOCLEANERSによって構成します。
ページ・クリーナーがプリフェッチャーと異なる点は、多く構成しすぎると、CPUへのオーバーヘッドになる可能性があ
るという点です。ページ・クリーナーは幾つかの事象によって起動されますが、ページ・クリーナーが起動される時は、
構成されているクリーナーが全て起動されます。必要な数よりも多く構成されていた場合、多くのクリーナーが起動
されることになり、それがCPUの負荷を必要以上に高める可能性があります。
ページ・クリーナーの初期値がCPUの数と言われているのはこのためです。プリフェッチャーの数は物理ディスクの
数＋２程度と言われています。
このように、バッファプールはそれだけを大きくしても、バッファプール－ディスク間のデータのやりとりを行うプリ
フェッチャーおよびページ・クリーナーを表スペースのPrefetchSizeおよびExtentSizeと共に正しく構成しないと、ディ
スクへの入出力を効率化し、パフォーマンス向上を図ることは難しくなります。
ページ・クリーナーが呼び出されるタイミング
ページ・クリーナーが呼び出されるタイミングに影響を与えるパラメータが以下の構成パラメータです。
z
z
ページ変更しきい値（chngpgs_thresh）
softmaxおよびlogfilsiz
ページ変更しきい値は、バッファプール中のこのパラメータで指定した比率がダーティページ（データが更新され、
バッファプール上では更新されているが、ディスクには反映されていないページのこと）になったら、ディスクにダー
ティページを書き出そうとします。
また、logfilsizとsoftmaxによって、ソフト・チェックポイントを発生させ、ダーティページをディスクに書き出すことも可能
です。ソフト・チェックポイントの正確な意味を考えると多少混乱するかもしれませんが、大体、ログが切り替わるタイ
ミングでソフト・チェックポイントによって、ダーティページをディスクに書き出すと考えてよいでしょう。Softmaxはデ
フォルトでは100%で、logfilsizと同じですが、softmaxを小さくするかlogfilsiz自身を小さくすることによって、頻繁に発生
させることができます。
このダーティページの量は、クラッシュ・リカバリーと呼ばれるDB2によるリカバリー処理に大きな影響を与えます。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
176
データベース物理設計
DB2デザイン・ガイド
AUTOMATIC値の算出<NUM_IOSERVERS>
算出方法
z 以下の3つの値の中で、最も大きな値を設定値とする
¾
¾
¾
1.V8でのデフォルト値(3)
2．SMS表スペースで、(「コンテナ数」*「DB2_PARALLEL_IOで設定された並行処
理物理ディスク数」) の、全SMS表スペースでの最大値
3．DMS表スペースで、(「表スペースのストライプセットにあるコンテナの最大数」 *
「DB2_PARALLEL_IOで設定された並行処理物理ディスク数」)の、全DMS表スペー
スでの最大値
最低でも、3つのプリフェッチャーが起動
算出値に影響する項目
z 表スペースのコンテナ数
z DB2_PARALLEL_IOレジストリー変数で指定された、
並行処理物理ディスク数
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
177
データベース物理設計
DB2デザイン・ガイド
AUTOMATIC値の算出<NUM_IOCLEANERS>
算出方法
z 以下の値のうち、大きな方の値を設定値とする
¾
1.V8でのデフォルト値(1)
– 最低でも1つのページクリーナーが起動
¾
2.ＣＰＵ数 -1
– ＤＰＦの場合
CEIL(CPU数÷同一サーバー上のDBパーティション数)－1
*CEIL=少数部分を切り上げ
z 各DBパーティションに配布されるページクリーナー数がほぼ均等、
かつCPU数を超えないように算出
算出値に影響する項目
z CPU数
z ＤＰＦの場合、DBパーティション数
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
178
データベース物理設計
DB2デザイン・ガイド
その他最低限構成すべきパラメーター
ログ関連
z
logfilsiz, logprimary, logsecond
ロック関連
z
locklst, maxlocks
ソート関連
z
sortheap, sheapthres
エージェント関連
z
maxappls, num_poolagents, num_init_agents
¾
¾
V9.5
V9.1まで使用されていたmaxagentsはV9.5から廃止
num_poolagentsはV8,9.1とV9.5で仕様が異なっています。
–
–
V9.1まではアクティブなエージェントとプールされるエージェントの合計最大数
V9.5からは、プールされるエージェントの最大数
その他
z
applheapsz, dbheap, intra_parallel, maxfilop
よくわからない場合は、構成アドバイザーで初期値を設定
z
V9では、データベース作成時に、システムリソース(メモリー、CPU、等)を考慮し、構成パラメーターをデフォルト
で自動設定する
¾
¾
構成アドバイザーの機能によってパラメーターが決定される。
V8.2までは、構成パラメーター(DBM, DB)のデフォルト値は固定
V9では、自己チューニング・メモリー（STMM)機能がデフォルトで稼動
z
STMMでのチューニング対象になっているメモリー領域は、デフォルト値がAUTOMATICになっている
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
179
データベース物理設計
DB2デザイン・ガイド
解説
ログ関連
z
logfilsiz,logprimary,logsecond
¾
¾
¾
¾
ロック関連
z
ログは、最大のトランザクション（通常大量更新を行うバッチジョブなど）で使用されるログ容量をスナップ
ショットより測定し、その数値を元に（データ件数などの増加率などを含めて）見積もり、
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は、オンライン系トランザクションではできるだけ発生させないように、メモリーサイズを大きくします。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
180
データベース物理設計
DB2デザイン・ガイド
解説
ソート関連
z
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の意味合いが変更されました。
V9.5
– V8,V9.1:アクティブなエージェントとプールされるエージェントの合計数をNUM_POOLAGENTSとして設定
– V9.5:プールされるエージェントの最大数を設定
z
V9.5
¾
¾
¾
MAXAGENTSパラメーターはV9.5で廃止されました。クライアントアプリケーションの最大数を制限したい場合は、
MAX_CONNECTIONSで制限をかけます。
DB2ではSMPサーバーのCPUを効果的に利用する為、intra_parallelの機能がありますが、これをONにした場合、エー
ジェントの数は接続数×並列度まで増加することになります。Intra_parallelはクライアント数が多いオンライントランザク
ション系のサーバーでは使用しないことが推奨されています。
エージェントによって使用されるメモリー容量を見積もる場合、最低限1.5MB／接続、大きい場合（複雑なSQL等を実行
する場合）では32MB／接続まで実メモリーの空き容量を見積もる必要があります。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
181
データベース物理設計
DB2デザイン・ガイド
解説
その他
z
applheapsz
¾
複雑なSQL文の実行
より複雑なSQL文を処理する場合、アプリケーション・ヒープ（applheapsz）およびステートメント・ヒープ（stmtheap）が不
足する可能性があります。
特に、アプリケーション・ヒープは、Websphere Application ServerのPrepared Statement Cacheのように１つの接続上
でステートメントを複数同時に実行するような場合に、大きくする必要があります。ただし、applheapszはデフォルトの
128ページでは不足するケースがよくありますが、512または1024ページを指定すれば、かなり複雑なSQL文を処理で
き、ほとんどのケースでは十分なはずです。
V9.5では、このパラメーターの意味合いが変更されています。以前の1つの接続のために設定されるパラメーターでは
なく、アプリケーション全体で消費されるアプリケーションメモリーの総量に変更になりました。
¾
アプリケーション・ヒープ不足
もし、あなたが担当しているシステムで、applheapszに10MBを超えるような値（2500ページ以上）にしないと、「アプリ
ケーション・ヒープ不足です」というエラーが発生する場合、そこで動作しているアプリケーション・プログラムが宣言し
て使った資源（ステートメント・ハンドルなど）を確実にクローズしているかを確認してください。
そのような接続上にゴミを残すようなアプリケーションを動かしている場合、applheapszを極端に大きな値にしなければ、
動かしている途中でエラーが発生します。
¾
applheapszを大きくするということは、その接続数分だけメモリ上にゴミが残るということになります。そのようなシステ
ムでは、長時間の連続稼働によって、メモリの使用量が増加し、システムが不安定になる場合があります。
そのようなケースでは、アプリケーション・ヒープを増やして対応せずに、アプリケーション・プログラムを直して、接続上
にゴミを残さないようにしてください。
V9.5
z
dbheap
¾
¾
V9.5
バッファプールを大きくするとデータベースヒープが不足する場合があります。この場合、データベースヒープも大きく
する必要があります。
データベース・ヒープにはログ・バッファー、カタログ・キャッシュ（V8では別）が含まれます。これらを大きくする場合も
データベース・ヒープを大きくする必要があります。
z
intra_parallel
z
maxfilop
¾ このパラメーターは、データベースに対して同時に開くことのできるファイル・ハンドルの最大数を表すように
変更されました。
¾ 以前のリリースでは、各データベース・エージェントに対して、同時に開くことのできるファイル・ハンドルの最
大数を示していました。
¾
このパラメータは情報系のシステムの為のものなので、OLTP系のシステムではデフォルトのOFFのままにし、YESに
設定しないようにしてください。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
182
データベース物理設計
DB2デザイン・ガイド
自己チューニングメモリー(Self Tuning Memory Manager)
DB2が自動的にメモリーチューニングを実施
z 管理者がメモリーチューニングを実施する必要なし
z 予期しないワークロードを検知し、必要に応じてチューニング
¾
メモリーの再分配を必要とするワークロードの変化に対応
¾
情報収集→分析→設定→テスト→情報収集・・・・
z メモリーチューニングに労する時間を節約可能
対象
z データベース構成パラメーター
¾
¾
¾
¾
¾
SORTHEAP
SHEAPTHRES_SHR
LOCKLIST(MAXLOCKS)
PCKCACHESZ
DATABASE_MEMORY
z バッファープール
データベース構成パラメーターSELF_TUNING_MEMにて設定
z デフォルト値はON(=STMM稼動)
z この値をOFFに設定することで、下位パラメーターがAUTOMATICに設定されてい
てもSTMMは停止
検証段階でSTMMを稼動させ、最適な設定値になった時点で、STMM
を停止する、という使い方も可能
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
183
データベース物理設計
DB2デザイン・ガイド
解説：
V9の新機能であるメモリーの自己チューニング機能（STMM）を使用すると、DB2によって自動的にメ
モリー･チューニングが行われます。
STMMは、ワークロードの大きな変化に対応し、構成パラメーターの値およびバッファー・プールのサ
イズを調整してパフォーマンスを最適化します。
対象となるメモリー領域は以下の通りです。
z
z
z
z
z
z
SORTHEAP
SHEAPTHRES_SHR
LOCKLIST(MAXLOCKS)
PCKCACHESZ
DATABASE_MEMORY
バッファープール
z
「DB2 V9.1以降でSTMMを使用する場合のOSのメモリー関連設定の注意事項 (DM-08-009)」
STMM使用時のOSの設定に関する注意事項
¾
http://www-06.ibm.com/jp/domino01/mkt/cnpages1.nsf/page/default-0002EA21
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
184
データベース物理設計
DB2デザイン・ガイド
STMM使用時のDATABASE_MEMORY設定方法
DATABASE_MEMORY=AUTOMATIC(デフォルト)
z 必要に応じてOSよりメモリー取得、解放を行いチューニングを行う
z STMMが増加すべきと判断した場合、メモリーを無制限に割り当てる
¾
DB2_MEM_TUNING_RANGEで設定したminfreeの値を残す
z DB2_PINNED_BP=YES, DB2_LARGE_PAGE_MEM=DB設定時は、
AUTOMATIC指定不可
z AIX(64bit), Windows(32bit & 64bit)のみで設定可能
DATABASE_MEMORY=数値
z 指定した数値の範囲内で、メモリーチューニングを行う
DATABASE_MEMORY=COMPUTED
z STMMは稼動しない
z V8のAUTOMATICの動作
¾
DB起動時の各パラメーターの初期値に基づき総容量を算出
z V8からの移行時は、設定値AUTOMATICは、COMPUTEDに変更され
る
z AIX, Windows以外のOSのデフォルト値
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
185
データベース物理設計
DB2デザイン・ガイド
STMM使用時のDATABASE_MEMORY設定方法（続き）
DB2_MEM_TUNING_RANGEレジストリー変数
zAUTOMATIC設定時、フリーメモリーを一定量確保し、それ以外のメモリー
を使用
z確保するメモリー量の設定方法
¾db2set
DB2_MEM_TUNING_RANGE =minfree, maxfree
¾minfree、maxfreeを定義
zAIX, Windows環境のみ適用可能
設定値と意味
zminfree
¾インスタンスが追加メモリーを必要としたときに、”minfree”で指定された％に達
するまでシステムの空き物理メモリーを割り振る
zmaxfree
¾インスタンスはフリーにしておく物理メモリー量を”maxfree”で指定された％で
維持する
z未設定（デフォルト）
¾DB2が物理メモリー量より算出
z注意
¾STMM = ON & DATABASE_MEMORY = AUTOMATICの環境で、空き物理メモ
リー量不足の問題が起きていなければ、特にチューニングに必要なし
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
186
データベース物理設計
DB2デザイン・ガイド
解説：
チューナーは、database_memory 構成パラメーターによって定義されたメモリー制限内で作動します。
Windows® および AIX® 上では、database_memory の値自体を自動的に調整することができます。
database_memory のセルフチューニングが使用可能である (AUTOMATIC に設定されている) 場合、
チューナーはデータベースの全体的なメモリー要件を判別し、現在のデータベース要求量に従って
データベース共用メモリーに割り振られるメモリーの量を増減します。たとえば、現行データベース要
求量が高く、システムに十分の空きメモリーがある場合、さらに多くのメモリーがデータベース共用メ
モリーによって消費されます。データベース・メモリー要求量が下げられるか、またはシステムの空き
メモリー量が過度に減ると、データベース共用メモリーの一部が解放されます。
database_memory パラメーターが自己チューニングで使用できない (AUTOMATIC に設定されていな
い) 場合、データベース全体は指定されたメモリー量を使用し、必要に応じてデータベースのメモリー・
コンシューマー間でそれを分配します。 database_memory が自己チューニングで使用できない場合、
データベースによって使用されるメモリーの量は 2 つの方法 (database_memory を数値に設定するか、
COMPUTED に設定する) で指定できます。 COMPUTEDは、V8以前のAUTOMATICに相当し、メモ
リーの合計量は、データベース起動時のデータベース・メモリー・ヒープの初期値の合計に基づいて
計算されます。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
187
データベース物理設計
DB2デザイン・ガイド
ブランク・ページです
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
188
データベース物理設計
DB2デザイン・ガイド
STMM使用時のその他のパラメーター設定方法
LOCKLIST, PCKCACHESZ, SORTHEAP,
SHEAPTHRES_SHR
z 現在の設定値からチューニングを開始
¾
xxxは各パラメーター名
yyは設定値
db2 update db cfg for DB using xxx automatic
z 設定値をyyに変更し、その値からチューニングを開始
¾
db2 update db cfg for DB using xxx yy automatic
z 現在の設定値でチューニングを停止
¾
db2 update db cfg for DB using xxx manual
z 設定値をyyに変更し、その値でチューニングを停止
¾
db2 update db cfg for DB using xxx yy
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
189
データベース物理設計
DB2デザイン・ガイド
バージョンによるソートの違い
V8.2までのソート
z プライベートソートの場合（エージェントプライベートメモリーを使用）
¾ SORTHEAP(DB CFG) & SHEAPTHRES(DBM CFG)で設定
¾ 専用ソートによって使用されるメモリーの合計量におけるソフトリミット
z 共有ソートの場合（データベース共有メモリーを使用）
¾ SORTHEAP(DB CFG) & SHEAPTHRES_SHR(DB CFG)で設定
– SHEAPTHRES_SHR=0の場合、SHEAPTHRESの値が使用される
¾
¾
SHEAPTHRES_SHRは１時点にソート用として使用できるデータベース共有メモ
リーの合計量に対するハードリミット
条件
– intra_parallel=yes
– max_connections > max_cordagents
V9.1からのソート
z すべてのソートはデータベース共有メモリーを使用
¾ SORTHEAP(DB CFG) & SHEAPTHRES_SHR(DB CFG)で設定
– デフォルトでSHEAPTHRES(DBM CFG)=0
¾
– SORTHEAP, SHEAPTHRES_SHRの自動チューニングはSHEAPTHRES=0
の場合のみ可能
データベース共有メモリーの合計量に対するソフトリミット
z SHEAPTHRES > 0と設定することで、V8.2のメモリーモデルを使用可能
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
190
データベース物理設計
DB2デザイン・ガイド
STMM使用時のバッファープールサイズ設定方法
作成
z バッファープールサイズを指定し作成、その値からSTMMによる
チューニング開始
¾
db2 create bufferpool BPNAME (immediate/deferred) size yy automatic
– yyは初期サイズ
z バッファープールを作成し、STMMによるチューニング開始
サイズ未指定でバッファープールを作成すると、1000ページで作成
¾
¾
db2 create bufferpool BPNAME (immediate/deferred)
db2 create bufferpool BPNAME (immediate/deferred) size automatic
変更
z 設定値をyyに変更し、その値からチューニングを開始
¾
db2 alter bufferpool BPNAME (immediate/deferred) size yy automatic
z 現在の設定値からチューニングを開始
¾
db2 alter bufferpool BPNAME (immediate/deferred) size automatic
z 設定値をyyに変更し、その値でチューニングを停止
¾
db2 alter bufferpool BPNAME size yy
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
191
データベース物理設計
DB2デザイン・ガイド
ブランク・ページです
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
192
データベース物理設計
DB2デザイン・ガイド
⑧シェル／コマンドの作成
データベース構築に必要なシェル／コマンド
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
193
データベース物理設計
DB2デザイン・ガイド
ブランク・ページです
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
194
データベース物理設計
DB2デザイン・ガイド
データベース構築に必要なシェル／コマンド
以下のような操作を行うシェルやコマンドを用意する
z 論理ボリューム，ファイルシステムの作成、権限の変更
¾
OS上の操作でDB2が使用する資源を準備する
AIX
Volume Group(VG) Physical Volume(PV) Logical Volume(LV)
Veritas Disk Group(DG)
¾
subdisk
volume
plex(ストライプ時など)
WindowsではファイルDMSが一般的 <- MSCSではローデバイスが使用できないこと
も要因
z データベース作成
¾
¾
¾
データベースのホームディレクトリー
ログの配置変更(newlogpath)
デフォルト表スペースやページ・サイズの変更
¾
prefetchsize , extentsizeを正しく設定（extentsizeは後から変更できないので特に注
意）
z バッファプール・表スペース作成
z 表・索引作成
z その他
構築時に使用したシェルは、事前にテスト環境で十分に検証を行
う。また、再構築などで使用する場合に備えてきちんと管理してお
く。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
195
データベース物理設計
DB2デザイン・ガイド
解説
論理ボリューム・ファイルシステム作成、権限の変更
z
AIXの例
論理ボリューム作成
ローデバイス用論理ボリュームの権限変更
ファイルシステム作成
mklv -y lv_name vg_name pp数 hdiskxx
chown user:group /dev/rlv_name
crfs -v jfs -m /mount_point -l lv_name -A yes
データベース作成例（/databaseをDBのホーム・ディレクトリとして作成）
z
db2 create database DB_NAME on /database
z
db2 create BP01 size 25000 pagesize 4K not extended storage
z
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"
バッファプール作成例(100MB)
表スペース作成例(DMS Raw Device)
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
196
データベース物理設計
DB2デザイン・ガイド
OS特有の設定
AIX
z IOCPの設定（V9.7からデフォルトで使用）
z AIO（非同期I/O）
¾
¾
AIX5.3（aiooコマンド）、AIX6.1（iooコマンド）
AIX6.1では基本はデフォルト値での稼動が推奨
– 必要に応じてモニタリングしながらチューニング
z vmo（AIX5.2以降）
¾ JFSのファイルキャッシュを抑えるために使用(minperm,maxperm)
¾ JFS2の場合、maxclient（ハードリミット）によって制限
¾ 以下の設定が推奨される（AIX6.1ではデフォルトの設定値）
z その他
– LRU_FILE_REPAGE=0
– min_perm=3
Linux
z Kernel parameterの設定
¾
V9.5FP5、V9.7FP1以前の環境では、必要に応じてカーネル・パラメーターの変
更を行う
– マニュアルにある強制最小設定値を参考
– V9.5FP6、V9.7FP2以降はデータベース・マネージャーが自動的にカーネル・
パラメーターの設定を調整するため手動での変更の必要なし
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
197
データベース物理設計
DB2デザイン・ガイド
解説
AIX
¾
V9.7よりIOCPの設定をデフォルトで使用するように変更されている
–
–
詳細はテクニカルフラッシュ「DM-11-043:DB2 V9.7で、AIXの入出力完了ポート（IOCP)をデフォルトで
使用するようになった」を参照
V9.5までは必須ではありません。
¾
AIOについて
¾
その他、チューニングについては以下の資料を参照
– AIX6.1ではデフォルトの値での稼動を推奨
– チューニングする場合は以下のマニュアルを参照
（参考）良好なパフォーマンスのための構成
http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=%2Fcom.ibm.db2.luw.admin.perf.doc%2Fdoc%2Fc0054689.html
Linux
z
（参考）BestPractices for DB2 on AIX 6.1 for POWER Systems
http://www.redbooks.ibm.com/abstracts/sg247821.html
カーネル・パラメーターの設定
¾
V9.1
–
¾
V9.5
–
–
¾
V9.7
–
–
–
http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=%2Fcom.ibm.db2.udb.uprun.doc%2Fdoc%
2Ft0008238.htm
http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=%2Fcom.ibm.db2.luw.qb.server.doc%2F
doc%2Fc0057140.html
http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=%2Fcom.ibm.db2.luw.qb.server.doc%2F
doc%2Ft0008238.html
http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=%2Fcom.ibm.db2.luw.qb.server.doc%2F
doc%2Fc0057140.html
http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=%2Fcom.ibm.db2.luw.qb.server.doc%2F
doc%2Ft0008238.html
自動で調整されるが、LOADを使用する場合は別途MSGMNBの値を調整するか検討する必要があります
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部
198

データベース物理設計 【DB2 9.7 対応版】 ©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部 ＜第１．００版

Comments

Description

Transcript

データベース物理設計【DB2 9.7 対応版】 ©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) Information Management部＜第１．００版