一次难忘的协助解决Oracle RAC恢复过程

解决过程

1）了解基本状况

   前一天晚上18点左右关闭RAC，重启小型机，重启 RAC，发现两个RAC组4个实例启动正常，另一个RAC，两个实例无法正常启动。

2) 小型机工程师，诊断Oracle 裸设备所在的datavg和archvg是正常的。

2) 请求一个朋友远程建立VPN协助，经过二小时左右的诊断，初步确定可能是OCR（OCR---Oracle Cluster Registry）有问题, 建议恢复前面使用正常的OCR

   他无法这样实施，风险很大，弄得不好，会把正常启动的RAC宕掉。他建议请求上海神码的人解决。

3) 经许言联系，晚上１０点多与上海神码的DBA联系上。

　将基本状况作一沟通，经过２个多小时的诊断，也无法确定问题的所在。

　最后他建议重新创建数据库，客户的要求，原RAC组名orcl最好不要变，经尝试修改orcl在集群里的信息，发现无法实施。

　所以从这一点看，我那朋友的判断是正确的。最后只得重新创建新的RAC组DZJC和数据库实例。创建数据库实例需要很多信息。

　由于Oracle实例的后台警告日志文件极大２５０Ｍ左右，基本无法从中提取关于ORACLE表空间的创建信息，只能根据原始的数据库配置文档来做，再加上

　应用程序提供商工程师的回忆，基本确定了数据库的组成,并且在创建时都要求尽量大。

　这个过程是漫长的，大约到凌晨４点半钟解决。至此所有相关的人都松了一口气。

 

４) Import　Oracle DMP文件，持续半小时。查看数据库倒入的数据是否正确，发现丢失一个Database Link（不知道是真的丢了，还是原来就没有）

　重新建立Database Link。重新编译无效的数据库对象，一切正常。

5）客户模拟RAC的故障转移功能。故意关掉某台小型机上的所有实例。发现应用程序一切正常。

 此过程大约持续了10几分钟。至此，大功告成。

6）赶回苏州家里，已经是凌晨6点多了。

这一次解决问题的过程，让我在正常环境下，无法学到的很多东西。包括协调相关工程师（不是我做的），IBM AIX 集群相关的（lslv/lsvg  clstat 启动/关闭smitty clstart/clstop），Oracle 集群实例的创建（也只是知道一个大概），ORACLE 集群软件的使用（srvctl/crs_stat/crsctl/ocrconfig）。要是下次遇到类似的问题，我能解决的话，那真是再熬一两个晚上都是值得的。

给我自己切身的感受是，书到用时方恨少；山外青山楼外楼；学无止境。