使用维护计划管理服务更新和维护

此维护计划功能可集成服务运行状况计划内维护通知、资源运行状况检查监视器，以及针对 Azure Synapse Analytics 中的 Synapse SQL 池（数据仓库）的维护计划服务。

应使用维护计划选择一个方便接收新功能、升级和修补程序的时间范围。 你将需要选择 7 天内的主要和辅助维护时段，每个时段必须在单独的日期范围内。

例如，可以这样计划：主要时段为星期六 22:00 到星期日 01:00，辅助时段为星期三 19:00 到 22:00。 如果在主要维护时段无法进行维护，它会尝试在辅助维护时段再次进行维护。 在主要时段和辅助时段期间都可能会进行服务维护。 为了确保快速完成所有维护操作，DW400c 和更低的数据仓库层可以在指定的维护时段之外完成维护。

所有新创建的数据仓库实例会在部署期间应用系统定义的维护计划。 部署完成后即可编辑该计划。

选择维护时段时，需要选择开始时间并设置最大持续时间。 “维护时段的最大持续时间”决定了执行维护任务的时间范围。此时间范围可以是三 (3) 到八 (8) 小时，最低要求为三 (3) 小时。 在此期间，数据仓库将暂时脱机，因为专用池将使用类似于暂停/恢复的过程移动到升级后的容量。 通常，此操作将在 30 分钟内完成，但请务必注意，在某些情况下，可能需要更长的时间。 例如，如果在维护开始时有活动事务，则会取消并回滚这些事务，这可能会导致还原联机服务时出现延迟。 为了防止出现这种情况，建议确保在启动维护时段期间没有长时间运行的事务处于活动状态。

所有维护操作都会在指定的维护时段内完成，除非我们必须部署时间敏感型更新。 如果在计划维护期间暂停数据仓库，则会在恢复操作期间进行更新。 数据仓库维护完成后，你会立即收到通知。

警报和监视

与服务运行状况通知和资源运行状况检查监视器的集成可让客户随时了解即将发生的维护活动。 此自动化利用 Azure Monitor。 你可以决定如何接收有关即将进行的维护事件的通知。 此外，可以选择自动化流来管理停机时间，尽量减少操作影响。

如果你提前收到了维护通知，但维护无法在通知中指定的时段进行，你会收到取消通知。 随即会在下一个计划的维护期间继续进行维护。

所有活动维护事件显示在“服务运行状况 - 计划内维护”部分中。 服务运行状况历史记录包括以往事件的完整记录。 可以在活动事件期间通过 Azure 服务运行状况检查门户仪表板监视维护。

维护计划可用性

即使维护计划在所选的区域中不可用，也随时可以查看和编辑维护计划。 维护计划在你的区域中可用后，指定的计划会立即对你的 Synapse SQL 池生效。

查看维护计划

默认情况下，所有新创建的数据仓库实例在部署期间会有八小时的主维护时段和辅助维护时段。 如上所述，部署完成后，你可以更改此时段。 在未事先通知的情况下，不会在指定的维护时段外进行维护。

若要查看已应用于 Synapse SQL 池的维护计划，请完成以下步骤：

1. 登录到 Azure 门户。
2. 选择要查看的 Synapse SQL 池。
3. 所选的 Synapse SQL 池随即在“概览”边栏选项卡上打开。 应用于该数据仓库的维护计划将显示在“维护计划”下方。

跳过或更改维护计划

为了确保符合最新的安全要求，我们无法满足跳过或延迟这些更新的请求。 但是，如果你使用 DW500c 和更高的数据仓库层，则可以选择在当前周期内调整维护时段，具体取决于你的情况：

• 如果收到维护挂起通知，并且需要更多时间来完成作业或通知团队，则可以在所定义维护时段开始之前更改窗口开始时间。 此操作会在周期内将窗口时间前移。

• 在收到“挂起”通知的周期开始后，可以通过暂停和恢复（或缩放）SQL 专用池来手动触发维护。 周末维护周期从星期六 00:00 UTC 开始；周中维护周期从星期二的 12:00 UTC 开始。

• 尽管我们确实需要至少 3 小时的维护时段，但通常情况下，此操作将在 30 分钟内完成。 但是，请务必注意，在某些情况下，可能需要更长的时间。 例如，如果在维护开始时有活动事务，则会取消并回滚这些事务，这可能会导致还原联机服务时出现延迟。 为了防止出现这种情况，建议确保在启动维护时段期间没有长时间运行的事务处于活动状态。

确定主要和辅助时段

主要和辅助时段必须包含不同的日期范围。 例如，主要时段为星期二到星期四，辅助时段为星期六到星期日。 术语“主要”和“次要”应分别视为“时段 1”和“时段 2”。 这意味着可以按任何顺序选取任一时段来部署维护升级。

若要更改 Synapse SQL 池的维护计划，请完成以下步骤：

1. 登录到 Azure 门户。

2. 选择要更新的 Synapse SQL 池。 页面将在概述边栏选项卡上打开。 在“概览”边栏选项卡上选择“维护计划摘要”链接，打开维护计划设置的页面。 或者，选择左侧资源菜单中的“维护计划”选项。

   

3. 使用页面顶部的选项确定主要维护时段的首选日期范围。 此选择确定主要时段会出现在工作日还是周末。 所做的选择会更新下拉列表值。 在预览期，某些区域可能尚不支持完整的可用“日期”选项集。

   

4. 使用下拉列表框选择首选的主要和辅助维护时段：

   • 日：在所选时段内执行维护的首选日期。
   • 开始时间：维护时段的首选开始时间。
   • 时间范围：时间范围的首选持续时间。

   边栏选项卡底部的“计划摘要”区域将根据所选的值更新。

5. 选择“保存” 。 此时会显示一条消息，确认新计划现已处于活动状态。

   可以随时更新“天”、“开始时间”、“时间范围”（包括默认的 8 小时时段）选择。 如果要在不支持维护计划的区域中保存计划，则会显示以下消息。 当此功能在所选区域中可用时，设置将会保存并且变为活动状态。

   

常见问题

什么是预期的维护频率。

维护每月可能会发生多次，因为维护可能包括 OS 更新、安全修补程序和驱动程序、内部 Azure 基础结构更新以及 DW 修补程序和更新。 每个客户在周六至周日和周二至周四这段时间都有每周两次的维护周期计划。

维护完成后进行了哪些更改，即使我的专用 SQL 池版本保持不变？

维护更新完成后，SQL 池版本可能会保持不变。 这是因为维护可能包括 OS 更新、安全修补程序和驱动程序、内部 Azure 基础结构更新以及 DW 补丁和更新。 仅当维护中包含 Synapse DW 补丁或更新时，你才会看到对 SQL 专用池版本的更改。

是否可以按需升级专用 SQL 池的版本？

• 否，计划性维护可处理专用 SQL 池的管理。 但在周期启动后，你将可以选择触发维护，具体取决于实际情况。 验证跳过或更改维护计划
• 请务必记住，专用 SQL 池是一项平台即服务 (PaaS) 功能。 这意味着 Azure 会处理与服务相关的各种任务，例如基础结构、维护、更新和可伸缩性。 通过设置警报/通知，可以跟踪计划内维护，以便随时了解即将发生的维护活动。

完成专用 SQL 池维护之前或之后应进行哪些更改（如果有）？

• 在维护期间，服务将短暂脱机，这类似于暂停、继续或缩放操作期间发生的情况。 通常，不到 30 秒即可完成总体维护操作。 但可能会需要更长的时间，具体取决于维护时段内的数据库活动。 建议暂停 ETL、表更新，尤其是事务操作，以避免耗时超过正常维护用时。 例如：
• 如果实例在计划时段非常繁忙，尤其是在进行频繁更新和删除活动时，维护操作需要的时间可能会超过正常时间。 为了降低维护活动延长的可能性，我们建议尽可能将活动限制为针对数据库的大多数只读查询，特别是避免进行长期运行的事务查询（请参阅下一项）。
• 如果在维护开始时存在活动事务，则会取消并回滚这些事务，这可能会导致还原联机服务时出现延迟。 为了防止出现这种情况，建议确保在启动维护时段期间没有长时间运行的事务处于活动状态。

我们已收到有关即将推出的专用 SQL 池计划性维护的通知，其跟踪 ID 为 0000-000，但随后该维护已取消或重新安排。 哪些对象已提示取消或重新安排该维护？

多种因素可能导致计划内维护取消，其中包括以下操作：

• 启动周期后，在收到挂起的维护通知后暂停或缩放操作。
• 如果在维护周期中面向不同的服务级别目标 (SLO)，例如从高于 DW400c 的任何 SLO 转换，然后缩减到低于或等于 DW400c 的 SLO（或进行反向操作），则可能会取消计划内维护。 这是因为维护时段不适用于 DW400c 或更低的性能级别，它们可以随时进行维护。
• 内部基础结构因素，例如发布团队对计划内维护计划的实际更改。
• 如果内部监视检测到维护时间超过预期，可能会取消或重新计划维护。 必须在客户维护时段设置所定义的服务级别协议 (SLA) 内完成维护。

在维护时段内，是否需要考虑对工作负载采用任何最佳做法？

• 是，如果可能，请在计划内维护间隔期间暂停所有事务性工作负载和 ETL 工作负载，以避免还原联机服务时出现错误或延迟。 在即将到来的维护周期之前，应当完成长期运行的事务操作。
• 要在发生维护操作导致的中断后能够复原工作负载，请对连接和命令（查询）级别使用重试逻辑，应用更长的重试间隔和/或更多重试尝试，以承受延长的连接丢失，在某些情况下，连接丢失时间最多可能会延长到 30 分钟或超过 30 分钟。

后续步骤

• 详细了解如何使用 Azure Monitor 创建、查看和管理警报。
• 详细了解用于日志警报规则的 Webhook 操作。
• 深入了解创建和管理操作组。
• 详细了解 Azure 服务运行状况。