遇到这种情况如何恢复数据库？

xjg

再次感谢各位的讨论

其实我发起这个问题的主要目的还是怎么样来完善我的备份策略，由于种种原因，暂时还没有采用RMAN来做备份，还是用手工脚本的方式，具体方案如下，大家帮忙看看：
1、数据库采用归档日志方式运行，除操作系统以外，所有ORACLE相关文件都在一个磁盘阵列中，联机日志也同时保存在操作系统所在的盘中。
2、每个月进行一次SHUTDOWN NORMAL的冷备份，归档日志定时也会拷贝到另一台机器中（15分钟同步一次），每天也会把ORACLE目录的所有文件（包括实例相关的TRC等文件）同步到备份机中。
也就是说，不出意外的话，我的备份机上保留了数据库的程序文件、一个冷备份、所有的归档日志、最新的创建控制文件的脚本（通过每天中午执行一次alter database backup controlfile to trace生成），如果不是小型机完全被人干掉的话，联机日志文件也是可以得到的。
在这种情况下，如果小型机的磁盘阵列崩溃，是不是可以进行数据库的完全恢复？
还有没有其他需要注意的事情？
谢谢各位。

yangwenchao

如果仅仅是一个条带或者一个RAID5 ，并不是很安全。因为数据文件是随机写的，所以如果磁盘阵列无法恢复，你的数据也就无法确认恢复了。如果是RAID 1 就好些。当然最好是RADID0+RAID1或者是RAID0+ RAID 5 。
仍然强烈建议你不要用冷备份。让控制文件记录下你的备份信息是最好的选择，这样当数据库出现非一致性错误时便于诊断，而且冷备份占用空间过大。
当然如果你不需要24*7的工作环境，备份策略也就不是很重要了。因为大多数备份和恢复策略都是针对24*7环境的，是针对连续工作环境的。当然冷备份也有好处，就是可以在数据库DOWN掉后，恢复时可以直接使用数据文件，避免了一致性恢复的困扰，只要你的日志购用。

对不起，刚才忽略了冷备份是可以用日志恢复当前状态的。但备份中一定要包括控制文件、系统参数文件、RDBMS文件和 SQL*NET文件。重建控制文件是非必要的选择，因为用文本方式重建会丢掉许多重要信息，只保留数据文件的基本信息。最好有其拷贝。

husthxd

数据文件备份、归档日志、联机日志没有丢失的话可以完全恢复。

btw：rman可以使备份和恢复简单化，建议采用rman

xjg

多谢各位，看来我得装个测试数据库做做实验才行。