ORACLE数据文件和控制文件头部

1、为了回答关于深入浅出Oracle中的一些疑问，引出本系列文章，讨论链接参考: HYPERLINK /609499.html /609499.html在 HYPERLINK /archives/2006/08/event_file_hdrs.html 上一讲中，我们说过：当我们使用file_hdrs事件来转储数据文件头信息时，Oracle会转储两部分信息，一部分来自控制文件，一部分来自数据文件，在数据库启动过程中，这两部分信息要用来进行启动验证。在数据库opeen的过程中中,Oraccle要进行行检查中包含含以下 HYPERLINK /internal/Checkpoint_CNT&SCN.ht

2、m 两个过过程:第一次检查数据据文件头中的的Checkkpointt cnt是是否与对应控控制文件中的的Checkkpointt cnt一一致.如果相相等,进行第第二次检查.第二次检查数据据文件头的开开始SCN和和对应控制文文件中的结束束SCN是否否一致如果结结束SCN等等于开始SCCN,则不需需要对那个文文件进行恢复复.对每个数据文件件都完成检查查后,打开数数据库.同时时将每个数据据文件的结束束SCN设置置为无穷大.通过以下过程我我们来进一步步说明一下这这个内容。我们来看以下来来自控制文件件部分(选取取一个文件测测试): DATA FIILE #44: (naame #44) /oppt/o

3、raacle/ooradatta/eyggle/eyygle011.dbfccreatiion siize=0 blockk sizee=81922 stattus=0 xxe heaad=4 ttail=44 dup=1tabllespacce 4, indexx=4 krrfil=44 prevv_filee=0unrrecoveerablee scn: 0 x00000.0000000000 01/01/19988 000:00:000Checckpoinnt cntt:58 sscn: 00 x00000.002aac8ee 08/111/20066 09:448:29SStop ss

4、cn: 00 x00000.002aac8ee 08/111/20066 09:448:29CCreatiion Chheckpoointedd at sscn: 00 x00000.00155078d 06/066/20066 09:441:54tthreadd:0 rbba:(0 xx0.0.00).aux_file is NOOT DEFFINED 这部分中包含的的重要信息有有:检查点计计数: Chheckpooint ccnt:588检查点SCCN: sccn: 0 xx0000.002acc8ee 008/11/2006 09:488:29数据据文件Stoop SCNN:Stopp

5、scn: 0 x00000.0002ac8eee 08/11/20006 099:48:229我们再看来自数数据文件头的的信息:FILE HEEADER:Softwware vvsn0 xx92000000, CCompattibiliity Vssn0 x880000000Db IID=140076865520=0 xx53e799778, Db Naame=EEYGLEActivvationn ID=00=0 x0CControol Seqq=979=0 x3d33, Fille sizze=12880=0 x5500Fille Numm

6、ber=44, Blkksiz=88192, File Type=3 DATTATabllespacce #4 - EYGGLE reel_fn:4 Creeationn at sscn: 00 x00000.00155078d 06/066/20066 09:441:54BBackupp takeen at scn: 0 x00000.0000000000 01/001/19888 00:00:000 threead:0rreset logs countt:0 x2332bee11f scnn: 0 x00000.00007c7781 reecoverred att 08/110/20006

7、 20:57:533statuus:0 x00 roott dba:0 x0000000000 chkppt cntt: 58 ctl ccnt:577beginn-hot-backuup fille sizze: 0CCheckppointeed at scn: 0 x00000.0022ac8eee 08/111/20006 09:48:299.这部分中包含的的重要信息有有:检查点SSCN: CCheckppointeed at scn: 0 x00000.0022ac8eee 08/111/20006 09:48:299检查点计数数: chkkpt cnnt: 588 ctl cnt:5

8、57这两者都和控制制文件中所记记录的一致。如如果这两者一一致，数据库库启动时就能能通过验证，启启动数据库。那么如果不一致致呢？Oraacle则请请求进行恢复复。我们看，从从备份中恢复复eyglee01.dbbf文件.首首先第一部分分从控制文件件中获得的信信息是相同的的: DATA FIILE #44: (naame #44) /oppt/oraacle/ooradatta/eyggle/eyygle011.dbfccreatiion siize=0 blockk sizee=81922 stattus=0 xxe heaad=4 ttail=44 dup=1tabllespacce 4, in

9、dexx=4 krrfil=44 prevv_filee=0unrrecoveerablee scn: 0 x00000.0000000000 01/01/19988 000:00:000Checckpoinnt cntt:58 sscn: 00 x0000.002acc8ee 008/11/2006 09:488:29Sttop sccn: 0 xx0000.002acc8ee 008/11/2006 09:488:29Crreatioon Cheeckpoiinted at sccn: 0 xx0000.00150078d 006/06/2006 09:411:54.auxx_filee

10、is NNOT DEEFINEDD 检查点计数: Checkkpointt cnt:58检查点点SCN: scn: 0 x00000.0022ac8eee 08/111/20006 09:48:299数据文件SStop SSCN:Sttop sccn: 0 xx0000.002acc8ee 008/11/2006 09:488:29而从文件头中获获得的备份文文件信息则是是： FILE HEEADER:Softwware vvsn0 xx92000000, CCompattibiliity Vssn0 x880000000Db IID=1400

11、76865520=0 xx53e799778, Db Naame=EEYGLEActivvationn ID=00=0 x0CControol Seqq=973=0 x3cdd, Fille sizze=12880=0 x5500Fille Nummber=44, Blkksiz=88192, File Type=3 DATTATabllespacce #4 - EYGGLE reel_fn:4 Creeationn at sscn: 00 x00000.00155078d 06/066/20066 09:441:54BBackupp takeen at scn: 0 x00000.00000

12、00000 01/001/19888 00:00:000 threead:0rreset logs countt:0 x2332bee11f scnn: 0 x00000.00007c7781 reecoverred att 08/110/20006 20:57:533statuus:0 x00 roott dba:0 x0000000000 chkppt cntt: 53 ctl ccnt:522beginn-hot-backuup fille sizze: 0CCheckppointeed at scn: 0 x00000.0022ac5f9 088/10/22006 220:58:21.

13、我们看到此时备备份文件的信信息：检查点点是：Cheeckpoiinted at sccn: 0 xx0000.002acc5f9 088/10/22006 220:58:21检查点点计数为:cchkpt cnt: 53 cttl cntt:52这两者不再一致致，首先是检检查点技术不不一致，当前前文件的chhkpt ccnt为533，小于控制制文件中记录录的58，OOraclee可以判断文文件是从备份份中恢复的，或或者文件故障障，需要进行行介质恢复。我们看如果此时时我们试图打打开数据库，则则Oraclle提示文件件需要介质恢恢复: SQL allter ddatabaase oppen;allt

14、er ddatabaase oppen*ERRORR at lline 11:ORA-011133: fille 4 nneeds mediaa recooveryOORA-011110: data file 4: /opt/ooraclee/oraddata/eeygle/eyglee01.dbbf执行恢复: SQL reecoverr dataafile 4;Meddia reecoverry commpletee.我们看看恢复完完成之后，控控制文件和数数据文件的变变化.首先看看控制文件的的变化: DATA FIILE #44: (namme #4) /optt/oraccle/orrad

15、ataa/eyglle/eyggle01.dbfcrreatioon sizze=0 bblock size=8192 statuus=0 xee headd=4 taail=4 dup=11tableespacee 4, iindex=4 krffil=4 prev_file=0unreecoverrable scn: 0 x00000.0000000000 01/001/19888 00:00:000Checkkpointt cnt:59 sccn: 0 xx0000.002acc8ee 008/11/2006 09:488:29Sttop sccn: 0 xx0000.002acc8ed

16、 008/11/2006 09:488:29Crreatioon Cheeckpoiinted at sccn: 0 xx0000.00150078d 006/06/2006 09:411:54.检查点计数: Checkkpointt cnt:59执行了了恢复之后，检检查点计数较较前增加了11检查点SCN: scn: 0 x00000.0002ac8eee 08/11/20006 099:48:229数据文件件Stop scn: 0 x00000.0022ac8edd 08/111/20006 09:48:299数据文件SStop sscn和数据据文件进行了了同步。数据文件头信息息: FILE

17、 HEEADER:Softwware vvsn0 xx92000000, CCompattibiliity Vssn0 x880000000Db IID=140076865520=0 xx53e799778, Db Naame=EEYGLEActivvationn ID=00=0 x0CControol Seqq=983=0 x3d77, Fille sizze=12880=0 x5500Fille Nummber=44, Blkksiz=88192, File Type=3 DATTATabllespacce #4 - EYGGLE ree

18、l_fn:4 Creeationn at sscn: 00 x00000.00155078d 06/066/20066 09:441:54BBackupp takeen at scn: 0 x00000.0000000000 01/001/19888 00:00:000 threead:0rreset logs countt:0 x2332bee11f scnn: 0 x00000.00007c7781 reecoverred att 08/111/20006 10:11:266statuus:0 x00 roott dba:0 x0000000000 chkppt cntt: 59 ctl

19、ccnt:588beginn-hot-backuup fille sizze: 0CCheckppointeed at scn: 0 x00000.0022ac8ed 008/11/2006 09:488:29.我们看到此时数数据文件的信信息：检查点点是：Cheeckpoiinted at sccn: 0 xx0000.002acc8ed 008/11/2006 09:488:29这个个检查点和控控制文件中记记录的stoop scnn一致，数据据库启动可以以顺利进行。检查点计数为:chkptt cnt: 59 cctl cnnt:58我们打开数据库库: SQL allter ddatabaas

20、e oppen;Databasse alttered.SQL allter ssessioon sett evennts iimmediiate ttrace name file_hdrs levell 10;Sessionn alteered.此时数据库恢复复正常运行。控制文件信息如下： DATA FIILE #44: (naame #44) /oppt/oraacle/ooradatta/eyggle/eyygle011.dbfccreatiion siize=0 blockk sizee=81922 stattus=0 xxe heaad=4 ttail=44 dup=1tabllesp

21、acce 4, indexx=4 krrfil=44 prevv_filee=0unrrecoveerablee scn: 0 x00000.0000000000 01/01/19988 000:00:000Checckpoinnt cntt:60 sscn: 00 x00000.002aac8ef 08/111/20066 10:119:30SStop sscn: 00 xfffff.fffffffff 08/111/20066 09:448:29CCreatiion Chheckpoointedd at sscn: 00 x00000.00155078d 06/066/20066 09:4

22、41:54此时stop scn被置置为无穷大。数据文件头信息如下:FILE HEEADER:Softwware vvsn0 xx92000000, CCompattibiliity Vssn0 x880000000Db IID=140076865520=0 xx53e799778, Db Naame=EEYGLEActivvationn ID=00=0 x0CControol Seqq=984=0 x3d88, Fille sizze=12880=0 x5500Fille Nummber=44, Blkksiz=88192, File Typ

23、e=3 DATTATabllespacce #4 - EYGGLE reel_fn:4 Creeationn at sscn: 00 x00000.00155078d 06/066/20066 09:441:54BBackupp takeen at scn: 0 x00000.0000000000 01/001/19888 00:00:000 threead:0rreset logs countt:0 x2332bee11f scnn: 0 x00000.00007c7781 reecoverred att 08/111/20006 10:11:266statuus:0 x44 roott d

24、ba:0 x0000000000 chkppt cntt: 60 ctl ccnt:599beginn-hot-backuup fille sizze: 0CCheckppointeed at scn: 0 x00000.0022ac8eff 08/111/20006 10:19:300未完待续.datafille bloock bllock ssize :8192Offset 0 1 2 3 4 5 6 7 8 9 a b c d e f 000140000 06 A2 00 00 0A 00 40 01 0E 89 43 00 00 00 05 02 type frmt spare1/2_

25、kcbbh rdba scn seq flg 1 : 20 bytestype: 0 x06=trans data defined in kcb.h frmt: 8i9i 都是0 x02 10.1.0 2k: 0 x62 4k:0 x82 8k:0 xa2 16k:0 xc2 (logfile 0 x22 512 bytes) spare1/2_kcbh: ub1 spare1_kcbh this field is no longer used (old inc#, now always 0) ub1 spare2_kcbh this field is no longer used (old

26、ts#, now always 0) rdba: 0 x0140000a 转换成2进制后它的前10 bit 表示file id 后22 bit 表示的block id 可以看出一个tablespace 可以有1023 个datafile ,每个datafile可以有4M 的block10G 出现的 big datafile 这里表示的就是block id了 没有file id 9.2.0试验过一个tablespace可以有1023个datafile 一个object可以存放在1023个datafile中 scn: scn: 0 x0000.0043890e seq: A sequence nu

27、mber incremented for each change to a block at the same SCN A new SCN is allocated if the sequence number wraps. 同一个SCN影响这个block中的行数大于 254 行就会为这个事务分配一个新的SCN 如下面的操作就可能引起同一个SCN但影响的同一个block 中的行超过254行 delete from table_name 影响的行数(最大254) 是用从 0 x01 到 0 xfe 表示的当这个byte 的数据为 0 xff 的时候标志这个 block 坏调了- ora-0157

28、8Sequence number:SEQ - 0 /* non-logged changes - do not advance seq# */SEQ - (UB1MAXVAL-1)/* maximum possible sequence number */SEQ - (UB1MAXVAL) /* seq# to indicate a block is corrupt,equal to FF. soft corrupt*/ 0 xff : When present it indicates that the block has been marked as corrupt by Oracle.

29、either by the db_block_checking functionality or the equivalent events (10210 for data blocks, 10211 for index blocks, and 10212 for cluster blocks) when making a database change, or by the DBMS_REPAIR.FIX_CORRUPT_BLOCKS procedure, or by PMON after an unsuccessful online block recovery attempt while

30、 recovering a failed process, or by RMAN during a BACKUP, COPY or VALIDATE command with the CHECK LOGICAL option. Logical corruptions are normally due to either recovery through a NOLOGGING operation, or an Oracle software bug. flg: as defined in kcbh.h #define KCBHFNEW 0 x01 /* new block - zeroed d

31、ata area */#define KCBHFDLC 0 x02 /* Delayed Logging Change advance SCN/seq */#define KCBHFCKV 0 x04 /* ChecK Value saved-block xors to zero */#define KCBHFTMP 0 x08 /* Temporary block */这是一个可以组合的值 也就是说有为 6 的时候是 2,4 两种情况的组合Block structure as defined in kcbh.h:struct kcbhub1 type_kcbh; /* Block type*

32、 / ub1 frmt_kcbh; /* #define KCBH_FRMT8 2 */ ub1 spare1_kcbh;ub1 spare2_kcbh;krdba rdba_kcbh; /* relative DBA /ub4 bas_kcbh; /* base of SCN */ub2 wrp_kcbh; /* wrap of SCN */ub1 seq_kcbh; /* sequence # of changes at same scn */ub1 flg_kcbh;ub2 chkval_kcbh; 000140110 00 00 00 00 01 00 17 00 54 D2 00 0

33、0 0A 89 43 00 chkval spare3_kcbh typ ? seg/objj csc spare3_kcbh : ub2 spare3_kcbh 2 : 24 bytes (总计44bytes)typ : 1 - DATA 2 index 改成3了在10.1.0 上引起了ora-6002032然后ORA-27101: shared memory realm does not existoracle进行查询的时候是根据 obj$表中的情况来判断对象的类型的,不是根据这个typ也就是说如果有一个表但改变表中block的这个标志位，一样可以查询出数据来,但dump block 时会

34、出错,ORA-00600: 内部错误代码，自变量: 4555, 0, , , , , , 错误中的 0 就是typ对应的数据在10G中改变它后update这个block的数据commit可以但rollback的报错 ? 见过有其他值 但用编辑器改这个值 在 dump 文件中显示不出来变化 seg/obj: 0 xd254 csc : 0 x00.43890a The SCN at which the last full cleanout was performed on the block 000140220 00 00 E8 1F 02 00 03 00 00 00 00 00 04 00

35、0C 00 csc ? itc ? flg fsl fnx xid 3 : 24 bytes * itl (2个itl总计92bytes)? 见过有其他值 但用编辑器改这个值 在 dump 文件中显示不出来变化 itc ITL 条目的个数 max 255超过会报ORA-02207 ORA-00060 ORA-00054 可能是没空间分配itl条目了或它的争用引起的在8i中 INITRANS default为1 , 9.2.0中 INITRANS default为2 flg indicates that the block is on a freelist. Otherwise the flag

36、 is -9i 的ASSM 的情况下这个值为 Eixora 上说他占用 2 bytes 但我下面的试验和他的结果有一定的出入我观察到的情况是 : Object id on Block? Y flg: O ver: 0 x01 上面的3项是用同一个 byte 来表示的flg: O ver: 0 x01 Object id on Block? Y 从我的观察中 dump 出来的文件中 flg ver Object id on Block他们共同占用的这个一个字节 他的规律可以从下面的情况看出2进制数据 flg ver Object id on Block?0 x00 - 0 x00 N0 x01

37、0 0 x00 N0 x02 - 0 x01 Y0 x03 0 0 x01 Y0 x04 - 0 x02 Y0 x05 0 0 x02 Y0 x06 - 0 x03 Y0 x07 0 0 x03 Y0 x08 - 0 x04 N0 x09 0 0 x04 N0 x0a - 0 x05 Y0 x0b 0 0 x05 Y0 x0c - 0 x06 Y0 x0d 0 0 x06 Y0 x0e - 0 x07 Y0 x0f 0 0 x07 Y0 x10 . 类似上面的循环了 这种情况在9i上已经改变因为ASSM的出现 fsl : Index to the first slot on the ITL f

38、reelist. ITL TX freelist slot fnx : 自由列表中下一块的地址 Null if this block is not on a freelist 有数据例如: fnx: 0 x1000029 000140330 50 18 00 00 96 14 80 00 B9 07 01 00 01 20 00 00 xid uba Lck Flaag Scn/Fscc xid : Transaction ID (UndoSeg.Slot.Wrap)值可以用select XIDUSN, XIDSLOT,XIDSQN from v$transaction;查到 This is

39、comprised of the rollback segment number (2 bytes), the slot numberin the transaction table of that rollback segment (2 bytes), and the numberof times use of that transaction table has wrapped (4 bytes). uba : Undo address (UndoDBA.SeqNo.RecordNo)The location of the undo for the most recent change t

40、o this block by this transaction. This is comprised of the DBA of the rollback segment block (4 bytes), the sequence number (2 bytes), and the record number for the change in that undo block (1 byte), plus 1 unused byte. Lck Flag: Lck 锁定的row数 这里还用到了下一个 byte 的数据2 对应的二进制表示为 0010 正好和dump文件中的 -U- 吻合flag

41、 1 nibble C = Committed; U = Commit Upper Bound; T = Active at CSC; B = Rollback of this UBA gives before image of the ITL.- = transaction is active, or committed pending cleanoutC- = transaction has been committed and locks cleaned out-B- = this undo record contains the undo for this ITL entry-U- =

42、 transaction committed (maybe long ago); SCN is an upper bound-T = transaction was still active at block cleanout SCNLck 3 nibbles The number of row-level locks held in the block by this transaction. Scn/Fsc : If the transaction has been cleaned out, this is the commit SCN or an upper bound thereof.

43、 Otherwise the leading two bytes contain the free space credit for the transaction - that is, the number of bytes freed in the block by the transaction Scn = SCN of commited TX; Fsc = Free space credit (bytes) 000140440 0E 89 43 00 00 00 00 00 00 00 00 00 00 00 00 00 Scn/Fscc 第2条itl 这里没使用用 000140550

44、 00 00 00 00 00 00 00 00 00 00 00 00 00 01 01 00 第2条itl 这里没使用用 flag ntab nrow 4 : 14 bytes 从这个flag位置开始是data区 也是下面的行的offset的起始地址flag : N=pctfree hit(clusters), F=dont put on free list K=flushable cluster keys. 当然还有别的标记: A . ntab : 这block中有几个table的数据 cluster这个就可能大于1 nrow : block 有多少行数据 000140660 FF FF

45、 14 00 9B 1F 83 1F 83 1F 00 00 01 00 9B 1F frre fsbo fseo avsp tosp offs nrow row offfs frre : First free row index entry. -1=you have to add one. fsbo : Free Space Begin offset 出去row dict 后面的可以放数据的空间的起始位置也可以看成是从这个区域的开始flag到最后一个 row offs占用的空间 fseo : Free Space End offset ( 9.2.0 )参与db_block_checking

46、的计算剩余空间select 的时候oracle不是简单的根据offset定位row.这个值也是参与了定位row的 avsp : Available space in the block (pctfree and pctused) ORA-01578 tosp : Total available space when all TXs commit ( 9.2.0 )参与db_block_checking offs : 偏移量 用 cluster 的时候可以看出值 nrow : 这个table有多少行数据 row offs : 这行数据相对的起始位置 after delete & commit i

47、s 0 xffff 00015FFF0 00 00 00 00 00 00 00 2C 01 01 01 61 05 06 0E 89 fb lb cc length data block ttail 5 : 用户数据6 : 4 bytes block tailfb : K = Cluster Key (Flags may change meaning if this is set to show HASH cluster) C = Cluster table member H = Head piece of row D = Deleted row F = First data piece L

48、 = Last data piece P = First column continues from previous piece N = Last column continues in next piece lb : 和上面的 ITL 的lck相对应 表示这行是否被 lock 了 cc : 有几列数据 这里只能表示255列 超过了就会有链接行 length : 这列的数据的长度是多少 0 xfa ( 250 bytes ) 其实0 xfb,0 xfc,0 xfd 也同样是250bytes 0 xfe fb 00 ( 0 xfb 00 表示的251 bytes 0 xfe表示row的长度超过

49、了250 bytes) 0 xff 表示number 的 null 这也是oracle中null的表现形式排序的时候null最大了字段的数据超过250字节是就用3bytes来表示字段的长度,因为如果是long类型它的字段再长它在这个block中的数据的长度不会超过64K 所以最长用3bytes来表示行的长度已经够了.再长就链接行了 data : a block tail : 改这 block 最后的4 bytes 数据中的任意肯定ora-1578 第 1 byte : 对应开始的 seq 第 2 byte : 对应开始的 type 第3,4byte : 对应开始的scn的末2为 control

50、 file 这里是control seq 10.1.0lgoneeONE.LG.OKK creeate ttable a(v vvarchaar2(40000) TABLEESPACEE t;Table ccreateed.10.1.0lgoneeONE.LG.OKK inssert iinto aa valuues(aa);1 row ccreateed.Start ddump ddata bblockss tsn: 17 ffile#: 5 miinblk 10 maaxblk 10buffer tsn: 17 rddba: 00 x01400000a (5/100) / bufffer

51、tssn: 数据文文件对应的 tableespacee 的 nuumber 这只是是dump文文件中记录的的数据而已 bloock 中是是没有记录 tableespacee 的 nuumber 的 scn: 0 xx0000.00438890e sseq: 00 x05 fflg: 00 x02 ttail: 0 x8900e06055frmt: 00 x02 cchkvall: 0 x00000 ttype: 0 x06=transs dataaBlock hheaderr dumpp: 0 xx01400000a Objectt id oon Bloock? YY seg/obbj: 0

52、xxd254 csc: 0 x000.438990a iitc: 22 flgg: O typ: 1 - DDATA fssl: 0 fnx: 0 x0 ver: 0 x01 Itl Xiid UUba Flagg Lckk Sccn/Fscc0 x01 0 x00004.00cc.000001850 0 x0008014996.07bb9.01 -U- 11 fscc 0 x00000.000438900e0 x02 0 x00000.0000.000000000 0 x0000000000.00000.00 - 00 fscc 0 x00000.0000000000 data_bllock

53、_ddump,ddata hheaderr at 00 x87e1125c / datta_bloock_duump,daata heeader at 0 xx87e1225c 其实这这个blocck不是直接接从 datta bufffer 中中 dumpp 出来的这这个表示真正正dump时时 blocck 的数据据区的起始位位置 也就是是下面这部分分开始的位置置 = / tsiiz: hsizz: ppbl: bdbaa: 在数据据文件都是没没有存储的 tsiz: 00 x1fa00 / Totaal datta areea sizze 88k的bloock: 88192-220(blooc

54、k heead)-224(Traansacttion HHeaderr)-24*2(一个事事务条)-44(blocck taiil)=80096(0 xx1fa0)hsiz: 00 x14 / Dataa headder siize 数数据块头200个字节+数数据块尾4个个字节=244字节(0 xx14)pbl: 0 xx087e1125c / Poinnter tto bufffer hholdinng thee blocckbdba: 00 x01400000a 7665432110 flag=-ntab=1nrow=1frre=-11fsbo=0 xx14fseo=0 xx1f9bavs

55、p=0 xx1f83tosp=0 xx1f830 xe:ptii0 nrow=1 offfs=00 x12:prri0 offs=0 x1f9bblock_rrow_duump:tab 0, row 00, 0 xx1f9btl: 5 ffb: -H-FL- lb: 0 x1 cc: 1col 0: 1 61end_of_blockk_dumppEnd dummp datta bloocks ttsn: 117 fille#: 55 minbblk 100 maxbblk 100block 坏坏掉了还可以以报: ORAA-600 (45199) Cacche laayer bblock typ

56、e is inncorreect ORAA-600 (43933) Cheeck foor Typpe forr Segmment hheaderr withh freee listt ORAA-600 (41366) Cheeck Roollbacck seggment blockk ORAA-600 (41544) Cheeck Roollbacck seggment blockk Oraa-600kcbzppb_1,d,kind,chkk getts siggnaledd whenn the blockk got corruupted in meemory. Thee onlyy way

57、 it shhould be baad is if a strayy storre intto memmory ddestrooyed tthe heeader or taail. d = bloccknumbber, kkind= kind of coorrupttion ddetectted,chhk = ccheckssum fllag oraa-6003398 and ora-660033339 oraa-6003398 is nnot inn oraccle 8. oraa-6003398 meanns it faileed a vverifiicatioon cheeck beef

58、ore writiing baack too diskk, soo it mmust be aan in-memorry corrruptiion. oraa-6003339 comees witth oraa-15788 and meanss eithher diisk coorrupttion oor in memorry corrruptiion affter rread. oraa-600 33399 hass beenn remooved ffrom 77.2+ Froom 7.22+ orra-6000 33998 haas beccome oora-6000 33374 wwit

59、h ssome ccheckss addeed.2进制存储格式式 ALLTER SSESSIOON SETT EVENNTS 110289 tracee namee conttext fforeveer, leevel 11; ALLTER SSESSIOON SETT EVENNTS 110289 tracee namee conttext ooff;为了回答一些疑疑问，引出本本系列文章，讨讨论链接参考考:htttp:/66094999.htmll当我们们使用fille_hdrrs事件来转转储数据文件件头信息时，OOraclee会转储两部部分信息，一一部分来自控控制文件，一一部分来自数数据文

60、件，在在数据库启动动过程中，这这两部分信息息要用来进行行启动验证。在数据库open的过程中,Oracle要进行检查中包含以下两个过程:第一次检查数据文件头中的Checkpointcnt是否与对应控制文件中的Checkpointcnt一致.如果相等,进行第二次检查.第二次检查数据文件头的开始SCN和对应控制文件中的结束SCN是否一致如果结束SCN等于开始SCN,则不需要对那个文件进行恢复.对每个数据文件都完成检查后,打开数据库.同时将每个数据文件的结束SCN设置为无穷大.通过以下过程我们来进一步说明一下这个内容。我们来看以下来自控制文件部分(选取一个文件 HYPERLINK /keyword/%