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

投稿日: 2000年10月04日

＜ローカルエクステントマネージメントに関する検証　その２＞
ペンネーム　ちゃむ
———————————————————————–
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 分の空き領域
が存在していることを意味しているからである。

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

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