liuyusheng

业务数据的重要性，业界普遍遵从的规则是按照各业务的RTO和RPO要求去划分，既可以量化、也可以作为规划的依据。

1、推荐对象和文件互通的成熟一体化方案，如EMC ECS等。2、跟随软件定义存储潮流（解耦、分布式架构）。

存储整合这个话题是需要考虑未来应用的转型+现有存储架构，SVC能解决一时之痛，但从长远看，并不利于存储架构的优化调整（都得依赖于SVC）。个人建议，如果你旧存储数量比较多，可以考虑虚拟化网关（但是SVC是要损坏数据的，而且只提供

容灾架构的演进是和上层业务演进密切相关的。分布式和微服务场景下，对底层基础架构的可靠性依赖程度没有传统架构高，业务本身就支持类似FT功能，切换、启动都很快，可以说不需要传统双活、复制等技术。但是，个人认为未来是“

在DG上执行：SQL> select database_role from v$database; DATABASE_ROLE PHYSICAL STANDBY 物理备库。SQL> select status from v$instance; STATUS MOUNTED 原本DG是mount状态。SQL> ALTER DATABAS

这种超远距离，只有考虑应用层，而且还得考虑数据改变量。怎么做，RPO都不能为0

IBM SVC和EMC VPLEX都属于网关，都能提供双活功能。HDS GAD，HW HyperMetro，EMC SRDF-Metro等都是阵列双活方案。在核心业务中，越来越多的用户选择全闪存，以提高性能、降低TCO。但，网关就限制了全闪存的性能优势。银行客户当

当前存储厂商提供的双活方案基本都能满足RAC的部署需求。这根本还取决于RAC本身的部署模式。部分城商行对链路质量没有信心的情况下，将RAC群集独立部署，也就是主中心一套RAC，备中心一套RAC。通常备中心RAC为只读。在灾难

仲裁就是防止脑裂的解决方案。没有防止仲裁脑裂的概念。

安全性和性能，就像是鱼和熊掌。数据实时性要求极高，可以考虑选择类似跨数据中心的Oracle RAC技术，既能够实现数据库的双活，也能实现严格同步。缺点是，对链路质量要求极高！（参考oracle最佳实践）基于存储层的双活技术，是有很多技