Merge branch 'main' of https://github.com/MicrosoftDocs/sql-docs-pr into 20260211-restart-database-for-hs

Author: Matt Hyon

azure-sql/database/automated-backups-overview.md

@@ -84,7 +84,7 @@ You can choose one of the following storage redundancies for backups:
 
    :::image type="content" source="media/automated-backups-overview/multi-paired-grs.svg" alt-text="Diagram showing the geo-redundant storage (GRS) option.":::
 
-- **Geo-Zone redundant storage (GZRS)** (preview): Geo-zone-redundant storage (GZRS) combines the high availability provided by redundancy across availability zones (ZRS) with protection from regional outages provided by geo-replication (GRS). Copies your backups synchronously across three Azure availability zones in the primary region, and asynchronously three times to a single physical location in the [paired secondary region](/azure/reliability/cross-region-replication-azure#azure-cross-region-replication-pairings-for-all-geographies). This feature is currently in preview.
+- **Geo-Zone redundant storage (GZRS)**: Geo-zone-redundant storage (GZRS) combines the high availability provided by redundancy across availability zones (ZRS) with protection from regional outages provided by geo-replication (GRS). Copies your backups synchronously across three Azure availability zones in the primary region, and asynchronously three times to a single physical location in the [paired secondary region](/azure/reliability/cross-region-replication-azure#azure-cross-region-replication-pairings-for-all-geographies).
 
    Microsoft recommends using GZRS for applications requiring maximum consistency, durability, and availability, excellent performance, and resilience for disaster recovery.
 

azure-sql/database/business-continuity-high-availability-disaster-recover-hadr-overview.md

@@ -18,11 +18,11 @@ keywords:
   - "cloud business continuity"
   - "database disaster recovery"
   - "database recovery"
-monikerRange: "=azuresql || =azuresql-db || =fabricsql"
+monikerRange: "=azuresql || =azuresql-db "
 ---
 # Business continuity in Azure SQL Database
 
-[!INCLUDE [appliesto-sqldb-fabricsqldb](../includes/appliesto-sqldb-fabricsqldb.md)]
+[!INCLUDE [appliesto-sqldb](../includes/appliesto-sqldb.md)]
 
 > [!div class="op_single_selector"]
 > * [Azure SQL Database](business-continuity-high-availability-disaster-recover-hadr-overview.md?view=azuresql-db&preserve-view=true)

azure-sql/database/serverless-tier-overview.md

@@ -4,7 +4,7 @@ description: This article describes the new serverless compute tier and compares
 author: WilliamDAssafMSFT
 ms.author: wiassaf
 ms.reviewer: moslake, mathoma, dfurman
-ms.date: 12/16/2025
+ms.date: 2/12/2026
 ms.service: azure-sql-database
 ms.subservice: service-overview
 ms.topic: concept-article
@@ -209,7 +209,7 @@ Monitoring, management, or other solutions performing any of these operations tr
 
 #### Auto-resume trigger identification
 
-Auto-resume triggers are exposed in the [Azure Monitor activity log](/azure/azure-monitor/platform/activity-log?tabs=log-analytics) for **Resume Databases** operations under the `Caller` property in the JSON of the **Succeeded** event.
+Auto-resume triggers are exposed in the [Azure Monitor activity log](/azure/azure-monitor/platform/activity-log?tabs=log-analytics) for **Resume Databases** operations under the `Caller` property in the JSON of the **Started** and **Succeeded** events.
 
 ### Connectivity
 

azure-sql/includes/sql-vm-deployment-failure.md

@@ -6,4 +6,4 @@ ms.service: sql
 ms.topic: include
 ---
 > [!WARNING]
-> Placing `tempdb` on the local temp disk for Azure VM images with uninitialized ephemeral disks isn't supported. Deployments through the Azure portal might fail, and SQL Server can fail to start. Either use a different VM size, or place `tempdb` on non-ephemeral storage both when you deploy the SQL Server image through the Azure portal, and when you install SQL Server manually. To learn more, review [VM deployment and SQL Server failures](/troubleshoot/sql/azure-sql/sql-deployment-fails-drive-not-ready).
+> Placing `tempdb` on the local temp disk for Azure VM images with uninitialized ephemeral disks, such as the **FXmdsv2**, isn't supported. This issue only affects Azure Virtual Machines with the new NVMe interface that also has local ephemeral storage. These deployments through the Azure portal might fail, and SQL Server can fail to start. Either use a different VM series, or place `tempdb` on non-ephemeral storage both when you deploy the SQL Server image through the Azure portal, and when you install SQL Server manually. To learn more more about the issue and also see a list of impacted VMs, review [VM deployment and SQL Server failures](/troubleshoot/sql/azure-sql/sql-deployment-fails-drive-not-ready).

azure-sql/includes/virtual-machines-best-practices-vm-size.md

@@ -6,18 +6,17 @@ ms.date: 01/23/2026
 ms.service: virtual-machines
 ms.topic: include
 ms.custom:
-  - ignite-2024
 ---
-- Identify workload performance characteristics to determine the appropriate VM size for your business.
+- Before choosing a VM size, configure your [storage](../virtual-machines/windows/performance-guidelines-best-practices-storage.md). Collect a [baseline](../virtual-machines/windows/performance-guidelines-best-practices-collect-baseline.md) from your source environment under the highest stress conditions and then configure your storage based on the IOPS and throughput needs of your workload with a 20% buffer for future growth. 
+- Identify workload performance characteristics ([OLTP](/azure/architecture/data-guide/relational-data/online-transaction-processing) vs [OLAP](/azure/architecture/data-guide/relational-data/online-analytical-processing), workload size) to determine the appropriate VM size for your business.
 - If you're migrating to Azure, [assess migration readiness](/sql/sql-server/azure-arc/migration-assessment) to find the right VM size for your existing SQL Server workload, and then migrate with [Azure Database Migration Service](/azure/dms/dms-overview). 
 - Use Azure Marketplace images to deploy your SQL Server VMs as the SQL Server settings and storage options are configured for optimal performance.
-- Use VM sizes with 4 or more vCPUs.
+- Use VM sizes with 4 or more vCores.
 - Use memory optimized virtual machine sizes for the best performance of SQL Server workloads. 
-   - The [Edsv5-series](../virtual-machines/windows/performance-guidelines-best-practices-vm-size.md#edsv5-series), and the [Msv3 and Mdsv3-series](../virtual-machines/windows/performance-guidelines-best-practices-vm-size.md#msv3-and-mdsv3-series) offer an optimal memory-to-vCore ratio recommended for OLTP workloads.
-   - The [Mbdsv3-series VMs](../virtual-machines/windows/performance-guidelines-best-practices-vm-size.md#mbsv3-and-mbdsv3-series) offer the best performance for SQL Server workloads on Azure VMs. Consider this series first for mission critical OLTP and data warehouse SQL Server workloads.
-   - The [Ebdsv5-series](../virtual-machines/windows/performance-guidelines-best-practices-vm-size.md#ebdsv5-series) provides a high I/O throughput-to-vCore ratio, along with a memory-to-vCore ratio of 8:1. This series offers the best price-performance for SQL Server workloads on Azure VMs. Consider these VMs first for most SQL Server workloads.  
-   - The [M-series family](../virtual-machines/windows/performance-guidelines-best-practices-vm-size.md#memory-optimized-m-series-vms) offers VMs with the highest memory allocation in Azure. 
-   - The [Mbsv3 and Mbdsv3 series](../virtual-machines/windows/performance-guidelines-best-practices-vm-size.md#mbsv3-and-mbdsv3-series) VMs provide a high memory allocation and the highest I/O throughput-to-vCore ratio amongst the M-series family, along with a consistent memory-to-vCore ratio of at least 8:1. 
-- Start development environments with the lower-tier D-Series, B-Series, or Av2-series and grow your environment over time.
+   - The [Mbdsv3-series](../virtual-machines/windows/performance-guidelines-best-practices-vm-size.md#mbdsv3-series) offers the best overall performance for mission critical OLTP and data warehouse workloads.
+   - The [Ebdsv5-series](../virtual-machines/windows/performance-guidelines-best-practices-vm-size.md#ebdsv5-series) provides the best price-performance for most production SQL Server workloads.  
+   - The [Easv7-series](../virtual-machines/windows/performance-guidelines-best-practices-vm-size.md#easv7-series) and [Msv3/Mdsv3-series](../virtual-machines/windows/performance-guidelines-best-practices-vm-size.md#msv3-and-mdsv3-medium-memory-series) are optimized for memory-intensive workloads.
+   - The [M-series family](../virtual-machines/windows/performance-guidelines-best-practices-vm-size.md#memory-optimized-m-series-vms) offers the highest memory configurations in Azure for the largest workloads. 
+- Start development environments with the lower-tier D-Series, or B-Series, and grow your environment over time.
 - Check [VM supportability](../virtual-machines/windows/performance-guidelines-best-practices-vm-size.md#supportability) to avoid unsupported configurations.
-- Use [VM vCore customization](../virtual-machines/windows/performance-guidelines-best-practices-vm-size.md#vm-vcore-customization) to appropriately allocate vCPUs for your workload and VM and reduce SQL Server licensing costs.
+- Use [VM vCore customization](../virtual-machines/windows/performance-guidelines-best-practices-vm-size.md#vm-vcore-customization) to appropriately allocate vCPUs for your workload and VM and reduce SQL Server licensing costs, as well as disable SMT/hyperthreading settings for optimal SQL Server performance.

azure-sql/managed-instance/managed-instance-link-feature-overview.md

@@ -201,6 +201,10 @@ Configuration limitations include:
 
   - If there are multiple SQL Server instances on a server, you can configure a link for each instance, but you must configure each instance to use a separate database mirroring endpoint, with a dedicated port per instance. Only the default instance should use port 5022 for the database mirroring endpoint. 
   - You can place only one database into a single availability group for one Managed Instance link. However, you can replicate multiple databases in a single SQL Server instance by establishing multiple links. 
+  
+   > [!NOTE]
+   > If you're interested in participating in a limited preview of a change to this behavior, please fill out the following [form](https://aka.ms/milink-multidb-prpr).
+
   - You can create a link with an existing availability group with a single database. If your existing availability group has multiple databases, you can create a link with the availability group only if you remove all databases except one from the availability group.
   - A single General Purpose or Business Critical SQL Managed Instance supports up to 100 links, and a single Next-gen General Purpose SQL Managed Instance supports up to 500 links, from the same, or from multiple SQL Server sources.
   - A Managed Instance link can replicate a database of any size if it fits into the chosen storage size of the target SQL Managed Instance deployment.

azure-sql/managed-instance/recovery-using-backups.md

@@ -163,7 +163,7 @@ If you need to restore an unintentionally deleted SQL managed instance, contact
 ## Geo-restore
 
 > [!IMPORTANT]
-> - Geo-restore is available only for managed instances configured with geo-redundant or geo-zone redundant (GZRS) [backup storage](automated-backups-overview.md#backup-storage-redundancy). If you're not currently using geo-replicated backups for a database, you can change this by [configuring backup storage redundancy](automated-backups-change-settings.md#configure-backup-storage-redundancy).
+> - Geo-restore is available only for SQL managed instances configured with geo-redundant or geo-zone redundant (GZRS) [backup storage](automated-backups-overview.md#backup-storage-redundancy). If you're not currently using geo-replicated backups for a database, you can change this by [configuring backup storage redundancy](automated-backups-change-settings.md#configure-backup-storage-redundancy).
 > - You can perform geo-restore on managed instances that reside in the same subscription only.
 
 Geo-restore is the default recovery option when your database is unavailable because of an incident in the hosting region. You can restore the database to an instance in any other region. You can restore a database on any managed instance in any Azure region from the most recent geo-replicated backups. Geo-restore uses a geo-replicated backup as its source. You can request a geo-restore even if an outage has made the database or datacenter inaccessible.