Edit

Plan for Azure maintenance events in Azure SQL Database and Azure SQL Managed Instance

  • Article

Applies to: Azure SQL Database Azure SQL Managed Instance

Learn how to prepare for planned maintenance events on your database in Azure SQL Database and Azure SQL Managed Instance.

What is a planned maintenance event?

To keep Azure SQL Database and Azure SQL Managed Instance services secure, compliant, stable, and performant, updates are being performed through the service components almost continuously. Thanks to the modern and robust service architecture and innovative technologies like hotpatching, majority of updates are fully transparent and nonimpactful in terms of service availability. Still, few types of updates cause short service interrupts and require special treatment.

During planned maintenance, members of the database quorum go offline one at a time, with the intent that there is one responding primary replica. For Business Critical and Premium databases, at least one secondary replica will also be online to ensure no client downtime.

When the primary replica needs to be brought offline, a reconfiguration process occurs.

  • For Business Critical and Premium databases, one of the secondary replicas will become the new primary replica.
  • For General Purpose, Standard, and Basic databases the primary replica will move to another stateless compute node with sufficient free capacity.

What to expect during a planned maintenance event

Maintenance event can produce single or multiple reconfigurations, depending on the constellation of the primary and secondary replicas at the beginning of the maintenance event. On average, 1.7 reconfigurations occur per planned maintenance event. Reconfigurations generally finish within 30 seconds. The average is eight seconds. If already connected, your application must reconnect to the new primary replica of your database.

If a new connection is attempted while the database is undergoing a reconfiguration before the new primary replica is online, you get error 40613 (Database Unavailable): Database '{databasename}' on server '{servername}' is not currently available. Please retry the connection later. If your database has a long-running query, this query will be interrupted during a reconfiguration and will need to be restarted.

Maintenance window feature

The maintenance window feature allows for the configuration of predictable maintenance window schedules for eligible Azure SQL databases and SQL managed instances. Maintenance window advance notifications are available for databases configured to use a non-default maintenance window.

  • For Azure SQL Database, maintenance windows and advance notifications for maintenance windows are generally available.
  • For Azure SQL Managed Instance, maintenance windows are generally available, but advance notifications are a preview feature.

How to simulate a planned maintenance event

Ensure that your client application is resilient to maintenance events before deploying to production.

Testing will mitigate the risk of application faults and contributes to application availability for your end users. You can test behavior of your client application during planned maintenance events by Testing Application Fault Resiliency via PowerShell, CLI, or REST API.

For Azure SQL Managed Instance, also review initiating manual failover. A manual failover produces identical behavior as maintenance event bringing primary replica offline.

Retry logic

Any client production application that connects to a cloud database service should implement a robust connection retry logic. Proper automatic retry logic helps make reconfigurations as transparent as possible to the end users.

Service Health Alert

If you want to receive alerts for service issues or planned maintenance activities, you can use Service Health alerts in the Azure portal with appropriate event type and action groups. For more information, see this Receive alerts on Azure service notifications.

Resource health

If your database is experiencing sign-in failures, check the Resource Health window in the Azure portal for the current status. The Health History section contains the downtime reason for each event (when available).

Related content