Oracle 10g 中 X$KCVFH 说明

 

一. 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

 

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

 

************* !!! 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

 

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

 

************* !!! 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

http://dbsnake.com/2009/05/10g-x-kcvfh.html

 

关于10g中的X$KCVFH(续)

http://dbsnake.com/2009/05/10g-x-kcvfh-continul.html

 

关于10g中的X$KCVFH(续2)

http://dbsnake.com/2009/05/10g-x-kcvfh-continue-2.html

 

 在下一篇文章中,将重点来看一下Bootstrap$.

 

 

 

 

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

版权所有,文章允许转载,但必须以链接方式注明源地址,否则追究法律责任!

Blog:   http://blog.csdn.net/tianlesoftware

Weibo:            http://weibo.com/tianlesoftware

Email:             tianlesoftware@gmail.com

Skype:            tianlesoftware

 

-------加群需要在备注说明Oracle表空间和数据文件的关系,否则拒绝申请----

DBA1 群:62697716(满);   DBA2 群:62697977(满)  DBA3 群:62697850(满)  

DBA 超级群:63306533(满);  DBA4 群:83829929(满) DBA5群: 142216823(满) 

DBA6 群:158654907(满)   DBA7 群:69087192(满)  DBA8 群:172855474

DBA 超级群2:151508914  DBA9群:102954821     聊天 群:40132017(满)

posted @ 2011-10-30 19:13  hibernate我最强  阅读(191)  评论(0编辑  收藏  举报