适用于：
Azure SQL 数据库Azure SQL 托管实例
了解如何为在 Azure SQL 数据库和 Azure SQL 托管实例中的数据库上执行计划内维护事件做准备。
为了保持 Azure SQL 数据库和 Azure SQL 托管实例服务的安全、合规性、稳定性和高性能，将持续通过服务组件进行更新。 由于现代且可靠的服务架构和创新技术（如热修补），大多数更新对可用性是完全透明且不影响的。 尽管如此，少数类型的更新会导致短暂的服务中断并需要特殊处理。
在计划内维护期间，数据库仲裁的成员会逐个脱机，目的是保留一个成员来响应主要副本。 对于业务关键型和高级数据库，还应至少有一个次要副本处于联机状态，确保不发生客户端停机。
当主要副本需要进入脱机状态时，将启动重新配置进程。
- 对于业务关键数据库和高级数据库，其中一个次要副本将成为新的主副本。
- 对于“常规用途”、“标准”和“基本”数据库，主副本将移动到具有足够可用容量的另一个无状态计算节点。
维护事件可能产生单个或多个重新配置，具体取决于维护事件开始时主要副本和次要副本的集合。 平均而言，每个计划内维护事件会出现 1.7 个重新配置。 重新配置通常在 30 秒内完成。 平均 8 秒。 如果应用程序处于已连接状态，则必须重新连接至新的数据库主要副本。
如果在新的主副本上线之前，尝试建立新的连接，则会出现错误 40613（数据库不可用）：Database '{databasename}' on server '{servername}' is not currently available. Please retry the connection later. 如果数据库有长时间运行的查询，则此查询会在重新配置期间被中断，需要重新启动。
维护时段功能允许配置适用于符合条件的 Azure SQL 数据库和 SQL 托管实例的可预测维护时段计划。 还可以配置在维护时段之前的提前通知。 有关详细信息，请参阅：
确保客户端应用程序在部署到生产环境之前能够应对维护事件。
测试可降低应用程序故障的风险，并为最终用户提供应用程序可用性。 可在计划内维护事件期间通过 PowerShell、CLI 或 REST API 测试应用程序的故障复原能力来测试客户端应用程序的行为。
对于 Azure SQL 托管实例，还请查看如何发起手动故障转移。 手动故障转移会生成与使主要副本脱机的维护事件相同的行为。
连接到云数据库服务的任何客户端生产应用程序均应实现一个可靠的连接重试逻辑。 正确的自动重试逻辑有助于使最终用户尽可能透明地进行重新配置。
如果你希望在出现服务问题或计划内维护活动时收到警报，可将 Azure 门户中的服务运行状况警报与相应的事件类型和操作组配合使用。 有关详细信息，请参阅接收有关 Azure 服务通知的警报。
如果数据库发生登录失败的情况，请在 Azure 门户的资源运行状况窗口中查看当前状态。 “健康历史记录”部分包含每个事件的停机原因（在可用时）。