10g中也存在著CACHE物件

對於Oracle獨一無二的cache物件，在Oracle9i中一直是bootstrap$的一個引導block.
通過system表空間資料檔案的File headers可以觀察到cache物件的rdba.
那麼這個特性在Oracle10g也是同樣被延續下來的：

$ sqlplus /nolog

SQL*Plus: Release 10.2.0.3.0 - Production on Sun Mar 23 18:21:57 2008

Copyright (c) 1982, 2006, Oracle.  All Rights Reserved.

SQL> conn / as sysdba;
Connected.
SQL> select comp_name,version from dba_registry;

COMP_NAME
----------------------------------------------------------------------------
VERSION
------------------------------
Oracle XML Database
10.2.0.3.0

Oracle Data Mining
10.2.0.3.0

OLAP Catalog
10.2.0.3.0


COMP_NAME
----------------------------------------------------------------------------
VERSION
------------------------------
Oracle Ultra Search
9.2.0.6.0

Oracle Text
10.2.0.3.0

Spatial
10.2.0.3.0


COMP_NAME
----------------------------------------------------------------------------
VERSION
------------------------------
Oracle interMedia
10.2.0.3.0

Oracle Workspace Manager
10.2.0.1.0

Oracle Database Catalog Views
10.2.0.3.0


COMP_NAME
----------------------------------------------------------------------------
VERSION
------------------------------
Oracle Database Packages and Types
10.2.0.3.0

JServer JAVA Virtual Machine
10.2.0.3.0

Oracle XDK
10.2.0.3.0


COMP_NAME
----------------------------------------------------------------------------
VERSION
------------------------------
Oracle Database Java Packages
10.2.0.3.0

OLAP Analytic Workspace
10.2.0.3.0

Oracle OLAP API
10.2.0.3.0

SQL> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bi
PL/SQL Release 10.2.0.3.0 - Production
CORE    10.2.0.3.0      Production
TNS for IBM/AIX RISC System/6000: Version 10.2.0.3.0 - Productio
NLSRTL Version 10.2.0.3.0 - Production

現在轉儲一下system表空間的檔案頭:
SQL>alter session set events 'immediate trace name file_hdrs level 10'
找到其中部分內容
 V10 STYLE. FILE HEADER:
        Software vsn=153092096=0x9200000, Compatibility Vsn=134217728=0x8000000
        Db ID=3056348506=0xb62c2d5a, Db Name='IRMDB'
        Activation ID=0=0x0
        Control Seq=2151=0x867, File size=79360=0x13600
        File Number=1, Blksiz=8192, File Type=3 DATA
Tablespace #0 - SYSTEM  rel_fn:1
Creation   at   scn: 0x0000.0000000a 05/13/2002 02:16:30
Backup taken at scn: 0x0000.00000000 01/01/1988 00:00:00 thread:0
 reset logs count:0x25acbede scn: 0x0000.0002b85d reset logs terminal rcv data:0x0 scn: 0x0000.00000000
 prev reset logs count:0x1b856fc9 scn: 0x0000.00000001 prev reset logs terminal rcv data:0x0 scn: 0x0000.00000000
 recovered at 03/23/2008 14:56:50
 status:0x4 root dba:0x004001a1 chkpt cnt: 615 ctl cnt:614
begin-hot-backup file size: 0
Checkpointed at scn:  0x0000.052d9d31 03/23/2008 17:06:54
 thread:1 rba:(0x189.173b.10)
 enabled  threads:  01000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000

看到這裡有一個很重要的root dba:0x004001a1，通過root dba可以快速定位到bootstrap$的位置從而可以進一步通過recursive的SQL來在記憶體中建立物件從而來引導資料庫的open.
分解這個root dba發現指向的是CACHE物件。
SQL> select dbms_utility.data_block_address_file(to_number('4001a1','xxxxxx')) file#,
  2         dbms_utility.data_block_address_block(to_number('4001a1','xxxxxx')) block#
  3  from dual;

     FILE#     BLOCK#
---------- ----------
         1        417

SQL> select segment_name,header_file,header_block from dba_segments
  2  where segment_type='CACHE';

SEGMENT_NAME
--------------------------------------------------------------------------------
HEADER_FILE HEADER_BLOCK
----------- ------------
1.417
          1          417

轉儲這個block
SQL> alter system dump datafile 1 block 417;

System altered.

......
Compatibility entry for 'COMPATSG':
   Size: 24  Release 0x134217728  By 0x153092096
Dump of memory from 0x0000000110416034 to 0x0000000110416038
110416030          00000000                        [....]
Compatibility entry for 'BOOTSTRP':
   Size: 24  Release 0x134217728  By 0x153092096
Dump of memory from 0x000000011041604C to 0x0000000110416050
110416040                            00400179              [.@.y]
Compatibility entry for 'UNDODATA':
   Size: 36  Release 0x153092096  By 0x153092096
Dump of memory from 0x0000000110416064 to 0x0000000110416074
110416060          00000053 00435870 05246BAE      [...S.CXp.$k.]
110416070 00003BC8                             [..;.]
......
發現00400179這個dba就是指向bootstrap$

通過上面的方法也不難得出bootstrap$位於資料檔案1的第377個block
大體上就是這樣。

因此可以得出一個結論在open database時，首先需要通過直接路徑讀取system表空間的root dba，進而通過單塊讀來獲得datafile 1 block 417，並通過417塊找到377這個bootstrap$的段頭進而讀取其中的內容，在記憶體中建立資料物件.所以我們可以看到System表空間中的資料檔案是非常的重要。平時要做好備份，否則一旦損壞將很難恢復。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/12361284/viewspace-216926/，如需轉載，請註明出處，否則將追究法律責任。