解决过程
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）。要是下次遇到类似的问题，我能解决的话，那真是再熬一两个晚上都是值得的。
给我自己切身的感受是，书到用时方恨少；山外青山楼外楼；学无止境。
