Oracle：用_minimum_giga_scn 解決沒法啓動的數據庫

那天遇到一個數據庫沒法啓動，看到alertlog中主要是ora 600和[2662]的報錯：

SQL> startupORACLE instance started.Total System Global Area 1076850392 bytesFixed Size 736984 bytesVariable Size 536870912 bytesDatabase Buffers 536870912 bytesRedo Buffers 2371584 bytesDatabasemounted.ORA-01092: ORACLE instance terminated. Disconnection forced
SQL>

其中alertlog中報錯：

Completed: ALTER DATABASE MOUNT
Thu Jan 22 13:05:08 2009
ALTER DATABASE OPEN
Thu Jan 22 13:05:09 2009
Beginning crash recovery of 1 threads
Thu Jan 22 13:05:09 2009
Started first pass scan
Thu Jan 22 13:05:09 2009
Completed first pass scan
0 redo blocks read, 0 data blocks need recovery
Thu Jan 22 13:05:09 2009
Started recovery at
Thread 1: logseq 2, block 3, scn 0.43536037
Recovery of Online Redo Log: Thread 1 Group 1 Seq 2 Reading mem 0
Mem# 0 errs 0: /oracle/oradata/ora9i/redo01.log
Thu Jan 22 13:05:09 2009
Ended recovery at
Thread 1: logseq 2, block 3, scn 0.43556038
0 data blocks read, 0 data blocks written, 0 redo blocks read
Crash recovery completed successfully
Thu Jan 22 13:05:10 2009
Thread 1 advanced to log sequence 3
Thread 1 opened at log sequence 3
Current log# 2 seq# 3 mem# 0: /oracle/oradata/ora9i/redo02.log
Successful open of redo thread 1.
Thu Jan 22 13:05:10 2009
SMON: enabling cache recovery
Thu Jan 22 13:05:10 2009
Errors in file /oracle/admin/ora9i/udump/ora9i_ora_12968.trc:
ORA-00600: internal error code, arguments: [2662], [0], [43556042], [261], [2396789971], [4194729], ,

遇到ora-600和2662的問題，咱們通常有2種方法解決：

一種是在open的狀態下：用alter session set events 'IMMEDIATE trace name adjust_scn level n';

一種是在mount狀態下：用alter session set events '10015 trace name adjust_scn level n';

其中n的運算以下：
根據alertlog中的報錯：
ORA-00600: internal error code, arguments: [2662], [0], [43556042], [261], [2396789971], [4194729], ,
這邊，咱們把2662後的參數[2662],[a],,[c],[d],[e]…
[a] Current SCN WRAP
Current SCN BASE
[c] dependent SCN WRAP
[d] dependent SCN BASE
[e] Where present this is the DBA where the dependent SCN came from.

其中scn能夠用十六進制表示0Xffff.ffffffff。爲了方便，oracle把前面的4個字節表示scn wrap，後面的8個字節表示scn base。scn最低值是0X0000.00000000，最高值是0Xffff.ffffffff。高位是scn wrap，低位是scn base。根據報錯，咱們須要把scn增進到dependent SCN WRAP爲261。

而咱們增進的level n，n是表示1g（即1024×1024×1024），也就是說，調整是以g爲單位進行的。

而高位的scn wrap的一個1，即0X0001.00000000=0X000100000000（去掉便於分隔高低位的點）=100000000000000000000000000000000=2^32（即2乘以10的32次方）=4×2^30（4乘以2的30次方）=4×（1024×1024×1024）=4g。所以咱們要增長到的scn，根據level n，n表示g，調整的level爲4×261。即1044，再比這個數字大一些，咱們能夠設置成1045，1047均可以。

嘗試用上述的方法去解決。因爲是mount狀態，所以只能用10015 trace name的adjust scn：
其中的隱含參數：

cat initora9i.ora
……
*.user_dump_dest='/oracle/admin/ora9i/udump'
*._allow_resetlogs_corruption=TRUE
"initora9i.ora" 47 lines, 1465 characters

SQL> startup nomount pfile='?/dbs/initora9i.ora'ORACLE instance started.Total System Global Area 1076850392 bytesFixed Size 736984 bytesVariable Size 536870912 bytesDatabaseBuffers 536870912 bytesRedo Buffers 2371584 bytesSQL> alter database mount;Database altered.SQL> alter session set events '10015 trace name ADJUST_SCN level 1045';Sessionaltered.SQL> alter database open;alter database open
*ERROR at line 1:ORA-01092: ORACLE instance terminated. Disconnection forced

alertlog中：

Thu Jan 22 13:27:56 2009
SMON: enabling cache recovery
Thu Jan 22 13:27:56 2009
Errors in file /oracle/admin/ora9i/udump/ora9i_ora_13322.trc:
ORA-00600: internal error code, arguments: [2662], [0], [43576046], [261], [2396789971], [4194729], ,
Thu Jan 22 13:28:37 2009
Errors in file /oracle/admin/ora9i/udump/ora9i_ora_13322.trc:
ORA-00704: bootstrap process failure
ORA-00600: internal error code, arguments: [2662], [0], [43576046], [261], [2396789971], [4194729], ,
Thu Jan 22 13:28:37 2009
Error 704 happened during db open, shutting down database
USER: terminating instance due to error 704
Instance terminated by USER, pid = 13322
ORA-1092 signalled during: alter database open...

看到報錯信息中的scn仍是沒有到達目標scn。版本是9i的，應該不會限制啊，根據在某些10g版本中須要另一個隱含參數_allow_error_simulation，才能增進scn，繼續修改初始化參數，嘗試啓動：

cat initora9i.ora
……
*.user_dump_dest='/oracle/admin/ora9i/udump'
*._allow_resetlogs_corruption=TRUE
*._allow_error_simulation=TRUE
"initora9i.ora" 47 lines, 1465 characters

SQL> startup mount pfile='?/dbs/initora9i.ora'ORACLE instance started.Total System Global Area 1076850392 bytesFixed Size 736984 bytesVariable Size 536870912 bytesDatabase Buffers536870912 bytesRedo Buffers 2371584 bytesDatabase mounted.SQL> alter session set events '10015 trace name ADJUST_SCN level 20000';Session altered.SQL> alter database open;

alertlog中報錯依舊：

Ended recovery at
Thread 1: logseq 5, block 3, scn 0.43616049
0 data blocks read, 0 data blocks written, 1 redo blocks read
Crash recovery completed successfully
Thu Jan 22 13:41:49 2009
Thread 1 advanced to log sequence 6
Thread 1 opened at log sequence 6
Current log# 2 seq# 6 mem# 0: /oracle/oradata/ora9i/redo02.log
Successful open of redo thread 1.
Thu Jan 22 13:41:49 2009
SMON: enabling cache recovery
Thu Jan 22 13:41:49 2009
Errors in file /oracle/admin/ora9i/udump/ora9i_ora_13660.trc:
ORA-00600: internal error code, arguments: [2662], [0], [43616053], [261], [2396789971], [4194729], ,

看來是不能用上述的方法了，小熊這個時候再次提出了一個隱含參數：_minimum_giga_scn，把該參數設置成1047再嘗試啓動：

cat initora9i.ora
……
*.user_dump_dest='/oracle/admin/ora9i/udump'
#*._allow_resetlogs_corruption=TRUE
*._allow_error_simulation=TRUE
*._minimum_giga_scn=1047
"initora9i.ora" 47 lines, 1465 characters

SQL> startup mount pfile='?/dbs/initora9i.ora'ORACLE instance started.Total System Global Area 1076850392 bytesFixed Size 736984 bytesVariable Size 536870912 bytesDatabase Buffers536870912 bytesRedo Buffers 2371584 bytesDatabase mounted.SQL> alter database open;Database altered.SQL>

數據庫終於起來了！

查詢了一下orafaq，這個參數是表示Minimum SCN to start with in 2^30 units ，2乘以10的三十次方，也就是1024×1024×1024，也就是g了。這個參數是oracle723就開始有了，表示最小scn的起始值1g，咱們這邊的scn wrap有261，所以須要4×261，再比這個稍微大一些，就得出1047了。

總結：在通常狀況下，遇到ora-600，2662的報錯，能夠經過10015的adjust scn起來，可是遇到Current SCN WRAP和dependent SCN WRAP相距比較遠，經過上述方法起不來，咱們能夠經過隱含參數_minimum_giga_scn直接設置最小scn，啓動數據庫。