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

<ローカルエクステントマネージメントに関する検証 その2>
ペンネーム ちゃむ
———————————————————————–
8iからの新機能ローカルエクステントマネージメントを以下「LOCAL」と呼ぶ。
従来のデータディクショナリーでエクステントを管理する方法を以下
「DICTIONARY」と呼ぶ。
———————————————————————–

今回は、実際に「LOCAL」がビットマップ管理している様子を見てみよう。
どうすれば、ビットマップ管理している様子を確認することができるのか?
答えは、お決まりのブロックダンプである。

「LOCAL」を作成する(DB_BLOCK_SIZE=2K)

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

作成直後のDBA_FREE_SPACEの様子

TABLESPACE_NAME  FILE_ID  BLOCK_ID  BYTES   BLOCKS
--------------------------------------------------
TBS_U_1          25       33        983040  480

ここまでは、前回の内容であるが、ここでブロックダンプを取得してみよう。
前回の内容からBLOCK_ID=1はデータファイルヘッダーであるが、ブロックダン
プを取得してみるとどうなるであろうか?

ALTER SYSTEM DUMP DATAFILE 25 BLOCK 1;
Start dump data blocks tsn: 36 file#: 25 minblk 1 maxblk 1
Block 1 (file header) not dumped: use dump file header command
End dump data blocks tsn: 36 file#: 25 minblk 2 maxblk 1

一応、エラーなしに出力されるが、use dump file header command
(データファイルヘッダーを取得するコマンドを使ってくれ)
というようなメッセージが読み取れる。

参考までに、データファイルヘッダーを取得するコマンドは、

ALTER SESSION SET EVENTS 'IMMEDIATE TRACE NAME FILE_HDRS LEVEL 10';

である。この結果も、初期化パラメータの user_dump_destにすべてのデータファ
イルヘッダーの情報が出力される。
ちなみに、LEVELの後にくる数字(1~10)は、ダンプ出力をする際の詳細度を
表している(10が最も詳細な情報を出力してくれる)。

前回は、BLOCK=2から31までの間に、ビットマップ情報が存在していると予想し
ていた。ということで、次にBLOCK=2のブロックダンプを取得してみよう。

ALTER SYSTEM DUMP DATAFILE 25 BLOCK 2;
File Space Header Block: 
Header Control: 
RelFno: 25, Unit: 4, Size: 512, Flag: 1 
AutoExtend: NO, Increment: 0, MaxSize: 0 
Initial Area: 31, Tail: 512, First: 0, Free: 120  ←(A) 
Header Opcode: 
Save: No Pending Op 
End dump data blocks tsn: 36 file#: 25 minblk 2 maxblk 2

このFile Space Header Blockとは、いったい何を意味しているのであろうか?
とりあえず無視して、BLOCK=3のブロックダンプを取得してみよう。

ALTER SYSTEM DUMP DATAFILE 25 BLOCK 3;
File Space Bitmap Block: 
BitMap Control: 
RelFno: 25, BeginBlock: 33, Flag: 0, First: 0, Free: 14336 
0000000000000000 0000000000000000 0000000000000000 0000000000000000 
0000000000000000 0000000000000000 0000000000000000 0000000000000000 
0000000000000000 0000000000000000 0000000000000000 0000000000000000 
       :                        :                       :
       :                        :                       :
                            (途中省略)
       :                        :                       :
       :                        :                       :
0000000000000000 0000000000000000 0000000000000000 0000000000000000 
0000000000000000 0000000000000000 0000000000000000 0000000000000000 
End dump data blocks tsn: 36 file#: 25 minblk 3 maxblk 3

でた!デタ!detaー!!!
ビットマップ情報だー!!

上記のように、ビットを用いて空領域および、使用領域の管理をしているのだ。
BLOCK=3からBLOCK=31までは、ご覧のようなビットマップ情報が格納されていた。
先ほど保留にしていたBLOCK=2のFile Space Header Blockとは、これらのビッ
トマップ情報を、さらに統括して管理している領域だと思われる。
その根拠として、BLOCK=2で取得したブロックダンプ中の(A)のところにFree: 120
という記述があるが、これは、総空き容量が「LOCAL UNIFORM SIZE」単位で120
個存在していることを表している。つまり、120 * 8KB = 960KB 分の空き領域
が存在していることを意味しているからである。

もう一つの根拠は、「カン」(通称「オラカン」)である。

以上 自転車の多い 茅ヶ崎にて