ざっくりと、ORACELのディスクサイズ設計方法

新規にORACLEデータベースを作成する場合、まず必要なディスクサイズを見積もります。
私は以下の方法を使います。
　※注意：本来は、アーカイブ領域、一時表領域、undo表領域の容量も考慮しますが、これらは机上で見積もるのは難しいです。そこで、今回はデータ領域だけに絞って話をします。

　■1.　テーブルサイズを求める。
　　　そのテーブルの最大件数×1レコードサイズ
　　　これをデータベースに作成する予定のテーブル数分計算します。
　■2.　データベースに作成する全テーブルのサイズを合計する。
　　　つまり、1で計算した全テーブルを足した合計になります。

インデックスも同じように求めます。
テーブルと異なる点として、インデックスの1レコードのサイズは、インデックスを構成するカラムの桁数を合計したものになります。

テーブルサイズの合計と、インデックスサイズの合計を足したものが、そのデータベースのデータ領域に必要な容量です。
これで、ざっくり求まります。
あとは、このサイズを一本当たりのディスクサイズで割れば、必要なディスク本数が求まります。

ただし、あくまでざっくりですので、ここに適当な安全率を掛けることを忘れずに。
安全率は過去のプロジェクトで作成したデータベースを参考にして決めることが多いです。
今回作成するデータベースと似ているものを参考にします。
参考にしたデータベースの設計値と運用後の容量を比較して、今回作成するデータベースの安全率をどうするか決定します。
例えば、1.3～1.5倍と言ったように決定します。
あと、容量に余裕を持たせるために、閾値を考慮する必要があります。
安全率を掛けた結果に対して、閾値のパーセンテージで割り算してください。

以下、簡単な例で計算をしてみます。

例)AとBという二つのテーブルを持つデータベースの容量を求めよ。
　ただし、ディスク使用率が80%以下を維持できることを考慮すること。
　安全率は1.3倍とする。

　■1.　テーブルサイズを求める。
　　　・Aテーブル
　　　　最大件数：100,000,000件
　　　　レコードサイズ：100Byte

　　　　Aテーブルのサイズ
　　　　　100,000,000件×100Byte＝10,000,000,000Byte(10GByte)

　　　・Bテーブル
　　　　最大件数：200,000,000件
　　　　レコードサイズ：50Byte

　　　　Bテーブルのサイズ
　　　　　200,000,000件×50Byte＝10,000,000,000Byte(10GByte)

　　※テーブルにインデックスが存在する場合は、同じように計算してください。
　　　今回は単純な説明にしたいためインデックスを省いてます。

　■2.　1で求めた全テーブルのサイズを合計しデータ領域のサイズとする。

　　AテーブルサイズとBテーブルサイズを足す。

　　10GByte＋10GByte＝20GByte

　■3.　2で求めたサイズに安全率1.3を掛ける。

　　20GByte×1.3＝26GByte

　■4.　3で求めたサイズの容量閾値を80%としてサイズを見積もる。

　　26GByte÷0.8＝32.5GByte

　　※設定したサイズぎりぎりで運用するのは危険なため閾値を考慮した
　　　サイズにしています。
　　　ここでは使用率80%を維持するものとし、常に20%(6.5GByte)の容量を
　　　余裕として確保するように計算しています。

　■5.　4で求めたデータベースサイズを一本当たりのディスクサイズで割って、
　　　必要なディスクサイズを見積もる。

　　※1本あたり5GByteとする。
　　32.5GByte÷5GByte＝6.5G本

　　端数切り上げで、5GByteのディスク7本必要とする。

ここで注意してほしいのが、最大件数は業務チームから頂くということです。
なるべく正確な数値を頂きたいところですが、開発当初は中々決まらない数字でもあります。
なので、業務からの回答も遅めになるかと思います。
そんな時は、多目でもいいので早く出してもらえるように働きかけましょう。

テーブルやインデックスのレコードサイズは、ざっくりならカラムごとの桁数を積算することで求めることができます。
実際には行ヘッダや列ヘッダまで考えると正確だとは思います。
ですが、そこまで考慮して計算すると時間も掛かるし、何よりカラムが増えたり減ったりしたときの再計算が面倒です。

そこで注目してほしいのが、安全率を掛けたり、ディスク本数を求めるところで端数を切り上げていると言うところです。
細かいところに目を向けても、どの道、上記の計算で丸められて大き目にされてしまうのです。
また、ORACLEはエクステントサイズ単位で容量を使うので数Byte単位で正確に見積もったとしても、内部処理で丸められてしまう運命なのです。
テーブルやカラムの数だって、ここで設計した後、増えたり減ったりするのが常です。
と言うことで、ここで正確さを求めすぎて、時間を費やすくらいなら、もっと他にも時間を掛ける場所は幾らでもあります。

ディスクの見積もりは、ある程度ざっくりスピーディにやることが肝かなと思ってます。
とにかく、早く仕上げて他のメンバーに見てもらうって言うのが大事だと思います。
確認してもらうことで、皆の思惑とこっちの見積もりとの間に思い違いや、すれ違いがあるのが分かって、早めに修正できるからです。