摘自--http://blog.csdn.net/tianlesoftware?viewmode=contents

一. X$表說明

之前整理了一篇有關動態效能檢視的blog：

Oracle 動態效能檢視

http://blog.csdn.net/tianlesoftware/article/details/5863191

Oracle 引數分類和引數的檢視方法

http://blog.csdn.net/tianlesoftware/article/details/5583655

The fixed X$tables are no real tables; you will not find them in any database schema. Thesevirtual tables provide a SQL interface to Oracle memory structures; that is,you can retrieve (real-time) information from memory structures using SQLqueries.

X$表包含了特定例項的各方面的資訊，X$表在oracle的不同版本里很可能是不一樣的，是Oracle資料庫的執行基礎，如當前的配置資訊，連線到例項的會話，以及豐富而有價值的效能資訊。 X$表並不是駐留在資料庫檔案的永久表或臨時表。

X$表僅僅駐留在記憶體中，當例項啟動時，由Oracle應用程式動態建立，在記憶體中進行實時的維護。它們中的大多數至少需要裝載或已經開啟的資料庫。X$表為SYS使用者所擁有，並且是隻讀的。不能進行DML(更新，插入，刪除)。X$表對資料庫來說至關重要，所以Oracle不允許SYSDBA之外的使用者直接訪問，顯示授權不被允許。

可以從v$fixed_table中查到X$：

SQL> select * from v$version;

BANNER

----------------------------------------------------------------

Oracle Database 10g Enterprise EditionRelease 10.2.0.5.0 - Prod

PL/SQL Release 10.2.0.5.0 - Production

CORE 10.2.0.5.0 Production

TNS for Linux: Version 10.2.0.5.0 -Production

NLSRTL Version 10.2.0.5.0 - Production

SQL> select count(*) from v$fixed_tablewhere name like 'X$%';

COUNT(*)

----------

620

以上是Oracle10.2.0.5 版本里的x$表的數量，在Oracle 11g裡又有大幅增加：

SQL> select count(*) fromv$fixed_table where name like 'X$%';

COUNT(*)

----------

945

關於X$表，其建立資訊我們也可以透過bootstrap$表檢視，該表中記錄了資料庫啟動的基本及驅動資訊。bootstrap$ 實際上儲存的是資料字典的基表的定義，如OBJ$,C_OBJ$,TAB$等等。Oracle透過讀取這些定義建立資料字典的基表，進而建立資料字典。有關bootstrap$會另篇說明。

SQL> select * from bootstrap$;

二.Oracle10g X$KCVFH說明

X$KCVFH是GV$DATAFILE_HEADER的內部檢視，不同版本的Oracle，X$KCVFH 的結構可能不同，如下說明基於Oracle 10gR2版本。這部分工作是dbsnake 做的，直接摘取自dbsnake的blog。

2.1 字典結構及含義

SQL> desc x$kcvfh

相關欄位的描述：

Column Name Data Type Description

ADDR RAW(4) ADDRESS

INDX NUMBER INDEX

INST_ID NUMBER INSTANCE ID

HXFIL NUMBER FILE#，Datafile number (from control file)

HXONS NUMBER ONLINE | OFFLINE (from control file),HXONS為 0表示'OFFLINE',為其他值表示 'ONLINE'

HXSTS VARCHAR2(16)

HXERR NUMBER ERROR，decode(HXERR, 0, NULL,

1,'FILE MISSING',

2,'OFFLINE NORMAL',

3,'NOT VERIFIED',

4,'FILE NOT FOUND',

5,'CANNOT OPEN FILE',

6,'CANNOT READ HEADER',

7,'CORRUPT HEADER',

8,'WRONG FILE TYPE',

9,'WRONG DATABASE',

10,'WRONG FILE NUMBER',

11,'WRONG FILE CREATE',

12,'WRONG FILE CREATE',

16,'DELAYED OPEN',

14,'WRONG RESETLOGS',

15,'OLD CONTROLFILE',

'UNKNOWN ERROR')

HXVER NUMBER FORMAT，Indicates the format for the header block. The possible values are 6, 7, 8, or 0.

6 - indicates Oracle Version 6；

7 - indicates Oracle Version 7；

8 - indicates Oracle Version 8；

0 - indicates the format could not be determined (for example, the header could not be read)

FHSWV NUMBER

FHCVN NUMBER Compatibility Vsn

FHDBI NUMBER DBID

FHDBN VARCHAR2(9) DB NAME

FHCSQ NUMBER controlfile sequence number

FHFSZ NUMBER BLOCKS, Current datafile size in blocks

FHBSZ NUMBER datafile block size

FHFNO NUMBER Tablespace datafile number

FHTYP NUMBER Type:

1 control file

2 redo log file

3 vanilla db file; that is, normal data, index, and undo blocks

4 backup control file

5 backup piece

6 temporary db file

FHRDB NUMBER Root dba: This field only occurs in data file #1, and is the location of blocks required during bootstrapping the data dictionary (bootstrap$)

FHCRS VARCHAR2(16) CREATION_CHANGE#，Datafile creation change#

FHCRT VARCHAR2(20) CREATION_TIME，Datafile creation timestamp

FHRLC VARCHAR2(20) RESETLOGS_TIME, Resetlogs timestamp

FHRLC_I NUMBER reset logs count

FHRLS VARCHAR2(16) RESETLOGS_CHANGE#, Resetlogs change#

FHPRC VARCHAR2(20) prev reset logs timestamp

FHPRC_I NUMBER prev reset logs count

FHPRS VARCHAR2(16) prev reset logs SCN

FHBTI VARCHAR2(20) Time the backup started, Updated when executing BEGIN BACKUP on the tablespace. RMAN does not update this field.

FHBSC VARCHAR2(16) System change number when backup started, Updated when executing BEGIN BACKUP on the tablespace. RMAN does not update this field.

FHBTH NUMBER Thread when when backup started, Updated when executing BEGIN BACKUP on the tablespace. RMAN does not update this field.

FHSTA NUMBER The value for the column X$KCVFH.FHSTA (file header status) for an open database with an online datafiles in versions prior to version 10 were all 4, indicating an online fuzzy status. With version 10 of Oracle the first system tablespace datafile will have a different status of 8196 if the datafile is online and the database is open and not in backup mode. In Oracle 10g, the X$KCVFH.FHSTA column will show 8196 for system data file if COMPATIBLE is set to 10.0.0.0 or higher. The value of 8196 is a value of 0x04, as in previous releases, plus an AND'd value of 0x2000 (8192) for internal uses. If COMPATIBLE is set to 9.2.0 (lowest possible value for Oracle 10g), the FHSTA column for system datafile will have a value of 4.

In Oracle10g, the COMPATIBLE value is irreversible if advanced to a higher value. So the value of 8196 for the fhsta (status) column for the first system tablespace datafile is normal.

FHSCN VARCHAR2(16) CHECKPOINT_CHANGE#, Datafile checkpoint change#,Updated on every checkpoint, but not when in Hot backup state (not online backups). This must remain untouched when you are in hot backup mode, because you might get checkpoints between the BEGIN BACKUP and when you actually start the copying process.

FHTIM VARCHAR2(20) CHECKPOINT_TIME, Datafile checkpoint timestamp

FHTHR NUMBER THREAD#

FHRBA_SEQ NUMBER SEQUENCE，即Redo log sequence number

FHRBA_BNO NUMBER Block number，即the redo log file block number

FHRBA_BOF NUMBER Byte offset，the byte offset into the block at which the redo record starts

FHETB RAW(132) enable threads byte(這個不確定)

FHCPC NUMBER CHECKPOINT_COUNT, Datafile checkpoint count

FHRTS VARCHAR2(20) Recoverd timestamp

FHCCC NUMBER Controlfile Checkpoint Count: Saved copy of the control file record of the checkpoint count. Helps detect old control files.

FHBCP_SCN VARCHAR2(16) Backup Checkpoint SCN: Updated with the checkpoint done while file in Hot backup

FHBCP_TIM VARCHAR2(20) Backup Checkpoint TIME: Updated with the checkpoint done while file in Hot backup

FHBCP_THR NUMBER Backup Checkpoint Thread: Updated with the checkpoint done while file in Hot backup

FHBCP_RBA_ SEQ NUMBER Backup Checkpoint Sequence, 即Redo log sequence number: Updated with the checkpoint done while file in Hot backup

FHBCP_RBA_ BNO NUMBER the redo log file block number, Updated with the checkpoint done while file in Hot backup

FHBCP_RBA_ BOF NUMBER Byte offset，the byte offset into the block at which the redo record starts, Updated with the checkpoint done while file in Hot backup

FHBCP_ETB RAW(132) enable threads byte(不確定)

FHBHZ NUMBER begin hot backup file size

FHXCD RAW(16) External cache id: Used to ensure that concurrent instances access data through consistent external cache

FHTSN NUMBER TS#，Tablespace number

FHTNM VARCHAR2(30) TABLESPACE_NAME, Tablespace name

FHRFN NUMBER RFILE#, Tablespace relative datafile number

FHAFS VARCHAR2(16) absolute fuzzy scn, 即Minimum PITR SCN

FHRFS VARCHAR2(16) The SCN at which the recovery of this file will be complete (no longer fuzzy). Both above fuzzy SCNs must be zero unless a fuzzy flag is set, and must be greater than the checkpoint SCN

FHRFT VARCHAR2(20) The time at which the recovery of this file will be complete (no longer fuzzy).

HXIFZ NUMBER File is fuzzy (YES | NO)，decode(hxifz, 0,'NO', 1,'YES', NULL)

HXNRCV NUMBER File needs media recovery (YES | NO)，decode(hxnrcv, 0,'NO', 1,'YES', NULL)

HXFNM VARCHAR2(513) NAME, Datafile name

FHPOFB NUMBER

FHPNFB NUMBER

FHPRE10 NUMBER

FHFIRSTUNRECSCN VARCHAR2(16) UNRECOVERABLE_CHANGE#, Last unrecoverable change number made to this datafile. If the database is in ARCHIVELOG mode, then this column is updated when an unrecoverable operation completes. If the database is not in ARCHIVELOG mode, this column does not get updated.

FHFIRSTUNRECTIME VARCHAR2(20) UNRECOVERABLE_TIME, Timestamp of the last unrecoverable change. This column is updated only if the database is in ARCHIVELOG mode.

HXLMDBA NUMBER SPACE_HEADER, The amount of space currently being used and the amount that is free, as identified in the space header. decode(hxlmdba, 0, NULL, hxlmdba)

HXLMLD_SCN VARCHAR2(16) LAST_DEALLOC_SCN, Last deallocated SCN

2.2 X$KCVFH的常見用法

2.2.1 判斷datafile是否需要recover，如果需要recover，那麼需要至少需要recover到什麼SCN，即執行如下查詢：

SQL> select max(fhafs) from x$kcvfh;

MAX(FHAFS)

----------------

0

如果返回返回結果大於0，則表示資料庫處於不一致的狀態，需要recover到上述查詢結果中的SCN。

2.2.2 判斷datafile做recover需要的archive log的sequence是多少，也就是說做recover到這個sequence，那麼control file和datafile header中的記錄就一致了。

即執行如下查詢：

SQL> select HXFILFile_num,substr(HXFNM,1,45) File_name, FHSCN SCN,FHRBA_SEQ Sequence fromX$KCVFH;

FILE_NUM FILE_NAME SCN SEQUENCE

---------- ------------------------------------------------------- ----------

1 /u01/app/oracle/oradata/anqing/system01.dbf 1329249 69

2 /u01/app/oracle/oradata/anqing/undotbs01.dbf 1329249 69

3 /u01/app/oracle/oradata/anqing/sysaux01.dbf 1329249 69

4 /u01/app/oracle/oradata/anqing/users01.dbf 1329249 69

5 /u01/app/oracle/oradata/anqing/example01.dbf 1329249 69

三. X$KCVFH 的出處

在第二節列出了x$kcvfh 大部分欄位的含義。這個含義也是dbsnake 自己推出來的。具體的方法就是將file #1 的datafile header（第一個block） dump 出來，然後用其值與DATA FILE #1在x$kcvfh中的內容值進行比較，這個一步是dbsnake 用自己的一個過程來實現的，我不知道其具體內容，但是透過BBED 可以看出對應的值。也可以進行一個比較。

至於為什麼x$kcvfh的內容放在file #1裡，這個是Oracle 的規定。

3.1 使用BBED檢視kcvfh 內容

Oracle BBED 工具說明

http://blog.csdn.net/tianlesoftware/article/details/5006580

Oracle bbed 五個實用示例

http://blog.csdn.net/tianlesoftware/article/details/6684505

先檢視一個File #1 對應的表空間，是system：

SQL> select file_id,file_name fromdba_data_files;

FILE_ID FILE_NAME

-------------------------------------------------------

4 /u01/app/oracle/oradata/anqing/users01.dbf

3 /u01/app/oracle/oradata/anqing/sysaux01.dbf

2 /u01/app/oracle/oradata/anqing/undotbs01.dbf

1 /u01/app/oracle/oradata/anqing/system01.dbf

5 /u01/app/oracle/oradata/anqing/example01.dbf

用BBED 工具檢視一下File #1 中kcvfh 的內容和對應的值：

dave:/u01> cat filelist.txt

1/u01/app/oracle/oradata/anqing/system01.dbf

dave:/u01> cat bbed.par

blocksize=8192

listfile=/u01/filelist.txt

mode=edit

dave:/u01> bbed parfile=/u01/bbed.par

Password:

BBED: Release 2.0.0.0.0 - LimitedProduction on Sun Oct 30 15:51:16 2011

************* !!! For Oracle Internal Useonly !!! ***************

BBED> show

FILE# 1

BLOCK# 1

OFFSET 0

DBA 0x00400001(4194305 1,1)

FILENAME /u01/app/oracle/oradata/anqing/system01.dbf

BIFILE bifile.bbd

LISTFILE /u01/filelist.txt

BLOCKSIZE 8192

MODE Edit

EDIT Unrecoverable

IBASE Dec

OBASE Dec

WIDTH 80

COUNT 512

LOGFILE log.bbd

SPOOL No

BBED> p kcvfh

struct kcvfh, 676 bytes @0

struct kcvfhbfh, 20 bytes @0

ub1 type_kcbh @0 0x0b

ub1 frmt_kcbh @1 0xa2

ub1 spare1_kcbh @2 0x00

ub1 spare2_kcbh @3 0x00

ub4 rdba_kcbh @4 0x00400001

ub4 bas_kcbh @8 0x00000000

ub2 wrp_kcbh @12 0x0000

ub1 seq_kcbh @14 0x01

ub1 flg_kcbh @15 0x04 (KCBHFCKV)

ub2 chkval_kcbh @16 0x9614

ub2 spare3_kcbh @18 0x0000

struct kcvfhhdr, 76 bytes @20

ub4 kccfhswv @20 0x00000000

ub4 kccfhcvn @24 0x0a200100

ub4 kccfhdbi @28 0x296d43c7

text kccfhdbn[0] @32 A

text kccfhdbn[1] @33 N

text kccfhdbn[2] @34 Q

text kccfhdbn[3] @35 I

text kccfhdbn[4] @36 N

text kccfhdbn[5] @37 G

text kccfhdbn[6] @38

text kccfhdbn[7] @39

ub4 kccfhcsq @40 0x00000402

ub4 kccfhfsz @44 0x0000fa00

s_blkz kccfhbsz @48 0x00

ub2 kccfhfno @52 0x0001

ub2 kccfhtyp @54 0x0003

ub4 kccfhacid @56 0x00000000

ub4 kccfhcks @60 0x00000000

text kccfhtag[0] @64

………..

text kccfhtag[31] @95

ub4 kcvfhrdb @96 0x00400179

struct kcvfhcrs, 8 bytes @100

ub4 kscnbas @100 0x00000009

ub2 kscnwrp @104 0x0000

ub4 kcvfhcrt @108 0x2184ef93

ub4 kcvfhrlc @112 0x2d8b028b

struct kcvfhrls, 8 bytes @116

ub4 kscnbas @116 0x0006ce7b

ub2 kscnwrp @120 0x0000

ub4 kcvfhbti @124 0x00000000

struct kcvfhbsc, 8 bytes @128

ub4 kscnbas @128 0x00000000

ub2 kscnwrp @132 0x0000

ub2 kcvfhbth @136 0x0000

ub2 kcvfhsta @138 0x2004 (KCVFHOFZ)

struct kcvfhckp, 36 bytes @484

struct kcvcpscn, 8 bytes @484

ub4 kscnbas @484 0x00144861

ub2 kscnwrp @488 0x0000

ub4 kcvcptim @492 0x2da69134

ub2 kcvcpthr @496 0x0001

union u, 12 bytes @500

struct kcvcprba, 12 bytes @500

ub4 kcrbaseq @500 0x00000045

ub4 kcrbabno @504 0x00000002

ub2 kcrbabof @508 0x0010

ub1 kcvcpetb[0] @512 0x02

……

ub1 kcvcpetb[7] @519 0x00

ub4 kcvfhcpc @140 0x00000089

ub4 kcvfhrts @144 0x2da69133

ub4 kcvfhccc @148 0x00000088

struct kcvfhbcp, 36 bytes @152

struct kcvcpscn, 8 bytes @152

ub4 kscnbas @152 0x00000000

ub2 kscnwrp @156 0x0000

ub4 kcvcptim @160 0x00000000

ub2 kcvcpthr @164 0x0000

union u, 12 bytes @168

struct kcvcprba, 12 bytes @168

ub4 kcrbaseq @168 0x00000000

ub4 kcrbabno @172 0x00000000

ub2 kcrbabof @176 0x0000

ub1 kcvcpetb[0] @180 0x00

……

ub1 kcvcpetb[7] @187 0x00

ub4 kcvfhbhz @312 0x00000000

struct kcvfhxcd, 16 bytes @316

ub4 space_kcvmxcd[0] @316 0x00000000

ub4 space_kcvmxcd[1] @320 0x00000000

ub4 space_kcvmxcd[2] @324 0x00000000

ub4 space_kcvmxcd[3] @328 0x00000000

word kcvfhtsn @332 0

ub2 kcvfhtln @336 0x0006

text kcvfhtnm[0] @338 S

……

text kcvfhtnm[29] @367

ub4 kcvfhrfn @368 0x00000001

struct kcvfhrfs, 8 bytes @372

ub4 kscnbas @372 0x00000000

ub2 kscnwrp @376 0x0000

ub4 kcvfhrft @380 0x00000000

struct kcvfhafs, 8 bytes @384

ub4 kscnbas @384 0x00000000

ub2 kscnwrp @388 0x0000

ub4 kcvfhbbc @392 0x00000000

ub4 kcvfhncb @396 0x00000000

ub4 kcvfhmcb @400 0x00000000

ub4 kcvfhlcb @404 0x00000000

ub4 kcvfhbcs @408 0x00000000

ub2 kcvfhofb @412 0x000a

ub2 kcvfhnfb @414 0x000a

ub4 kcvfhprc @416 0x2184ef74

struct kcvfhprs, 8 bytes @420

ub4 kscnbas @420 0x00000001

ub2 kscnwrp @424 0x0000

struct kcvfhprfs, 8 bytes @428

ub4 kscnbas @428 0x00000000

ub2 kscnwrp @432 0x0000

ub4 kcvfhtrt @444 0x00000000

BBED>

這裡我們可以從結果裡看到X$KCVFH實際上是來源於kcvfh這個struct。這裡的@符號表示的是偏移量，後面對應的是其值，dbsnake 應該是寫了一個方法，直接獲取了這個值。如：

ub4 kccfhcvn @24 0x0a200100

檢視該物件對應的值：

SQL> selectto_number('0a200100','xxxxxxxxx') from dual;

TO_NUMBER('0A200100','XXXXXXXXX')

---------------------------------

169869568

3.2 Dump Datafile header

Oracle oradebug 命令使用說明

http://blog.csdn.net/tianlesoftware/article/details/6525628

Datafile Header 是datafile 中的第一個block. 要dump datafile header 不能直接使用如下命令：

alter systemdump datafile 1 block 1;

該命令會顯示：

Block 1 (file header) not dumped: use dumpfile header command。

檢視DSI文件403 File DumpAnalysis 一節,可以找到具體的用法：

This data file headeris in all Oracle data files, that is, files belonging to a tablespace.

The header is the samefor a temp file.

（1）Dump 'FILE_HDRSLEVEL n'

N=1: The control file’sentry of the data file. This appears before the string FILE

HEADER, and is notshown on the slide. It will be covered in the control file dump.

N=2: The control file’sentry and generic header. This has been covered in the

previous slide, and isnot shown on the above slide.

N=3: The control file’sentry, generic header, and the header information in the data

file. This causes thefile to be opened and read if the database is only mounted.

（2）Data File Header

This resides in block1, somewhere after the generic file header.

Tablespace: Name of the tablespace to which the filebelongs.

rel_fn: Relative file number

Creation SCN,time: SCN at the time thefile was created. There can not be any redo

information for thisfile prior to this SCN. The timestamp is approximate. This can be

used to distinguishbetween different files created with the same name (for example,

drop and recreate atablespace).

Backup scn,time: Updated whenexecuting BEGIN BACKUP on the tablespace.

RMAN does not updatethis field.

(The next few lines inthe dump are incorrectly indented, erroneously suggesting they

belong to the backupSCN.)

reset logscount and scn: The counter with the SCN is called the Reset Log Stamp,

and is a uniqueidentification. The counter is in fact a timestamp.

Recovered at: Used during recovery to help ensure thatif many processes are used

for recovery, all areusing the same file, in case of name duplication.

Status: Flags. Here are also the fuzzy flags

KCVFHHBP 001 Hot backup-in-progress on file (fuzzy file)

KCVFHHBM 002 End hot backup marker seen (Bit only validor set in Oracle7)

KCVFHOFZ 004 Online fuzzy because it was online and dbopen

KCVFHCRM 008 Crash Recovery Media marker seen (Bit onlyvalid or set in

Oracle7)

KCVFHMFZ 010 Media recovery fuzzy - file in mediarecovery

KCVFHCMF 020 Clear media recovery (Bit only valid or setin Oracle7)

KCVFHAFZ 040 Absolutely fuzzy - fuzziness from file scan

KCVFHBCP 100 Bad Checkpoint - no enabled thread bitvec

(In Oracle7 this flagmeans: File belongs to SYSTEM tablespace)

KCVFHFMH 200 Freshly munged header. Resetlogs are notfinished.

Bit is cleared at nextcheckpoint. A set bit allows an OPEN

RESETLOGS to berepeated (for example, file headers were

updated

(this bit was set) butcontrol file record not updated)

KCVFHXCH 400 Externally cached by operating system. Ifthe server is aware

of an OS cache thatdelays writes to media, then this bit gets set,

and the server willforce a media recovery when file is reopened.

KCVFHZBA 800 Zeroed blocks allowed. File may containOracle7 unused blocks,

which are all zero.Oracle8 blocks have a nonzero initial value

with SEQ and TAIL.

KCVFHPCP 1000 Proxy copy in progress

Rootdba: This fieldonly occurs in data file #1, and is the location of blocks required

duringbootstrapping the data dictionary (bootstrap$)

CheckpointCount: Number ofcheckpoints attempted to this file (some may have

been skipped, if thefile already has a checkpoint at a later time then the checkpoint

now being attempted).Helps to detect files that have been restored.

ControlfileCheckpoint Count: Saved copy of thecontrol file record of the

checkpoint count.Helps detect old control files.

begin-hot-backupfile size: Updated when BackupSCN is updated. To cope with

data files that wereresized during backup.

Checkpoint SCN: Updated on every checkpoint, but not whenin Hot backup state

(not online backups).This must remain untouched when you are in hot backup mode,

because you might getcheckpoints between the BEGIN BACKUP and when you

actually start thecopying process.

BackupCheckpoint: Updated with thecheckpoint done while file in Hot backup.

External cacheid: Used to ensure thatconcurrent instances access data through

consistent externalcache.

Absolute FuzzySCN: Shows this file is abackup copy and is fuzzy.

Recovery fuzzySCN: The SCN at which therecovery of this file will be complete

(no longer fuzzy).

Both above fuzzy SCNsmust be zero unless a fuzzy flag is set, and must be greater

than the checkpointSCN

Comment in the codethat examines the fuzzy bits:

/* Fuzzy-Wuzzy was afile.

** Fuzzy-Wuzzy needsno redo.

** Fuzzy-Wuzzywasn't fuzzy, was he? */

（3）Data File Blocks

Data file blocks arenot covered in this course, because they have been covered in

other courses in thisseries.

這裡就有兩種方法來dump Datafile header：

（1）使用sql 語句：

SQL>alter system set events 'immediate tracename file_hdrs level 3;

（2）使用oradebug命令，這裡用oradebug 命令示例

SQL> oradebug setmypid

Statement processed.

SQL> oradebug dump file_hdrs 10

Statement processed.

SQL> oradebug tracefile_name

/u01/app/oracle/admin/anqing/udump/anqing_ora_4556.trc

這裡會把所有的datafile 的header 都dump 出來，我們從trace裡找到file#1的dump：

DATA FILE #1:

(name #7) /u01/app/oracle/oradata/anqing/system01.dbf

creation size=0 block size=8192 status=0xehead=7 tail=7 dup=1

tablespace 0, index=1 krfil=1 prev_file=0

unrecoverablescn: 0x0000.00000000 01/01/1988 00:00:00

Checkpoint cnt:140 scn: 0x0000.0014c0c110/30/2011 17:46:40

Stopscn: 0xffff.ffffffff 10/30/2011 16:29:42

Creation Checkpointed at scn: 0x0000.00000009 06/30/2005 19:10:11

thread:0 rba:(0x0.0.0)

enabled threads: 00000000 0000000000000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000

……

00000000 00000000 00000000 00000000 00000000 00000000

Offline scn: 0x0000.0006ce7a prev_range: 0

Online Checkpointed at scn: 0x0000.0006ce7b 10/09/2011 13:47:55

thread:1 rba:(0x1.2.0)

enabled threads: 01000000 0000000000000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000

……

00000000 00000000 00000000 00000000 00000000 00000000

HotBackup end marker scn: 0x0000.00000000

aux_file is NOT DEFINED

V10STYLE. FILE HEADER:

Compatibility Vsn = 169869568=0xa200100

Db ID=695026631=0x296d43c7, Db Name='ANQING'

Activation ID=0=0x0

Control Seq=1049=0x419, File size=64000=0xfa00

File Number=1, Blksiz=8192, File Type=3 DATA

Tablespace #0 - SYSTEM rel_fn:1

Creation at scn: 0x0000.0000000906/30/2005 19:10:11

Backup taken at scn: 0x0000.0000000001/01/1988 00:00:00 thread:0

reset logs count:0x2d8b028b scn:0x0000.0006ce7b reset logs terminal rcv data:0x0 scn: 0x0000.00000000

prevreset logs count:0x2184ef74 scn: 0x0000.00000001 prev reset logs terminal rcvdata:0x0 scn: 0x0000.00000000

recovered at 10/30/2011 17:46:38

status:0x2004 root dba:0x00400179 chkpt cnt:140 ctl cnt:139

begin-hot-backup file size: 0

Checkpointed at scn: 0x0000.0014c0c1 10/30/2011 17:46:40

thread:1 rba:(0x46.2.10)

enabled threads: 01000000 0000000000000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000

…..

00000000 00000000 00000000 00000000 00000000 00000000

Backup Checkpointed at scn: 0x0000.00000000

thread:0 rba:(0x0.0.0)

enabled threads: 00000000 0000000000000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 ……

00000000 00000000 00000000 00000000 00000000 00000000

External cache id: 0x0 0x0 0x0 0x0

Absolute fuzzy scn: 0x0000.00000000

Recovery fuzzy scn: 0x0000.0000000001/01/1988 00:00:00

Terminal Recovery Stamp 01/01/1988 00:00:00

Platform. Information: Creation Platform. ID: 10

Current Platform. ID: 10 Last Platform. ID:10

Dbsnake 就是用dump 出來的值和BBED 計算出來的值進行比較推測出x$kcvfh 字典中每個欄位的含義。

3.3 X$KCVFH 中的FHRDB 欄位說明

剛才在DSI 403裡有這麼一句話：

Root dba: This fieldonly occurs in data file #1, and is the location of blocks required during bootstrapping the data dictionary (bootstrap$)

事實上，x$kcvfh 中的FHRDB 就是代表這個root dba,而且這個bootstrap$ 對資料庫來說還非常重要。

下面我們來驗證上面的這個結論：

BBED顯示的FHRDB中的值：

ub4 kcvfhrdb @96 0x00400179

使用如下SQL,將這個DBA地址轉換稱對應的block，具體參考：

Oracle rdba和 dba 說明

http://blog.csdn.net/tianlesoftware/article/details/6529346

SQL> SELECTDBMS_UTILITY.data_block_address_file (

2 TO_NUMBER (LTRIM ('0x00400179', '0x'),'xxxxxxxx'))

3 AS file_no,

4 DBMS_UTILITY.data_block_address_block (

5 TO_NUMBER (LTRIM('0x00400179', '0x'), 'xxxxxxxx'))

6 AS block_no

7 FROM DUAL;

FILE_NO BLOCK_NO

---------- ----------

1 377

透過這個結果，可以看出DBA0x00400179 指向的是file 1 block 377.

我們使用BBED 命令輸出377 block 裡面的內容：

dave:/home/oracle> bbed parfile=/u01/bbed.par

Password:

BBED: Release 2.0.0.0.0 - LimitedProduction on Sun Oct 30 18:44:26 2011

************* !!! For Oracle Internal Useonly !!! ***************

BBED> set dba 1,377

DBA 0x00400179(4194681 1,377)

BBED> show

FILE# 1

BLOCK# 377

OFFSET 0

DBA 0x00400179(4194681 1,377)

FILENAME /u01/app/oracle/oradata/anqing/system01.dbf

BIFILE bifile.bbd

LISTFILE /u01/filelist.txt

BLOCKSIZE 8192

MODE Edit

EDIT Unrecoverable

IBASE Dec

OBASE Dec

WIDTH 80

COUNT 512

LOGFILE log.bbd

SPOOL No

BBED> p ktemh

struct ktemh, 16 bytes @92

ub4 count_ktemh @92 0x00000001

ub4 next_ktemh @96 0x00000000

ub4 obj_ktemh @100 0x00000038

ub4 flag_ktemh @104 0x40000000

BBED> map

File:/u01/app/oracle/oradata/anqing/system01.dbf (1)

Block: 377 Dba:0x00400179

------------------------------------------------------------

Unlimited Data Segment Header

struct kcbh, 20 bytes @0

struct ktech, 72 bytes @20

struct ktemh, 16 bytes @92

struct ktetb[1], 8 bytes @108

struct ktshc, 8 bytes @4148

struct ktsfs_seg[1], 20 bytes @4156

struct ktsfs_txn[16], 320 bytes @4176

ub4tailchk @8188

BBED> p ktemh

struct ktemh, 16 bytes @92

ub4count_ktemh @92 0x00000001

ub4 next_ktemh @96 0x00000000

ub4 obj_ktemh @100 0x00000038

ub4 flag_ktemh @104 0x40000000

BBED>

這裡可以看到FHRDB 對應的物件是：0x00000038

SQL> select to_number('38','XX') from dual;

TO_NUMBER('38','XX')

--------------------

56

SQL> select name from sys.obj$ where obj#=56;

NAME

------------------------------

BOOTSTRAP$

以上測試證明：10g中X$KCVFH中欄位FHRDB對應的就是bootstrap$.

這篇文章根據dbsnake 的blog 重新整理測試而來，感謝dbsnake的幸苦勞動，dbsnake的原文連結如下：

關於10g中的X$KCVFH

關於10g中的X$KCVFH（續）

關於10g中的X$KCVFH（續2）

Oracle 10g 中 X$KCVFH 說明

相關文章