为了最大限度的保证数据安全，在发生灾难时尽快恢复数据库，需要进行日常的备份。

备份应该根据数据库的大小、负载、可用性要求等制定策略。（服务器的i/o性能、磁盘空间等应该是在规划阶段就充分考虑的，一般不应该有瓶颈）

根据不同的划分方式，可以将备份分为物理备份/逻辑备份、一致性备份/非一致性备份。rman为我们提供了功能强大、方式多样的备份选项，即使整个数据库都没了、磁盘没了，只要有一个完整、可靠的备份，依然可以恢复原样。

我们关注数据，首先是安全性（不丢失），更高一层的就是高可用了。数据库的高可用是我们都追求的，不过根据业务要求不同而有宽有紧；完整、迅速的恢复数据是一个dba需要特别关注的。

数据库的技术说到底其实就是两个层面：数据安全、速度。安全包括数据不丢失、不被非法查看或使用；速度方面不仅是性能高，而且出现问题时可以快速有效地恢复。其实恢复时间的要求在两方面都有体现。

什么时候应该全备份？什么时候做增量备份？这个没有严格的标准，但根据官方文档提供的经验值，如果数据的变化超过了总量的20%，增量备份是不会比全量备份高效的。当然，可能由于磁盘空间等原因的暂时性限制，还是会用增量备份。

备份是为了防灾，在灾难发生时进行恢复。如果是普通的数据文件坏了，可能只有在访问对应数据时才会报错，不会影响整个数据库运行。若相对独立，可以将表空间脱机后恢复、还原，不必重启数据库；如果是普通数据文件头坏了，数据文件被offline，还原方法同上；如果是数据文件丢失，则只能mount数据库，打不开，restore+recover方式恢复同样适用

如果系统表空间故障，文件丢失或文件头损坏，实例只能mount；restore+recover方式恢复

如果出现数据字典损坏、sys.system损坏、控制文件同时损坏等状况时，数据库甚至无法nomount。有时系统可能无法shutdown ，需要用kill -9操作系统命令强制删除会话后再恢复

如果是参数文件损坏了，可以通过参数文件的备份恢复。

如果是控制文件损坏、丢失、故障了，同时连接到目标库和编录库，nomount目标库，然后restore controlfile；就可以mountle。

重做日志文件的恢复方式类似。

总之，将rman备份放到安全的地方，并确认备份有效，相应的数据就非常安全了。再配合恢复编录的合理使用和恰当的备份保留策略，可以高枕无忧了。

当然，以上都是就归档模式下的系统来说的。对于平时实验、测试等目的的数据库，可能未考虑或条件不允许进行充分备份，将如何恢复呢？

下周继续学习。

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/26451536/viewspace-755275/，如需转载，请注明出处，否则将追究法律责任。