通过

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

维护计划功能将 Service Health 计划内维护通知、资源健康检查监视器和维护计划服务集成在 Azure Synapse Analytics 的 Synapse SQL 池（数据仓库）中。

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

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

所有新创建的data warehouse实例都将在部署期间应用系统定义的维护计划。 部署完成后即可编辑该计划。

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

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

备注

  • 维护时段不适用于 DW400c 或更低性能级别。 它们可以随时进行维护。
  • 在维护时段，型号为 DW400c 及更低的设备可能会多次经历短暂的连接中断情况。

警报和监视

Azure提供对云资源的运行状况的全面见解，包括当前和即将发生的问题、影响服务的事件、计划内维护和其他可能影响可用性的更改。

Service Health提供了你使用的Azure服务和区域的个性化视图，使其成为影响服务通信（如中断、计划内维护和其他运行状况公告）的最佳来源。 通过设置Service Health警报，可以通过首选的通信渠道收到有关影响服务的任何问题或更改的通知。

若要为计划内维护设置服务运行状况警报，请导航到 Azure 门户并访问 Service Health 部分。 选择 Alerts 选项卡，并根据池类型将服务类型指定为 SQL Data Warehouse创建新的警报。 选择“维护”作为事件类型，根据你的偏好来定义范围和通知设置，然后保存警报配置。 若要获取详细说明，请参考以下资源：

备注

在执行所有维护事件之前，会提前 24 小时发送通知。 在我们需要部署时间关键型更新的情况下，提前通知时间可能会显著减少。 由于更新的主要性质，这种情况可能会在确定的维护时段之外发生。 如果你提前收到了维护通知，但维护无法在通知中指定的时段进行，你会收到取消通知。 随即会在下一个计划的维护期间继续进行维护。 所有活动维护事件都显示在 Service Health - 计划内维护部分中。 Service Health历史记录包括过去事件的完整记录。 在活动事件期间，可以通过 Azure 服务运行状况检查门户仪表板监视维护。

维护时间表可用性

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

查看维护计划

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

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

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

概述面板

跳过或更改维护安排

为了确保符合最新的安全要求，我们无法满足跳过或延迟这些更新的请求。 但是，如果在当前周期中使用 DW500c 和更高data warehouse层，则根据情况，你可能有一些选项可以调整维护时段：

  • 如果您收到待处理的维护通知，并且需要更多时间来完成工作或通知团队，只要在定义的维护窗口开始之前，您可以更改维护窗口的开始时间。 此操作会在周期内将窗口时间前移。

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

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

备注

  • 如果将时窗更改为早于当前实际时间的开始时间，则维护将立即触发，如果维护启动时有活动事务，这些事务将被中止并回滚。
  • 暂停和恢复操作完成以启动维护后，不会收到确认维护完成的通知，而会收到已取消维护的通知。
  • 如果使用的是 DW400c 或更低版本，虽然你可以更改维护计划，但不会遵循该计划，因为它的性能级别更低。 如前所述，这些数据仓库层可以随时在维护周期内进行维护。

确定主要和次要窗口

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

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

  1. 登录到 Azure portal。

  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 分钟。

后续步骤

  • Last updated on