Merge pull request #36758 from MicrosoftDocs/main

Auto Publish – main to live - 2026-03-03 23:30 UTC

Author: learn-build-service-prod[bot]

azure-sql/database/service-tier-hyperscale.md

@@ -7,7 +7,7 @@ ms.reviewer: dfurman, mathoma, oslake, randolphwest, adbadram
 ms.date: 12/12/2025
 ms.service: azure-sql-database
 ms.subservice: service-overview
-ms.topic: article
+ms.topic: concept-article
 ms.custom:
   - sqldbrb=1
   - build-2025

azure-sql/includes/virtual-machines-best-practices-storage.md

@@ -17,8 +17,8 @@ ms.topic: include
 - Place data, log, and `tempdb` files on separate drives.  
   - For the data drive, use [premium P30 and P40 or smaller disks](/azure/virtual-machines/disks-types#premium-ssds) to ensure the availability of cache support. When using the [Ebdsv5 VM series](/azure/virtual-machines/ebdsv5-ebsv5-series), use [Premium SSD v2](../virtual-machines/windows/storage-configuration-premium-ssd-v2.md) which provides better price-performance for workloads that require high IOPS and I/O throughput.
   - For the log drive plan for capacity and test performance versus cost while evaluating either [Premium SSD v2](/azure/virtual-machines/disks-types#premium-ssd-v2) or Premium SSD [P30 - P80 disks](/azure/virtual-machines/disks-types#premium-ssds)
-    - If submillisecond storage latency is required, use either [Premium SSD v2](../virtual-machines/windows/storage-configuration-premium-ssd-v2.md) or [Azure ultra disks](/azure/virtual-machines/disks-types#ultra-disks) for the transaction log.
-    - For M-series virtual machine deployments, consider [write accelerator](/azure/virtual-machines/how-to-enable-write-accelerator) over using Azure ultra disks.
+    - If submillisecond storage latency is required, use either [Premium SSD v2](../virtual-machines/windows/storage-configuration-premium-ssd-v2.md) or [Azure Ultra Disks](/azure/virtual-machines/disks-types#ultra-disks) for the transaction log.
+    - For M-series virtual machine deployments, consider [write accelerator](/azure/virtual-machines/how-to-enable-write-accelerator) over using Azure Ultra Disks.
   - Place [tempdb](/sql/relational-databases/databases/tempdb-database) on the [temporary disk](../virtual-machines/windows/tempdb-ephemeral-storage.md) (the temporary disk is ephemeral, and defaults to `D:\`) for most SQL Server workloads that aren't part of a failover cluster instance (FCI) after choosing the optimal VM size.
     - If the capacity of the local drive isn't enough for `tempdb`, consider sizing up the VM. For more information, see [Data file caching policies](../virtual-machines/windows/performance-guidelines-best-practices-storage.md#data-file-caching-policies).
   - For failover cluster instances (FCI) place `tempdb` on the shared storage.

azure-sql/managed-instance/doc-changes-updates-known-issues.md

@@ -5,7 +5,7 @@ description: Learn about the currently known issues with Azure SQL Managed Insta
 author: MashaMSFT
 ms.author: mathoma
 ms.reviewer: randolphwest
-ms.date: 02/13/2026
+ms.date: 03/03/2026
 ms.service: azure-sql-managed-instance
 ms.subservice: service-overview
 ms.topic: troubleshooting-known-issue
@@ -25,7 +25,7 @@ This article lists the currently known issues with [Azure SQL Managed Instance](
 | [Misleading error message when connecting to a read replica using invalid credentials](#misleading-error-message-when-connecting-to-a-read-replica-using-invalid-credentials) | February 2026 |
 | [Modifying backup retention period for the free offer](#modifying-backup-retention-period-for-the-free-offer) | June 2025 | Has workaround | |
 | [Login to read-secondary failed due to long wait on "HADR_DATABASE_WAIT_FOR_TRANSITION_TO_VERSIONING"](#login-to-read-secondary-failed-due-to-long-wait-on-hadr_database_wait_for_transition_to_versioning) | April 2025 | Has workaround | |
-| [Interim guidance on 2024 time zone updates for Paraguay](#interim-guidance-on-2024-time-zone-updates-for-paraguay) | March 2025 |  | February 2026 |
+| [Interim guidance on 2024 time zone updates for Paraguay](#interim-guidance-on-2024-time-zone-updates-for-paraguay) | March 2025 | Resolved | February 2026 |
 | [Error 8992 when running DBCC CHECKDB on a SQL Server database that originated from SQL Managed Instance](#error-8992-when-running-dbcc-checkdb-on-a-sql-server-database-that-originated-from-sql-managed-instance) | March 2025 | Has workaround | |
 | [Differential backups aren't taken when an instance is linked to SQL Server](#differential-backups-arent-taken-when-an-instance-is-linked-to-sql-server) | Sept 2024 | By design | |
 | [List of long-term backups in Azure portal shows backup files for active and deleted databases with the same name](#list-of-long-term-backups-in-azure-portal-shows-backup-files-for-active-and-deleted-databases-with-the-same-name) | Mar 2024 | Has workaround | |
@@ -46,7 +46,7 @@ This article lists the currently known issues with [Azure SQL Managed Instance](
 | [Wrong error returned while trying to remove a file that isn't empty](#wrong-error-returned-while-trying-to-remove-a-file-that-isnt-empty) | Oct 2019 | Resolved | August 2020 |
 | [Change service tier and create instance operations are blocked by ongoing database restore](#change-service-tier-and-create-instance-operations-are-blocked-by-ongoing-database-restore) | Sep 2019 | Has workaround | |
 | [Resource Governor on a readable secondary replica needs reconfiguration after failover](#resource-governor-on-a-readable-secondary-replica-needs-reconfiguration-after-failover) | Sep 2019 | Has workaround | |
-| [Cross-database Service Broker dialogs need reinitialization after service tier upgrade](#cross-database-service-broker-dialogs-need-reinitialization-after-service-tier-upgrade) | Aug 2019 | Has workaround | |
+| [Cross-database Service Broker dialogs need reinitialization after service tier upgrade](#cross-database-service-broker-dialogs-need-reinitialization-after-service-tier-upgrade) | Aug 2019 | Resolved | January 2020 |
 | [Impersonation of Microsoft Entra login types isn't supported](#impersonation-of-azure-ad-login-types-isnt-supported) | Jul 2019 | No Workaround | |
 | [Transactional replication must be reconfigured after geo-failover](#transactional-replication-must-be-reconfigured-after-geo-failover) | Mar 2019 | No Workaround | |
 | [Exceeding storage space with small database files](#exceeding-storage-space-with-small-database-files) | | Has workaround | |
@@ -188,12 +188,6 @@ The [Resource governor](/sql/relational-databases/resource-governor/resource-gov
 
 <a id="cross-database-service-broker-dialogs-must-be-reinitialized-after-service-tier-upgrade"></a>
 
-### Cross-database Service Broker dialogs need reinitialization after service tier upgrade
-
-Cross-database Service Broker dialogs stop delivering the messages to the services in other databases after change service tier operation. The messages *aren't lost*, and they can be found in the sender queue. Any change of vCores or instance storage size in SQL Managed Instance causes a `service_broke_guid` value in [sys.databases](/sql/relational-databases/system-catalog-views/sys-databases-transact-sql) view to change for all databases. Any `DIALOG` created using a [BEGIN DIALOG](/sql/t-sql/statements/begin-dialog-conversation-transact-sql) statement that references Service Brokers in other databases stops delivering messages to the target service.
-
-**Workaround**: Stop any activity that uses cross-database Service Broker dialog conversations before updating a service tier, and reinitialize them afterward. If undelivered messages remain after a service tier change, read the messages from the source queue and resend them to the target queue.
-
 ### Exceeding storage space with small database files
 
 `CREATE DATABASE`, `ALTER DATABASE ADD FILE`, and `RESTORE DATABASE` statements might fail because the instance reaches the Azure Storage limit on the General Purpose service tier, but not the [Next-gen General Purpose service tier upgrade](service-tiers-next-gen-general-purpose-use.md) or Business Critical service tier.
@@ -346,6 +340,12 @@ In May 2025, this issue was resolved for reading session data from SSMS. The iss
 
 This change in behavior is an unintended consequence of a required security fix. You can work around this issue by creating your own equivalent of the `system_health` session with an `event_file` target in Azure Blob Storage. For more information, including a T-SQL script to create the `system_health` session that can be modified to create your own equivalent of `system_health`, see [Use the system_health session](/sql/relational-databases/extended-events/use-the-system-health-session).
 
+### Cross-database Service Broker dialogs need reinitialization after service tier upgrade
+
+**(Resolved in January 2020)** Cross-database Service Broker dialogs stop delivering the messages to the services in other databases after change service tier operation. The messages *aren't lost*, and they can be found in the sender queue. Any change of vCores or instance storage size in SQL Managed Instance causes a `service_broke_guid` value in [sys.databases](/sql/relational-databases/system-catalog-views/sys-databases-transact-sql) view to change for all databases. Any `DIALOG` created using a [BEGIN DIALOG](/sql/t-sql/statements/begin-dialog-conversation-transact-sql) statement that references Service Brokers in other databases stops delivering messages to the target service.
+
+**Workaround**: Stop any activity that uses cross-database Service Broker dialog conversations before updating a service tier, and reinitialize them afterward. If undelivered messages remain after a service tier change, read the messages from the source queue and resend them to the target queue.
+
 ## Contribute to content
 
 To contribute to the Azure SQL documentation, see the [Docs contributor guide](/sql/sql-server/sql-server-docs-contribute).

azure-sql/managed-instance/free-offer.md

@@ -27,7 +27,7 @@ To get started, select the **Try for free** link on the [Azure SQL hub at aka.ms
 
 ## Prerequisites
 
-To create a free Azure SQL Database, you need:
+To create a free Azure SQL Managed Instance, you need:
 
 - An Azure account.
 - A [supported Azure subscription](#supported-subscription-types). There's a limit of 1 free offer SQL managed instance per subscription.

azure-sql/toc.yml

@@ -1657,7 +1657,7 @@
         items:
         - name: VM to a new region
           href: virtual-machines/windows/move-sql-vm-different-region.md
-        - name: Migrate storage to Ultradisk
+        - name: Migrate storage to Ultra Disk
           href: virtual-machines/windows/storage-migrate-to-ultradisk.md
       - name: Business continuity
         items:

azure-sql/virtual-machines/modernization-advisor.md

@@ -38,7 +38,7 @@ Modernization Advisor evaluates the following SQL Server VM resources to match w
 - The number of vCores
 - Memory used per vCore
 - Storage size
-- Storage type (Standard, Premium SSD, Premium SSDv2)
+- Storage type (Standard, Premium SSD, Premium SSD v2)
 
 ## Potential migration benefits 
 

azure-sql/virtual-machines/windows/availability-group-manually-configure-multiple-regions.md

@@ -230,11 +230,11 @@ After the domain controller restarts, the next step is to [Create a SQL Server v
 
 Before you proceed, consider the following design decisions:
 
-- **Storage: Azure managed disks**
+- **Storage: Azure Managed Disks**
 
-  For the virtual machine storage, use Azure managed disks. We recommend managed disks for SQL Server virtual machines. Managed disks handle storage behind the scenes. In addition, when virtual machines with managed disks are in the same availability set, Azure distributes the storage resources to provide appropriate redundancy.
+  For the virtual machine storage, use Azure Managed Disks. We recommend managed disks for SQL Server virtual machines. Managed disks handle storage behind the scenes. In addition, when virtual machines with managed disks are in the same availability set, Azure distributes the storage resources to provide appropriate redundancy.
 
-  For more information, see [Introduction to Azure managed disks](/azure/virtual-machines/managed-disks-overview). For specifics about managed disks in an availability set, see [Use managed disks for VMs in an availability set](/azure/virtual-machines/availability).
+  For more information, see [Introduction to Azure Managed Disks](/azure/virtual-machines/managed-disks-overview). For specifics about managed disks in an availability set, see [Use managed disks for VMs in an availability set](/azure/virtual-machines/availability).
 
 - **Network: Private IP addresses in production**
 

azure-sql/virtual-machines/windows/availability-group-manually-configure-prerequisites-tutorial-single-subnet.md

@@ -357,11 +357,11 @@ Windows Server 2016 and later versions can use a [cloud witness](/windows-server
 
 Before you proceed, consider the following design decisions:
 
-- **Storage: Azure managed disks**
+- **Storage: Azure Managed Disks**
 
-  For the virtual machine storage, use Azure managed disks. We recommend managed disks for SQL Server virtual machines. Managed disks handle storage behind the scenes. In addition, when virtual machines with managed disks are in the same availability set, Azure distributes the storage resources to provide appropriate redundancy.
+  For the virtual machine storage, use Azure Managed Disks. We recommend managed disks for SQL Server virtual machines. Managed disks handle storage behind the scenes. In addition, when virtual machines with managed disks are in the same availability set, Azure distributes the storage resources to provide appropriate redundancy.
 
-  For more information, see [Introduction to Azure managed disks](/azure/virtual-machines/managed-disks-overview). For specifics about managed disks in an availability set, see [Availability options for Azure virtual machines](/azure/virtual-machines/availability).
+  For more information, see [Introduction to Azure Managed Disks](/azure/virtual-machines/managed-disks-overview). For specifics about managed disks in an availability set, see [Availability options for Azure virtual machines](/azure/virtual-machines/availability).
 
 - **Network: Private IP addresses in production**
 

azure-sql/virtual-machines/windows/create-sql-vm-powershell.md

@@ -46,7 +46,7 @@ Modify as you want and then run these cmdlets to initialize these variables.
 
 Define the storage account and the type of storage to be used by the virtual machine.
 
-Modify as you want, and then run the following cmdlet to initialize these variables. We recommend using [premium SSDs](/azure/virtual-machines/disks-types#premium-ssds) for production workloads.
+Modify as you want, and then run the following cmdlet to initialize these variables. We recommend using [Premium SSDs](/azure/virtual-machines/disks-types#premium-ssds) for production workloads.
 
 :::code language="powershell" source="~/../azure_powershell_scripts/azure-sql/virtual-machine/create-sql-server-vm.ps1" id="StorageVariables":::
 

azure-sql/virtual-machines/windows/doc-changes-updates-release-notes-whats-new-archive.md

@@ -118,7 +118,7 @@ Return to [What's new in SQL Server on Azure VMs?](doc-changes-updates-release-n
 | **Distributed network name (DNN)** | SQL Server 2019 on Windows Server 2016+ is now previewing support for routing traffic to your failover cluster instance (FCI) by using a [distributed network name](./failover-cluster-instance-distributed-network-name-dnn-configure.md) rather than using Azure Load Balancer. This support simplifies and streamlines connecting to your high-availability (HA) solution in Azure. | 
 | **FCI with Azure shared disks** | It's now possible to deploy your [failover cluster instance (FCI)](failover-cluster-instance-overview.md) by using [Azure shared disks](failover-cluster-instance-azure-shared-disks-manually-configure.md). |
 | **Reorganized FCI docs** | The documentation around [failover cluster instances with SQL Server on Azure VMs](failover-cluster-instance-overview.md) has been rewritten and reorganized for clarity. We've separated some of the configuration content, like the [cluster configuration best practices](hadr-cluster-best-practices.md), how to prepare a [virtual machine for a SQL Server FCI](failover-cluster-instance-prepare-vm.md), and how to configure [Azure Load Balancer](./availability-group-vnn-azure-load-balancer-configure.md). | 
-| **Migrate log to ultra disk** | Learn how you can [migrate your log file to an ultra disk](storage-migrate-to-ultradisk.md) to leverage high performance and low latency. | 
+| **Migrate log to Ultra Disk** | Learn how you can [migrate your log file to an Ultra Disk](storage-migrate-to-ultradisk.md) to leverage high performance and low latency. | 
 | **Create availability group using Azure PowerShell** | It's now possible to simplify the creation of an availability group by using [Azure PowerShell](availability-group-az-commandline-configure.md) as well as the Azure CLI. | 
 | **Configure availability group in portal** | It's now possible to [configure your availability group via the Azure portal](availability-group-azure-portal-configure.md). This feature is currently in preview and being deployed so if your desired region is unavailable, check back soon. | 
 | **Automatic extension registration** | You can now enable the [Automatic registration](sql-agent-extension-automatic-registration-all-vms.md) feature to automatically register all SQL Server VMs already deployed to your subscription with the [SQL IaaS Agent extension](sql-server-iaas-agent-extension-automate-management.md). This applies to all existing VMs, and will also automatically register all SQL Server VMs added in the future.   |