数据库容灾、复制解决方案全分析(绝对).pdfVIP

数据库容灾、复制解决方案全分析（绝对精品） 目前，针对 oracle 数据库的远程复制、容灾主要有以下几种技术或解决方案： （1）基于存储层的容灾复制方案 这种技术的复制机制是通过基于 SAN的存储局域网进行复制，复制针对每个 IO 进行， 复制的数据量比较大 ; 系统可以实现数据的同步或异步两种方式的复制 . 对大数据量的 系统来说有很大的优势（每天日志量在 60G以上） , 但是对主机、操作系统、数据库版 本等要求一致，且对络环境的要求比较高。 目标系统不需要有主机，只要有存储设备就可以，如果需要目标系统可读，需要额外 的配置和设备，比较麻烦。 （2 ）基于逻辑卷的容灾复制方案 这种技术的机制是通过基于 TCP/IP 的网络环境进行复制，由操作系统进程捕捉逻辑 卷的变化进行复制。其特点与基于存储设备的复制方案比较类似，也可以选择同步或 异步两种方式，对主机的软、硬件环境的一致性要求也比较高，对大数据量的应用比 较有优势。其目标系统如果要实现可读，需要创建第三方镜像。个人认为这种技术和 上面提到的基于存储的复制技术比较适合于超大数据量的系统，或者是应用系统的容 灾复制。 我一直有一个困惑， 存储级的 复制，假如是同步的， 能保证 数据库所有文件一致吗 ？ 或者说是保证在 异常发生的那一刻有足够的缓冲来保障？ 也就是说， 复制的时候起文件写入顺序和 oracle 的顺序一致吗？如果不一致就可能有 问题，那么是通过什么机制来实现的呢？ 上次一个存储厂商来讲产品，我问技术工程师这个问题，没有能给出答案 我对存储级的复制没有深入的研究过，主要是我自己的一些理解，你们帮我看一下 吧…… 我觉得基于存储的复制应该是捕捉原系统存储上的每一个变化，而不是每隔一段时间 去复制一下原系统存储上文件内容的改变结果，所以在任意时刻，如果原系统的文件 是一致的，那么目标端也应该是一致的，如果原系统没有一致，那目标端也会一样的。 形象一点说它的原理可能有点像 raid 0 ，就是说它的写入顺序应该和原系统是一样的。 不知道我的理解对不对。另外，在发生故障的那一刻，如果是类似断电的情况，那么 肯定会有缓存中数据的损失，也不能 100% 保证数据文件的一致。一般来说是用这种 方式做 oracle 的容灾备份，在发生灾难以后目标系统的数据库一般是只有 2/3 的机会 是可以正常启动的（这是我接触过的很多这方面的技术人员的一种说法，我没有实际 测试过）。我在一个移动运营商那里看到过实际的情况，他们的数据库没有归档，虽 然使用了存储级的备份，但是白天却是不做同步的，只有在晚上再将存储同步，到第 二天早上，再把存储的同步断掉，然后由另外一台主机来启动目标端存储上的数据库， 而且基本上是有 1/3 的机会目标端数据库是起不来的，需要重新同步。 所以我觉得如果不是数据量大的惊人，其他方式没办法做到同步，或者要同时对数据 库和应用进行容灾，存储级的方案是没有什么优势的，尤其是它对网络的环境要求是 非常高的，在异地环境中几乎不可能实现。 不知道我的理解对不对，也不知道是不是回答了你的问题，呵呵。欢迎指正！ 应该说部分地回答了我的问题，呵呵 因为 实际上存储设备的写入顺序 和 oracle 的进程的写入顺序肯定是不一样的，存 储设备一定是做过重整的，那 不管同步或者异步的拷贝都 有可能 存在问题的。 所以我一直对这个方案的可靠性不敢完全相信，这样一来，倒不如 data guard 可靠 了 因为很明显，存储设备拷贝过去的数据文件 不一致是有很大的概率的 你的意思是说即使不考虑目标端，仅在源端的情况下，存储设备的写入顺序也是和 Oracle 不一致的？这应该是一个原因。 我觉得还有一种可能性就是在忽略存储设备的 这种情况下，在主系统当机，发生切换的时候，主系统存储上的数据文件也不一定能 保