Maintenance window (Preview)
APPLIES TO: Azure SQL Database Azure SQL Managed Instance
The maintenance window feature allows you to configure maintenance schedule for Azure SQL Database and Azure SQL Managed Instance resources making impactful maintenance events predictable and less disruptive for your workload.
The maintenance window feature only protects from planned impact from upgrades or scheduled maintenance. It does not protect from all failover causes; exceptions that may cause short connection interruptions outside of a maintenance window include hardware failures, cluster load balancing, and database reconfigurations due to events like a change in database Service Level Objective.
Azure periodically performs planned maintenance of SQL Database and SQL managed instance resources. During Azure SQL maintenance event, databases are fully available but can be subject to short reconfigurations within respective availability SLAs for SQL Database and SQL managed instance.
Maintenance window is intended for production workloads that are not resilient to database or instance reconfigurations and cannot absorb short connection interruptions caused by planned maintenance events. By choosing a maintenance window you prefer, you can minimize the impact of planned maintenance as it will be occurring outside of your peak business hours. Resilient workloads and non-production workloads may rely on Azure SQL's default maintenance policy.
The maintenance window can be configured on creation or for existing Azure SQL resources. It can be configured using the Azure portal, PowerShell, CLI, or Azure API.
Configuring maintenance window is a long running asynchronous operation, similar to changing the service tier of the Azure SQL resource. The resource is available during the operation, except a short reconfiguration that happens at the end of the operation and typically lasts up to 8 seconds even in case of interrupted long-running transactions. To minimize the impact of the reconfiguration you should perform the operation outside of the peak hours.
Gain more predictability with maintenance window
By default, Azure SQL maintenance policy blocks impactful updates during the period 8AM to 5PM local time every day to avoid any disruptions during typical peak business hours. Local time is determined by the location of Azure region that hosts the resource and may observe daylight saving time in accordance with local time zone definition.
You can further adjust the maintenance updates to a time suitable to your Azure SQL resources by choosing from two additional maintenance window slots:
- Weekday window, 10PM to 6AM local time Monday - Thursday
- Weekend window, 10PM to 6AM local time Friday - Sunday
Once the maintenance window selection is made and service configuration completed, planned maintenance will occur only during the window of your choice. While maintenance events typically complete within a single window, some of them may span two or more adjacent windows.
In very rare circumstances where any postponement of action could cause serious impact, like applying critical security patch, configured maintenance window may be temporarily overriden.
Cost and eligibility
Configuring and using maintenance window is free of charge for all eligible offer types: Pay-As-You-Go, Cloud Solution Provider (CSP), Microsoft Enterprise Agreement, or Microsoft Customer Agreement.
An Azure offer is the type of the Azure subscription you have. For example, a subscription with pay-as-you-go rates, Azure in Open, and Visual Studio Enterprise are all Azure offers. Each offer or plan has different terms and benefits. Your offer or plan is shown on the subscription's Overview. For more information on switching your subscription to a different offer, see Change your Azure subscription to a different offer.
Maintenance notifications can be configured to alert you on upcoming planned maintenance events for your Azure SQL Database 24 hours in advance, at the time of maintenance, and when the maintenance is complete. For more information, see Advance Notifications.
Supported service level objectives
Choosing a maintenance window other than the default is available on all SLOs except for:
- Instance pools
- Legacy Gen4 vCore
- Basic, S0 and S1
- DC, Fsv2, M-series
Azure region support
Choosing a maintenance window other than the default is currently available in the following regions:
- Australia East
- Australia SouthEast
- Brazil South
- Canada Central
- Canada East
- Central India
- Central US
- East US
- East US2
- East Asia
- France South
- Germany West Central
- Japan East
- Korea Central*
- NorthCentral US
- North Europe
- SouthCentral US
- SouthEast Asia
- UK South
- UK West
- West Central US
- West Europe
- West US
- West US2
*Available only for Azure SQL Managed Instance
Gateway maintenance for Azure SQL Database
To get the maximum benefit from maintenance windows, make sure your client applications are using the redirect connection policy. Redirect is the recommended connection policy, where clients establish connections directly to the node hosting the database, leading to reduced latency and improved throughput.
In Azure SQL Database, any connections using the proxy connection policy could be affected by both the chosen maintenance window and a gateway node maintenance window. However, client connections using the recommended redirect connection policy are unaffected by a gateway node maintenance reconfiguration.
In Azure SQL Managed Instance, the gateway nodes are hosted within the virtual cluster and have the same maintenance window as the managed instance, but using the redirect connection policy is still recommended to minimize number of disruptions during the maintenance event.
For more on the client connection policy in Azure SQL Database, see Azure SQL Database Connection policy.
For more on the client connection policy in Azure SQL Managed Instance see Azure SQL Managed Instance connection types.
Considerations for Azure SQL Managed Instance
Azure SQL Managed Instance consists of service components hosted on a dedicated set of isolated virtual machines that run inside the customer's virtual network subnet. These virtual machines form virtual cluster(s) that can host multiple managed instances. Maintenance window configured on instances of one subnet can influence the number of virtual clusters within the subnet, distribution of instances among virtual clusters, and virtual cluster management operations. This may require a consideration of few effects.
Maintenance window configuration is long running operation
All instances hosted in a virtual cluster share the maintenance window. By default, all managed instances are hosted in the virtual cluster with the default maintenance window. Specifying another maintenance window for managed instance during its creation or afterwards means that it must be placed in virtual cluster with corresponding maintenance window. If there is no such virtual cluster in the subnet, a new one must be created first to accommodate the instance. Accommodating additional instance in the existing virtual cluster may require cluster resize. Both operations contribute to the duration of configuring maintenance window for a managed instance. Expected duration of configuring maintenance window on managed instance can be calculated using estimated duration of instance management operations.
A short reconfiguration happens at the end of the maintenance operation and typically lasts up to 8 seconds even in case of interrupted long-running transactions. To minimize the impact of the reconfiguration you should schedule the operation outside of the peak hours.
IP address space requirements
Each new virtual cluster in subnet requires additional IP addresses according to the virtual cluster IP address allocation. Changing maintenance window for existing managed instance also requires temporary additional IP capacity as in scaling vCores scenario for corresponding service tier.
IP address change
Configuring and changing maintenance window causes change of the IP address of the instance, within the IP address range of the subnet.
Make sure that NSG and firewall rules won't block data traffic after IP address change.
Serialization of virtual cluster management operations
Operations affecting the virtual cluster, like service upgrades and virtual cluster resize (adding new or removing unneeded compute nodes) are serialized. In other words, a new virtual cluster management operation cannot start until the previous one is completed. In case that maintenance window closes before the ongoing service upgrade or maintenance operation is completed, any other virtual cluster management operations submitted in the meantime will be put on hold until next maintenance window opens and service upgrade or maintenance operation completes. It is not common for a maintenance operation to take longer than a single window per virtual cluster, but it can happen in case of very complex maintenance operations. The serialization of virtual cluster management operations is general behavior that applies to the default maintenance policy as well. With a maintenance window schedule configured, the period between two adjacent windows can be few days long. Submitted operations can also be on hold for few days if the maintenance operation spans two windows. That is very rare case, but creation of new instances or resize of the existing instances (if additional compute nodes are needed) may be blocked during this period.