用_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,启动数据库。

相关文章

4条评论

  1. 我发现你们在写技术时总是不给别人讲原理和原因细节啊,这样才显得高深

  2. adjust scn level n,n是表示增进n个g的scn,现在dependent scn wrap是261,而wrap位的一个1即为4g,所以要增进4×261

发表评论

电子邮件地址不会被公开。 必填项已用*标注

This site uses Akismet to reduce spam. Learn how your comment data is processed.