huangxiaobaobao

引用:

原帖由 SIBELIUS 于 2008-5-6 06:34 发表
这个很简单。。如果客户的应用是ORACLE， 你几乎只能够选择基于ORACLE的DR方案了（DATA GUARD是一种），但是建议评估一下DSG的方案，DATA GUARD在实际环境中间好用不好用， 去ORACLE之家问问那些DBA们就知道了。可以 ...

除了data guard，还有什么呢？

太感谢这位老兄了，马上给您发邮件

asyqm

如果是原来的存储就是hds，还是建议你继续使用hds的对应level的硬件做设备层的容灾，确实不需要替换原来的存储，不需要停机。

asyqm

另外，如果你用的是AMS系列，那设备级的只有TrueCopy。如果你用的是NSC/USP级的，那还有HUR可以作为选择，毕竟你的RTO是2个小时，是否能撑住其实跟你的业务量以及中间的线路质量和带宽有很大关系。HUR技术对线路的要求比起EMC/IBM来应该是好一些。
至于数据的一致性，如果这个都搞不定，HDS就别在圈子里混了

mike79

在存储层面作容灾的话各个厂商都有很成熟的方案，这个是不用担心的，把厂商叫过来多交流。在数据库层面作容灾的话dataguard也是很牢靠的，尤其是physical standby模式。其他收费的软件，例如shareplex等也蛮好，不过如果你们环境比较简单，就一个生产数据库+1个容灾数据库的话那也用不着花钱买这些，用dataguard就可以了。
容灾中心要起到作用，首先要评估下容灾中心对生产的性能影响，尤其是在同步复制的模式下。其次中间链路很重要，高带宽低延时高可靠性。至少要每天看一次链路状况，最好有软件自动监控。最后就是把切换流程文档化。如果需要人工干预的话那么所有步骤和命令都记录下来，在容灾中心投产后要定期作切换演练。

冬瓜头

但是很多实际中的案例，用底层同步的，结果发现备份库起不来，诸多因素有关，普遍现象。

mike79

采用存储复制方式的，拉起备库就相当于主库系统crash然后重启，这个就是考验DBA的时候了

huangxiaobaobao

引用:

原帖由 asyqm 于 2008-5-6 09:20 发表
另外，如果你用的是AMS系列，那设备级的只有TrueCopy。如果你用的是NSC/USP级的，那还有HUR可以作为选择，毕竟你的RTO是2个小时，是否能撑住其实跟你的业务量以及中间的线路质量和带宽有很大关系。HUR技术对线路的要 ...

是ams的，异地灾备，那我是不是必须要要上dwdn了？

huangxiaobaobao

引用:

原帖由 mike79 于 2008-5-6 10:17 发表
在存储层面作容灾的话各个厂商都有很成熟的方案，这个是不用担心的，把厂商叫过来多交流。在数据库层面作容灾的话dataguard也是很牢靠的，尤其是physical standby模式。其他收费的软件，例如shareplex等也蛮好，不过 ...

经过各位达人的指点，我好像有点铺了，非常感谢啊

问一下，datagurrd这个软件和实施一般怎么收费的？是直接找oracle的人吗？上百万级别吗?

huangxiaobaobao

引用:

原帖由 冬瓜头 于 2008-5-6 10:30 发表
但是很多实际中的案例，用底层同步的，结果发现备份库起不来，诸多因素有关，普遍现象。

怕的就是这个啊。。。

huangxiaobaobao

引用:

原帖由 mike79 于 2008-5-6 10:52 发表
采用存储复制方式的，拉起备库就相当于主库系统crash然后重启，这个就是考验DBA的时候了

客户没有dba，或者说dba够呛。。。

我这里也是半桶水。。。