に関連したコンテナーを再定義することはできな い（SQL20319N）。
自動ストレージの一時表スペース
一時表スペースはSMSとして作成される
非自動ストレージと自動ストレージの管理の違い
ストレージ・パスの容量は揃える–
一時表スペースのコンテナは、データベースが開始するたびにストレージ・パスの空き容量によっ て自動的に再定義されるため、それぞれのストレージ・パスの空き容量は揃えておく非自動ストレージ 自動ストレージ
表スペースの作成時にコンテナーを明示的に 提供する必要がある。
表スペースの作成時にコンテナーを提供すること はできず、DB2 UDB によって自動的に割り当て および割り振りが行われる。
リダイレクトされたリストア操作を使用して表 スペースに関連したコンテナーを再定義でき る。
DB2 UDB がスペース管理を制御するので、リダ
イレクトされたリストア操作を使用して表スペース に関連したコンテナーを再定義することはできな い（SQL20319N）。DMS ファイル表スペースの自動サイズ変更
DMS ファイル・コンテナのサイズを自動的に拡張
表スペース 表スペース
SQL0289N 発生
自動的に拡張される
自動サイズ変更を使用しない場合 自動サイズ変更を使用した場合
DMS ファイル表スペースの自動サイズ変更
DMS
ファイル・コンテナのサイズを自動的に拡張–
コンテナがいっぱいになる（SQL0289N）前に、追加領域の必要に応じてコンテナを自動的に拡張する–
ファイル・コンテナのみ使用可能•
ロー・デバイス・コンテナの自動サイズ変更は不可能–
表スペースの最後のレンジにあるコンテナが拡張される•
自動サイズ変更によってリバランスは発生しない•
それぞれのコンテナは同じ量だけ拡張される–
自動ストレージ・表スペースのDMS
、自動ストレージ・表スペースでないDMS
のいずれに対しても使用可能–
自動ストレージ・表スペースでない場合、ユーザーによるコンテナの拡張、削除が可能•
従来どおり、ALTER TABLESPACEステートメントを使用する–
区分化データベース環境でも使用可能 DMS
なのでパフォーマンスがよく、自動的にサイズ拡張するので、SMS
同様管理が容易になる
考慮点–
自動サイズ変更が行われる場合、表に対する挿入処理は、自動サイズ変更が完了するまで待たされる。–
一時表スペースを使用しないREORGの際にも自動サイズ変更が行われる。• REORG
完了後もサイズは拡張されたままで、縮小されない。まとめ ページ・サイズ
レコード長を明確にして、適切なページ・サイズを決定する
1 種類のページ・サイズで済むかどうか検討する
– それぞれのページ・サイズ毎にバッファープール、一時表スペースを作るとス ペースをより多く必要とするため（運用も複雑になる）。
– ページ・サイズを検討するにあたって、ページサイズによる制限値を超えてい ないこと、格納効率によって判断する。
使用するページ・サイズの種類はなるべく少なくする
※LOBデータの場合はページ・サイズは決めなくても良い
指針
パフォーマンスを考慮し、表スペースの割り当てを検討– I/O効率化による分割:
表データ、索引を異なる表スペースに配置–
業務データの更新頻度による分割–
基本は、サイズの大きいひとつのバッファープールを使用•
パフォーマンス・テストで、要件上の応答時間に収まらない場合には、必要に応じてバッファー プールの分割を検討できるように表スペース分割を検討 I/Oの並列処理を考慮し、データの物理配置に合わせて表スペースを構成
バックアップ等の運用面で検討–
業務データ種類（バックアップ取得頻度）による分割
ページ・サイズによる制限事項を考慮まとめ 表スペース分割
指針
まとめ エクステント・サイズの決定
ほとんどの場合デフォルト32から変更する必要はない
多数の小さい表からなる表スペースは、サイズを減らすことも検討
大量の結果行を返す照会を行う表や急激に拡張される表からなる表スペースは、
サイズを増やすことも検討
指針
まとめ ファイル管理のタイプによる表スペースの種別の決定
パフォーマンスを重視する場合は、 DMS ローデバイス、または DMS ファイル を使用する
管理の容易さを重視する場合は、自動ストレージ、 SMS を検討する
指針
物理設計のステップ
データ容量の見積もり
インスタンスの構成と データベース分割
表スペース容量の見積もり
表の分類と 表スペースの構成
ディスク上への オブジェクトの配置
データ容量の見積もりステップ
1. 各表のレコード件数を出す
2. 各表の 1 行あたりのサイズ ( 平均行サイズ ) を出す
3. レコード件数 * 平均行サイズ = 1 テーブルのサイズを出す
4. 索引容量の見積もりを出す
1. レコード件数の見積もり
見積りの前提となる数値、算定根拠を明確にする
– 各テーブルのレコード件数を見積もる上で必要な数値の収集
• コード類、マスター類の件数
• １日あたりの処理件数
• データの保持期間
• データ増加率 ．．．etc.
– 各テーブルとテーブルの関係を明確化
ポイント
お客様にAuthorizeされた前提の数値であることが重要
前提に変更があれば、都度再見積り可能なようにワークシートにまとめておく
レコード件数の算出例
お客様との合意事項– 2年後のデータ量を想定しディスク容量を見積もること
前提となる数値–
一日あたりのデータ発生件数10,000件 –
データの保持期間1週間
–
データは、保持期間経過後、履歴表へ–
各テーブルの現在の件数•
マスタ表100,000件
•
トランザクション表0件
•
履歴表0件
トランザクション表のレコード件数は？– 1日のデータ発生件数が10,000件
–
データ保持期間1週間 →10,000 * 7 = 70,000件
履歴表のレコード件数は？– 1日あたりの処理件数 10,000件 – 1年365日
– 2年後のレコード件数
→10,000件* 365 * 2 = 7,300,000件
2. 平均行サイズの算出
平均行サイズ : 表の一行あたりの長さ
表の列定義から、一行あたりの長さ ( バイト ) を出す
可変長は、平均のデータ量を算出する
NULL 値を許す場合１バイト、可変長の場合 4 バイトを各該当の列項
目あたり加算
各データ・タイプ毎のサイズ
各データ・タイプ毎のサイズデータ・タイプ バイト
SMALLINT 2
INTEGER 4
BIGINT 8
DOUBLE 8
ドキュメント内
第５章 データベースの物理設計
(ページ 39-52)