如何强制打开无法启动的Oracle数据库

白鳝的洞穴 2020-04-13

2490

Oracle数据库如果因为系统掉电，存储故障等原因，可能出现无法打开的现象。当出现下面情况的时候：

ORA-00600: internal error code, arguments: [kccpb_sanity_check_2], [21173472],[21173471], [0x000000000], [], [], [], []

ORA-00600: internal error code, v arguments: [3020], [128], [1893626], [538764538], [], [], [], []

ORA-00600: internal error code, arguments : [2662], [37], [337162776], [37], [338630729], [8388617], [], []

那么我们可能遇到了因为数据库由于存储故障而导致UNDO/REDO不一致，造成数据库无法正常打开。处置这个问题在十多年前算是一个高技术的活，不少老DBA可能都有做类似的业务赚钱的经历。在90年代末新千禧的初年，搞一次这样的数据恢复，可能报价在3-5万一次，对于当时的物价水平和平均收入水平，可以说是天价了。

现在处置这样一个故障已经成为DBA的必备技能了。这个问题说白了是因为磁盘故障，导致数据文件的文件头与控制文件不一致，而数据块要进行REDO前滚的时候发现REDO/UNDO不一致，无法自动全滚导致的。要处理这类问题有一个基本的标注步骤，按照这个步骤去做，大多数情况都可以把数据库拉起来。不过拉起来的数据库可能还是存在一定的不一致，因此ORACLE官方也是建议拉起来后，把数据导出，然后重建数据库。老白在这些年里也经常能看到有些用户把通过特殊方式打开的数据库作为生产库长期使用的情况，一般也会提醒用户进行重建。事实上，在大多数场景中，如果强制拉起的数据库的不一致数据不影响用户的业务，那么数据库不重建的风险也是不大的。当然也不排除某些数据字典存在的不一致还有可能导致数据库宕机的可能性。不过如果你已经使用了好长时间，没有发现问题，那么这个数据库长期使用的风险也是极低的。

言归正传，老白下面给大家介绍一个修复类似错误，强制打开数据库的技巧。

步骤1：按需重建控制文件：如果我们遇到了ORA-00600: internal error code, arguments: [kccxxx] ... 这样的ORA-600错误，那么可能是控制文件出现了坏块或者不一致，这时候重建控制文件是必须的步骤，否则无法继续恢复。

步骤2：忽略不一致的REDO LOG，强制打开数据库

1、在原先的参数文件/oracle/init0819.ora中增加以下行：
_allow_error_simulation=TRUE(10g及其以上版本需要)
2、启动数据库到mount状态：
SQL> startup mount pfile=/oracle/init0819.ora;
3、调整SCN：
SQL> alter session set events '10015 trace name adjust_scn level 149';

(注：11g后adjust scn有所不同，请参考相关指示）
4、恢复数据库：
SQL> recover database using backup controlfile until cancel;
执行恢复后敲cancel
5、强制打开数据库：
SQL> alter database open resetlogs;

步骤3：如果此时遇到ORA-600 [4193]

数据库成功打开，但随即又宕掉，alert日志中出现很多如下报错：
ORA-00600: internal error code, arguments: [4193],
这是由于undo记录和redo中的记录不匹配导致
6、继续在init0819.ora中设置如下参数：
undo_management=manual
event='10513 trace name context forever, level 2'
event='10512 trace name context forever, level 1'
event='10511 trace name context forever, level 2'
event='10510 trace name context forever, level 1'
随后正常打开数据库，打开成功

步骤4：如果此时遇到ORA-600 [4194]等情况

ORA-600 [4XXX]一般都是和UNDO有关，4194错误等情况也是因为回滚段损坏导致，不过处理方法和[4193]有所不同，一般来说，需要通过trace文件，找到出现故障的RBS段，然后使用_offline_rollback_segments或者_corrupt_rollback_segments参数把这些回滚段放进去。这两个参数的含义是前者仅仅是把设置的回滚段暂时离线，以后如果有可能还可以再ONLINE，而后者直接把这些回滚段设置未故障的，经过处理后，这些回滚段无法再次离线。不过我们在遇到类似的问题的时候，一般来说都是回滚段无法恢复了，使用哪个参数的关系并不很大。

设置了这个参数后，可以再尝试阿凯数据库。一般情况下数据库可以正常打开。不过打开后数据库有可能再次当掉，这个情况和步骤3中的6号步骤情况类似，如果遇到就采用6号步骤的参数，停止相关的回滚操作。

强制打开数据库是死马当做活马医的最后步骤，在生产环境中是不可逆的，因此在操作前要先做好备份。另外也要确定没有其他更好的恢复方法的时候再使用这个办法。另外就是严格按照步骤来，千万不要轻易从网上随便百度一些方法来做。

oracle