ローカルエクステントマネージメントに関する検証 その１
＜ローカルエクステントマネージメントに関する検証 その１＞
ペンネーム ちゃむ
お久しぶりです。約4ヶ月ぶりに復帰します。よろしくお願いします。
今回からローカルエクステントマネージメント(以下「LOCAL」)に関して検証
を行なう。この、「LOCAL」は8iからの機能であるが、いろいろ検証を行なっ
た結果、「かなりいけてる」機能であることが分かった。
まだ、あまり書籍などでも紹介が少ない内容であるが、いち早く皆さんにお伝え
しよう。
「LOCAL」の概要を話すと、従来のようにデータディクショナリーでエクステント
を管理せず、データファイルの中のある領域の割り当て、解放を示す 0 or 1 の
ビットマップを確保し、領域管理する新しいアーキテクチャーである。
従来のデータディクショナリーでエクステントを管理する方法を以下
「DICTIONARY」と呼ぶ。
まずは、「LOCAL」を実際に作成するSQL文から紹介する。（DB_BLOCK_SIZE=2K）
CREATE TABLESPACE tbs_u_1 DATAFILE 'c:tbs_u_1.ora' SIZE 1024k EXTENT MANAGEMENT LOCAL UNIFORM SIZE 8K; CREATE TABLESPACE tbs_a_1 DATAFILE 'c:tbs_a_1.ora' SIZE 1024k EXTENT MANAGEMENT LOCAL AUTOALLOCATE;
後ほど、比較に使うので「DICTIONARY」のテーブルスペースも作っておく。
CREATE TABLESPACE tbs_d_1 DATAFILE 'c:tbs_d_1.ora' SIZE 1024k;
UNIFORM SIZEオプションを指定すると明示的にエクステントサイズを指定でき、
AUTOALLOCATEを指定すると、ORACLEが自動的に最適なエクステントサイズを
割り出してくれる。
AUTOALLOCATEの最小エクステントサイズは64kである。
この明示的に指定したエクステントサイズまたは、SYSTEMが自動的に指定する
エクステントサイズとは実際どのようなものなのだろうか？
以下のように、UNIFORM SIZE 8Kのtbs_u_1テーブルスペースにテーブルを作成
してみよう。
CREATE TABLE tbs_u_1_tbl (col number) storage (initial 2k next 2k minextents 10 pctincrease 0) tablespace tbs_u_1;
定義的には、2kのエクステント10個分の領域20Kを確保してくれという意味で
ある。これを実行すると以下のようなエクステントの割当てになる。
(DBA_EXTENTSより）
SEGMENT_NAME TABLESPACE_NAME EXTENT_ID BLOCK_ID BYTES BLOCKS ----------------------------------------------------------------- TBS_U_1_TBL TBS_U_1 0 33 8192 4 TBS_U_1_TBL TBS_U_1 1 37 8192 4 TBS_U_1_TBL TBS_U_1 2 41 8192 4
「20K確保してくれ」という命令を8Kで丸めて（8kの倍数で）24kとして、その
サイズ24kを確保する動きになる。minextents 10なので10×8k=80k確保すると
勘違いしそうであるが、結果は、定義上の総サイズをUNIFORM SIZEで丸めた分
だけ確保する動きとなった。これで、UNIFORM SIZEのイメージはつかめたであ
ろう。同様にAUTOALLOCATEで指定した場合も、SYSTEMが自動的に指定したサイ
ズ（例えば64kなど）で丸められて同様にエクステントが確保される。
以下は上記のテーブルスペース作成直後の、DBA_FREE_SPACEビューの様子である。
(テーブルなどを作成する前の状態)
TABLESPACE_NAME BLOCK_ID BYTES BLOCKS ------------------------------------------ TBS_D_1 2 1046528 511 TBS_A_1 33 983040 480 TBS_U_1 33 983040 480
ここで、まず気がつくのは、「LOCAL」ではフリーブロック数が480ということ
である。「DICTIONARY」であれば、SIZE 1024kで作成すれば、ヘッダー情報1ブ
ロックを差し引いた「指定サイズ-1ブロック」の511ブロックのフリーブロック
ができる。しかし、上記では、480ブロックのフリーブロックしかない。つまり、
テーブルスペースのヘッダー情報に32ブロックもの領域を必要としたことになる。
そのうち１ブロックはデータファイルヘッダーであるから、上記の場合31ブロッ
クを空領域と使用領域理を管理するビットマップ情報で管理していると予想され
る。
テーブルスペースが「LOCAL」か「DICTIONARY」はDBA_TABLESPACESで確認できる。
SELECT TABLESPACE_NAME,EXTENT_MANAGEMENT,ALLOCATION_TYPE FROM DBA_TABLESPACES; TABLESPACE_NAME EXTENT_MANAGEMENT ALLOCATION_TYPE --------------------------------------------------- TBS_A_1 LOCAL SYSTEM TBS_D_1 DICTIONARY USER TBS_U_1 LOCAL UNIFORM
EXTENT_MANAGEMENT列により「LOCAL」か「DICTIONARY」かわかる。
また、ALLOCATION_TYPE列からは「LOCAL」の場合、「UNIFORM」指定かSYSTEM
で自動的に割り当て単位の判断を行なう「AUTOALLOCATE」かを判断できる。
次回は、実際に「LOCAL」がビットマップ管理している様子を見てみよう。
以上 私のふるさと 茅ヶ崎にて