使用oracle DG 和 EMC 存储mirror恢复的效率和使用场景对比？

Oracle DG和EMC SRDF/SWAP都可以实现灾备功能，但是还是有各自特色的：
1. Oracle DG是在数据库层实现灾备功能，只需要执行角色转换命令即可完成切换，切换速度更快。Oracle DG的备库可以实现只读，作为查询库对外提供服务，分担主库的负载。
Oracle DG一定程度上可以修复数据库逻辑错误。
2. EMC是在存储层实现灾备，正常情况下只有主环境可以访问，灾备环境不可读写，灾备切换时需要存储、VG、FS等操作才能拉起数据库，步骤多，耗时长。
EMC存储复制无法发现逻辑坏块。
如果一定要找出缺点：
1. Oracle DG维护更加复杂，且只用于Oracle数据库，不能用于其他数据库和非数据库。
2. EMC操作简单，不用再在备端维护一个备库，极端情况下，灾备端没有主机也可以进行数据同步，实现灾备功能，可以多套系统的数据库分时复用同一台主机，用于灾备的验证。

我说说这2年我们团队的容灾切换Disaster Recovery（简称DR）技术方案路线：应用级—>存储级—>应用级。

1、10几年前，中高端存储尚未普及，产品价格不菲。我们一般的DR方案都是基于应用。当时很多应用本身没有DR机制，因此核心是围绕数据库，毕竟数据才是核心，数据能够切换，其他都不是问题，最多耽误一点时间而已，只要前期方案设计合理，即使应用本身没有完整DR机制，辅以脚本、网络等手段，完全可以实现30分钟内RTO。

2、随着中高端存储价格平民化，我们总算用上了存储级复制和故障转移。同时，越来越多的应用系统本身提供了DR机制，这样一来，应用DR+存储级复制，成为我们的主打DR方案。我们的方案主要基于HP产品，期间也遇到过EMC Mirror，我认为存储级复制和切换方案到了后期，厂家的技术已经非常成熟，因此基本大同小异，优劣不分明。

3、直至近3年，越来越多的数据库在DR方面越来越傻瓜，且数据库从业经验远比存储多得多，毕竟中高端存储的价格还是具有一定门槛，相比之下，数据库应用就非常广泛了，数百人的企业没有中高端存储并不稀罕，但是有一套基于Oracle的应用却很常见。因此我们通过若干实施案例后发现，数据库容灾相比存储复制和切换具有明显几个优势：

• 切换步骤少。因为DR要切的是应用和数据，依赖存储反倒多了一层手续。 "多"就是复杂，容易引发问题。
• 演练方便。随便搭个模拟环境，就可以测试，不依赖任何硬件，中高档存储基本上不会有硬件冗余供测试。 同时存储牵一发而动全身， 演练的风险比较高。这就是圈子里常见的情况，购买了中高端存储，但不到万不得已不会进行容灾演练。
• 解决问题的成本低。无论是哪些品牌的中高端存储，资源都远比数据库的资源少。特别是有些厂商入国内投入资源少得可怜。软件的门槛远比硬件低。发生问题或者需求支持，中高端存储基本上还是依赖集成商和厂商，网络资源非常狭窄。因为玩得起的人数实在有限。

从目前看，厂商宣传的存储级复制和切换的最大优势就是速度快。其实这也不过是一种过时的说法，或者说匹配的场景非常少—数据量大，复制带宽小，RTO要求高。这么多前提条件合在一起，我都不知道厂商是怎么想出来的:-)

只用过oracleDG emc存储mirror没用过
只说一下oracleDG吧
他是oracle自己的一个功能，不需要额外花费，当主机宕掉以后，备机可以启动当做主机进行业务支撑、主库正常使用过程中，备库也可以实现只读，分担主库的负载。
DG可以缩短故障时间，快速恢复业务 降低业务中断时间

目前很多数据库厂商提供基于DG+快照的技术，灾备端可以基于DG库起多个快照库，基于厂商的平台，鼠标点几下就提供一个快照库，用于开发测试、查询，不用就清理掉，灾备库也可以做到一键切换提供服务，运维工作量应该不太多，存储MIRROR没做过，不好评价

因为原来所在的环境没有很牛的DBA,加上本人也是做系统运维的。所以对数据库方面。特别是ORACLE数据库一直都是敬而远之，能通过其他方式解决的方案都一般习惯采用其他方式。
以前设计的方案中没有用EMC的存储。采用的是IBM的存储。不过原理都是一样的。通过底层存储同步实现数据容灾，让主被存储设备同步，在主机房故障时启用备用机房业务，
效率上和维护量上我觉得都不太好做比较。不同的环境。场景。还有运维能力结果会不一样。我觉得选择上首先看你们的技术储备对那种方案驾驭的更好。更熟练，

首先不纠结那种技术，就我自己而言2种都可，我们现有团队都能驾驭。放在4年前我们大概率选择基于存储mirror方案 。在结合应用软件运维实际情况应用支持ip修改吗？？，应用完全基于域名解析了嘛？？ 最后结合你现有供应商团队支撑能力强项在哪方面。
2种技术各有特色与缺点。上面很多仁兄都提到了。
DG 基于DBA的视角切换可控，主备资源可利用。单要考虑应用修个IP方面不？？？若应用修改ip配置复杂就放弃吧。
存储mirror 基于系统运维视角，对于系统运维人员切换可控，应用可以做到不修改IP。完全模拟主机的环境。但就是太闲置备机资源。

你的 问题仅考虑数据的切换不够全， 重要系统 要把数据，应用都做好全才有良好的SLA。
仅仅考虑数据是属于非重要系统那种RTO可容忍就无所谓。

之前的回答已经比较全面，数据库 DG实现起来比较容易，切换也比较简单，唯一的缺点时应用连接数据库采用IP地址不是域名访问，需要改动应用的数据库连接配置。
存储层面实现灾备，日常维护量较少，基本上不用任何操作，只有做好监控即可。优势是可以实现多个系统、多个数据库数据的一致性。切换的操作相对比较繁琐。

mirrorview是中端存储数据同步的技术，首先要考虑中端存储开启复制资源够不够用。
DG非常成熟，数据库自身技术切换后备库可以打开用。而存储复制灾备要启用启用需要停复制并把灾备置成可以读写的状态，操作完还要主机识别灾备的盘，相对回复杂一些。

可以综合使用