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

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

————————————————————————–
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の位置であるが今回は、あまり気にし
なくてよい。これは次回検証内容とする。

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

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

上記の１、２，３の「」で括られた数字を掛け合わせると、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

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

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