你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure SQL 托管实例的维护时段
适用于： 
Azure SQL 托管实例
使用维护时段功能，可以为 Azure SQL 托管实例资源配置维护计划，从而使重大维护事件可预测，并减少工作负载的中断次数。
注意
维护时段功能仅保护免受升级或计划性维护产生的计划影响。 它不能保护免受所有故障转移原因影响；可能在维护时段之外导致短暂连接中断的异常包括硬件故障和其他重新配置。
使用提前通知，客户可以将通知配置为最多在发生任何计划事件前的 24 小时内发送。
概述
Azure 会定期执行 SQL 托管实例资源的计划内维护。 在维护事件期间，SQL 托管实例完全可用，但可能会根据 SQL 托管实例的可用性服务级别协议 (SLA) 进行短暂的重新配置。
维护时段专用于无法适应实例重新配置，并且无法缓解由计划内维护事件引起的短暂连接中断的生产工作负载。 通过选择喜欢的维护时段，可以通过将计划内维护计划安排在高峰营业时间外发生，最大程度地减少计划内维护的影响。 可复原的工作负载和非生产工作负载可能依赖于 Azure SQL 的默认维护策略。
维护时段是免费的，可在创建时或针对现有资源进行配置。 可以使用 Azure 门户、PowerShell、CLI 或 Azure API 对其进行配置。
重要
配置维护时段是一种长期运行的异步操作，类似于更改 Azure SQL 资源的服务层级。 该资源在操作过程中可用，只在操作结束时会发生短暂的重新配置，即使在长期运行的事务中断的情况下，通常最多也仅持续 8 秒。 若要将重新配置的影响降至最低，应在高峰时段之外执行操作。
通过维护时段提高可预测性
默认情况下，Azure SQL 维护策略会在当地时间每天早上 8 点到下午 5 点段期间阻止影响最大的更新，以避免在正常高峰营业时间内发生任何中断。 当地时间由承载资源的 Azure 区域的位置确定，并根据当地时区定义遵守夏令时。
在维护期间，数据库仍可用，但某些更新可能需要故障转移。 系统默认维护时段（下午 5 点到上午 8 点）将大多数活动限制到该时段，但紧急更新可能会超出该时段。 若要确保所有更新仅在维护时段内发生，请选择非默认选项。
通过从两个非默认的维护时段槽中进行选择，可以将维护更新时段调整为适用于 Azure SQL 资源的时间：
- 工作日时段：本地时间晚上 10 点到早上 6 点，星期一到星期四
- 周末时段：本地时间晚上 10 点到早上 6 点，星期五到星期日
列出的维护时段所在日子表示每个 8 小时维护时段的开始日期。 例如，“本地时间晚上 10 点到早上 6 点，星期一到星期四”表示维护时段从本地时间（星期一到星期四的）每天晚上 10:00 开始，并在本地时间（星期一到星期四的）早上 6:00 结束。
选择维护时段并且服务配置完成后，计划内维护将仅在所选的时段中进行。 维护事件通常是在单个时段内完成，但其中某些事件可能会跨越两个或更多相邻时段。
重要
Azure SQL 托管实例遵循安全部署做法，确保 Azure 配对区域不会同时部署到其中。 但是，无法预测将首先升级哪个区域，因此无法保证部署顺序。 有时将首先升级主实例，有时将首先升级辅助实例。
如果 SQL 托管实例具有故障转移组，并且这些组与 Azure 区域配对不一致，则应为主要和辅助 SQL 托管实例选择不同的维护时段计划。 例如，可以为异地辅助 SQL 托管实例选择“工作日”维护时段，为异地主要 SQL 托管实例选择“周末”维护时段。
在极少数情况下，任何延迟操作都可能会导致严重影响（例如应用关键安全修补程序），可能会暂时覆盖已配置的维护时段。
提前通知
维护通知可配置为向你发出警报，提醒你即将发生 Azure SQL 托管实例的计划内维护事件。 警报会在维护时段打开前 24 小时以及维护时段结束时到达。 有关详细信息，请参阅提前通知。
功能可用性
支持的订阅类型
配置和使用维护时段适用于以下套餐类型：即用即付、云解决方案提供商 (CSP)、Microsoft 企业协议或 Microsoft 客户协议。
仅限开发/测试使用的套餐不符合条件（例如即用即付开发/测试或企业开发/测试）。
备注
Azure 套餐是用户拥有的 Azure 订阅类型。 例如，具有即用即付率的订阅、Azure 开放许可和 Visual Studio Enterprise 都是 Azure 套餐。 每个套餐和计划都有不同的条款和权益。 你的套餐或计划显示在订阅的“概述”上。 有关将订阅切换到其他套餐的详细信息，请参阅将 Azure 订阅更改为其他套餐。
受支持的服务级别目标
除 Azure SQL 托管实例池外，所有的 SLO 上都可以选择默认维护时段之外的维护时段。
Azure SQL 托管实例区域对维护时段的支持
在所有区域都可以为 Azure SQL 托管实例选择默认维护时段以外的维护时段。
网关维护
在 Azure SQL 托管实例中，网关节点托管在虚拟群集中，并与 SQL 托管实例具有相同的维护时段。
重要
建议使用重定向连接策略，以最大程度地减少维护事件期间的中断次数，请参阅连接类型。
Azure SQL 托管实例的注意事项
Azure SQL 托管实例由一组服务组件构成，这些组件托管在一组专用的、在客户的虚拟网络子网中运行的独立虚拟机上。 这些虚拟机进行分组后构成了虚拟群集，可以托管多个托管实例。 由于为同一子网中的实例配置的维护时段会影响虚拟群集内的虚拟机组数量和虚拟群集管理操作，因此在配置维护时段之前需要考虑一些事项。
维护时段配置是一个长期操作
托管在同一虚拟机组中的所有实例共享同一维护时段。 默认情况下，所有托管实例都托管在具有默认维护时段的组中。 如果在创建实例时指定其他维护时段，或者在创建实例后指定维护时段，则该实例将放入具有相应维护时段的单独的计算机组中。 如果群集中不存在此类组，则会创建一个新组来适应实例的新配置。 如果将虚拟群集中的其他实例配置为使用相同的维护时段，则这些实例也会添加到该组中，这意味着可能需要调整组的大小。 若将实例添加到新的计算机组并调整现有计算机组的大小，可能会增加配置维护时段的操作所需的时间。
为托管实例配置维护时段的预期持续时间可使用实例管理操作的估计持续时间进行计算。
重要
配置维护时段时，该操作的最后一步需要重新配置实例，这通常需要长达 8 秒的时间，即使它会中断长时间运行的事务。 若要将重新配置的影响降至最低，应在高峰时段之外配置维护时段。
IP 地址空间要求
子网中的每个新虚拟机组都根据虚拟群集 IP 地址分配来要求额外的 IP 地址。 更改现有托管实例的维护时段还需要临时额外的 IP 容量，就像为相应的服务层级调整虚拟核心数量一样。
IP 地址更改
配置或更改维护时段会导致更改实例的 IP 地址（在子网的 IP 地址范围内）。
重要
请确保 IP 地址更改后网络安全组 (NSG) 和防火墙规则不会阻止数据流量。
虚拟群集管理操作序列化
服务升级或虚拟群集大小调整（例如添加新计算节点或删除不使用的计算节点）等影响虚拟群集的操作均已序列化。 因此，在前一个虚拟群集管理操作完成之前，无法开始新的虚拟群集管理操作。 如果正在执行的维护操作尚未完成维护时段就结束了，则正在进行的维护操作将会搁置，直至下一个维护时段开放。 在此期间提交的其他管理操作也会搁置，并在正在进行的原有维护操作完成后的下一个维护时段开放期间或之后恢复。 群集内每个虚拟机组的维护操作时间超出单个维护时段的情况并不常见，但如果维护操作很复杂，就可能会发生这种情况。
虚拟群集管理操作序列化是常规行为，也适用于默认维护策略。 配置维护时段计划时，两个相邻时段之间的时间段可能是几天。 如果维护操作跨越两个时段，则新提交的操作可能会搁置几天，这种情况非常罕见，但在此期间可能会阻止需要更多计算节点的操作，例如创建新实例或调整现有实例的大小。
检索维护事件列表
Azure Resource Graph 是可以扩展 Azure 资源管理的 Azure 服务。 Azure Resource Graph Explorer 可提供高效且高性能的资源浏览功能，它能够在一组给定的订阅中进行大规模查询，使你能够有效地管理环境。
你可以使用 Azure Resource Graph Explorer 查询维护事件。 有关如何运行这些查询的介绍，请参阅快速入门：使用 Azure Resource Graph Explorer 运行第一个 Resource Graph 查询。
若要检查订阅中所有 SQL 托管实例的维护事件，请在 Azure Resource Graph 资源管理器中使用以下示例查询：
servicehealthresources
| where type =~ 'Microsoft.ResourceHealth/events'
| extend impact = properties.Impact
| extend impactedService = parse_json(impact[0]).ImpactedService
| where impactedService =~ 'SQL Managed Instance'
| extend eventType = properties.EventType, status = properties.Status, description = properties.Title, trackingId = properties.TrackingId, summary = properties.Summary, priority = properties.Priority, impactStartTime = todatetime(tolong(properties.ImpactStartTime)), impactMitigationTime = todatetime(tolong(properties.ImpactMitigationTime))
| where eventType == 'PlannedMaintenance'
| order by impactStartTime desc
有关示例查询的完整参考以及如何跨 PowerShell 或 Azure CLI 等工具使用这些查询，请访问适用于 Azure 服务运行状况的 Azure Resource Graph 查询示例。