一次数据库崩溃处理事件

    
  13号早上接到领导通知，说某下属单位数据库崩溃，给处理一下。联系到相关负责人，了解了一些情况，跟同事一步一步的，边商量，边互相监督着进行拯救操作，监督不是因为有信任问题，是担心对方操作过程中有疏漏。毕竟在急救过程中的处理心态跟平时自己做实验时的悠闲自得的心态是不同的，这一刻真的是鸭梨山大！谁的命令敲错了，谁的心态不稳了，都可能导致数据库的状态往更差的方向发展！

   这个项目是找的我处理，领导也是安排给我处理的，但同事小秋秋一直跟我加班加点奋斗了好多天，很幸运碰到这种能担当的同伴，他不会打太极，也不会踢皮球，让人觉得值得信任。

   最终数据库恢复了，不过处理过程中走了很多的弯路，比如控制文件损坏应该是先从备份集里恢复控制文件，而不是通过转储重新创建控制文件。当时由于情况紧急，之前确实没碰到过这种状况，处理思路有些混乱，下次碰到数据库崩溃造成控制文件和数据文件损失的情况下，一定首先从备份集里恢复控制文件，找到所有以前的备份集，通过备份集恢复控制文件，找到所有备份集信息，从备份集里恢复丢失的数据文件。

   

    控制文件损坏以后数据库打不开，而且rman里面list backup命令找不到任何的备份集，这时候指定备份集恢复就可以：restore control file from '备份集'; 

    通过这次项目，学到了两点：

    1.认真打好理论基础。一定分析好故障原因，自习检查数据库状态，尽可能确定数据库哪些资源可用，哪些资源不可用，具体通过什么方式用，再去进行处理，宁愿处理的慢一些，也不能因为各种紧急的催促盲目的进行没经过深思熟虑的操作，毕竟生产环境崩溃就跟病人濒临死亡的性质是差不多的，大夫不能因为思维错误错手杀死病人。

    2.一定要保证心态冷静，任何操作之前跟同事讨论可行性，如果自己单枪匹马的处理的话，一定深思熟虑之后再动手，宁愿让他 dying 也不能让他 died ！！！

 

    之后自己重新模拟当时的故障场景做了一次模拟故障恢复测试报告。