关于数据库灾备的重要性

各位，数据库的灾备机制对一个十分重要的业务系统，是相当关键的。

如下是主流商用数据库的数据库灾备机制：

Oracle ------DataGuard

DB2----------HADR

Sybase ASE---Replication Serve r

MS SQLServer-数据库镜像（2012版本有了always on）

当然我们现在力推的HVR也能做。

也许有人说：

我的环境如下：

物理存储是两个，通过存储的软件虚拟出来了一份LUN给数据库用，数据是分布在两个物理存储上的，这两个物理存储同时坏掉的可能性几乎没有吧？

如上的观点有两个致命伤：

第一个 致命 伤：你就是有10000个的物理存储也抵御不了突然断电。突然断电很可能打不开数据库，这一点稍微有点断电处理故障的DBA都知道。而 打不开数据库，前台业务就无法做，业务无法做，后果你懂的。

第二个致命伤： 你就是有10000个的物理存储，若是没有主机（即：服务器），数据库也是没有办法对外提供服务的。

也许有人说：

我的环境中采用了存储厂商提供的存储级别复制功能，绝对没问题。

如上的观点有两个致命伤：

第一个 致命 伤：存储复制是好的，不代表数据库能打开。---这其实是说：存储复制运行正常和 数据库能打开，这其实是两回事。

 参考资料之一： Supported Backup, Restore and Recovery Operations using Third Party Snapshot Technologies [ID 604683.1]

 参考资料之二：中国银监会办公厅文件：银监办发[2015]162号 ---中国银监会办公厅关于数据库文件损坏风险的通知

第二个致命伤：  存储复制运行的再好，也仅仅是存储本身而已，若是没有主机（即：服务器），数据库也是没有办法对外提供服务的。

也许有人说：

我有rman备份，出问题了我就用rman恢复。

且不论此人把备份和灾备混为一谈，我们就观点来看观点：如上的观点有三个致命伤：

第一个 致命 伤：你能保证你的rman备份能恢复成功？

第二个致命伤：假设rman备份能恢复成功 ，但是你的数据库的数据量很大，比如20TB，你能找到这么大的空闲空间进行恢复？

第三个致命伤：这20TB在恢复过程中，前台业务是无法做的，20TB的数据量，假设恢复需要X小时，那么前台业务就必须等待X小时。