スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

なんだよ!オラクル使うと2TB玉でも400GBちょっとしか使えないの?

実効容量オラクル編です。タイトルはキャッチーなんであしからず(笑)嘘は書いてませんので。

まず、前提として下記のような内容のモデルとします。前提によっていかようにでもなるので、より一般的なものを意識します。
・シンプルなシングルインスタンス構成(非RAC、非ASM)
・ファイルシステムで構築(非RAWデバイス)
・DBのサイズは500GBクラスの中小規模
・適度な参照、更新があるパターン(やたら巨大な履歴を参照したり、複雑な結合をしたり、一部に更新が集中するなどの特殊なケースは除きます)

これ以降各レイヤーで計算します。

■OSレイヤー
まず、ファイルシステムの実効容量を求めます。以下のサイト
http://hesonogoma.com/linux/ComparativeTableOfFileSystem.html
でよくまとまっているので参考にします。標準的なものはext3だと思いますが、その他のファイルシステムと比較してもあまり差はありません。なのでここではファイルシステムのオーバーヘッドを約10パーセントとして計算します。

■DBレイヤー
まず、ファイル設計を以下のようにします。ここでも細かく考えればいかようにでもなるので、かなりザックリレベルだとします。

インストール等のバイナリー領域 : 10GB
ログやコアファイルの吐出し先 : 10GB
system、temp、undo、redo、swsauxなどの管理系 : 20GB
データファイル : 500GB

合計が540GBで500GBのデータ領域なので管理領域のペナルティーは約10パーセントです。いろいろな意見はあろうかと思いますが大きな違和感はないと思います(と信じます(笑))

次にオブジェクトレベルでのオーバーヘッドを考えます。オブジェクトとはオラクルでいうテーブル、インデックスなどの「もの」を言いますが、前提としてビューやLOBデータなどの計算を複雑にするのもは除きます。

今回は実効容量に大きく影響を与えるものにフォーカスしたいので、ザックリ下記のように考えます。
・テーブルのオーバーヘッド(カラムやテーブルのオーバーヘッド+PCTFREEなどの予備領域) : 20パーセント
・インデックスはテーブルデータの三割と仮定 : 30パーセント

つまり、オブジェクトレベルでは0.8×0.7=56パーセントとなります。なお、ケースによっては一つのテーブルに10個も20個もインデックスがあるような非常識な?テーブル設計や、10カラム以上につけている複合索引なども例外として考えません。




ここで一旦まとめます。

まずOSレイヤーで10パーセントなので実効容量は0.9

オラクルのファイルレイヤー(物理設計レベル)で10パーセントなので
実効容量は0.81

さらにオブジェクトレベル(論理設計レベル)では56パーセントなので実効容量は0.4536

となります。これに昨日のストレージレイヤーの話と合わせると2TB玉で0.93TBの実効容量なので
0.93×0.45=0.42
となります。

結論としては2TB玉買ったのに400Gちょっとしか使えないってどういうこと?となります(笑)まあ、ここでは話のネタとしてRAID4(NetAppはRAID4+DP)の2TB玉にしましたが、実際にはDBの場合600GBのFC玉でさらにRAID10で組むと思うので、実効容量はもっと下がるでしょうね。

ちなみに、今までSJISで運用していたものをUTFにするとさらに2/3になるので注意が必要です。ここもはまりポイントですね。

でも、実はもっと大きな問題があるんですよ。それは次回記載しようと思います。つづく(笑)
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。