今天中午遇见一个生产数据库宕机，需要处理，下面是处理的过程记录
1、Startup到mount是没有问题的，但是Open时报
ORA-03113: end-of-file on communication channel
其实这个错误经常会遇到的, 导致这个错误的原因有很多种(大约):
· 系统的核心参数设置不恰当
· oracle环境变量和权限
· SQL,PL/SQL引起的错误
· 磁盘空间满
· 防火墙问题
· 其它因素
2、 由于是一个正常运行的生产库，突发这个问题，所以，排除了环境变量什么的问题，查看磁盘空间，也没有问题，剩余空间很大，那么，问题就是加载数据文件时出现的，仔细查看Alert.log,
发现，数据文件6出现block recovery的报警
Doing block recovery for file 6 block 150469
3、既然是数据文件损坏，使用DBV工具对数据块进行检查。
通过几分钟等待，显示坏块为150469，如下图（另有Blog文章专门针对DBV使用方法的介绍）
4、确认数据文件问题以后，打算将该 restore datafile，但是在确认restore datafile命令的时候，想起blockrecover 工具，由于只有一个坏块，所以决定尝试使用blockrecover去恢复（第一次在生产环境使用这个命令哦，之前全部是测试环境）。
由于没有实际在生产环境中使用该命令，所以，立即google前人经验，经过总结多个高手的经验，开始了坏块修复，（另有Blog文章专门针对Blockrecover使用方法的介绍）
由于公司使用带库，所以rman脚本如下进行恢复，
- run
- {allocate channel c1 type sbt Parms 'ENV=(NSR_SERVER=nlasav02.100,NSR_COMPRESSION=FALSE,NSR_MMDB_RETRY_TIME=30,NSR_FXBUSY_RETRIES=30)';
- allocate channel c2 type sbt Parms 'ENV=(NSR_SERVER=nlasav02.100,NSR_COMPRESSION=FALSE,NSR_MMDB_RETRY_TIME=30,NSR_FXBUSY_RETRIES=30)';
- BLOCKRECOVER DATAFILE 6 BLOCK 150469 FROM BACKUPSET;
- release channel c1;
- release channel c2;
- }
观察alert.log发现如下日志，在Starting block media recovery之后应用了
大约10分钟后，recover完成，数据块正常Open
5、修复之后再次用DBV数据文件，确认已经修复成功（其实多余，呵呵，为什么呢？因为数据库已经open成功了啊！数据文件当然已经是没有问题的，不然….你懂的）
总结，有些知识不常用，平时记忆不清晰，不牢固，所以使用的时候还需要到google去查询具体命令，防止犯低级的命令错误。所以还要加强记忆。
同时由于很多知识，尤其是恢复类的，在实战中真的很少用到，使用时，还是很有压力的，毕竟生产库的宕机，恢复的时效性和恢复的正确性是不容疏忽的，当recover完成，alter database open成功的那一刻，还是有点小兴奋的，毕竟，这是一件好事，证明自己的工作有效果的吗！收获还是高兴的。
之后，我要把DBV和blockrecover的知识整理下，写上来。
