Azure SQL Managed Instance frequently asked questions (FAQ)

For a list of supported features in SQL Managed Instance, see Azure SQL Managed Instance features.

For differences in syntax and behavior between Azure SQL Managed Instance and SQL Server, see T-SQL differences from SQL Server.

For available hardware characteristics, see Technical differences in hardware configurations. For available service tiers and their characteristics, see Technical differences between service tiers.

Any customer is eligible for any service tier. Both Standard and Enterprise editions covered with Software Assurance can be exchanged by using the Azure Hybrid Benefit (AHB) for the General Purpose (which includes the Next-gen General Purpose service tier upgrade, currently in preview) or Business Critical service tier using the following exchange ratios 1 Standard edition = 1 General Purpose, 1 Enterprise edition = 1 Business Critical, 1 Enterprise edition = 4 General Purpose, and 4 General Purpose = 1 Enterprise Edition. For more information, see Specific rights of the AHB.

For the list of supported subscription types, see Supported subscription types.

Managed instances can be created in most of the Azure regions; see Supported regions for SQL Managed Instance. If you need managed instance in a region that is currently not supported, send a support request via the Azure portal.

SQL Managed Instance has two default limits: limit on the number of subnets you can use and a limit on the number of vCores you can provision. Limits vary across the subscription types and regions. For the list of regional resource limitations by subscription type, see table from Regional resource limitation. These are soft limits that can be increased on demand. If you need to provision more managed instances in your current regions, send a support request to increase the quota using the Azure portal. For more information, see Request quota increases for Azure SQL Database.

The limit of 100 databases per SQL Managed Instance is a hard limit that can't be changed in the General Purpose and Business Critical service tiers. You can have up to 500 databases in the Next-gen General Purpose service tier.

You can consider migrating to other Azure flavors that suit your workload: Azure SQL Database Hyperscale or SQL Server on Azure Virtual Machines.

You can consider migrating to SQL Server on Azure Virtual Machines or Azure SQL Database memory/cpu optimized.

For product defects and known issues, see Known issues.

For new and preview features, see What's new.

You can provision a managed instance from Azure portal, PowerShell, Azure CLI and ARM templates.

Yes, you can provision a managed instance in an existing subscription if that subscription belongs to the Supported subscription types.

This is a current limitation on underlying component that verifies subnet name against the regex ^[a-zA-Z_][^\/:*?"<>|`'^]*(?<![.\s])$. All names that pass the regex and are valid subnet names are currently supported.

You can scale your managed instance from Azure portal, PowerShell, Azure CLI or ARM templates.

Yes, you can. For instructions, see Move resources across regions.

You can delete managed instances via Azure portal, PowerShell, Azure CLI or Resource Manager REST APIs.

Expected time to create a new managed instance or to change service tiers (vCores, storage), depends on several factors. See Management operations.

Restoring each database is guaranteed during the entire defined retention period - even databases that were created and then deleted after only a few seconds. When a database is created, deleted, or restored, backups are taken at different intervals to preserve the data so it's possible to restore during the given retention period. If a database is dropped before a backup operation completes, the drop operation might be blocked with the following error:

Message database 'backup_restore_db_lkg_native_restore' already exists. Choose a different database name.

To avoid this error, check the state of the drop operation before recreating a database with the same name. For more information, see sys.dm_operation_status. Once the operation state shows Completed, it's possible to RESTORE or CREATE a database with the same name.

The following common use cases are likely to encounter this error:

• If multiple databases are dropped and created again with the same name in short succession. When a database is dropped, the remaining tail-end of the transaction log is backed up synchronously before the drop operation finishes, as the image shows:

  

  It's not possible to create a database with the same name until the tail-log is backed up and the drop operation completes. The sequential nature of the drop operation puts databases dropped in short succession into a queue, which can prolong the process of dropping the databases and delays the possibility of creating new ones using the same name.

• If a database is restored and dropped before a full backup is created. When a database is restored, the first step of the restoration process is to take a new full backup of the database. If you try to restore a database, and then drop it immediately before the full backup completes, you won't be able to drop the database and create another database with that same name until the full backup is taken, and the database drop operation completes. Depending on the size of the database, the full backup could take hours.

It's possible your subscription isn't eligible for the free SQL Managed Instance. Otherwise, there's a limit of one free instance per subscription. You need to remove an existing free instance to create another one. If you have recently deleted your free instance, it can take up to one hour for the free offer banner to reappear.

It's likely you ran out of credits for the month. Go to your SQL managed instance in the Azure portal and check the state to see if your instance is in a stopped state due to insufficient credits.

This functionality is currently unavailable.

Yes, you can restore an automated backup from Azure storage, or you can Restore a database backup by using SQL Server Management Studio (SSMS).

Despite the resource limitations, the free SQL Managed is designed to let you test your workloads without any impact. The performance you experience while using the free SQL Managed Instance is identical to the performance of a production version of the instance.

The free SQL Managed Instance offers 4 and 8 vCore options. If your business requires an instance with more resources, create a fully fledged paid SQL Managed Instance.

Backup options can't be changed for the free SQL Managed Instance.

Currently, the Student subscription is ineligible. For eligible subscriptions, review the free SQL Managed Instance offer prerequisites.

Changing a managed instance name isn't supported.

Yes, the SQL Managed Instance default DNS zone .database.windows.net can be changed with your own. However, the managed instance hostname part of its FQDN should remain the same.

To use another DNS zone instead of the default, for example, .contoso.com:

• Use SQL Server Client Network Utility (CliConfg) to define an alias. You can use either just the managed instance hostname, or the managed instance hostname followed by a custom domain name. The CliConfg tool just adds alias in the registry under "HKLM\SOFTWARE\Microsoft\MSSQLServer\Client\ConnectTo" or "HKLM\SOFTWARE\WOW6432Node\Microsoft\MSSQLServer\Client\ConnectTo" depending if you use the 64-bit version (C:\Windows\System32\cliconfg.exe) or the 32-bit version (C:\Windows\SysWOW64\cliconfg.exe), so it can be done using group policy or a script as well. Use both to ensure 32-bit and 64-bit programs can resolve the alias.
• Use CNAME record in DNS with managed instance hostname pointing to managed instance FQDN. In this case, TrustServerCertificate=TRUE is needed when using authentication with Microsoft Entra ID (formerly Azure Active Directory).
• Use A record in DNS with managed instance hostname pointing to the managed instance IP address. Using IP address isn't recommended, as it can change without notice. In this case, TrustServerCertificate=TRUE is needed when using Microsoft Entra authentication.

Azure SQL Managed Instance offers the same performance levels per compute and storage size as other deployment options of Azure SQL Database. If you want to consolidate data on a single instance, or you simply need a feature supported exclusively in SQL Managed Instance, you can migrate your data by using export/import (BACPAC) functionality. Here are other ways to consider for SQL Database migration to SQL Managed Instance:

• Using Data Source External
• Using SQLPackage
• Using BCP

One option is to export a database to BACPAC and then import the BACPAC file. This is the recommended approach if your database is smaller than 100 GB.

Transactional replication can be used if all tables in the database have primary keys and there are no In-memory OLTP objects in the database.

To migrate your SQL Server instance, see SQL Server to Azure SQL Managed Instance Guide.

For migration information about migrating from other platforms, see Azure Database Migration Guide.

For a performance comparison between managed instance and SQL Server, a good starting point is Best practices for performance comparison between Azure SQL Managed Instance and SQL Server article.

See Key causes of performance differences between SQL Managed Instance and SQL Server. The transaction log file size can impact General Purpose SQL Managed Instance performance. For more information, see Impact of log file size on General Purpose.

You can optimize the performance of your managed instance by:

• Automatic tuning that provides peak performance and stable workloads through continuous performance tuning based on AI and machine learning.
• In-memory OLTP that improves throughput and latency on transactional processing workloads and delivers faster business insights.
• Applying some of the best practices for application and database tuning.
• Switching the connection type from proxy to redirect mode for lower latency and higher throughput, in case your workload consists of lots of small transactions.

To improve performance on a General Purpose instance, consider increasing data file size. To optimize storage performance on a General Purpose instance, see Storage best practice guidelines for General Purpose tier.

See Analyzing wait statistics on SQL Managed Instance. Wait statistics are information that might help you understand why the query duration is long and identify the queries that are waiting for something in database engine.

For all possible options to monitor and alert on SQL Managed Instance consumption and performance, see Azure SQL Managed Instance monitoring options blog post. For the real-time performance monitoring for SQL Managed Instance, see Real-time performance monitoring for Azure SQL Managed Instance.

See Monitoring and performance tuning.

See Real-time performance monitoring for Azure SQL Managed Instance.

Yes, SQL Profiler is supported on SQL Managed Instance. For more information, see SQL Profiler. Instead, however, you should consider Extended Events for "tracing" activity with less impact to the monitored instance. For more information, see Extended Events.

No, they aren't supported. You can use DMVs and Query Store together with SQL Profiler and XEvents to monitor your databases.

See Monitor CPU usage on your SQL Server and Azure SQL.

Yes. For instructions, see Create alerts for SQL Managed Instance. For more tips and tricks, see the blog.

You can't, alerting metrics are available for a managed instance only. Alerting metrics for individual databases in a managed instance aren't available.

Storage size for SQL Managed Instance depends on the selected service tier (General Purpose, Next-gen General Purpose or Business Critical). For storage limitations of these service tiers, see Resource limits.

The minimum amount of storage available in an instance is 32 GB. Storage can be added in increments of 32 GB up to the maximum storage size. First 32 GB are free of charge.

Yes, you can purchase add-on storage, independently from compute, to some extent. See Max instance reserved storage in the Table.

To optimize storage performance, see Storage best practices in General Purpose.

No, backup storage isn't deducted from your managed instance storage space. The backup storage is independent from the instance storage space and it isn't limited in size. Backup storage is limited by the time period to retain the backup of your instance databases, configurable up to 35 days. For details, see Automated backups.

To track when automated backups have been performed on a SQL managed instance, review Monitor backup activity.

Yes, you can create a copy-only full backup in their Azure Blob Storage, but it will only be restorable to a managed instance. For details, see Copy-only backup. However, copy-only backup is impossible if the database is encrypted by service-managed TDE since the certificate used for encryption is inaccessible. In such case, use point-in-time-restore feature to move the database to another managed instance, or switch to customer-managed key.

Yes, it's supported and available for SQL Server 2005+ versions. To use native restore, upload your .bak file to Azure blob storage and execute T-SQL commands. For more information, see Native restore from URL.

Yes, but only to SQL Server 2022, during the mainstream support period of SQL Server 2022. It's possible that, in the future, some Azure SQL Managed Instance features might be introduced that require changes to the database format, making backups incompatible with the latest version of SQL Server. Access to such features requires explicit opt-in.

System databases aren't replicated to the secondary instance in a failover group. Therefore, scenarios that depend on objects from the system databases are impossible on the secondary instance unless the objects are manually created on the secondary. For workaround, see Enable scenarios dependent on the object from the system databases.

The required NSG and UDR rules are documented here, and automatically set by the service. Keep in mind that these rules are just the ones we need for maintaining the service. To connect to your instance and use different features you need to set additional, feature specific rules, that you need to maintain.

SQL Managed Instance is responsible for setting rules on management ports. This is achieved through functionality named service-aided subnet configuration. This is to ensure uninterrupted flow of management traffic in order to fulfill an SLA.

Yes. You could analyze traffic coming through your networks security group by configuring Network Watcher flow logs.

Yes. After a managed instance is provisioned, you can set NSG that controls inbound access to the port 1433. It's advised to narrow its IP range as much as possible.

No. This isn't supported for several reasons:

• Routing traffic that represents a response to an inbound management request would be asymmetric and couldn't work.
• Routing traffic to Azure Storage would be affected by throughput constraints and latency so this way we won't be able to provide expected service quality and availability.
• These configurations are error prone and aren't supportable.

Yes. The simplest way to achieve this is to add 0/0 rule to a UDR associated with the managed instance subnet to route traffic through NVA.

Subnet must have sufficient number of available IP addresses. To determine VNet subnet size for SQL Managed Instance, see Determine required subnet size and range for Azure SQL Managed Instance.

In case there aren't enough IP addresses in the subnet where your SQL managed instance is provisioned, create a new subnet and move the SQL managed instance to it. We also suggest that the new subnet is created with more IP addresses allocated so future update operations avoid similar situations. Learn how to move Azure SQL Managed Instance across subnets.

No. You can use either an empty subnet or a subnet that already contains managed instances.

Not if there are managed instances inside. This is an Azure networking infrastructure limitation. You're only allowed to add additional address space to an empty subnet.

Yes. A SQL managed instance can be moved to another subnet inside the same virtual network or in a different virtual network in an online way. Learn how to move Azure SQL Managed Instance across subnets.

This isn't required. You can either Create a virtual network for Azure SQL Managed Instance or Configure an existing virtual network for Azure SQL Managed Instance.

No. Currently we don't support placing a managed instance in a subnet that already contains other resource types.

No, this isn't supported. A managed instance's host name maps to the load balancer in front of the managed instance's virtual cluster. As one virtual cluster can host multiple managed instances, a connection can't be routed to the proper managed instance without specifying its name. For more information on SQL Managed Instance virtual cluster architecture, see Virtual cluster connectivity architecture.

Currently, only private endpoints to managed instances guarantee static IP addresses.

In rare but necessary situations, we might do an online migration of a managed instance to a new virtual cluster, or a different virtual machine group within the virtual cluster, because of technology stack changes that aim to improve the security and reliability of the service. Migrating to a new virtual machine group or virtual cluster results in changing the IP address that is mapped to the managed instance host name. The managed instance service doesn't provide static IP address support, and reserves the right to change the IP address without notice, as a part of regular maintenance cycles.

For the above reason, VNet-local and public endpoints should only be accessed via their associated domain names. We strongly discourage relying on immutability of their IP address as doing so might lead to prolonged unavailability while the service is healthy.

If you require a static IP address that is reachable from outside the virtual network, you can deploy Azure Firewall with a frontend public IP address and configure a NAT rule to translate inbound traffic to a managed instance's private endpoint. Then, set up DNS resolution or configure client aliases so that that SQL clients connect to the firewall's public IP address via managed instance's fully qualified domain name.

Yes, a public endpoint can be enabled to enable inbound traffic from the Internet to reach SQL Managed Instance. For more information, see Use SQL Managed Instance with public endpoints and Configure public endpoint in SQL Managed Instance.

No, using a custom port isn't available. For VNet-local endpoint, SQL Managed Instance uses default port number 1433 and for public data endpoint, SQL Managed Instance uses default port number 3342.

Both global virtual network peering (VNet peering) and Azure virtual WAN are recommended methods to connect two managed instances in different regions. Express Route circuit peering is an alternative option. If neither option is possible in your environment, the only other connectivity method is a Site-to-Site VPN connection. Configure Site-to-Site VPN by using the Azure portal, PowerShell, or the Azure CLI

Support for global virtual network peering (VNet peering) for newly created virtual clusters was added to Azure SQL Managed Instance on September 22, 2020. As such, virtual network peering is supported for managed instances created in empty subnets after Sept 22, 2020. For instances deployed before this date, peering support is limited to networks within the same region due to the constraints of global virtual network peering. For more information, review the relevant section of the Azure Virtual Networks frequently asked questions.

To use global VNet peering with instances created before Sept 2020, considering configuring a maintenance window or moving the instance to a new subnet as either option will move the instance to a new virtual cluster that supports global virtual network peering.

See how to check if global virtual network peering is supported on the virtual cluster if needed.

To mitigate any data exfiltration risks, customers are recommended to apply a set of security settings and controls:

• Turn on Transparent Data Encryption (TDE) on all databases.
• Turn off Common Language Runtime (CLR). This is recommended on-premises as well.
• Use Microsoft Entra authentication only.
• Access the instance with a low-privileged DBA account.
• Configure JIT jumpbox access for the sysadmin account.
• Turn on SQL auditing, and integrate it with alerting mechanisms.
• Turn on Threat Detection from the Microsoft Defender for SQL suite.
• Apply a service endpoint policy to the subnet to control outbound traffic to Azure Storage.
• CREATE EXTERNAL TABLE AS SELECT (CETAS) is disabled by default. To enable CETAS via the allowPolyBaseExport server configuration option, see CREATE EXTERNAL TABLE AS SELECT (CETAS).

Yes. See Resolving private DNS names in Azure SQL Managed Instance.

Yes. See Resolving private DNS names in Azure SQL Managed Instance.

Time zone configuration can be set when a managed instance is provisioned for the first time. Changing the time zone of an existing managed instance isn't supported. For details, see Time zone limitations.

Workarounds include creating a new managed instance with the proper time zone and then either performing a manual backup and restore, or what we recommend, performing a cross-instance point-in-time restore.

Yes, customers can create logins that are members of the sysadmin role. Customers who assume the sysadmin privilege are also assuming responsibility for operating the instance, which can negatively impact the SLA commitment. To add a login to the sysadmin server role, see Microsoft Entra authentication.

Yes, Azure SQL Managed Instance supports Transparent Data Encryption (TDE). For details, see Transparent Data Encryption for SQL Managed Instance.

Yes, Azure Key Vault for BYOK scenario is available for Azure SQL Managed Instance. For details, see Transparent Data Encryption with customer-managed key.

Yes, you can. To migrate an encrypted SQL Server database, you need to export and import your existing certificates into SQL Managed Instance, then take a full database backup and restore it to a managed instance.

You can also use Azure Database Migration Service to migrate the TDE encrypted databases.

You can rotate TDE protector for SQL Managed Instance using Azure Cloud Shell. For instructions, see Transparent Data Encryption in SQL Managed Instance using your own key from Azure Key Vault.

Yes, you don't need to decrypt your database to restore it to SQL Managed Instance. You do need to provide a certificate/key used as the encryption key protector on the source system to SQL Managed Instance to be able to read data from the encrypted backup file. There are two possible ways to do it:

• Upload certificate-protector to SQL Managed Instance. It can be done using PowerShell only. The sample script describes the whole process.
• Upload asymmetric key-protector to Azure Key Vault and point SQL Managed Instance to it. This approach resembles bring-your-own-key (BYOK) TDE use case that also uses Key Vault integration to store the encryption key. If you don't want to use the key as an encryption key protector, and just want to make the key available for SQL Managed Instance to restore encrypted database(s), follow instructions for setting up BYOK TDE, and don't check the checkbox Make the selected key the default TDE protector.

Once you make the encryption protector available to SQL Managed Instance, you can proceed with the standard database restore procedure.

SQL Managed Instance offers vCore-based purchasing model.

You can save costs with the Azure SQL benefits in the following ways:

• Maximize existing investments in on-premises licenses and save up to 55 percent with Azure Hybrid Benefit.
• Commit to a reservation for compute resources and save up to 33 percent with Reserved Instance Benefit. Combine this with Azure Hybrid benefit for savings up to 82 percent.
• Save up to 55 percent versus list prices with Azure Dev/Test Pricing Benefit that offers discounted rates for your ongoing development and testing workloads.

To be eligible for reserved Instance benefit, your subscription type must be an enterprise agreement (offer numbers: MS-AZR-0017P or MS-AZR-0148P) or an individual agreement with pay-as-you-go pricing (offer numbers: MS-AZR-0003P or MS-AZR-0023P). For more information about reservations, see Reserved Instance Benefit.

You can cancel, exchange, or refund reservations with certain limitations. For more information, see Self-service exchanges and refunds for Azure Reservations.

To explore SQL Managed Instance pricing options, see Pricing page.

You can do so using the Microsoft Cost Management solution. Navigate to Subscriptions in the Azure portal and select Cost Analysis.

Use the Accumulated costs option and then filter by the Resource type as microsoft.sql/managedinstances.

You can use compatible Microsoft or third party client tools to access SQL Managed Instance, and you won't be charged any additional costs on your Azure invoice. However, if some of the tools require a license, you're required to have a legally licensed software. This is governed by separate agreements you have with each individual tool manufacturer.

You get the equal amount of free backup storage space as the reserved data storage space purchased, regardless of the backup retention period set. If your backup storage consumption is within the allocated free backup storage space, automated backups on SQL Managed Instance are no additional cost to you, therefore will be free of charge. Exceeding the use of backup storage above the free space result in additional cost. See the Backup storage section of the pricing page for details. More technical information on SQL Managed Instance automated backups is available at Backup storage consumption explained.

You can monitor cost for backup storage via Azure portal. For instructions, see Monitor costs for automated backups.

To optimize your backup storage costs, see Fine backup tuning on SQL Managed Instance.

SQL Managed Instance case studies:

• Komatsu
• KMD
• PowerDETAILS
• Allscripts

To get a better understanding of the benefits, costs, and risks associated with deploying Azure SQL Managed Instance, there's also a Forrester study: The Total Economic Impact of Microsoft Azure SQL Managed Instance databases.

SQL Managed Instance password policy for SQL logins inherits Azure platform policies that are applied to the VMs forming virtual cluster holding the managed instance. At the moment it is not possible to change any of these settings as these settings are defined by Azure and inherited by managed instance.

Each login must set its password upon sign-in, and change its password after it reaches maximum age.

Yes, it's possible to control CHECK_POLICY and CHECK_EXPIRATION fields at the login level. You can check current settings by executing following T-SQL command:

SELECT *
FROM sys.sql_logins

After that, you can modify specified login settings by executing :

ALTER LOGIN <login_name> WITH CHECK_POLICY = OFF;
ALTER LOGIN <login_name> WITH CHECK_EXPIRATION = OFF;

(Replace 'test' with desired login name and adjust policy and expiration values.)

See Certificate rotation for Azure SQL Database & SQL Managed Instance.

See Plan for Azure maintenance events in SQL Managed Instance.

You can vote for a new SQL Managed Instance feature or create a new improvement idea in the SQL Managed Instance Feedback Forum. This way you can contribute to the product development and help us prioritize our potential improvements.

To learn how to create Azure support request, see How to create Azure support request.

All regions, offers, and subscription types have the feature wave enabled starting November 2023.

The feature wave is available to instances in eligible subnets. If you don't see new features, it's likely that the subnet where your SQL managed instance is deployed isn't eligible.

This is likely because your instance doesn't have the November 2022 Feature Wave enabled. To work around this, create a new instance in an empty subnet that has the November 2022 feature wave enabled, and then move or copy the data from your existing instance to the new one.

For instances inside of a failover group, changing the service tier to, or from, the Next-gen General Purpose tier is not supported. You must first delete the failover group before modifying either replica, and then re-create the failover group after the change takes effect.

Zone redundancy is not currently supported for the Next-gen General Purpose service tier.

No, the Next-gen General Purpose service tier upgrade is not currently supported for Instance Pools, or instances inside a pool.