7同行回答
分享很久以前记录的一个事吧
晚上11点多，客户突然打来电话，说数据库崩溃了，通过了解详细情况，得知崩溃的原因是
因为换电源，停机（停机过程正常），在开机存储就丢失了。
在这里我想提醒各位同仁，在做任何操作之前，一定要把生产库备份一个全备，以防万一，并要查看之前
的备份是否都正常，还要收集一下数据库的相关信息，参数文档，控制文件，以及一些基本的数据库名称
DBID等，万万不可大意，以下是恢复过程。
客户的运气比较好，他的全备是在周六晚，出问题是周日的晚上，但是他的数据库是8*5的，数据只要恢复
到16号晚上就可以，过程比较曲折
因客户对数据库不太熟悉，很多路径，什么的都不清楚，只能自己来收集。
1、通过alert日志中的信息先找到DBID，RMAN连接要使用；
2、恢复参数文件，和控制文件，并启动到mount状态；
3、恢复之前的目录架构，因为是SAP的数据库，目录有几百个，只能一个一个的对比；
4、写了两个恢复脚本，执行恢复；
5、恢复完成，400G数据不算多，但也恢复了2小时左右；
6、让客户启动应用，测试了一下，数据库恢复正常，不会耽误第二天早晨的使用。
在测试应用的是的，我发现他的数据库响应比较慢，但由于时间的关系，没有帮他优化。这次恢复算是比较幸运
，客户有完整的备份，虽然少了一天，但是这是周末，只要恢复到前一天的数据就可以了。
这个能恢复，算是不幸中的万幸，如果备份无效，基本任何数据也恢复不了。
我也来说一个吧
DB2 V8.1 32位
应用系统为数据平台
日志LSN号满，造成数据库宕机，无法启动
由于数据库较大6T，恢复了几乎3天3夜，当时请了IBM LEVEL3的美国佬恢复的LSN序号，将它清零，然后才可以将数据库实例启动，但是数据是无法进行更新操作的，只能将数据库的所有表，用IMPORT操作导出，然后再导入到新的数据库当中，由于数据库版本太老，也不支持联邦方式导数据，也不支持游标方式，花了大量时间对数据恢复，最后导完数据后，对原表的数据量进行统计，看和新表是否一致。
最后才将数据库给应用使用。
对于这种大数据量的数据库，平时又无法备份，出现问题确实非常麻烦。
所以后面我们对这种大数据量的数据库所在的存储每天都做快照，保留两份快照，循环。来规避以后类似的问题。
