关于基础结构维护

Oracle 会定期更新 Oracle Data Infrastructure Cloud@Customer 上的所有 Oracle 管理的基础设施组件。

Oracle 使用遵循优秀实践的自动化流程来应用产品修复和安全修复。这些更新有助于保护数据，并支持数据库可用性、完整性、安全性和 Oracle Cloud 合规性要求。自动化维护还可以减少维护基础设施所需的工作量。

Oracle 管理的组件可以包括物理服务器主机、存储、网卡、Integrated Lights Out Management (ILOM) 接口以及控制层代理服务 VM。

Oracle 每三个月执行一次季度维护，其中可以包括产品修复、增强和安全修复。

除极少数特殊情况外，Oracle 还会提前通知安排的维护。Oracle 还为 VM 集群中的 VM 提供相应建议更新的通知。

Oracle 会安排维护以尽可能保持服务可用性。某些更新可能会暂时影响性能和吞吐量，而单个组件不可用。例如，服务器打补丁通常需要重新启动。Oracle 尽可能按滚动顺序重新启动服务器，以便该服务在更新过程中保持可用。在重新启动期间，每个服务器在短时间内都保持不可用状态，这会降低整体服务容量。在应用程序无法容忍重新启动时计划缓解措施。例如，在服务器打补丁期间关闭应用程序。

每季度维护

Oracle 使用滚动维护操作在整个更新过程中保持数据库可用性，尽可能减少季度维护对应用的影响。专为高可用性而设计的应用可自动、透明地将数据库连接迁移到可用实例，而不会中断，因此无需安排停机时间。

Oracle 根据 Oracle 定义的维护策略调度维护。如果出现意外业务需求，您可以重新安排维护。

默认情况下，使用滚动更新（从服务器开始，然后更新存储）执行基础结构维护。

服务器一次更新一个，任何时候至多有一个服务器脱机。对于每台主机，VM 将关闭，服务器将更新并重新启动，然后启动 VM，而其他服务器将保持运行状态。此方法不会影响专为高可用性设计的应用程序，但未写入以处理滚动实例重新启动的旧应用程序可能会受到影响。此过程将继续，直到两个服务器都更新。

服务器维护完成后，将开始存储维护。存储磁盘一次更新一个。为存储打补丁不会影响数据库可用性，因此不会影响您的应用。但是，滚动存储维护可以在存储磁盘脱机（降低可用 I/O 容量）以及在恢复服务后重新同步（数据基础结构服务器开销很小）时降低 I/O 性能。适当调整数据库和存储大小以适应未维护的服务器上的额外工作，可以最大限度地减少或消除任何性能影响。

虽然预计数据库在滚动维护期间可用，但自动维护会验证 Oracle Clusterware 是否正在运行，但不会验证服务器恢复联机后所有数据库服务和可插入数据库 (Pluggable Databases，PDB) 是否都可用。数据库服务和 PDB 在维护后的可用性可能取决于服务定义。例如，配置有首选和可用节点的数据库服务可以在维护期间重新定位，并且维护完成后不会自动重新定位回其原始节点。Oracle 建议查看有关实现应用持续可用性的文档，以减少潜在影响。通过遵循这些准则，基础设施维护的影响应仅限于次要的服务降级，因为服务器会按顺序更新。

Oracle 建议遵循高可用性架构 (Maximum Availability Architecture，MAA) 实践并使用数据卫士来确保关键应用的高可用性。对于启用了 Data Guard 的数据库，Oracle 建议为运行主数据库和备用数据库的数据基础结构分离维护窗口。您还可以在托管主数据库的数据基础结构上进行维护之前执行切换，以避免在基础结构维护期间对主数据库产生影响。

在维护窗口开始识别可能阻止维护成功的问题之前，会对 Oracle Data Infrastructure Cloud@Customer 基础结构组件执行预检查。预检查期间，基础结构和所有组件保持联机状态。初始预检查在维护开始前大约两周运行，另一个预检查在维护开始前大约 24 小时运行。如果预检查确定需要重新计划的问题，则会向已订阅通知的用户发送通知。

最小化维护窗口