テーブルの容量はDBA_SEGMENTS.BYTESに格納されているので、
SEGMENT_NAMEにテーブル名を与えればゲットすることが出来る
SELECT SEGMENT_NAME,BYTES
FROM DBA_SEGMENTS
WHERE SEGMENT_NAME = :TAB_NAME
BYTESは単位が本当に「バイト」なので、
キロバイトにするなら÷1024
メガバイトにするなら÷(1024^2)
ギガバイトにするなら÷(1024^3)
をする必要がある。
取得してきた後にEXCELとか電卓とかで計算してもいいけど
面倒な場合は取得するときに割ればよい。
SELECT SEGMENT_NAME ,BYTES ,BYTES/1024 K_BYTES ,BYTES/1024/1024 M_BYTES ,BYTES/1024/1024/1024 G_BYTES FROM DBA_SEGMENTS WHERE SEGMENT_NAME = :TAB_NAME
なお、パーティション表の場合は、
SEGMENT_NAMEがテーブル名
PARTITION_NAMEがパーティション名になり、
単にSEGMENT_NAMEだけ与えただけではパーティションの数だけ結果が返ってくる。
SELECT項目にPARTITION_NAMEを加えた方が良い。
続きがあります
大体これで大まかな容量は把握できるのだが、
この容量はOracleのデータブロック数から計算された容量である（らしい）ため
最大でも１データブロックサイズ分、実体値とは異なる可能性がある。
（つまり、領域として確保してはいるが、実際には使っていない領域があり、
DBA_SEGMENTS.BYTESはその領域も含めている）
実際の容量を把握するならデータ内容から計算すればよいのだが、
テーブルの全項目のlengthbとってsumする必要があるので、
テーブル全レコードを総舐めすることになり、
レコード件数が多いとそれなりの時間がかかる。
テーブル全体のデータ量調査（lengthbをsum）するためのSQL生成.sql
このSQLにテーブル名をあたえてかえってきた内容をコピーして、
先頭に"SELECT"と、最後尾に"FROM [テーブル名]"をつければ
そのままSQLとして使える。
中身といえば、USER_TAB_COLUMNSにテーブル名をあてて、
各項目をlengthbで繋いだ文字を生成しているだけだ。
今見るとかなり無理矢理な方法だ。
ここまでして実体値を取得するのは
労力に見合った報酬にはならないと今にして自分でも思う。
バックグラウンドでぶん投げて翌朝見るとかならまだ使えそうだけど、
運用中じゃ軽々しく出来ないし。
こんなん作るとは俺も暇な時期があったんだな。
要するに、基本的にはDBA_SEGMENTSでなんとなく値を把握するだけで良いだろう。
どうしても気になるならexpして実際に吐いてみたほうが多分早いｗ
ちなみに、巨大なテーブルに関しては、
検索速度向上のために得てしてINDEXが付与されていることが多く、
「テーブル」そのもののデータ容量はもとより
INDEXの容量も馬鹿に出来ないことになっていたりするものだ。
こちらも基本はDBA_SEGMENTSで検索できる（SEGMENT_NAMEにINDEX名をいれるだけ）が
テーブルの容量を含めて一発で取得する方法をよく知らない。
副問い合わせとか駆使すればできそうだが面倒なのでやってない。
わかったら追記しよう。
