ローカルエクステントマネージメントに関する検証 その4

<ローカルエクステントマネージメントに関する検証 その4>
ペンネーム ちゃむ

————————————————————————–
8iからの新機能ローカルエクステントマネージメントを以下「LOCAL」と呼ぶ。
従来のデータディクショナリーでエクステントを管理する方法を以下「DICTIONARY」
と呼ぶ。
————————————————————————–

前回は、「LOCAL」で管理されている領域に対して、実際にオブジェクトを作成
した時の、ビットマップ情報の変化について見てみた。
内容が少し難しいとの意見が多かったので、今回は、同様のことをdb_block_sizeを
とUNIFORM SIZEを変えてもう一度流れを追ってみよう。

今回紹介するすべての検証結果は、DB_BLOCK_SIZE = 8Kで行ったものである。
(前回はDB_BLOCK_SIZE = 2K)

「LOCAL」を作成する

CREATE TABLESPACE tbs_u_1 DATAFILE 'c:tbs_u_1.ora' SIZE 1024K
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 16K;

作成直後のDBA_FREE_SPACEの様子

TABLESPACE_NAME  FILE_ID  BLOCK_ID  BYTES   BLOCKS
--------------------------------------------------
TBS_U_1          10       9         983040  120

ここで、前回との大きな違いは、BLOCK_ID=9からFREE BLOCKが使用可能という
ことである。つまり、前回よりもDB_BLOCK_SIZEが大きくなった分1ブロックに
格納できるビットマップ情報が増えたということである。BLOCK_ID=9というこ
とからビットマップ情報は、BLOCK_ID=3から8までの7ブロック分ということが
わかる。(前回はBLOCK_ID=3から32までの30ブロック分がビットマップ情報)

この状態で、以下のようなテーブルを作成してみよう。
このテーブルは、空領域のすべて(960K(983040))を使い切らせるためのも
のである。

CREATE TABLE tbs_u_1_tbl (col number)
storage (initial 960k next 2k minextents 1 pctincrease 0)
tablespace tbs_u_1;

このときのブロックダンプはどうなるであろうか?

ALTER SYSTEM DUMP DATAFILE 10 BLOCK 3;
File Space Bitmap Block: 
BitMap Control: 
RelFno: 10, BeginBlock: 9, Flag: 0, First: 60, Free: 63428 
FFFFFFFFFFFFFF0F 0000000000000000 0000000000000000 0000000000000000 1行目
0000000000000000 0000000000000000 0000000000000000 0000000000000000 2行目
0000000000000000 0000000000000000 0000000000000000 0000000000000000 3行目
       :                        :                       :
       :                        :                       :
                            (途中省略)
       :                        :                       :
       :                        :                       :
0000000000000000 0000000000000000 0000000000000000 0000000000000000 246行目
0000000000000000 0000000000000000 0000000000000000 0000000000000000 247行目
0000000000000000 0000000000000000 0000000000000000 0000000000000000 248行目
End dump data blocks tsn: 10 file#: 10 minblk 3 maxblk 3

まず、気になるのは「FFFFFFFFFFFFFF0F」の0の位置であるが今回は、あまり気にし
なくてよい。これは次回検証内容とする。

前回と同様上記のダンプの状態を考察してみよう。

1.16進数一桁で表現できる状態の数は4ビットなので「4」通り
(1つのビットで「使用」「未使用」を表している)
2.領域を確保していく単位は、UNIFORM SIZE 16K(2ブロック)
この場合、「2」ブロックを1つの塊(単位)として、1ビットで「使用」
「未使用」を表すことになる
3.上記ダンプ中の F の数 → 「15」個

上記の1、2,3の「」で括られた数字を掛け合わせると、4×2×15=120になる。
これは、始めにテーブルスペースを作成した直後の未使用ブロック数、つまりtbs
_u_1_tblの総使用可能領域と一致する。

ビットマップ管理されている領域の「0000000000000000」の16進数の列は、
8ブロック(16進数一桁で表現できる状態のブロック数)×16( 0 の数)= 128通り
の状態を表現できる。この「0000000000000000」が、1ブロック中に
4(列の数)× 248(行の数)=992 セット存在している。つまり、1ブロックで
992×128=126976ブロック分の「使用」および「未使用」の状態を表現できる計算
になる。

では、前回と同様少し大き目の「LOCAL」を作成してみよう。
以下のテーブルスペース中、8ブロック分はビットマップ管理などに使用され
ることから、実質105600ブロックが未使用領域として確保されるはずである。
1200000K / 8K(ブロック・サイズ) – 8(管理領域) = 149992

CREATE TABLESPACE tbs_u_1_b1 DATAFILE 'd:tbs_u_b1.ora' SIZE 1200000K
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 16K;

作成直後のDBA_FREE_SPACEの様子

TABLESPACE_NAME  FILE_ID  BLOCK_ID  BYTES      BLOCKS
-----------------------------------------------------
TBS_U_1_B1       12       9         1.040E+09  126976
TBS_U_1_B1       12       126985    188547072  23016

これまた予定通りの結果である。
2行表示されているが、「126976」は前回と同様、先ほど計算した1ブロックで
表わせる「使用」および「未使用領域」の数だ。

DB_BLOCK_SIZEが違っても、基本的な考え方はまったく同様であることが分かっていただ
けたであろうか。

以上 烏帽子岩がインターネットでも見える 茅ヶ崎にて
烏帽子岩を見たい方は↓へ
http://www.hi-ho.ne.jp/sugitn/eboshiiwa.htm