数据库容灾、复制解决方案全分析

herycom

有谁在实际使用同步复制的吗？

江山千里

最初由 zjxs 发布
[B]实现异步复制，可以把queue的基表从system表空间中移出来 [/B]

任何一个产品所提供的功能在实际应用时，都有优点和缺陷。希望能看到各位前辈或大虾在实际使用中发现的问题和解决的方法。也便于后辈们学习提高。

herycom

最初由 wbo 发布
[B]我们现在用的是Oracle 9i ，想用复制软件VERITAS Storage Replicator 3.0使两台服务器上的数据库同步，应该复制Oracle下的那些数据文件，表空间？还有复制后应该怎么做？

服务器硬件说明：
两台服务器为了节约成本，没有使用双机热备，没用磁盘阵列，每台服务器用4块SCSI硬盘做成Raid 5，两台服务器操作系统，数据库安装路径，设置都一致，有没有解决办法啊?

使用SQL Server 2000数据库把数据文件复制到另外一台服务器，数据库可以实现同步，但是Oracle 9i把一台服务器上的表空间复制到另一台服务器后数据库不用能。 [/B]

现在问题解决了吗？我前面介绍的内容就完全可以很方便地解决数据同步的问题，当然shareplex和dsg也有解决方案。
VERITAS Storage Replicator 3.0我不是很熟，不好评价，但如果用它 ，目标数据库应该不是一直可以使用的，而我们这的方案，shareplex、dsg的方案目标数据库一直都是可以使用的，而且复制后也不需要附加其他操作。
供参考。

herycom

Oracle的实例化视图方式多样：有Read-Only, Updatable, and Writeable Materialized Views三种方式。目标表可以设置为只读、可写、可更新。
只读不用说了；
可写则会在下一次同步时丢失所有目标段的dml操作；
可更新则在刷新时会将目标端修改的内容同步到原表（pushed back to the master ）。

herycom

最初由 Kamus 发布
[B]

eygle他们在用同步复制。
另外我前面有问到一个问题，如果主备之间网络中断，你们怎么处理？你们用光纤，那么比如说光纤交换机坏了。 [/B]

eygle能介绍一下你们的同步复制规模吗？

光纤断了，两边都可以进行查询操作。
如果要恢复修改操作，就要修复网络。
如果短期内不能修复网络，那就切换到单机模式，但不能2台机同时使用，只能使用一台，否则恢复后就不知道以哪台为基准了。

我们这光纤很少出问题，因为有环路保护，即使进行割接或一般的故障，仍然能够保障网络不断。这就是电信级的传输的基本要求。

herycom

最初由 yanzr_sb 发布
[B]-怎么对该的产品如此认同？你作为技术把关岗位应该对产品提一些问题出来才是啊, [/B]

如果不认同，还会用它的产品吗？整个春节期间无需任何人工干预，能够这样稳定，我知足了。
再说这也是试用几家著名产品后，没办法中的办法。
都已经这样好了，还能说什么？至少实现了报表机同步，解决了实际问题，我已经非常满足了。

eygle

最初由 herycom 发布
[B]
eygle能介绍一下你们的同步复制规模吗？

光纤断了，两边都可以进行查询操作。
如果要恢复修改操作，就要修复网络。
如果短期内不能修复网络，那就切换到单机模式，但不能2台机同时使用，只能使用一台，否则恢复后就不知道以哪台为基准了。

我们这光纤很少出问题，因为有环路保护，即使进行割接或一般的故障，仍然能够保障网络不断。这就是电信级的传输的基本要求。 [/B]

没有任何技术能够满足所有的需求。
我的观点还是，能够满足需求的技术就是值得采用的。

"20多公里远的100M光纤环境"，不是任何企业都能有的。

我们的同步复制主要用于同步用户信息，我自己写了一系列的脚本用于故障处理，一旦发生网络故障，在主体定义站点打破复制关系，这样所有业务可以正常运行，待故障恢复后，再用脚本进行数据纠正，这部分基于对于数据的充分认识，是自己写的脚本，比Oracle的冲突纠正效率要高。

采用基于WAN的同步复制，最初也是有担心的。
但是我的想法是，如果可能出现问题，我们就来看看出问题的概率是多少，是否是可以容忍的。

还好运行至今，没有出现任何问题，WAN并没有想象的那么不稳定。
至少，目前这种方式满足了我们的需求。

boyli

讨论的好热闹
看了大家的讨论，才觉得自己还真是孤陋寡闻啊
前几天替gf写了一点容灾计划，只提到了存储级别和数据级别（standby db和dataguard）

不知道那样的计划让行家看到会笑成什么样：（

herycom

最初由 eygle 发布
[B]

"20多公里远的100M光纤环境"，不是任何企业都能有的。

我们的同步复制主要用于同步用户信息，我自己写了一系列的脚本用于故障处理，一旦发生网络故障，在主体定义站点打破复制关系，这样所有业务可以正常运行，待故障恢复后，再用脚本进行数据纠正，这部分基于对于数据的充分认识，是自己写的脚本，比Oracle的冲突纠正效率要高。

采用基于WAN的同步复制，最初也是有担心的。
但是我的想法是，如果可能出现问题，我们就来看看出问题的概率是多少，是否是可以容忍的。

还好运行至今，没有出现任何问题，WAN并没有想象的那么不稳定。
至少，目前这种方式满足了我们的需求。 [/B]

哈哈，我们马上就要建个100公里的100M光纤网络了，从广州到深圳。设备已经到位，正在调试之中。光纤是155M的，不过设备只支持100M。
随着以后通讯的发展，高带宽的环境会越来越多。
我准备在我们的一个小计费系统上建一个测试环境，该计费系统每5秒就增量处理一次话单文件，不过表不是很多，就话单表增长较快。大家听我的好消息。

zhao_yu

“100公里的100M光纤网络”
看到这个别的不说，以后要少用手机了，看看他们把钱都怎么花了。 @_@