前回で終わったーと思って寝たのですが。
前々回の先頭3ブロックが気になる。。
そして、OS上で1ブロック分領域が多く獲得されているのも気になる。。。
ということで続きます。
何度も書いてますが、役に立つ内容ではないですね。
ローカル管理表領域
ローカル管理表領域では、データファイル・ヘッダー内に、データファイル本体の空き領域および使用済領域を追跡するためのビットマップが保持されています。各ビットは、1ブロック・グループに対応します。領域が割り当てられるか、解放されると、Oracle Databaseでは、ビットマップの値がブロックの新しい状態を反映する値に変更されます。
領域を管理するためのデータ・ディクショナリ表の更新をしなくてよくなったんですよね。
ディクショナリ管理時は、ディクショナリの更新のための再帰SQLの発行や競合による待ち、
redoの生成とか色々な課題があったんですよね。
ローカル管理表領域だと、自分の表領域内で領域の使用状況をビットマップで管理することによって、
エクステントの管理にデータ・ディクショナリを使用する必要がなくったので、
上記のような課題を解消してパフォーマンスがアップしたのでした。
ということで、使えない先頭3ブロックにはビットマップ情報の情報がきっと入ってるんだろうなぁ。。。
・・・KROWNの文書番号：29765に中にちゃんと書いてありますね。。
1ブロック目：データファイルヘッダー。デーファイル毎の1ブロック目
データファイルの管理情報を格納
2ブロック目： ビットマップ・ヘッダ・ブロック。ローカル管理表領域デーファイル毎の
2ブロック目※。ローカル管理するための管理情報を格納
※最初からローカル管理としてデータファイルを作った場合のみ
3ブロック目： ビットマップ・ブロック。ローカル管理表領域デーファイル毎の
3ブロック目移行に1個以上獲得される。
実際の領域管理のためのビットマップ情報を格納。
とすると88KBは、(上記3ブロック+セグメント用8ブロック)×8で88KBか。
96KBとOS上で見えている、残り1ブロック分の領域。
これもKROWNの文書番号：29765に書いてありました。
OS側でのファイル管理用領域なんですね。
以下のSQL文で確認ができます。
SQL> select a.FILE_NAME,b.BLOCK1_OFFSET from dba_data_files a,v$datafile b where a.file_id=b.file# and a.tablespace_name='TEST_EXT';
FILE_NAME BLOCK1_OFFSET
--------------------------------------------- -------------
C:\APP\ORACLE\ORADATA\ORCL\TEST_EXT01.DBF 8192
BLOCK1_OFFSET：ファイルの最初からOracleの共通情報の開始点へのオフセット
確かにデータファイルの8KB以降からOracleの情報が開始されるみたいですね。
ということで、96KBの謎が解けた。
スッキリ！
でも、まだ、ちょっとだけ気になるのでしつこく続けます。
次回：INITIAL_EXTENTと遅延セグメント作成な話4
0 件のコメント:
コメントを投稿