在學習段（segment）、區間（extent）時，對段的HEADER_BLOCK有一些疑問，本文記錄一下探究的實驗過程以及相關總結，，如有不對的地方，敬請指出。以SCOTT.EMP表為例（下麵測試環境為Oracle Database 10g Release 10.2.0.5.0 - 64bit P... ...
在學習段（segment）、區間（extent）時，對段的HEADER_BLOCK有一些疑問，本文記錄一下探究的實驗過程以及相關總結，，如有不對的地方，敬請指出。以SCOTT.EMP表為例（下麵測試環境為Oracle Database 10g Release 10.2.0.5.0 - 64bit Production）：
SELECT FILE_ID, BLOCK_ID,
BLOCKS
FROM DBA_EXTENTS WHERE OWNER ='&OWNER'
AND SEGMENT_NAME = '&TABLE_NAME';
SELECT HEADER_FILE, HEADER_BLOCK
, BYTES
, BLOCKS
, EXTENTS
FROM DBA_SEGMENTS WHERE OWNER='&OWNER' AND SEGMENT_NAME='&SEGMENT_NAME';
如上所示，DBA_SEGMENTS 中的HEADER_BLOCK 與DBA_EXTENTS的BLOCK_ID不同（HEADER_BLOCK：文件ID為4的第27個塊，區間的第一個塊的BLOCK_ID為第25個塊），這個的原因如下：
一個segment的第一個區的第一個塊是FIRST LEVEL BITMAP BLOCK，第二個塊是SECOND LEVEL BITMAP BLOCK，這兩個塊是用來管理free block的，第三個塊是PAGETABLE SEGMENT HEADER，這個塊才是segment里的HEADER_BLOCK，再後面的塊就是用來記錄數據的。所以25+2=27. 詳細可以參考《循序漸進ORCLE:資料庫管理、優化與備份》這本書的第5章。
下麵我們創建一個表，測試一下是否也是這個規律，如下所示：
SQL> CREATE TABLE TEST1.MMM
2 AS3 SELECT * FROM DBA_OBJECTS;
Table created.SQL> COL SEGMENT_NAME FOR A32;
SQL> SELECT SEGMENT_NAME
2 ,FILE_ID
3 ,BLOCK_ID
4 ,BLOCKS
5 FROM DBA_EXTENTS 6 WHERE SEGMENT_NAME='MMM' AND OWNER='TEST1'
7 ORDER BY BLOCK_ID ASC;
SEGMENT_NAME FILE_ID BLOCK_ID BLOCKS
-------------------------------- ---------- ---------- ----------MMM 76 9 8MMM 76 17 8
MMM 76 25 8
MMM 76 33 8
MMM 76 41 8
MMM 76 49 8
MMM 76 57 8
MMM 76 65 8
MMM 76 73 8
MMM 76 81 8
MMM 76 89 8
SEGMENT_NAME FILE_ID BLOCK_ID BLOCKS
-------------------------------- ---------- ---------- ----------MMM 76 97 8MMM 76 105 8
MMM 76 113 8
MMM 76 121 8
MMM 76 129 8
MMM 76 137 128
MMM 76 265 128
MMM 76 393 128
MMM 76 521 128
MMM 76 649 128
MMM 76 777 128
22 rows selected.SQL> SELECT HEADER_FILE
2 , HEADER_BLOCK
3 , BYTES
4 , BLOCKS
5 , EXTENTS
6 FROM DBA_SEGMENTS 7 WHERE OWNER='TEST1' AND SEGMENT_NAME='MMM';
HEADER_FILE HEADER_BLOCK BYTES BLOCKS EXTENTS
----------- ------------ ---------- ---------- ----------
76 11 7340032 896 22
如上所示，段對象TEST1.MMM的header_block為11 ，而對應的區間的第一個塊對象ID為9， 也是9+2=11，確實是如此，那麼我們來DUMP數據塊看看，如下所示
SQL> alter system dump datafile 76 block 9;
System altered.
SQL> alter system dump datafile 76 block 10;
System altered.
SQL> alter system dump datafile 76 block 11;
System altered.
SQL> select user_dump.value
2 || '/' 3 || lower(instance.value)
4 || '_ora_' 5 || v$process.spid
6 || nvl2(v$process.traceid, '_' 7 || v$process.traceid, null) 8 || '.trc'"trace file"
9 from v$parameter user_dump
10 cross join v$parameter instance
11 cross join v$process
12 join v$session
13 on v$process.addr = v$session.paddr
14 where user_dump.name = 'user_dump_dest'
15 and instance.name = 'instance_name'
16 and v$session.audsid = sys_context('userenv', 'sessionid');
trace file--------------------------------------------------------------------------------
/u01/app/oracle/admin/SCM2/udump/scm2_ora_22642.trc
第一個區的第一個塊（block_id=9)是FIRST LEVEL BITMAP BLOCK，第二個塊(block_id=10)是SECOND LEVEL BITMAP BLOCK，這兩個塊是用來管理free block的，第三個塊(block_id=11)是PAGETABLE SEGMENT HEADER，這個塊才是segment里的HEADER_BLOCK，再後面的塊就是用來記錄數據的
不過有一個奇怪的現象，對SCOTT.EMP其數據塊做dump，發現25、26、27數據塊的type都是trans data，0x06表示的Block Type為 Table/cluster/index segment data block 。 不知是否因為SCOTT.EMP對象位於USERS表空間下的緣故。不過USER表空間也是ASSM管理的。具體情況尚不清楚？
