用_minimum_giga_scn解决无法启动的数据库

今天遇到一个数据库无法启动，看到alertlog中主要是ora 600和[2662]的报错：

其中alertlog中报错：

遇到ora-600和2662的问题，我们一般有2种方法解决：

其中n的运算如下：
根据alertlog中的报错：
ORA-00600: internal error code, arguments: [2662], [0], [43556042], [261], [2396789971], [4194729], [], []
这边，我们把2662后的参数[2662],[a],[b],[c],[d],[e]…
[a] Current SCN WRAP
[b] 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：
其中的隐含参数：

alertlog中：

看到报错信息中的scn还是没有到达目标scn。版本是9i的，应该不会限制啊，根据在某些10g版本中需要另外一个隐含参数_allow_error_simulation，才能增进scn，继续修改初始化参数，尝试启动：

alertlog中报错依旧：

看来是不能用上述的方法了，小熊这个时候再次提出了一个隐含参数：_minimum_giga_scn，把该参数设置成1047再尝试启动：

数据库终于起来了！

查询了一下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，启动数据库。