MQTの作成
CREARE TABLE 文にて指定
materialized-query-definition で基礎表に対するSELECT文を定義
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) データ・プラットフォーム部 93
②データ容量の見積もり
物理設計の流れ
①表・索引定義の作成
②データ容量の見積もり
③インスタンスの構成と データベース分割
④表の分類と 表スペースの構成
⑤表スペース容量の見積もり
⑥ディスク上への オブジェクトの配置
表の見積り
索引の見積り
表圧縮(行圧縮)/索引圧縮の 考慮
⑨シェル／コマンドの作成
⑧構成パラメータの設定
⑦ユーザーと権限の設計
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) データ・プラットフォーム部 95
表・索引の見積もり
前提：
物理設計手順「①表・索引定義の作成」において、作成すべき表、索引が洗い出され ている
見積もりの基礎となる前提の数値、算定根拠を明確にする
各表のレコード件数を見積もる上で必要な数値の収集 – コード類、マスター類の件数、１日あたりの処理件数
– データの保持期間、データ増加率 ．．．etc.
お客様にAuthorizeされた前提の数値であることが重要
– 前提に変更があれば、都度再見積もり可能なようにワークシートにまとめてお く
手順
表の容量を見積もる
MQTは、表と同様
索引の容量を見積もる
圧縮率を加味する
あくまでも見積もりであり、テスト環境のDBでデータを格納し確認
解説
物理設計手順「①表・索引定義の作成」において、作成すべき表、索引が洗い出され、表の列定義、索引キー定義 が行われていることを前提とします。表定義(カラムの属性・長さ)および、索引のキーが決定した後、どれだけのディ スク容量が必要となるかを見積もる必要があります。
この容量見積もりは、表に含まれるデータだけではなく、索引のデータも含まれます。後段階でパフォーマンス チューニングを行う際に索引が追加されることも考慮し、索引を作成する表スペースの容量には余裕を持たせる必 要があります。
見積もりの基礎となる前提の数値（コード類、マスター類の件数、１日あたりの処理件数、データの保持期間、データ 増加率等や算定根拠を明確にする必要があります。
各表のレコード件数を見積もる上で必要な数値の収集は、お客様にAuthorizeされた前提の数値であることが重要
です。前提に変更があれば、都度再見積もりが必要となりますので、再見積もりが容易になるようにワークシートにまとめ ておきましょう。
手順としては、全ての表、索引の容量を見積もり、圧縮を使用する場合は、圧縮率を加味します。
MQTはViewの一種ですが、永続的にストレージを使用するため、表と同様に容量を算出します。
データベース・オブジェクトのサイズは、正確に見積もることができません。サイズの見積もりを難しくする原因は、
ディスクのフラグメント化によって発生するオーバーヘッド、フリー・スペース、および可変長列の使用などです。これ は、列タイプや行の長さが広い範囲で異なる可能性があるためです。まずデータベースのサイズを見積もってから、
テスト・データベースを作成し、それに標準的なデータを入れてみてください。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) データ・プラットフォーム部 97
表の見積もり
表容量概算：
（論理レコード長＋10）×レコード件数×安全率
論理レコード長
各データ項目のデータ・タイプ、桁数から各項目の物理サイズを算出。
可変長の場合は、平均長を採用。
NULL値を許す場合１バイト、可変長の場合4バイトを各該当の列項目あたり加算
すべてを合計したのが1行あたりの論理レコード長
レコード件数
保存期間、データ増加率も加味
安全率（余裕率）
PCTFREEの割合やAPPENDモードであるかも考慮する
オーバーヘッド分（フラグメンテーションやオーバー・フロー・レコードの有無）
Long列データは他の表データとは別のところに保管
表内の他の列と同じページには、実際のLONG, LOBデータへのポインター情報のみ持つ – LONG VARCHAR、LONG VARGRAPHICは24バイト
– LOB記述子(LOBデータへのポインター)はLOB最大サイズによって長さが異なる
V9.7から、指定サイズ以下のLOBは、他のデータと同じ場所に保存可能(インライン格納)
必要なディスク容量
表スペースのページ・サイズを決定し、１ページあたりの行数から必要ページ数を導く（後述）
解説
ここで、レコード長を計算する場合、ヌルが可の場合1バイト、可変長の場合4バイトを加える必要があります。
論理レコード長は、各データ項目のデータ・タイプ、桁数から各項目の物理サイズを算出して、可変長の場合は、平 均長を採用します。NULL値を許す場合１バイト、可変長の場合4バイトを各該当の列項目あたり加算し、これらをす べて合計したのが１行のレコード長となります。
レコード件数は、保存期間、データ増加率も加味します。また、安全率としてPCTFREEの割合やAPPENDモードであ るかの考慮や、オーバーヘッド分（フラグメンテーションやオーバー・フロー・レコードの有無）も考慮します。
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) データ・プラットフォーム部 99
索引の見積もり
索引容量概算：
(平均索引キー・サイズ＋索引キーのオーバーヘッド）×行数×安全率
表スペースの
タイプ 表タイプ 索引タイプ
索引キーの オーバーヘッド
(バイト)
通常
(REGULAR)
非パーティション 任意 9
パーティション
パーティション 9
非パーティショ
ン 11
大きい
(LARGE) パーティション
パーティション 11
非パーティショ
ン 13
平均索引キー・サイズ
基本的な算出方法の考え方は表と同等
索引キーのオーバーヘッド
索引を保管する表スペースのタイプ、索引 が作成される表のタイプ、に依存
安全率
ノンリーフ・ページやフリー・スペースなどのオーバーヘッドのため、少なくとも２倍は必要
索引の作成時のソートに必要な一時スペースの領域は、上記の式の安全率を３．２として見積 もる
後にパフォーマンスチューニングで索引が追加されることも考慮し余裕を見ておく
解説
索引のキー長も算出方法は基本的には表と同等です。
行数については、MDC表のブロック索引(MDC表に対して、内部的に作成される)は、「行数」を「ブロック数」で置き換 えます。
LARGE表スペース(RID6バイト)は、通常のREGULAR表スペース(RID4バイト)より、2バイト拡張されています。また、
索引タイプを非パーティション(NOT PARTITIONED)にすると、パーティション表のグローバル索引となり、索引キー にパーティションIDが含まれるため、その分の2バイトが追加で必要となります。
後段階でパフォーマンスチューニングを行う際に索引が追加されることも考慮し、索引を作成する表スペースの容量 には余裕を持たせる必要があります。
最終的に必要なディスク容量は、表スペースのページ・サイズを決定し、1行の長さから１ページあたりの行数を算出 し、全データ件数をその１ページあたりの行数で割ることにより、必要ページ数を導きます。（後述）
©日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) データ・プラットフォーム部 101