通过_minimum_giga_scn消除SCN异常

郑全

在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