记这两天恢复数据库的一个过程
这两天遇到客户因为误操作，将RAC环境下的所有共享存储格式化掉了，客户只有一个最近的RMAN的0级全备（无数据文件，无控制文件，无归档日志，无redo日志），需要帮忙恢复。将大致的恢复过程记录一下。
0.恢复共享存储是第一步，给存储原厂打电话，原厂推是os的问题，让给os打电话，结果只能初始化了，最后只能恢复到被识别的状态，一切从头开始。
1.因为集群软件是装在本地的，所以恢复rac的集群环境，只需要将ocr和vdisk重新配置一下，就可以了。可以执行root.sh脚本来进行重新的配置，如果中间报一个已经被配置过的提示，那就先用dd清除ocr和vdisk的信息，并删除相应的目录文件，如下:
rm -rf /usr/tmp/.oracle /var/tmp/.oracle /tmp/.oracle /etc/oracle/* /var/opt/oracle/*
rm -rf /etc/init.cssd /etc/init.crs* /etc/init.evmd /etc/init.d/init.cssd /etc/init.d/init.crs
rm -rf /etc/init.d/init.crsd /etc/init.d/init.evmd /etc/rc3.d/K96init.crs /etc/rc3.d/S96init.crs
rm -rf /etc/rc.d/rc2.d/K96init.crs /etc/rc.d/rc2.d/S96init.crs
2.恢复完集群环境之后，开始恢复数据库。因为询问到客户有去年年底的一个RMAN的0级全备，以及控制文件的快照没有放到共享存储上，故可以采用重建控制文件+restore备份的方法来恢复。中途遇到很多问题，因为所有的日志备份均放到共享存储下的，故这次恢复在recover的步骤时是没有日志用来补充的。所以restore databse until 时间后，再recover，再alter database open resetlogs后，会报一个需要恢复数据文件的错误提示，操作的时候运气不好，刚好遇到的是需要恢复datafile 1，再折腾了几个小时候，终于发现按照正常的手段是行不通的.
3.因为没有日志，无法使得数据库达到一致性，所以只有采取修改隐藏参数的办法来忽略数据库的不一致，来强行打开数据库.先将数据库打到mount状态，在做完restore，recover之后，将隐藏参数修改 alter system set "_allow_resetlogs_corruption"=true scope=spfile;再shutdown数据库，启动到mount状态之后，alter database open resetlogs; resetlogs打开数据库后，运气仍然不是太好，又遇到了ORA-00600 2662号的错误.
4. 当使用修改_allow_resetlogs_corruption ，再打开数据库时遇到了ORA-00600 2662号的错误， 如果SCN相差不多，可以通过多次重起数据库解决 ，但是这次遇到的SCN相差很大(通过查v$datafile和v$datafile_header的CHECKPOINT_CHANGE#来判断)，这个时候只有再修改另外一个隐藏参数 _minimum_giga_scn来解决问题._minimum_giga_scn的作用是推进SCN号，该参数值的单位是billion，也就是说设置了该参数后，SCN号会变成XX* (1024*1024*1024) ，XX可以通过2662的几个参数来确定. 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.
5.当修改了2个隐藏参数之后，数据库终于能启动了，但是alert日志还是会报一些600的错误，暂时忽略.用exp(expdp可能会报错)将数据全部导出，重建新的实例，再用imp导入数据到新的库中.exp的时候需要注意一个参数compress，这个参数可以降低HWM，使的imp的时候，时间相对尽量少一些.