在Oracle 10g中,可以通过隐含参数_minimum_giga_scn来推进SCN,每个1将SCN推进到1G。SQL>?select?ksppinm,ksppdesc?from?x$ksppi ??2??where?ksppinm?like?'%giga%' ??3??/ KSPPINM????????????????????????KSPPDESC ------------------------------?--------------------------------------------- _minimum_giga_scn??????????????Minimum?SCN?to?start?with?in?2^30?units 以下将SCN 0xb5f.f28cc1fd进行一个转换运算,获得十进制值,再转换成以_minimum_giga_scn为单位。 SQL>?col?scn?for?99999999999999999 SQL>?select?to_number('b5ff28cc1fd','xxxxxxxxxxxx')?scn?from?dual; ???????SCN ------------------ ????12506719109629 SQL>?select?12506719109629/1024/1024/1024?giga?from?dual; ??????GIGA ---------- 11647.7898 对于这个数据库,将该参数设置为11649,稍微多推进一点,数据库的错误就可以被成功消除了。我们首先在初始化参数文件中增加如下两个参数。 *._allow_resetlogs_corruption=true *._minimum_giga_scn=11649 然后尝试打开数据库。 SQL>?startup?mount?pfile=initdma_eygle.ora ORACLE?例程已经启动。 Total?System?Global?Area?1.3640E+10?bytes Fixed?Size??????????????????2115392?bytes Variable?Size????????????1889450176?bytes Database?Buffers?????????1.1744E+10?bytes Redo?Buffers????????????????4259840?bytes 数据库装载完毕。 SQL>?recover?database?using?backup?controlfile?until?cancel; ORA-00279:?更改?12506717382696?(在?12/30/2011?19:22:18?生成)?对于线程?1是必需的 ORA-00289:?建议:/archive/DMA/archivelog/2011_12_31/o1_mf_1_5_%u_.arc ORA-00280:?更改?12506717382696?(用于线程?1)?在序列?#5?中 指定日志:?{<RET>=suggested?|?filename?|?AUTO?|?CANCEL} cancel ORA-01547:?警告:?RECOVER?成功但?OPEN?RESETLOGS?将出现如下错误 ORA-01194:?文件?1?需要更多的恢复来保持一致性 ORA-01110:?数据文件?1:?'/dma_sys/sysdata/dma/system01.dbf' ORA-01112:?未启动介质恢复 SQL>?alter?database?open?resetlogs; alter?database?open?resetlogs * 第?1?行出现错误: ORA-00603:?ORACLE?服务器会话因致命错误而终止 此时观察告警日志文件,可以发现4000错误已经不再出现,但是由于UNDO的4194错误导致数据库再次崩溃。4194错误的解决就容易很多了。 在以上尝试启动时,告警日志的提示如下。 Sat?Dec?31?16:06:30?2011 alter?database?open?resetlogs Sat?Dec?31?16:06:30?2011 RESETLOGS?is?being?done?without?consistancy?checks.?This?may?result?in?a?corrupted?database.?The?database?should?be?recreated. RESETLOGS?after?incomplete?recovery?UNTIL?CHANGE?12506717382696 Resetting?resetlogs?activation?ID?984777556?(0x3ab28354) Sat?Dec?31?16:07:12?2011 Setting?recovery?target?incarnation?to?3 Sat?Dec?31?16:07:12?2011 Advancing?SCN?to?12508018507776?according?to?_minimum_giga_scn 注意以上日志提示,因为_minimum_giga_scn参数的设置,将SCN增进到了12508018507776。 继续看打开数据库接下来的日志信息。 Sat?Dec?31?16:07:12?2011 Assigning?activation?ID?984841183?(0x3ab37bdf) Thread?1?opened?at?log?sequence?1 ??Current?log#?4?seq#?1?mem#?0:?/dma_sys/sysdata/dma/redo04a.log ??Current?log#?4?seq#?1?mem#?1:?/dma_sys/sysdata/dma/redo04b.log Successful?open?of?redo?thread?1 Sat?Dec?31?16:07:12?2011 MTTR?advisory?is?disabled?because?FAST_START_MTTR_TARGET?is?not?set Sat?Dec?31?16:07:12?2011 SMON:?enabling?cache?recovery Sat?Dec?31?16:07:13?2011 Successfully?onlined?Undo?Tablespace?1. Dictionary?check?beginning Tablespace?'TEMP'?#3?found?in?data?dictionary,?but?not?in?the?controlfile.?Adding?to?controlfile. File?#181?found?in?data?dictionary?but?not?in?controlfile. Creating?OFFLINE?file?'MISSING00181'?in?the?controlfile. This?file?can?no?longer?be?recovered?so?it?must?be?dropped. Dictionary?check?complete 注意这里提示说181号文件在数据字典(file$)中存在,但是在控制文件中不存在,现在被添加回控制文件,命名为MISSING00181。这也告诉我们,试图通过重建控制文件以去掉某个文件的做法是根本错误的。 这里的181号文件就是被误操作删除掉的文件。提示也告知用户,当数据库被resetlogs打开,这个文件将不能够再通过恢复加入到数据库中,只能被删除。 接下来的下列提示说应当添加临时表空间。 ********************************************************************* Sat?Dec?31?16:07:13?2011 SMON:?enabling?tx?recovery WARNING:?The?following?temporary?tablespaces?contain?no?files. ?????????This?condition?can?occur?when?a?backup?controlfile?has ?????????been?restored.??It?may?be?necessary?to?add?files?to?these ?????????tablespaces.??That?can?be?done?using?the?SQL?statement: ? ?????????ALTER?TABLESPACE?<tablespace_name>?ADD?TEMPFILE ? ?????????Alternatively,?if?these?temporary?tablespaces?are?no?longer ?????????needed,?then?they?can?be?dropped. Sat?Dec?31?16:07:13?2011 ???????????Empty?temporary?tablespace:?TEMP ********************************************************************* Database?Characterset?is?ZHS16GBK |