你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure 虚拟机上的 Oracle 数据库的架构
适用于：✔️ Linux VM
本文介绍如何在 Azure 上部署高可用性 Oracle 数据库。 此外，本指南还深入探讨灾难恢复注意事项。 本文描述的体系结构是依据客户部署创建而成。 本指南仅适用于 Oracle Database Enterprise Edition。
如果有兴趣了解有关如何最大程度提高 Oracle 数据库性能的详细信息，请参阅在 Azure 中设计和实现 Oracle 数据库。
必备条件
- 了解 Azure 的不同概念，如可用性区域
- Oracle Database Enterprise Edition 12c 或更高版本
- 在使用本文中的解决方案时已了解许可含义
Oracle 数据库的高可用性
在云中实现高可用性是每个组织规划和设计的重要组成部分。 Azure 提供可用性区域和可用性集（用于在可用性区域不可用的区域中使用）。 有关如何针对云进行设计的详细信息，请参阅 Azure 虚拟机的可用性选项。
除了云原生工具和产品/服务，Oracle 还提供了可在 Azure 上设置的解决方案，以实现高可用性：
本指南介绍其中每种解决方案的参考体系结构。
迁移或创建云应用程序时，建议使用云原生模式，例如重试模式和断路器模式。 有关可帮助提高应用程序复原能力的其他模式，请参阅云设计模式指南。
云中的 Oracle RAC
Oracle Real Application Cluster (RAC) 是 Oracle 的一种解决方案，可通过让多个实例访问一个数据库存储来帮助客户实现高吞吐量。 此模式是一种全共享体系结构。 尽管 Oracle RAC 可用于本地高可用性，但单独使用 Oracle RAC 无法在云中实现高可用性。 Oracle RAC 仅防范实例级故障，而不防范机架级或数据中心级故障。 因此，Oracle 建议将 Oracle Data Guard 与数据库（无论是单实例还是 RAC）配合使用，以实现高可用性。
客户通常需要使用高 SLA 来运行任务关键型应用程序。 Oracle 目前不认证或支持 Azure 上的 Oracle RAC。 但是，Azure 提供了一些功能（例如可用性区域和计划内维护时段）来帮助防止实例级故障。 除了这些产品/服务外，还可以使用 Oracle Data Guard、Oracle GoldenGate 和 Oracle 分片实现高性能和复原能力。 这些技术可帮助保护数据库免受机架级、数据中心级和地理政治故障的影响。
通过 Oracle Data Guard 或 GoldenGate 在多个可用性区域上运行 Oracle Database 时，可实现 99.99% 的运行时间 SLA。 在可用性区域尚不存在的 Azure 区域中，你可以使用可用性集并实现 99.95% 的运行时间 SLA。
注意
运行时间目标可远远高于 Microsoft 提供的运行时间 SLA。
Oracle 数据库的灾难恢复
在云中托管任务关键型应用程序时，在实现高可用性和灾难恢复方面进行设计十分重要。
对于 Oracle Database Enterprise Edition，Oracle Data Guard 是一项用于灾难恢复的有用功能。 可以在配对的 Azure 区域中设置备用数据库实例，并设置 Data Guard 故障转移，以便实现灾难恢复。 对于零数据丢失，建议除 Active Data Guard 外，另外再部署一个 Oracle Data Guard Far Sync 实例。
如果应用程序允许延迟，不妨考虑在不同于 Oracle 主数据库的可用性区域中设置 Data Guard Far Sync 实例。 全面测试配置。 使用最大可用性模式来设置恢复文件到 Far Sync 实例的同步传输。 然后，这些文件将异步传输到备用数据库。
在“最大可用性”模式（同步）下的另一个可用性区域中设置 Far Sync 实例时，你的应用程序可能不允许性能损失。 如果没有，可以在主数据库所在的同一可用性区域中设置一个 Far Sync 实例。 为了提高可用性，请考虑在主数据库附近设置多个 Far Sync 实例，并在备用数据库附近至少设置一个实例（如果角色转换）。
使用 Oracle Standard Edition 数据库时，可以使用 DBVisit 备用等 ISV 解决方案来设置高可用性和灾难恢复。
参考体系结构
Oracle 数据防护
Oracle Data Guard 可确保企业数据的高可用性、数据保护和灾难恢复。 Data Guard 将备用数据库作为主数据库的事务一致副本进行维护。 根据主数据库和辅助数据库之间的距离以及应用程序对延迟的容差，可以设置同步或异步复制。 如果主数据库因计划内或计划外中断而不可用，Data Guard 可以将任何备用数据库切换为主要角色，从而最大程度地减少故障时间。
使用 Oracle Data Guard 时，你还能够以只读目的打开辅助数据库。 此配置称为 Active Data Guard。 Oracle Database 12c 引入了一项称为 Data Guard Far Sync 实例的功能。 借助此实例，你可以设置 Oracle 数据库的零数据丢失配置，且不会影响性能。
注意
Active Data Guard 需要额外的许可。 使用 Far Sync 功能也需要此许可证。 与 Oracle 代表联系以讨论许可影响。
Oracle Data Guard with Fast-Start Failover
Oracle Data Guard with Fast-Start Failover (FSFO) 可通过在单独的计算机上设置代理来提供更多复原能力。 Data Guard Broker 和辅助数据库均运行观察程序，并观察主数据库的故障时间。 此方法也允许在 Data Guard 观察程序设置中实现冗余。
在 Oracle Database 版本 12.2 及更高版本中，还可以使用单个 Oracle Data Guard Broker 配置来配置多个观察程序。 如果一个观察程序和辅助数据库遇到故障时间，那么此设置可提供额外的可用性。 Data Guard Broker 比较轻型，可托管在相对较小的虚拟机上。 有关 Data Guard Broker 及其优点的详细信息，请参阅 Oracle Data Guard Broker 概念。
下图是将 Azure 上的 Oracle Data Guard 与可用性区域配合使用的建议体系结构。 此体系结构使你可获得 99.99% 的 VM 运行时间 SLA。
在上图中，客户端系统使用 Oracle 后端通过 Web 访问自定义应用程序。 Web 前端在负载均衡器中进行配置。 Web 前端对适当的应用程序服务器进行调用以处理工作。 应用程序服务器查询主 Oracle 数据库。 Oracle Database 使用超线程内存优化虚拟机进行配置（该虚拟机具有受约束的核心 vCPU），以节省许可成本并充分提高性能。 多个高级或超级磁盘（托管磁盘）用于实现性能和高可用性。
Oracle 数据库放置在多个可用性区域中，以实现高可用性。 每个区域由一个或多个数据中心组成，这些数据中心配置了独立电源、冷却和网络。 为确保复原能力，所有已启用的区域中至少设置了三个单独的区域。 数据中心发生故障时，区域中的可用性区域的物理隔离可保护数据。 此外，在两个可用性区域之间设置两个 FSFO 观察程序，以便在发生故障时启动数据库并将数据库故障转移到辅助区域。
可以在与先前体系结构所示区域不同的可用性区域（本例中为 AZ 1）中设置其他观察程序或备用数据库。 最后，Oracle Enterprise Manager (OEM) 会监视 Oracle 数据库的运行时间和性能。 OEM 还让你能够生成各种性能和使用情况报告。
在不支持可用性区域的区域中，可以使用可用性集以高度可用的方式部署 Oracle Database。 可用性集可让你实现 99.95% 的 VM 运行时间。 下图是此用法的参考体系结构：
注意
- 由于只部署了一个 OEM 实例，因此不必将 Oracle Enterprise Manager VM 放置在可用性集中。
- 当前不支持在可用性集配置中使用超级磁盘。
Oracle Data Guard Far Sync
Oracle Data Guard Far Sync 为 Oracle Database 提供零数据丢失保护功能。 借助此功能，你可以在数据库计算机出现故障时防止数据丢失。 Oracle Data Guard Far Sync 需要安装在单独的 VM 上。 Far Sync 是一种轻型 Oracle 实例，仅包含控制文件、密码文件、spfile 和备用日志。 没有数据文件或恢复日志文件。
为实现零数据丢失保护，主数据库和 Far Sync 实例之间必须进行同步通信。 Far Sync 实例以同步方式从主副本接收恢复内容，并以异步方式将其立即转发到所有备用数据库。 此设置还将减少主数据库上的开销，因为它只需将恢复内容发送到 Far Sync 实例，而不是所有备用数据库。 如果 Far Sync 实例失败，Data Guard 会自动使用从主数据库到辅助数据库的异步传输，以维持近乎为零的数据丢失保护。 为提升复原能力，客户可以为每个数据库实例（包括主数据库和辅助数据库实例）部署多个 Far Sync 实例。
下图是一种使用 Oracle Data Guard Far Sync 的高可用性体系结构：
在上述体系结构中，有一个 Far Sync 实例部署在与数据库实例不同的可用性区域中，以确保不会丢失任何数据，并在可用性区域发生故障时自动进行故障转移。 如果应用程序对延迟敏感，请考虑将数据库和 Far Sync 实例部署在同一可用性区域的某个邻近放置组中。
下图是一种使用 Oracle Data Guard FSFO 和 Far Sync 实现高可用性和灾难恢复的体系结构：
Oracle GoldenGate
GoldenGate 支持在整个企业的多种异构平台之间在事务级交换和操作数据。 它将提交的事务移至现有基础结构上，同时保持事务完整性，并将开销降至最低。 借助其模块化体系结构，你可以灵活地在各种拓扑中提取并复制所选数据记录、事务更改以及对数据定义语言 (DDL) 的更改。
Oracle GoldenGate 通过提供双向复制，让你可配置数据库来实现高可用性。 此方法可以让你设置多主数据库或主动-主动配置。 以下关系图是 Azure 上 Oracle GoldenGate 主动-主动设置的建议体系结构。 在以下体系结构中，Oracle 数据库使用超线程内存优化虚拟机进行配置（该虚拟机具有受约束的核心 vCPU），以节省许可成本并最大限度地提高性能。 此体系结构使用多个高级或超级磁盘（托管磁盘）来实现性能和可用性。
注意
在可用性区域当前不可用的区域中，可以使用可用性集来设置类似的体系结构。
Oracle GoldenGate 的进程（如提取、抽取和 复制）有助于将数据从一个 Oracle 数据库服务器异步复制到另外一个。 借助这些进程，你可以设置双向复制，以确保数据库的高可用性，前提是存在可用性区域级故障时间。
在前面的图中，提取过程在与你的 Oracle 数据库相同的服务器上运行。 数据抽取和复制进程在同一可用区域的单独服务器上运行。 Replicat 进程用于接收另一个可用性区域中的数据库中的数据，并将数据提交到其可用性区域中的 Oracle 数据库。 同样，数据抽取进程会将提取进程提取的数据发送到另一个可用性区域中的复制进程。
虽然前面的体系结构关系图显示了在单独服务器上配置的数据抽取和复制进程，但你可以根据服务器的容量和使用情况在同一服务器上设置所有 Oracle GoldenGate 进程。 请始终查阅 AWR 报告和 Azure 中的指标，了解服务器的使用模式。
在不同可用性区域或不同区域中设置 Oracle GoldenGate 双向复制时，务必确保应用程序可接受不同组件之间的延迟。 可用性区域和区域之间的延迟可能会有所不同。 延迟取决于多个因素。 建议在不同可用性区域或区域中的应用层和数据库层之间设置性能测试。 该测试可以确认配置满足应用程序性能要求。
应用层可在其自身的子网中设置，数据库层可分离到其自身的子网中。 如有可能，请考虑使用 Azure 应用程序网关对应用程序服务器之间的流量进行负载均衡。 应用程序网关是一种可靠的 Web 流量负载均衡器。 该网关提供了基于 cookie 的会话亲和性，可让用户会话保留在同一服务器上，从而最大程度减少数据库上的冲突。 应用程序网关的替代项为 Azure 负载均衡器和 Azure 流量管理器。
Oracle Sharding
Sharding 是 Oracle 12.2 中引入的一种数据层模式。 你可以借助它在独立数据库之间对数据进行横向分区和缩放。 它是一种无共享体系结构，其中每个数据库托管在专用虚拟机上。 除了复原能力和提高可用性外，此模式还支持高读取和写入吞吐量。
此模式消除了单一故障点，提供故障隔离，并支持滚动升级，且没有故障时间。 一个分片或数据中心级故障的故障时间不会影响其他数据中心中其他分片的性能或可用性。
Sharding 适用于不能承受故障时间的高吞吐量 OLTP 应用程序。 具有相同分片键的所有行始终保证在同一个分片上。 这样就提高了性能，提供高度的一致性。 使用分片的应用程序必须具有定义完善的数据模型和数据分布策略，例如一致的哈希、范围、列表或复合。 该策略主要使用分片键（例如 customerId 或 accountNum）访问数据。 借助分片，你还可以将特定数据集存储在更接近最终客户的位置，从而帮助满足性能和合规性要求。
建议复制分片，以实现高可用性和灾难恢复。 可以使用 Oracle Data Guard 或 Oracle GoldenGate 等 Oracle 技术来完成此设置。 复制单元可以是分片或分片的一部分，也可以是一组分片。 一个或多个分片中断或减速不会影响分片数据库的可用性。
为实现高可用性，可以将备用分片放置在主分片所在的同一可用性区域中。 对于灾难恢复，备用分片可以位于另一个区域。 还可以在多个区域中部署分片，以服务这些区域中的流量。 若要详细了解如何配置分片数据库的高可用性和复制，请参阅分片级别高可用性。
Oracle Sharding 主要包含以下组件。 有关详细信息，请参阅 Oracle 分片概述：
分片目录。 专用 Oracle 数据库，它是所有分片数据库配置数据的永久存储。 所有配置更改（如添加或删除分片、数据映射和分片数据库中的 DDL）都在分片目录中启动。 分片目录还包含 SDB 中所有复制表的主副本。
分片目录使用具体化视图自动将更改复制到所有分片中的复制表。 分片目录数据库还充当查询协调器，用于处理多分片查询和未指定分片键的查询。
我们建议的最佳做法是将 Oracle Data Guard 与可用性区域或可用性集结合使用来实现分片目录的高可用性。 分片目录的可用性不会影响分片数据库的可用性。 分片目录中的故障时间仅会影响 Data Guard 故障转移完成这一短暂期间的维护操作和多分片查询。 SDB 继续路由和运行联机事务。 目录中断不会影响它们。
分片控制器。 需在分片驻留的每个区域/可用性区域中进行部署的轻量级服务。 分片控制器是在 Oracle Sharding 上下文中部署的 Global Service Manager。 为实现高可用性，建议在分片所在的每个可用性区域中至少部署一个分片控制器。
最初连接到数据库时，分片控制器会设置路由信息并缓存后续请求的信息，从而绕过分片控制器。 通过分片建立会话后，所有 SQL 查询和 DML 都受支持，并在给定分片范围内执行。 此路由速度快，并用于执行分片内事务的所有 OLTP 工作负载。 建议将直接路由用于需要最高性能和可用性的所有 OLTP 工作负载。 当分片变得不可用或对分片拓扑进行更改时，路由缓存将自动刷新。
对于依赖于数据的高性能路由，Oracle 建议在访问分片数据库中的数据时使用连接池。 Oracle 连接池、特定于语言的库和驱动程序支持 Oracle Sharding。 有关详细信息，请参阅 Oracle 分片概述。
全局服务。 全局服务类似于常规数据库服务。 除了数据库服务的所有属性外，全局服务还具有分片数据库的属性。 这些属性包括客户端与分片之间的区域相关性以及复制延迟容差。 只需创建一种全局服务即可从/向分片数据库中读取/写入数据。 使用 Active Data Guard 并设置分片的只读副本时，可以为只读工作负载创建另一种全局服务。 客户端可以使用这些全局服务连接到数据库。
分片数据库。 分片数据库是你的 Oracle 数据库。 每个数据库都使用 Oracle Data Guard 在 Broker 配置中进行复制，并启用 FSFO。 无需在每个分片上都设置 Data Guard 故障转移和复制。 创建共享数据库时会对此方面自动配置和部署。 如果特定分片失败，则 Oracle Sharing 会对数据库连接进行从主数据库到备用数据库的故障转移。
可以使用两个界面来部署和管理 Oracle 分片数据库：Oracle Enterprise Manager Cloud Control GUI 和 GDSCTL 命令行实用程序。 甚至可以使用云控制来监视不同分片的可用性和性能。 GDSCTL DEPLOY 命令会自动创建分片及其相应的侦听器。 此外，此命令会自动部署用于管理员指定的分片级高可用性的复制配置。
可通过不同方式对数据库分片：
- 系统托管分片：使用分区跨分片自动分发
- 用户定义的分片：允许指定数据到分片的映射，这在具有法规或数据本地化要求时效果很好
- 复合分片：不同分片空间的系统托管分片和用户定义的分片的组合
- 表子分区：类似于常规已分区表
有关详细信息，请参阅分片方法。
分片数据库看起来就像是应用程序和开发人员的单一数据库。 迁移到分片数据库时，请仔细规划以了解哪些表是复制的，哪些是分片的。
复制表存储在所有分片上，而分片表分布在不同分片中。 建议复制小型和维度表，并分发/分片事实表。 数据可以加载到分片数据库中，方法是使用分片目录作为中心协调器或在每个分片上运行数据抽取。 有关详细信息，请参阅将数据迁移到分片数据库。
使用 Data Guard 的 Oracle Sharding
Oracle Data Guard 可用于通过系统托管分片、用户定义的分片和复合分片方法进行分片。
下图是将 Oracle Data Guard 用于实现每个分片的高可用性的 Oracle Sharding 的参考体系结构。 该体系结构关系图显示了复合分片方法。 对于对数据区域、负载均衡、高可用性、灾难恢复等具有不同要求的应用程序，该体系结构图可能会有所不同。 应用程序可能使用不同的分片方法。 Oracle Sharding 通过提供这些选项，可让你满足这些要求，并高效进行横向缩放。 甚至可以使用 Oracle GoldenGate 部署类似的体系结构。
系统托管的分片是最容易配置和管理的。 用户定义的分片或复合分片非常适用于数据和应用程序是异地分布的场景（你需要控制每个分片的复制情况）。
在前面的体系结构中，复合分片用于对数据进行异地分布，并横向扩展应用层。 复合分片是系统托管分片和用户定义的分片的组合，因此可提供这两种方法的优点。 在上述场景中，首先在由区域分隔的多个分片空间之间对数据分片。 然后，在分片空间中的多个分片上通过一致哈希对数据进行进一步分区。
每个分区空间包含多个分区组。 每个分区组都有多个分片，是复制的单元。 每个分区组都包含分区空间中的所有数据。 分区组 A1 和 B1 是主分区组，而分区组 A2 和 B2 均为备用分区组。 可以选择将单个分片作为复制单元，而不是选择分区组。
在前面的体系结构中，每个可用性区域中都部署了 Global Service Manager (GSM)/分片控制器，以实现高可用性。 建议为每个数据中心/区域至少部署一个 GSM/分片控制器。 此外，还会在包含分区组的每个可用性区域中部署应用程序服务器的实例。 此设置使应用程序可让应用程序服务器与数据库/分区组之间的延迟保持较短时间。 如果数据库发生故障，在发生数据库角色转换后，与备用数据库位于同一区域中的应用程序服务器便可以处理请求。 Azure 应用程序网关和分片控制器将跟踪请求和响应延迟，并相应地路由请求。
从应用程序的角度来看，客户端系统向 Azure 应用程序网关（或 Azure 中的其他负载平衡技术）发出请求，后者将请求重定向到离客户端最近的区域。 Azure 应用程序网关还支持粘滞会话，因此来自同一客户端的任何请求都将路由到同一应用程序服务器。 应用程序服务器在数据访问驱动程序中使用连接池。 JDBC、ODP.NET、OCI 等驱动程序中提供了此功能。 驱动程序可以识别请求中指定的分片键。 用于 JDBC 客户端的 Oracle Universal Connection Pool (UCP) 使非 Oracle 应用程序客户端（如 Apache Tomcat 和 IIS）能够与 Oracle Sharding 配合使用。 有关详细信息，请参阅用于数据库分片的 UCP 共享池概述。
在初始请求期间，应用程序服务器将连接到其区域中的分片控制器，以获取需要将请求路由到的分片的路由信息。 根据传递的分片键，控制器会将应用程序服务器路由到各自的分片。 应用程序服务器通过构建映射来缓存此信息，而对于后续请求，则绕过分片控制器并直接将请求路由到分片。
使用 GoldenGate 的 Oracle Sharding
下图是将 Oracle GoldenGate 用于每个分片的区域内高可用性的 Oracle Sharding 的参考体系结构。 与上述体系结构不同，此体系结构仅描述具有多个可用性区域的单个 Azure 区域中的高可用性。 可以使用 Oracle GoldenGate 部署多区域高可用性分片数据库，类似于前面的示例。
上述参考体系结构使用系统托管分片方法来对数据进行分片。 由于 Oracle GoldenGate 复制在区块级完成，因此，复制到一个分片的数据可复制到另一个分片。 另一半可复制到其他分片。
复制数据的方式取决于复制因子。 若复制因子为 2，在分片组中的三个分片之间，你拥有每个数据块的两个副本。 同样，若复制因子为 3，分片组中有三个分片，那么每个分片中的所有数据都会复制到该分片组中的所有其他分片中。 分片组中的每个分片都有不同的复制因子。 此设置可帮助你在分片组中以及跨多个分片组有效地定义高可用性和灾难恢复设计。
在前面的体系结构中，分片组 A 和分片组 B 都包含相同数据，但驻留在不同的可用性区域中。 如果分片组 A 和分片组 B 的复制因子均为 3，则分片表的每个行/块会在两个分片组之间复制 6 次。 如果分片组 A 的复制因子为 3，分片组 B 的复制因子为 2，则每个行/块区会在两个分片组之间复制 5 次。
如果发生实例级或可用性区域级故障，此设置可防止数据丢失。 应用程序层能够对每个分片进行读取和写入。 为最大限度减少冲突，Oracle Sharding 为每个哈希值范围指定了一个主块。 此功能可确保将特定块区的写入请求定向到相应的区块。 此外，Oracle GoldenGate 提供自动冲突检测和解决方法来处理可能出现的所有冲突。 有关向 Oracle Sharding 实现 GoldenGate 的详细信息和限制，请参阅将 Oracle GoldenGate 与分片数据库配合使用。
在前面的体系结构中，每个可用性区域中都部署了 GSM/分片控制器，以实现高可用性。 建议为每个数据中心或区域至少部署一个 GSM/分片控制器。 会在包含分片组的每个可用性区域中部署一个应用程序服务器实例。 此设置使应用程序可让应用程序服务器与数据库/分区组之间的延迟保持较短时间。 如果数据库发生故障，在数据库角色转换后，与备用数据库位于同一区域中的应用程序服务器便可以处理请求。 Azure 应用程序网关和分片控制器将跟踪请求和响应延迟，并相应地路由请求。
从应用程序的角度来看，客户端系统向 Azure 应用程序网关（或 Azure 中的其他负载平衡技术）发出请求，后者将请求重定向到离客户端最近的区域。 Azure 应用程序网关还支持粘滞会话，因此来自同一客户端的任何请求都将路由到同一应用程序服务器。 应用程序服务器在数据访问驱动程序中使用连接池。 JDBC、ODP.NET、OCI 等驱动程序中提供了此功能。 驱动程序可以识别请求中指定的分片键。 用于 JDBC 客户端的 Oracle Universal Connection Pool (UCP) 使非 Oracle 应用程序客户端（如 Apache Tomcat 和 IIS）能够与 Oracle Sharding 配合使用。
在初始请求期间，应用程序服务器将连接到其区域中的分片控制器，以获取需要将请求路由到的分片的路由信息。 根据传递的分片键，控制器会将应用程序服务器路由到各自的分片。 应用程序服务器通过构建映射来缓存此信息，而对于后续请求，则绕过分片控制器并直接将请求路由到分片。
修补和维护
将 Oracle 工作负载部署到 Azure 时，Microsoft 会负责所有主机操作系统级修补。 Microsoft 会提前与客户沟通任何计划的操作系统级别维护。 两个不同可用性区域的两个服务器绝不会同时修补。 有关 VM 维护和修补的详细信息，请参阅 Azure 虚拟机的可用性选项。
可以使用 Azure 自动化更新管理来自动修补虚拟机操作系统。 可以使用 Azure Pipelines 或 Azure 自动化更新管理来自动执行和安排 Oracle 数据库的修补和维护，以最大程度减少故障时间。 有关持续交付和蓝/绿部署的详细信息，请参阅渐进式曝光技术。
体系结构和设计注意事项
- 请考虑对 Oracle Database VM 使用超线程内存优化虚拟机（具有受约束的核心 vCPU），以节省许可成本并最大限度地提高性能。 使用多个高级或超级磁盘（托管磁盘）来实现性能和可用性。
- 使用托管磁盘时，重启时磁盘/设备名称可能会更改。 建议使用设备 UUID 而不是名称，以确保在重启后装载保持不变。 有关详细信息，请参阅将新文件系统添加到 /etc/fstab。
- 使用可用性区域实现区域内的高可用性。
- 考虑为 Oracle 数据库使用超级磁盘（如果可用）或高级磁盘。
- 请考虑使用 Oracle Data Guard 在另一个 Azure 区域中设置备用 Oracle 数据库。
- 请考虑使用邻近的放置组来降低应用层和数据库层之间的延迟。
- Azure VM 的最大网络带宽（通常）高于同一 SKU 上的最大磁盘吞吐量。 你可以在同一 VM SKU 上实现更高的吞吐量，也可以使用较小的 VM SKU，方法是将高性能、低延迟的网络存储（例如 Azure NetApp 文件） 用于数据库。
- 设置 Oracle Enterprise Manage 以进行管理、监视和日志记录。
- 请考虑使用 Oracle Automatic Storage Management 来简化数据库的存储管理。
- 使用 Azure Pipelines 以在无故障时间的情况下管理对数据库的修补和更新。
- 调整你的应用程序代码，添加云原生模式，这可能有助于使你的应用程序更具复原力。 请考虑重试模式、断路器模式等模式，以及云设计模式指南中定义的其他模式。
后续步骤
查看适用于自身场景的以下 Oracle 参考文章。