数据库备份恢复的原理

1、揭密备份恢复的原理！其实一句话就可以说明白：那就是数据文件的头上不仅包含了checkpoint_change#，更重要的是它包含了这个checkpoint_change#所在的logfile的sequence#，准确的说是rba。有了rba，在恢复时就能准确的知道到底需要哪个logfile(archivelogorredo)。结果花了很大篇幅，只想以试验的方式做个简单的验证，便于大家理解。欢迎拍砖！另外提个问题：是否存在一些数据字典它是源于redo的？-controlfile中记录的checkpoint_change#SQLselectcheckpoint_change#fromv$datab

2、ase;CHECKPOINT_CHANGE#1951985-datafile中记录的checkpoint_change#SQLselectcheckpoint_change#,checkpoint_timefromv$datafile_header;CHECKPOINT_CHANGE#CHECKPOINT_TIME19519852008/10/0114:17:0019519852008/10/0114:17:0019519852008/10/0114:17:0019519852008/10/0114:17:00-controlfile中记录的每一个datafile的checkpoint_cha

3、nge#SQLselectcheckpoint_change#,checkpoint_timefromv$datafile;CHECKPOINT_CHANGE#CHECKPOINT_TIME19519852008/10/0114:17:0019519852008/10/0114:17:0019519852008/10/0114:17:0019519852008/10/0114:17:00-controlfile中记录的redo的checkpoint_change#SQLselectcheckpoint_change#,checkpoint_timefromv$thread;CHECKPOINT

4、_CHANGE#CHECKPOINT_TIME19519852008/10/0114:17:00SQLaltersystemcheckpoint;系统已更改。-检查点发生之后，上面提到的checkpoint_change#都给更新SQLselectcheckpoint_change#fromv$database;CHECKPOINT_CHANGE#1955601SQLselectcheckpoint_change#,checkpoint_timefromv$datafile_header;CHECKPOINT_CHANGE#CHECKPOINT_TIME19556012008/10/0116:

5、15:2619556012008/10/0116:15:2619556012008/10/0116:15:2619556012008/10/0116:15:26SQLselectcheckpoint_change#,checkpoint_timefromv$datafile;CHECKPOINT_CHANGE#CHECKPOINT_TIME19556012008/10/0116:15:2619556012008/10/0116:15:2619556012008/10/0116:15:2619556012008/10/0116:15:26SQLselectcheckpoint_change#,c

6、heckpoint_timefromv$thread;CHECKPOINT_CHANGE#CHECKPOINT_TIME19556012008/10/0116:15:26SQLshutdownimmediate数据库已经关闭。已经卸载数据库。ORACLE例程已经关闭。-冷备份db,为下面的恢复试验使用SQLstartupmountORACLE例程已经启动。TotalSystemGlobalArea163577856bytesFixedSizeVariableSizeDatabaseBuffersRedoBuffers1247876bytes92276092bytes67108864bytes2

7、945024bytes数据库装载完毕。-查看备份时刻的checkpoint_change#,此时的checkpoint_change#=1955692是实例shutdown时系统所做的完全检查点对应的checkpoint_change#，下面在恢复时还会看到这个checkpoint_change#：1955692SQLselectcheckpoint_change#fromv$database;CHECKPOINT_CHANGE#1955692SQLselectcheckpoint_change#,checkpoint_timefromv$datafile_header;CHECKPOINT_

8、CHANGE#CHECKPOINT_TIME19556922008/10/0116:17:2419556922008/10/0116:17:2419556922008/10/0116:17:2419556922008/10/0116:17:24SQLselectcheckpoint_change#,checkpoint_timefromv$datafile;CHECKPOINT_CHANGE#CHECKPOINT_TIME19556922008/10/0116:17:2419556922008/10/0116:17:2419556922008/10/0116:17:2419556922008/

9、10/0116:17:24SQLselectcheckpoint_change#,checkpoint_timefromv$thread;CHECKPOINT_CHANGE#CHECKPOINT_TIME19556922008/10/0116:17:24SQLalterdatabaseopen;数据库已更改。-输入测试数据，验证备份恢复的过程，注意仔细观查插入到tt表中的dbms_flashback.get_system_change_number和v$log中的FIRST_CHANGE#之间的关系，我们通常理解备份恢复的原理是：事务对应的scn如果落在了哪个archivelog里，那么这个a

10、rchivelog在恢复时就被用到，下面的大致试验过程也会验证这一点：SQLconnecttest/test已连接。SQLselectgroup#,status,sequence#,archived,first_change#fromv$log;GROUP#STATUSSEQUENCE#ARCFIRST_CHANGE#1INACTIVE74YES19266392CURRENT76NO19519853INACTIVE75YES1947901SQLtruncatetablett;表被截断。SQLdesctt名称是否为空?类型IDNUMBER(38)NAMEVARCHAR2(10)SQLinsert

11、intottvalues(dbms_flashback.get_system_change_number,a);已创建1行。SQLcommit;提交完成。SQLconnect/assysdba已连接。-datafileheader上记录的rba信息，rba的意义在下面做了详细解释，这里只需知道FHRBA_SEQ表示redo的sequence#=76对应的是当前联机日志，而该sequence#被记录在了datafileheader上SQLselecthxfil,fhrba_seq,fhrba_bno,fhrba_boffromx$kcvfh;HXFILFHRBA_SEQFHRBA_BNOFHRB

12、A_BOF176661816276661816376661816476661816SQLselectgroup#,status,sequence#,archived,first_change#fromv$log;GROUP#STATUSSEQUENCE#ARCFIRST_CHANGE#1INACTIVE74YES19266392CURRENT3INACTIVE76NO75YES19519851947901SQLinsertintotest.ttvalues(dbms_flashback.get_system_change_number,b);已创建1行。SQLcommit;提交完成。SQLal

13、tersystemswitchlogfile;系统已更改。SQLselectgroup#,status,sequence#,archived,first_change#fromv$log;GROUP#STATUSSEQUENCE#ARCFIRST_CHANGE#CURRENT77NO1956233ACTIVE76YES1951985INACTIVE75YES1947901SQLselecthxfil,fhrba_seq,fhrba_bno,fhrba_boffromx$kcvfh;HXFILFHRBA_SEQFHRBA_BNOFHRBA_BOF1766618162766618163766618

14、16476661816SQLaltersystemcheckpoint;系统已更改。SQLselecthxfil,fhrba_seq,fhrba_bno,fhrba_boffromx$kcvfh;HXFILFHRBA_SEQFHRBA_BNOFHRBA_BOF177916277916377916477916SQLselect*fromtest.tt;IDNAME1956113a1956225bSQLselectgroup#,status,sequence#,archived,first_change#fromv$log;GROUP#STATUSSEQUENCE#ARCFIRST_CHANGE#

15、1CURRENT2INACTIVE3INACTIVE77NO195623376YES195198575YES1947901SQLinsertintotest.ttvalues(dbms_flashback.get_system_change_number,c);已创建1行。SQLcommit;提交完成。SQLselectgroup#,status,sequence#,archived,first_change#fromv$log;GROUP#STATUSSEQUENCE#ARCFIRST_CHANGE#1CURRENT2INACTIVE3INACTIVE77NO195623376YES1951

16、98575YES1947901SQLaltersystemswitchlogfile;系统已更改。SQLselect*fromtest.tt;IDNAME1956113a1956225b1956317cSQLselectgroup#,status,sequence#,archived,first_change#fromv$log;GROUP#STATUSSEQUENCE#ARCFIRST_CHANGE#ACTIVE77YES1956233INACTIVE76YES1951985CURRENT78NO1956324SQLinsertintotest.ttvalues(dbms_flashback

17、.get_system_change_number,d);已创建1行。SQLcommit;提交完成。SQLaltersystemswitchlogfile;系统已更改。SQLselect*fromtest.tt;IDNAME1956113a1956225b1956317c1956472d-总共往tt表里插入了4条数据，对应的id值(通过dbms_flashback.get_system_change_number获得的)都大于sequence#=76所对应的first_change#:1951985,因此在恢复db时sequence#=76的归档日志会被用到，还会用到那些归档日志呢？要看tt表

18、中对应的id值落在了那些归档日志的FIRST_CHANGE#和NEXT_CHANGE#之内，如果落在其中，则恢复时这个归档日志就会被用到，就这个例子而言，76，77，78号归档日志在恢复db时都会被用到，接下来的恢复过程也会验证这一点SQLselectsequence#,first_change#,next_change#fromv$archived_log2wheresequence#in(76,77,78)andresetlogs_id=666280390;SEQUENCE#FIRST_CHANGE#NEXT_CHANGE#761951985195623377195623319563247

19、819563241956480-通过dumpdatafileheader中的信息发现datafileheader上不仅记录了checkpoint_change#,更重要的是记录了checkpoint_change#所在的redosequence#:SQLaltersessionseteventsimmediatetracenameFILE_HDRSlevel12;会话已更改。tracefile中最有用的信息莫过于：Checkpointedatscn:0 x0000.001dd9e410/01/200816:30:40-checkpoint_change#thread:1rba:(0 x4e.2

20、.10)-sequence#(rba的含义在下面会有详细介绍)SQLselecthxfil,fhrba_seq,fhrba_bno,fhrba_boffromx$kcvfh;HXFILFHRBA_SEQFHRBA_BNOFHRBA_BOF179216279216379216479216SQLshutdownimmediate数据库已经关闭。已经卸载数据库。ORACLE例程已经关闭。-拷贝备份的datafile回来SQLstartupORACLE例程已经启动。TotalSystemGlobalArea163577856bytesFixedSizeVariableSizeDatabaseBuffe

21、rsRedoBuffers1247876bytes92276092bytes67108864bytes2945024bytes数据库装载完毕。ORA-01113:文件1需要介质恢复ORA-01110:数据文件1:E:ORACLEPRODUCT10.2.0ORADATATESTSYSTEM01.DBF-为什么会发出文件1需要介质恢复这样的提示，是因为controlfile中记录的checkpoint_change#是:1967625，而datafileheader上记录的checkpoint_change#是：1955692SQLselectcheckpoint_change#fromv$dat

22、abase;CHECKPOINT_CHANGE#1967625SQLselectcheckpoint_change#,checkpoint_timefromv$datafile_header;CHECKPOINT_CHANGE#CHECKPOINT_TIME19556922008/10/0116:17:2419556922008/10/0116:17:2419556922008/10/0116:17:2419556922008/10/0116:17:24SQLselectcheckpoint_change#,checkpoint_timefromv$datafile;CHECKPOINT_CH

23、ANGE#CHECKPOINT_TIME19676252008/10/0119:06:2119676252008/10/0119:06:2119676252008/10/0119:06:2119676252008/10/0119:06:21SQLselectcheckpoint_change#,checkpoint_timefromv$thread;CHECKPOINT_CHANGE#CHECKPOINT_TIME19676252008/10/0119:06:21-下面通过dumpdatafileheader中的信息来观查checkpoint_change#和rba的信息，来看看oracle到

24、底在恢复时是如何使用归档日志的。SQLaltersessionseteventsimmediatetracenameFILE_HDRSlevel12;会话已更改。tracefile中每个datafile都有一段对应的描述，内容摘录如下：DATAFILE#1:(name#7)E:ORACLEPRODUCT10.2.0ORADATATESTSYSTEM01.DBF中间无关内容省略Checkpointedatscn:0 x0000.001dd76c10/01/200816:17:24thread:1rba:(0 x4c.19da.10)-0racle在恢复时最有用的就是Checkpointedats

25、cn：0 x0000.001dd76c和thread:1rba:(0 x4c.19da.10)了DATAFILE#2:(name#1)E:ORACLEPRODUCT10.2.0ORADATATESTTEST.DBF中间无关内容省略Checkpointedatscn:0 x0000.001dd76c10/01/200816:17:24thread:1rba:(0 x4c.19da.10)DATAFILE#3:(name#5)E:ORACLEPRODUCT10.2.0ORADATATESTSYSAUX01.DBF中间无关内容省略Checkpointedatscn:0 x0000.001dd76c1

26、0/01/200816:17:24thread:1rba:(0 x4c.19da.10)DATAFILE#4:(name#6)E:ORACLEPRODUCT10.2.0ORADATATESTUNDOTBS01.DBF中间无关内容省略Checkpointedatscn:0 x0000.001dd76c10/01/200816:17:24thread:1rba:(0 x4c.19da.10)-而上面tracefile中记录的Checkpointedatscn：0 x0000.001dd76c转化为10进制数：SQLselectto_number(001dd76c,xxxxxxxx)fromdual

27、;TO_NUMBER(001DD76C,XXXXXXXX)1955692而1955692正是我们在最开始备份时记录下来的checkpoint_change#,另外检查点发生的时间其实也是吻合的：10/01/200816:17:24，也许有人说查询:selectcheckpoint_change#,checkpoint_timefromv$datafile_header;其实读取的就是数据文件头，结果当然是一样的，呵呵，没错，不论是上面查询还是dumpdatafileheader其实信息的来源都是来自datafileheader。只是dump出来我们看的更加直观一些，其实在数据字典中也提供了类似

28、的信息，如上面执行的查询：selecthxfil,fhrba_seq,fhrba_bno,fhrba_boffromx$kcvfh;为什么要查询x$kcvfh,是因为x$kcvfh是v$datafile_header的源，这个大家可以查看v$fixed_view_definition而得知。其实fhrba_seq,fhrba_bno,fhrba_bof这3个字段对应的就是rba，rba的意思是：RecententriesintheredothreadofanOracleinstanceareaddressedusinga3-partredobyteaddress,orRBA.AnRBAisco

29、mprisedofthelogfilesequencenumber(4bytes)thelogfileblocknumber(4bytes)thebyteoffsetintotheblockatwhichtheredorecordstarts(2bytes)在datafileheader上记录rba，在恢复时就能非常准确的知道需要哪个日志文件(通过thelogfilesequencenumber)以及哪个block(通过thelogfileblocknumber)以及在这个日志block上从哪个byte开始读取恢复(通过thebyteoffset)下面我们来接着上面打开db时的提示来恢复db，

30、验证一下：SQLalterdatabaseopen;alterdatabaseopen*第1行出现错误:ORA-01113:文件1需要介质恢复ORA-01110:数据文件1:E:ORACLEPRODUCT10.2.0ORADATATESTSYSTEM01.DBFSQLrecoverdatabase;ORA-00279:更改1955692（在10/01/200816:17:24生成）对于线程1是必需的ORA-00289:建议:E:ORACLEPRODUCT10.2.0FLASH_RECOVERY_AREATESTARCHIVELOG2008_10_01O1_MF_1_76_%U_.ARCORA-

31、00280:更改1955692（用于线程1）在序列#76中指定日志:=suggested|filename|AUTO|CANCEL-这里为什么会从1955692开始恢复db,原因当然就是备份时db发生检查点其对应的checkpoint_change#是1955692,这个我们在最开始的时候就提到过，说在备份时会用到这个值：1955692,那么序列#76就是如何来的呢？其实就是从rba转化来得：备份时候datafileheader的dump信息上面已经显示出来了,其实rba是：thread:1rba:(0 x4c.19da.10)根据rba表示的意义把4c转化成10进制数不正是：4*16+12(

32、16进制的c)=76,那么sequence#=76的归档日志文件O1_MF_1_76_%U_.ARC其实并不会在恢复时完全用到,而是从block：19da转化为10进制数是：SQLselectto_number(19da,xxxx)fromdual;TO_NUMBER(19DA,XXXX)6618也就是从6618#block开始恢复下面开始恢复：接着上面要求恢复的提示敲回车：ORA-00279:更改1956233（在10/01/200816:27:12生成）对于线程1是必需的ORA-00289:建议:E:ORACLEPRODUCT10.2.0FLASH_RECOVERY_AREATESTARC

33、HIVELOG2008_10_01O1_MF_1_77_%U_.ARCORA-00280:更改1956233（用于线程1）在序列#77中ORA-00278:此恢复不再需要日志文件E:ORACLEPRODUCT10.2.0FLASH_RECOVERY_AREATESTARCHIVELOG2008_10_01O1_MF_176_4G6F313F_.ARC指定日志:=suggested|filename|AUTO|CANCELsequence#=76的日志已经恢复，接下来需要77#日志：恢复时到底需要那些归档日志可以通过查看v$recovery_log来获得：v$recovery_log的信息就是通

34、过比较controlfile中的checkpoint_change#和datafileheader上的checkpoint_change#而产生的，如果我们在恢复时把备份的controlfile和datafile一同拷贝回来（不要拷贝redo），那么肯定在v$recovery_log不会查到任何信息。SQLselectsequence#fromv$recovery_log;SEQUENCE#7778SQL在76#归档日志恢复之后再来观察一下数据文件头上checkpoint_change#和rba的变化情况:checkpoint_change#信息：SQLselectcheckpoint_cha

35、nge#,checkpoint_timefromv$datafile_header;CHECKPOINT_CHANGE#CHECKPOINT_TIME19562332008/10/0116:27:1219562332008/10/0116:27:1219562332008/10/0116:27:1219562332008/10/0116:27:12SQLrba信息：SQLselecthxfil,fhrba_seq,fhrba_bno,fhrba_boffromx$kcvfh;HXFILFHRBA_SEQFHRBA_BNOFHRBA_BOF17720277203772047720SQL此时再恢复

36、db时会使用sequence#=77的归档日志，同时是从第二个日志block开始使用的，因为日志文件头占用1个block，如果有人通过dd命令做过redofile从文件系统和raw转化的话应该知道redo的头占用1个block，不过这个可能也和os有关的，不同的os,redo的头块也可能会占用不同个数的block，具体没有做过太深入的研究。接着恢复：ORA-00279:更改1956324（在10/01/200816:30:40生成）对于线程1是必需的ORA-00289:建议:E:ORACLEPRODUCT10.2.0FLASH_RECOVERY_AREATESTARCHIVELOG2008_1

37、0_01O1_MF_1_78_%U_.ARCORA-00280:更改1956324（用于线程1）在序列#78中ORA-00278:此恢复不再需要日志文件E:ORACLEPRODUCT10.2.0FLASH_RECOVERY_AREATESTARCHIVELOG2008_10_01O1_MF_1_77_4G6F9JSW_.ARC指定日志:=suggested|filename|AUTO|CANCEL查询一下checkpoint_change#和rba的信息：上面通过查询view验证过了，这次dump一下datafileheader来看看：SQLaltersessionseteventsimmed

38、iatetracenameFILE_HDRSlevel12;会话已更改。tracefile主要信息：（仅摘录一个文件的信息，4个文件的信息其实都相同）DATAFILE#1:（name#7）E:ORACLEPRODUCT10.2.0ORADATATESTSYSTEM01.DBF（省去无关的信息）Checkpointedatscn:0 x0000.001dd9e410/01/200816:30:40thread:1rba:（0 x4e.2.0）这里只转化一下sequence#:4e看看是否是78就可以了4*16+14（16进制的e）=78正好是78，也就是恢复时下一个要使用的归档日志。接着恢复：O

39、RA-00279:更改1956324（在10/01/200816:30:40生成）对于线程1是必需的ORA-00289:建议:E:ORACLEPRODUCT10.2.0FLASH_RECOVERY_AREATESTARCHIVELOG2008_10_01O1_MF_1_78_%U_.ARCORA-00280:更改1956324(用于线程1)在序列#78中ORA-00278:此恢复不再需要日志文件E:ORACLEPRODUCT10.2.0FLASH_RECOVERY_AREATESTARCHIVELOG2008_10_01O1_MF_1_77_4G6F9JSW_.ARC指定日志:=suggest

40、ed|filename|AUTO|CANCEL已应用的日志。完成介质恢复。SQL78#归档日志恢复之后checkpoint_change#可以达到1956480,通过下面查询78#归档日志的next_change#可以得知：SQLselectsequence#,first_change#,next_change#fromv$archived_log2wheresequence#in(76,77,78)andresetlogs_id=666280390;SEQUENCE#FIRST_CHANGE#NEXT_CHANGE#76195198519562337719562331956324781956

41、3241956480SQL但目前datafileheader的checkpoint_change#和rba信息是：1967624以及81128116,是因为在恢复时系统自动读取了联机日志。SQLselectcheckpoint_change#,checkpoint_timefromv$datafile_header;CHECKPOINT_CHANGE#CHECKPOINT_TIME19676242008/10/0119:06:2119676242008/10/0119:06:2119676242008/10/0119:06:2119676242008/10/0119:06:21SQLselec

42、thxfil,fhrba_seq,fhrba_bno,fhrba_boffromx$kcvfh;HXFILFHRBA_SEQFHRBA_BNOFHRBA_BOF181128116281128116381128116481128116SQLselectgroup#,status,sequence#,archived,first_change#fromv$log;GROUP#STATUSSEQUENCE#ARCFIRST_CHANGE#1INACTIVE80YES19617503CURRENT81NO19670882INACTIVE79YES1956480SQL-oracle为什么能自动读取red

43、o来恢复，是因为在controlfile中记录了redo的信息SQLselectsequence#,checkpoint_change#,last_redo_change#fromv$thread;SEQUENCE#CHECKPOINT_CHANGE#LAST_REDO_CHANGE#8119676251967375SQL-下面把最新的redo暂时隐藏起来，也就是说不让其自动应用redo再来观查一下oracle是如何要寻找redo的：SQLshutdownimmediateORA-01109:数据库未打开已经卸载数据库。ORACLE例程已经关闭。-拷贝备份的数据文件，同时把redo隐藏起来SQ

44、LstartupORACLE例程已经启动。TotalSystemGlobalArea163577856bytesFixedSizeVariableSizeDatabaseBuffersRedoBuffers数据库装载完毕。1247876bytes92276092bytes67108864bytes2945024bytesORA-01113:文件1需要介质恢复ORA-01110:数据文件1:E:ORACLEPRODUCT10.2.0ORADATATESTSYSTEM01.DBFSQLrecoverdatabase;ORA-00279:更改1955692（在10/01/200816:17:24生成

45、）对于线程1是必需的ORA-00289:建议:E:ORACLEPRODUCT10.2.0FLASH_RECOVERY_AREATESTARCHIVELOG2008_10_01O1_MF_1_76_%U_.ARCORA-00280:更改1955692（用于线程1）在序列#76中指定日志:=suggested|filename|AUTO|CANCELORA-00279:更改1956233（在10/01/200816:27:12生成）对于线程1是必需的ORA-00289:建议:E:ORACLEPRODUCT10.2.0FLASH_RECOVERY_AREATESTARCHIVELOG2008_10_

46、01O1_MF_1_77_%U_.ARCORA-00280:更改1956233（用于线程1）在序列#77中ORA-00278:此恢复不再需要日志文件E:ORACLEPRODUCT10.2.0FLASH_RECOVERY_AREATESTARCHIVELOG2008_10_01O1_MF_1_76_4G6F313F_.ARC指定日志:=suggested|filename|AUTO|CANCELORA-00279:更改1956324（在10/01/200816:30:40生成）对于线程1是必需的ORA-00289:建议:E:ORACLEPRODUCT10.2.0FLASH_RECOVERY_AR

47、EATESTARCHIVELOG2008_10_01O1_MF_1_78_%U_.ARCORA-00280:更改1956324（用于线程1）在序列#78中ORA-00278:此恢复不再需要日志文件E:ORACLEPRODUCT10.2.0FLASH_RECOVERY_AREATESTARCHIVELOG2008_10_01O1_MF_1_77_4G6F9JSW_.ARC指定日志:=suggested|filename|AUTO|CANCELORA-00283:恢复会话因错误而取消ORA-00313:无法打开日志组2（用于线程1）的成员ORA-00312:联机日志2线程1:E:ORACLEPRO

48、DUCT10.2.0ORADATATESTREDO02.LOGORA-27041:无法打开文件OSD-04002:无法打开文件O/S-Error:（OS2）系统找不到指定的文件。ORA-01112:未启动介质恢复-oracle为什么会找REDO02.LOG,因为REDO02.LOG对应的sequence#是79,看看在controlfile中记录的redo信息就知道了,v$log的信息来自controlfile,这也说明了为什么我们在恢复db时如果controlfile是最新的话那么在恢复时redo会被自动应用，而当controlfile是从备份中恢复过来（也就是说controlfile不是最

49、新的，是备份的，在恢复时需要使用usingbackupcontrolfile子句）的话在恢复db时redo不会被自动应用，而需要我们手动输入来尝试看看oracle到底需要哪个redoSQLselectgroup#,status,sequence#,first_change#fromv$log;GROUP#STATUSSEQUENCE#FIRST_CHANGE#1INACTIVE8019617503CURRENT8119670882INACTIVE791956480SQL验证一下使用usingbackupcontrolfile自己恢复db时使用redo的情况SQLshutdownimmediat

50、eORA-01109:数据库未打开已经卸载数据库。ORACLE例程已经关闭。SQL-拷贝备份的datafileandcontrolfile以及最新的redo回来SQLstartupORACLE例程已经启动。TotalSystemGlobalArea163577856bytesFixedSize1247876bytesVariableSize92276092bytesDatabaseBuffers67108864bytesRedoBuffers2945024bytes数据库装载完毕。ORA-00314:日志1（用于线程1）要求的序号与不匹配ORA-00312:联机日志1线程1:E:ORACLEP

51、RODUCT10.2.0ORADATATESTREDO01.LOGSQL为什么在opendb时会发出这样的提示：看看controlfileanddatafile_header中记录的checkpoint_change#:SQLselectcheckpoint_change#fromv$database;CHECKPOINT_CHANGE#1955692SQLselectcheckpoint_change#,checkpoint_timefromv$datafile_header;CHECKPOINT_CHANGE#CHECKPOINT_TIME19556922008/10/0116:17:24

52、19556922008/10/0116:17:2419556922008/10/0116:17:2419556922008/10/0116:17:24SQLselectcheckpoint_change#,checkpoint_timefromv$datafile;CHECKPOINT_CHANGE#CHECKPOINT_TIME19556922008/10/0116:17:2419556922008/10/0116:17:2419556922008/10/0116:17:2419556922008/10/0116:17:24SQLselectcheckpoint_change#,checkp

53、oint_timefromv$thread;CHECKPOINT_CHANGE#CHECKPOINT_TIME19556922008/10/0116:17:24SQLselecthxfil,fhrba_seq,fhrba_bno,fhrba_boffromx$kcvfh;HXFILFHRBA_SEQFHRBA_BNOFHRBA_BOF176661816276661816376661816476661816SQLselectgroup#,status,sequence#,first_change#fromv$log;GROUP#STATUSSEQUENCE#FIRST_CHANGE#1INACT

54、IVE7419266393INACTIVE7519479012CURRENT761951985-很显然v$log的信息是来自controlfile的，和上面新的controlfile中记录的v$log的信息对比，当然doc上也明确提到v$log的信息来自controlfile从上面的查询看出来controlfile和datafile中记录的checkpoint_change#都是1955692，而且controlfile中记录的redo的checkpoint_change#也是1955692；但是再来看看redo中记录的checkpoint_change#又是多少呢？我发现redoheader

55、上并不会记录checkpoint_change#，这一点大家可以验证，当然当checkpoint发生时很多doc上都提到会把当前的scn更新到controlfile和datafileheader上，并没有提到会更新再redo的头上。SQLaltersessionseteventsimmediatetracenameREDOHDRlevel12;会话已更改。SQL从下面的tracefile中我们知道大致判断LOGFILE#1(#2,#3)这一段的信息和controlfile中记录的一致，我在这里认定LOGFILE#1(#2,#3)这段信息是来自controlfile中：从seq(sequence

56、#)就可以判断出来：0 x0000004a,0 x0000004c,0 x0000004b分别对应10进制的74，76，75,而且LOGFILE#2的Nextscn:0 xffff.ffffffff，说明它表示是当前redo,这些内容都和controlfile中记录的完全一致；但是从FILEHEADER:这一段开始发现它的内容才是真真来自redo：因为LOGFILE#1(#2,#3)对应的Seq#分别是：0000000080,0000000079，0000000081而且LOGFILE#3的Nextscn:0 xffff.ffffffff，说明它表示是当前redo那么在redo的header上

57、是否记录controlfile的信息呢，应该不记录，这里是这条命令：altersessionseteventsimmediatetracenameREDOHDRlevel12;执行时要从controlfile里读取redo的路径以及一些相关信息(就是LOGFILE#1(#2,#3)这一段)从而再到redo的header上真真读取redo的内容。由于controlfile中记录的redo的信息和redoheader上记录的信息不符，所以打开db时出现了上面的提示：ORA-00314:日志1(用于线程1)要求的序号与不匹配ORA-00312:联机日志1线程1:E:ORACLEPRODUCT10.2

58、.0ORADATATESTREDO01.LOGtracefile的信息如下：LOGFILE#1:(name#2)E:ORACLEPRODUCT10.2.0ORADATATESTREDO01.LOGThread1redologlinks:forward:2backward:0siz:0 x2000seq:0 x0000004ahws:0 x4bsz:512nab:0 x4ebflg:0 x1dup:1Archivelinks:fwrd:0back:0Prevscn:0 x0000.001d6386Lowscn:0 x0000.001d65ef09/30/200823:04:54Nextscn:0

59、 x0000.001db8fd10/01/200812:59:45FILEHEADER:CompatibilityVsn=169869568=0 xa200100DbID=1963034992=0 x75018970,DbName=TESTActivationID=1964389871=0 x751635efControlSeq=3855=0 xf0f,Filesize=8192=0 x2000FileNumber=1,Blksiz=512,FileType=2LOGdescrip:Thread0001,Seq#0000000080,SCN0 x0000001def16-0 x0000001e

60、03f0thread:1nab:0 x1ffdseq:0 x00000050hws:0 x2eot:0dis:0resetlogscount:0 x27b6a1c6scn:0 x0000.0015dd61Lowscn:0 x0000.001def1610/01/200817:16:54Nextscn:0 x0000.001e03f010/01/200819:00:41Enabledscn:0 x0000.0015dd6109/24/200813:53:10Threadclosedscn:0 x0000.001def1610/01/200817:16:54Diskcksum:0 x2a74Cal