你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
优化业务连续性和灾难恢复
将 Oracle 资源迁移到 Azure 时，请考虑数据库的可靠性，以及虚拟机（VM）、虚拟网络子网和存储组件上层的可靠性。
Azure 基础结构即服务（IaaS）上的 Oracle 可以实现最苛刻的 Oracle 工作负载所需的复原目标。 若要有效地使用本文中的指南，请先根据业务需求定义复原关键绩效指标（KPI）。 使用恢复时间目标（RTO）和恢复点目标（RPO）要求作为基线 KPI 来确定 Azure 上 Oracle 工作负荷的最佳体系结构。
RTO 是应用程序在发生灾难、失败或可比事件后保持不可用的最大时间。
RPO 是发生灾难、失败或可比事件后的最大数据丢失量。
数据保护的备份方法
Azure IaaS 上 Oracle 工作负荷的三种 Oracle 数据库备份方法包括：
流式备份。 将 Oracle 恢复管理器 （RMAN） 用于此方法。 RMAN 将备份流式传输到顺序磁带介质。
Azure 上的备份目标包括：
- 可以在Azure 市场中找到的非Microsoft虚拟磁带库。
- 本地和远程文件共享，例如使用网络文件系统协议、Azure 文件存储和Azure NetApp 文档Azure Blob 存储。
存储级快照。 对此方法使用Azure 备份。 此方法依赖于用于数据库文件的存储类型。 例如，如果使用 Azure 托管磁盘（例如 Azure 高级 SSD），Azure 备份与 Oracle 数据库集成。 如果使用Azure NetApp 文档，可以使用Azure NetApp 文档数据保护功能，例如Azure NetApp 文档备份和跨区域复制。
VM 级备份。 对此方法使用Azure 备份。
注意
确保备份环境中的 VM 正在运行可支持性的 OS。 了解受支持的 OS。
流式传输大型数据库的备份时，复制数据所需的时间将超过 RTO 要求。 存储级快照是该方案的最佳选项。
建议
请仔细考虑是实施基于流式处理、存储级快照还是基于这两种策略的备份策略。
评估备份策略对 RTO 和 RPO 要求的影响。
根据每个选项的记录吞吐量限制分析 RMAN 备份的可用存储目标。 选择满足要求的选项。
考虑对存储级快照使用 Azure 备份，并考虑将快照置于配对区域或可用性区域进行额外保护。
请考虑使用各种存储选项来存储恢复数据库所需的存档日志备份。 请考虑每个选项的性能、复制和成本注意事项。
开发并定期测试备份和还原计划，防止生产环境中出现不必要的意外。
服务保护和业务连续性
本部分介绍如何通过实施服务保护和业务连续性（BC）注意事项，改进 Azure IaaS 上 Oracle 工作负荷的整体高可用性（HA）和灾难恢复（DR）。
结合以下建议来改进体系结构冗余，并最终最大程度地提高服务可用时间。 旨在最大程度地减少因计划内中断（例如修补程序、更新和升级）以及计划外中断（如故障）而导致的服务停机时间。 使用 Azure 和 Oracle 功能改进从地域范围的故障恢复。
Azure 提供了许多选项，用于在 IaaS 体系结构上实现 Oracle 中各个组件的高可用性。 例如，可以：
- 使用灵活的虚拟机规模集部署 VM，该规模集可自动将 VM 分散到容错域。
- 创建可用性区域以防止数据中心故障。
- 将部署放置在不同的区域，以防止全区域故障。
各种 Azure 存储功能提供不同的存储冗余级别，例如本地冗余存储、区域冗余存储和异地冗余存储。 在 Azure IaaS 上规划 Oracle 工作负荷部署时，请考虑每个选项。
还可以使用 Oracle Data Guard，这是用于 Oracle 数据库服务保护设置的工具。 Data Guard 转发并将事务日志应用于一个或多个备用数据库。 此过程维护主数据库的确切副本，如果计划内维护或故障方案，则可以故障转移到该数据库。
Data Guard 有三种数据复制模式：最大保护、最大可用性和最佳性能。 每个复制模式为辅助数据库上的应用程序提供不同的日志传输模式和不同的事务保证组合。
根据策略（例如零延迟或零数据丢失策略），可以选择同步或异步配置。 还可以实现快速启动故障转移，具体取决于最大停机时间要求。 参考体系结构提供不到一分钟或不到五分钟的恢复，最多四个小时。 Oracle 数据库的企业版包括 Data Guard。
Oracle GoldenGate 是另一种工具，可用于在两个数据库之间复制数据并启用多主方案。 必须单独购买 GoldenGate。
建议
考虑 Azure 在 Azure IaaS 实现上 Oracle 中为各种基础结构组件提供高可用性的功能。
在将 Data Guard 用于 HA 和 DR 时，请仔细选择满足要求的数据库保护模式。 例如，最大性能模式可最大程度地减少对源的影响，但可能会丢失数据。 有关详细信息，请参阅 Azure 上的 Oracle BCDR 虚拟机登陆区域加速器和 Oracle Data Guard 保护模式。
考虑自动执行故障转移过程。 例如，可以使用快速启动故障转移。
为故障转移过程建立测试过程，并定期进行测试以避免任何问题。
使用 Azure 原生功能（如可用性区域）和 Oracle 原生工具（如 Data Guard）全面构建解决方案，以满足 HA 和 DR 要求。 以下两个示例使用 Azure 本机组件和 Oracle 本机组件。
使用被动待机创建故障转移
本部分介绍具有被动备用的两可用性区域部署中业务关键型 Oracle 应用程序的故障转移方案示例。
业务关键型 Oracle 应用程序（如 Oracle 电子商务套件）需要故障防护，因此需要整体体系结构。
本示例：
具有两个可用性区域部署。 应用程序层将 Azure Site Recovery 与被动辅助 VM 配合使用。
利用 Data Guard 快速启动故障转移功能。 若要获得最高可用性，建议安装两个观察程序。 主要观察程序位于可用性区域 1 中，辅助观察程序位于可用性区域 2 中。 观察者监视和定向流量。 当主数据库不可用时，观察者会自动故障转移到辅助数据库。 Data Guard 执行重做同步。重做同步的时间范围取决于重做配置。
Data Guard 已配置为 数据保护模式，例如最大可用性、最佳性能或最大保护。 有关为工作负荷要求选择模式的详细信息，请参阅 Oracle Data Guard 保护模式。
以下体系结构旨在使停机时间阈值少于 5 分钟。
创建具有活动待机状态的故障转移
本部分介绍具有活动备用状态的两可用性区域部署中业务关键 Oracle 应用程序的故障转移方案示例。
在此示例中：
Web 服务器层、应用程序层和数据库层驻留在其自己的虚拟网络子网中。
主数据库驻留在可用性区域一中。
使用 Active Data Guard 将主数据库复制到活动备用数据库的数据库驻留在可用性区域 3 中。
注意
此设置需要 Active Data Guard 许可证。
以下体系结构旨在缩短一分钟的停机时间阈值。 此故障转移方案具有活动备用配置，但具有只读功能。
