OracleDG和EMC存储mirror方案选型分析.docx

《OracleDG和EMC存储mirror方案选型分析.docx》由会员分享，可在线阅读，更多相关《OracleDG和EMC存储mirror方案选型分析.docx（6页珍藏版）》请在第一文库网上搜索。

1、Orac1eDG和EMC存储mirror方案选型分析使用Orac1eDG和EMC存储mirror恢复的效率和使用场景对比？主机房故障，应用系统链接数据库切换效率的对比。背景：应用前端连接后端OraCIe数据库，该场景主要发生在公募基金行业。技术方案对比：1 .方案一、使用OraCIeDG技术在灾备机房搭建多台独立的数据库，平时为只读状态，应急时启用；2 .方案二、使用EMC存储的Hiirrorview技术，对主数据库的数据通过底层同步至灾备机房的存储，灾备机房部署服务器连接至该存储，平时不启用，在故障时连接使用。不明白须答疑的问题：两种灾备方案在应急切换中的效率和日常维护量的对比，能体现出每种

2、方式的优劣及适应场景。问题来自社区会员zwo365某基金系统运维工程师，下文来自twt社区众多同行实践经验分享，欢迎大家参与交流，各抒己见。*“争议”栏目内容来自同行分享的一手体验和观察，仅代表个人观点ZhangyOngjUnCMBC工程师：Orac1eDG和EMCSRDF/SWAP都可以实现灾备功能，但是还是有各自特色的：1Orac1eDG是在数据库层实现灾备功能，只需要执行角色转换命令即可完成切换，切换速度更快。Orac1eDG的备库可以实现只读，作为查询库对外提供服务，分担主库的负载。Orac1eDG一定程度上可以修复数据库逻辑错误。2.EMC是在存储层实现灾备，正常情况下只有主环境可以

3、访问，灾备环境不可读写，灾备切换时需要存储、VG、FS等操作才能拉起数据库，步界多，耗时长。EMC存储复制无法发现逻辑坏块。如果一定要找出缺点：1. Orac1eDG维护更加复杂，且只用于OraC1e数据库，不能用于其他数据库和非数据库。2. EMC操作简单，不用再在备端维护一个备库，极端情况下，灾备端没有主机也可以进行数据同步，实现灾备功能，可以多套系统的数据库分时复用同一台主机，用于灾备的验证。raph1gu旭升项目经理：我说说这2年我们团队的容灾切换DiSaSterRecovery（简称DR）技术方案路线：应用级一存储级一应用级。1、10几年前，中高端存储尚未普及，产品价格不菲。我们一般

4、的DR方案都是基于应用。当时很多应用本身没有DR机制，因此核心是围绕数据库，毕竟数据才是核心，数据能够切换，其他都不是问题，最多耽误一点时间而已，只要前期方案设计合理，即使应用本身没有完整DR机制，辅以脚本、网络等手段，完全可以实现30分钟内RTOo2、随着中高端存储价格平民化，我们总算用上了存储级复制和故障转移。同时，越来越多的应用系统本身提供了DR机制，这样一来，应用DR+存储级复制，成为我们的主打DR方案。我认为存储级复制和切换方案到了后期，厂家的技术已经非常成熟，因此基本大同小异，优劣不分明。3、直至近3年，越来越多的数据库在DR方面越来越傻瓜，且数据库从业经验远比存储多得多，毕竟中高

5、端存储的价格还是具有一定门槛，相比之下，数据库应用就非常广泛了，数百人的企业没有中高端存储并不稀罕，但是有一套基于OraC1e的应用却很常见。因此我们通过若干实施案例后发现，数据库容灾相比存储复制和切换具有明显几个优势：切换步骤少。因为DR要切的是应用和数据，依赖存储反倒多了一层手续。“多”就是复杂，容易引发问题。演练方便。随便搭个模拟环境，就可以测试，不依赖任何硬件，中高档存储基本上不会有硬件冗余供测试。同时存储牵一发而动全身，演练的风险比较高。这就是圈子里常见的情况，购买了中高端存储，但不到万不得已不会进行容灾演练。解决问题的成本低。无论是哪些品牌的中高端存储，资源都远比数据库的资源少。特

6、别是有些厂商投入资源少得可怜。软件的门槛远比硬件低。发生问题或者需求支持，中高端存储基本上还是依赖集成商和厂商，网络资源非常狭窄。因为玩得起的人数实在有限。从目前看，厂商宣传的存储级复制和切换的最大优势就是速度快。其实匹配的场景非常少一数据量大，复制带宽小，RTO要求高。anonymous金融行业工程师：只用过OraC1eDG,EMC存储Inirror没用过。只说一下OraC1eDG吧，它是OraCIe自己的一个功能，不需要额外花费，当主机宕掉以后，备机可以启动当做主机进行业务支撑、主库正常使用过程中，备库也可以实现只读，分担主库的负载。DG可以缩短故障时间，快速恢复业务，降低业务中断时间。潘

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

8、大概率选择基于存储DIirrOr方案。在结合应用软件运维实际情况应用支持ip修改吗？应用完全基于域名解析了嘛？最后，结合你现有供应商团队支撑能力强项在哪方面？2种技术各有特色与缺点。上面很多仁兄都提到了。DG基于DBA的视角切换可控，主备资源可利用。单要考虑应用修个IP方面不？若应用修改ip配置复杂就放弃吧。存储mirror基于系统运维视角，对于系统运维人员切换可控，应用可以做到不修改IP。完全模拟主机的环境。但就是太闲置备机资源。你的问题仅考虑数据的切换不够全，重要系统要把数据、应用都做好做全才有良好的S1A。仅仅考虑数据是属于非重要系统那种RTO可容忍就无所谓。duansq华夏人寿技术经理

9、：目前很多数据库厂商提供基于DG+快照的技术，灾备端可以基于DG库起多个快照库，基于厂商的平台，鼠标点几下就提供一个快照库，用于开发测试、查询，不用就清理掉，灾备库也可以做到一键切换提供服务，运维工作量应该不太多，存储MirrOr没做过，不好评价。guwenkuan金融系统架构师：之前的回答已经比较全面，数据库DG实现起来比较容易，切换也比较简单，唯一的缺点是应用连接数据库采用IP地址不是域名访问，需要改动应用的数据库连接配置。存储层面实现灾备，日常维护量较少，基本上不用任何操作，只有做好监控即可。优势是可以实现多个系统、多个数据库数据的一致性。切换的操作相对比较繁琐。ZhangjUnXi570xjtu系统分析师：mirrorview是中端存储数据同步的技术，首先要考虑中端存储开启复制资源够不够用。DG非常成熟，数据库自身技术切换后备库可以打开用。而存储复制灾备要启用需要停复制并把灾备置成可以读写的状态，操作完还要主机识别灾备的盘，相对会复杂一些。-全文完-