具体的にシートへの記述方法を紹介します。

前提

設定数値関連

イベント系の表に関しては、データ保持期限の1年分の容量を見積もっています。

マスタ系の表は、過去のデータも管理しているため、カレントで使用しているデータは80％とします。
営業日は週5日。
設計レコード数はあらかじめ与えられた現状の値を使用しています。
レコード長、カラム数は、論理設計で設計した値を使用していると仮定します。

PCTFREEは以下を想定しています。
マスタ系は10%、イベント系の表では、表に最初にオカレンスが挿入されたときはNULL、後から値が人力される項目のデー夕長に注目します。
最終行長から初期行長を引いた差分の行長が、最終行長に対して何%かを計算して設定するのが原則です。
本例では、だいたい20%と見積もっています。
更新によって行長が長くなるものについては25%、サマリー系で導出（バッチ処理など）で作成される表は5%を設定しています。
パーティションは、元の表（イベント系の表）に準じます。

ブロックサイズは基本的に8K。大きい表は16Kを設定しています。

エクステントサイズは、エクステント数が10以内に収まるよう、5ブロックの倍数で設定しています。
表の種類は、主要なエンティティのみを使用しています。
実際にはもっと多数の表が存在しますが、サンプルとしていくつか抽出したものを使用しています。

業務関連

アプリケーション間発チームの要望で、以下の5つのサブシステムが提示されたことを想定しています。
サブシステムは、表領域の分割の際に参考にします。

• 販売管理
• 在庫管理
• 仕入れ管理
• 経理管理
• 売上分析

パーティションの採用

受注、売上、発注、仕入れ等のイベント系の表に関しては、データ量が非常に多いこと、使用されるSQLから目付単位での絞り込み条件が多いことが予測されるため、パーティション機能の使用を考えました。
1パーティションが数百MBになるものに関して、パーティション化を適用しました。
本例では、2か月につき1パーティションとしていますが、SQLの処理を考慮すると、1か月につき1パーティションが最善だと思われます。

パーティション化する表の容量増加に対する対策としては、年度が替わるごとにパーティションを追加することによって対応します。
パーティション化した表のうち、売上表に関しては、分析業務のために、次の4つのサマリ表をマテリアライズドビューという形であらかじめサマリデータを集計しておくことを考えました。

• 日別商品別顧客別売上サマリ
• 日別商品別営業部員別売上サマリ
• 日別商品別部門別売上サマリ
• 日別商品分類別売上サマリ

業務要件として、1日前の売上情報を分析するというレベルでよいとの判断から、バッチ更新によるマテリアライズドビューの使用を考えました。
マテリアライズドビューも大規模で日付単位で集計、計算することが多いため、パーティション化します。
マテリアライズドビューの容量増加に対しても、年度をまたがった場合には、パーティションを追加することで対応します。

管理項目として、予算と実績を比較するのであれば予算、利益率を分析したいのであれば利益、日別ではオンラインの処理速度として不足であれば月別といったサマリを作成しておくことも考慮します。
ユーザの戦略と要求に従って、適切な選択をする必要があります。

表領域設計例

解説トレーナー