Merge pull request #35520 from MicrosoftDocs/main

Auto Publish – main to live - 2025-10-08 22:30 UTC

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

azure-sql/virtual-machines/windows/tempdb-ephemeral-storage.md

@@ -38,7 +38,7 @@ However, because the local SSD drive is non-persistent, its contents and permiss
 
 Before you can configure your `tempdb` to use ephemeral storage, you need the following prerequisites:
 
-- An Azure subscription. If you don't have an Azure subscription, create a [free account](https://azure.microsoft.com/free/).
+- An Azure subscription. If you don't have an Azure subscription, create a [free account](https://azure.microsoft.com/pricing/purchase-options/azure-account?cid=msft_learn).
 
 - SQL Server manually installed to an [Azure VM](/azure/virtual-machines/windows/quick-create-portal).
 

data-migration/sql-server/managed-instance/custom-roles.md

@@ -1,10 +1,10 @@
 ---
-title: "Custom roles: Online SQL Server to SQL Managed Instance migrations using ADS"
+title: "Custom Roles: Online SQL Server to SQL Managed Instance Migrations Using ADS"
 titleSuffix: Azure Database Migration Service
 description: Learn to use the custom roles for SQL Server to Azure SQL Managed Instance migrations.
 author: rwestMSFT
 ms.author: randolphwest
-ms.date: 06/11/2025
+ms.date: 10/08/2025
 ms.service: azure-database-migration-service
 ms.topic: conceptual
 ms.collection:
@@ -74,6 +74,9 @@ You can use either the Azure portal, Azure PowerShell, Azure CLI, or Azure REST
 
 For more information, see [Create or update Azure custom roles using the Azure portal](/azure/role-based-access-control/custom-roles-portal) and [Azure custom roles](/azure/role-based-access-control/custom-roles).
 
+> [!NOTE]  
+> When migrating to SQL Managed Instance via **Azure portal** using **Managed Identity**, make sure the signed in user has **Storage Blob Data Reader** access on the storage account. This permission is needed to list folders and files in the blob container during migration setup via Azure portal. For more information, see [DMS - Support for Managed Identity for Azure SQL Managed Instance migration](https://techcommunity.microsoft.com/blog/microsoftdatamigration/dms---support-for-managed-identity-for-azure-sql-managed-instance-migration/4411274).
+
 ## Description of permissions needed to migrate to Azure SQL Managed Instance
 
 | Permission action | Description |

data-migration/sql-server/managed-instance/database-migration-service.md

@@ -5,7 +5,7 @@ description: Learn how to migrate on-premises SQL Server to Azure SQL Managed In
 author: abhims14
 ms.author: abhishekum
 ms.reviewer: randolphwest
-ms.date: 10/06/2025
+ms.date: 10/08/2025
 ms.service: azure-database-migration-service
 ms.topic: tutorial
 ms.collection:
@@ -88,7 +88,7 @@ To complete this tutorial, you need to:
     1. In the Azure portal, go to **Storage account** (used for the migration for keeping backup files), and navigate to **IAM roles** > **Assign role**, and assign Storage Blob Data Reader to the associated managed identity.
 
        > [!NOTE]  
-       > The Storage account should have the **Allow storage account key access** option enabled. For more information, see [DMS - Support for Managed Identity for Azure SQL Managed Instance migration](https://techcommunity.microsoft.com/blog/microsoftdatamigration/dms---support-for-managed-identity-for-azure-sql-managed-instance-migration/4411274).
+       > When migrating to SQL Managed Instance via **Azure portal** using **Managed Identity**, make sure the signed in user has **Storage Blob Data Reader** access on the storage account. This permission is needed to list folders and files in the blob container during migration setup via Azure portal. For more information, see [DMS - Support for Managed Identity for Azure SQL Managed Instance migration](https://techcommunity.microsoft.com/blog/microsoftdatamigration/dms---support-for-managed-identity-for-azure-sql-managed-instance-migration/4411274).
 
   As an alternative to using one of these built-in roles, you can [assign custom roles](custom-roles.md).
 

data-migration/sql-server/managed-instance/performance-baseline.md

@@ -1,10 +1,10 @@
 ---
-title: "SQL Server to Azure SQL Managed Instance: Performance baseline"
+title: "SQL Server to Azure SQL Managed Instance: Performance Baseline"
 description: Learn to create and compare a performance baseline when migrating your SQL Server databases to Azure SQL Managed Instance.
 author: rwestMSFT
 ms.author: randolphwest
 ms.reviewer: mathoma, wiassaf
-ms.date: 06/26/2024
+ms.date: 10/08/2025
 ms.service: azure-sql-managed-instance
 ms.subservice: migration-guide
 ms.topic: how-to
@@ -25,9 +25,9 @@ Select a set of queries that are important to, and representative of your busine
 
 The following resources can help define a performance baseline:
 
-- [Monitor CPU usage](https://techcommunity.microsoft.com/t5/azure-sql-blog/monitor-cpu-usage-on-sql-server-and-azure-sql/ba-p/680777#M131)
-- [Monitor memory usage](/sql/relational-databases/performance-monitor/monitor-memory-usage) and determine the amount of memory used by different components such as buffer pool, plan cache, column-store pool, [In-Memory OLTP](/sql/relational-databases/in-memory-oltp/monitor-and-troubleshoot-memory-usage), etc. In addition, you should find average and peak values of the Page Life Expectancy memory performance counter.
-- Monitor disk IO usage on the source SQL Server instance using the [sys.dm_io_virtual_file_stats](/sql/relational-databases/system-dynamic-management-views/sys-dm-io-virtual-file-stats-transact-sql) view or [performance counters](/sql/relational-databases/performance-monitor/monitor-disk-usage).
+- [Monitor CPU usage](https://techcommunity.microsoft.com/blog/azuresqlblog/monitor-cpu-usage-on-sql-server-and-azure-sql/680777#M131)
+- [Monitor memory usage](/sql/relational-databases/performance-monitor/monitor-memory-usage) and determine the amount of memory used by different components such as buffer pool, plan cache, column-store pool, [In-Memory OLTP](/sql/relational-databases/in-memory-oltp/monitor-and-troubleshoot-memory-usage), etc. In addition, you should find average and peak values of the Page Life Expectancy memory performance counter.
+- Monitor disk IO usage on the source SQL Server instance using the [sys.dm_io_virtual_file_stats](/sql/relational-databases/system-dynamic-management-views/sys-dm-io-virtual-file-stats-transact-sql) view or [performance counters](/sql/relational-databases/performance-monitor/monitor-disk-usage).
 - Monitor workload and query performance by examining Dynamic Management Views (or Query Store if you're migrating from SQL Server 2016 and later). Identify average duration and CPU usage of the most important queries in your workload.
 
 Any performance issues on the source SQL Server should be addressed before migration. Migrating known issues to any new system might cause unexpected results and invalidate any performance comparison.
@@ -44,7 +44,7 @@ Performance comparison is likely to result in the following outcomes:
 
 - Most performance parameters and queries in the workload perform as expected, with some exceptions resulting in degraded performance. In this case, identify the differences and their importance. If there are some important queries with degraded performance, investigate whether the underlying SQL plans have changed, or whether queries are hitting resource limits. You can mitigate this by applying some hints on critical queries (for example, change compatibility level, legacy cardinality estimator) either directly or using plan guides. Ensure statistics and indexes are up to date and equivalent in both environments.
 
-- Most queries are slower on a managed instance compared to your source SQL Server instance. In this case, try to identify the root causes of the difference such as [reaching some resource limit](/azure/azure-sql/managed-instance/resource-limits#service-tier-characteristics) such as IO, memory, or instance log rate limits. If there are no resource limits causing the difference, try changing the compatibility level of the database or change database settings like legacy cardinality estimation and rerun the test. Review the recommendations provided by the managed instance or Query Store views to identify the queries with regressed performance.
+- Most queries are slower on a managed instance compared to your source SQL Server instance. In this case, try to identify the root causes of the difference such as [reaching some resource limit](/azure/azure-sql/managed-instance/resource-limits#service-tier-characteristics) such as IO, memory, or instance log rate limits. If there are no resource limits causing the difference, try changing the compatibility level of the database or change database settings like legacy cardinality estimation and rerun the test. Review the recommendations provided by the managed instance or Query Store views to identify the queries with regressed performance.
 
 SQL Managed Instance has a built-in automatic plan correction feature that is enabled by default. This feature ensures that queries that worked fine in the past don't degrade in the future. If this feature isn't enabled, run the workload with the old settings so SQL Managed Instance can learn the performance baseline. Then, enable the feature and run the workload again with the new settings.
 
@@ -55,16 +55,16 @@ Make changes in the parameters of your test or upgrade to higher service tiers t
 SQL Managed Instance provides advanced tools for monitoring and troubleshooting, and you should use them to monitor performance on your instance. Some of the key metrics to monitor are:
 
 - CPU usage on the instance to determine if the number of vCores that you provisioned is the right match for your workload.
-- Page-life expectancy on your managed instance to determine if you need [more memory](https://techcommunity.microsoft.com/t5/azure-sql-blog/do-you-need-more-memory-on-azure-sql-managed-instance/ba-p/563444).
-- Statistics like INSTANCE_LOG_GOVERNOR or PAGEIOLATCH that identify storage IO issues, especially on the General Purpose tier, where you might need to preallocate files to get better IO performance.
+- Page-life expectancy on your managed instance to determine if you need [more memory](https://techcommunity.microsoft.com/blog/azuresqlblog/do-you-need-more-memory-on-azure-sql-managed-instance/563444).
+- Statistics like `INSTANCE_LOG_GOVERNOR` or `PAGEIOLATCH` that identify storage IO issues, especially on the General Purpose tier, where you might need to preallocate files to get better IO performance.
 
 ## Considerations
 
 When comparing performance, consider the following requirements:
 
 - Settings match between source and target. Validate that various instance, database, and `tempdb` settings are equivalent between the two environments. Differences in configuration, compatibility levels, encryption settings, trace flags, etc., can all skew performance.
 
-- Storage is configured according to [best practices](https://techcommunity.microsoft.com/t5/azure-sql-blog/storage-performance-best-practices-and-considerations-for-azure/ba-p/305525). For example, for General Purpose, you might need to preallocate the size of the files to improve performance.
+- Storage is configured according to [best practices](https://techcommunity.microsoft.com/blog/azuresqlblog/storage-performance-best-practices-and-considerations-for-azure-sql-db-managed-i/305525). For example, for General Purpose, you might need to preallocate the size of the files to improve performance.
 
 - There are [key environment differences](https://azure.microsoft.com/blog/key-causes-of-performance-differences-between-sql-managed-instance-and-sql-server/) that might cause the performance differences between a managed instance and SQL Server. Identify risks relevant to your environment that might contribute to a performance issue.
 
@@ -74,5 +74,5 @@ When comparing performance, consider the following requirements:
 
 - [How to identify why workload performance on Azure SQL Managed Instance is different than SQL Server?](https://medium.com/azure-sqldb-managed-instance/what-to-do-when-azure-sql-managed-instance-is-slower-than-sql-server-dd39942aaadd)
 - [Key causes of performance differences between SQL Managed Instance and SQL Server](https://azure.microsoft.com/blog/key-causes-of-performance-differences-between-sql-managed-instance-and-sql-server/)
-- [Storage performance best practices and considerations for Azure SQL Managed Instance (General Purpose)](https://techcommunity.microsoft.com/t5/azure-sql-blog/storage-performance-best-practices-and-considerations-for-azure/ba-p/305525)
+- [Storage performance best practices and considerations for Azure SQL Managed Instance (General Purpose)](https://techcommunity.microsoft.com/blog/azuresqlblog/storage-performance-best-practices-and-considerations-for-azure-sql-db-managed-i/305525)
 - [Real-time performance monitoring for Azure SQL Managed Instance (this is archived, is this the intended target?)](/archive/blogs/sqlcat/real-time-performance-monitoring-for-azure-sql-database-managed-instance)

docs/database-engine/availability-groups/windows/configure-distributed-availability-groups.md

@@ -33,13 +33,13 @@ To configure a distributed availability group, you must have the following:
 
 Requires **CREATE AVAILABILITY GROUP** permission on the server to create an availability group and `sysadmin` to fail over a distributed availability group. 
 
-## Set the endpoint listeners to listen to all IP addresses
+## Set the database mirroring endpoints to listen on all IP addresses
 
-Make sure the endpoints can communicate between the different availability groups in the distributed availability group. If one availability group is set to a specific network on the endpoint, the distributed availability group doesn't work properly. On each server that hosts a replica in the distributed availability group, set the listener to listen on all IP addresses (`LISTENER_IP = ALL`).
+Make sure the database mirroring endpoints can communicate between the different availability groups in the distributed availability group. If one availability group is set to a specific network on the database mirroring endpoint, the distributed availability group doesn't work properly. On each server that hosts a replica in the distributed availability group, set the database mirroring endpoint to listen on all IP addresses (`LISTENER_IP = ALL`).
 
-### Create an endpoint to listen to all IP addresses
+### Create a database mirroring endpoint to listen on all IP addresses
 
-For example, the following script creates a listener endpoint on TCP port 5022 that listens on all IP addresses.
+For example, the following script creates a new database mirroring endpoint on TCP port 5022 that listens on all IP addresses.
 
 ```sql
 CREATE ENDPOINT [aodns-hadr]
@@ -58,9 +58,9 @@ CREATE ENDPOINT [aodns-hadr]
 GO
 ```
 
-### Alter an endpoint to listen to all IP addresses
+### Alter an existing database mirroring endpoint to listen on all IP addresses
 
-For example, the following script changes a listener endpoint to listen on all IP addresses.
+For example, the following script changes an existing database mirroring endpoint to listen on all IP addresses.
 
 ```sql
 ALTER ENDPOINT [aodns-hadr]
@@ -75,7 +75,7 @@ GO
 
 ### Create the primary availability group on the first cluster
 
-Create an availability group on the first Windows Server Failover Cluster (WSFC).   In this example, the availability group is named `ag1` for the database `db1`. The primary replica of the primary availability group is known as the **global primary** in a distributed availability group. Server1 is the global primary in this example.
+Create an availability group on the first Windows Server Failover Cluster (WSFC). In this example, the availability group is named `ag1` for the database `db1`. The primary replica of the primary availability group is known as the **global primary** in a distributed availability group. Server1 is the global primary in this example.
 
 ```sql
 CREATE AVAILABILITY GROUP [ag1]