Staging link fixes (#33911)

Author: MashaMSFT

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, mathoma
-ms.date: 04/03/2025
+ms.date: 04/27/2025
 ms.service: azure-sql-managed-instance
 ms.subservice: service-overview
 ms.topic: troubleshooting-known-issue
@@ -24,6 +24,7 @@ This article lists the currently known issues with [Azure SQL Managed Instance](
 
 | Issue | Date discovered | Status | Date resolved |
 | --- | --- | --- | --- |
+| [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 | Has workaround| |
 | [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 | |
@@ -46,7 +47,6 @@ This article lists the currently known issues with [Azure SQL Managed Instance](
 | [Restoring manual backup without CHECKSUM might fail](#restoring-manual-backup-without-checksum-might-fail) | May 2020 | Resolved | June 2020 |
 | [Agent becomes unresponsive upon modifying, disabling, or enabling existing jobs](#agent-becomes-unresponsive-upon-modifying-disabling-or-enabling-existing-jobs) | May 2020 | Resolved | June 2020 |
 | [Permissions on resource group not applied to SQL Managed Instance](#permissions-on-resource-group-not-applied-to-sql-managed-instance) | Feb 2020 | Resolved | Nov 2020 |
-| [Limitation of manual failover via portal for failover groups](#limitation-of-manual-failover-via-portal-for-failover-groups) | Jan 2020 | Has Workaround | |
 | [SQL Agent roles need explicit EXECUTE permissions for nonsysadmin logins](#sql-agent-roles-need-explicit-execute-permissions-for-non-sysadmin-logins) | Dec 2019 | Resolved | Sep 2022 |
 | [SQL Agent jobs can be interrupted by Agent process restart](#sql-agent-jobs-can-be-interrupted-by-agent-process-restart) | Dec 2019 | Resolved | Mar 2020 |
 | [Microsoft Entra logins and users aren't supported in SSDT](#azure-ad-logins-and-users-arent-supported-in-ssdt) | Nov 2019 | No Workaround | |
@@ -71,6 +71,14 @@ This article lists the currently known issues with [Azure SQL Managed Instance](
 
 ## Has workaround
 
+### Login to read-secondary failed due to long wait on "HADR_DATABASE_WAIT_FOR_TRANSITION_TO_VERSIONING"
+
+You might see this error as an exception for the **Microsoft OLE DB Driver 19 for SQL Server** driver when you try to connect to a read-only secondary replica of a [failover group](failover-group-sql-mi.md), or a database replicated through the [Managed Instance link](managed-instance-link-feature-overview.md). 
+
+This error occurs when the secondary replica is not available for logins because row versions are missing for transactions that were in-flight when a secondary replica was restarted, or recycled, either for maintenance, or due to a failover. When an instance is restarted, or fails over, the versioning data stored in `tempdb` gets cleared so secondary read queries are aborted if there are long-running active transactions that were started before the failover or restart. 
+
+To resolve this issue roll back, or commit, active transactions on the primary replica. To avoid this error, minimize long-running write transactions on the primary replica. 
+
 ### Interim guidance on 2024 time zone updates for Paraguay
 
 On October 14, 2024, the Paraguayan government announced a permanent change to the country’s time zone policy. Paraguay will remain on Daylight Saving Time (DST) year-round, effectively adopting UTC-3 as its standard time. As a result, clocks will not advance by 60 minutes at 12:00 a.m. on March 23, 2025, as previously scheduled. This change affects the Paraguay Standard Time time-zone. Microsoft has released related [Windows updates in February and March 2025](https://techcommunity.microsoft.com/blog/dstblog/paraguay-2025-time-zone-update-now-available/4386720). Azure SQL Managed Instance currently does not reflect this update. Instances using affected time zone will not reflect the changes until Azure SQL Managed Instance service absorbs the update on the OS level. 
@@ -191,12 +199,6 @@ In some circumstances, there might exist an issue with Service Principal used to
 
 **Workaround**: To prevent this issue from occurring on your SQL Managed Instance, before executing any update commands, or in case you have already experienced this issue after update commands, go to the **Overview page** of your SQL managed instance in the Azure portal. Under **Settings**, select **Microsoft Entra ID** to access the SQL Managed Instance [Microsoft Entra ID admin page](../database/authentication-aad-configure.md#azure-sql-managed-instance). Verify if you can see the error message "Managed Instance needs a Service Principal to access Microsoft Entra ID. Click here to create a Service Principal". In case you've encountered this error message, select it, and follow the step-by-step instructions provided until this error has been resolved.
 
-### Limitation of manual failover via portal for failover groups
-
-If a failover group spans across instances in different Azure subscriptions or resource groups, manual failover can't be initiated from the primary instance in the failover group.
-
-**Workaround**: Initiate failover via the portal from the geo-secondary instance.
-
 ### SQL Agent roles need explicit EXECUTE permissions for non-sysadmin logins
 
 If non-sysadmin logins are added to any [SQL Agent fixed database roles](/sql/ssms/agent/sql-server-agent-fixed-database-roles), there exists an issue in which explicit EXECUTE permissions need to be granted to three stored procedures in the `master` database for these logins to work. If this issue is encountered, the error message `The EXECUTE permission was denied on the object <object_name> (Microsoft SQL Server, Error: 229)` is shown.

azure-sql/managed-instance/failover-group-configure-sql-mi.md

@@ -4,7 +4,7 @@ description: Learn how to configure a failover group for Azure SQL Managed Insta
 author: Stralle
 ms.author: strrodic
 ms.reviewer: mathoma, randolphwest
-ms.date: 09/08/2024
+ms.date: 04/27/2025
 ms.service: azure-sql-managed-instance
 ms.subservice: high-availability
 ms.topic: how-to
@@ -265,9 +265,6 @@ Use [New-AzSqlDatabaseInstanceFailoverGroup](/powershell/module/az.sql/new-azsql
 
 Test failover of your failover group by using the Azure portal or PowerShell.
 
-> [!NOTE]
-> If the instances are in different subscriptions, or resource groups, initiate the failover from the secondary instance.
-
 ### [Azure portal](#tab/azure-portal)
 
 Test failover of your failover group using the Azure portal.
@@ -316,6 +313,19 @@ Optionally, use the [Switch-AzSqlDatabaseFailoverGroup](/powershell/module/az.sq
 
 ---
 
+## Track failover in the activity log
+
+You can use the **Activity log** in the Azure portal to track the status of the failover operation. To do this, follow these steps:
+
+1. Go to your [SQL managed instance](https://portal.azure.com/#browse/Microsoft.Sql%2FmanagedInstances) in the Azure portal.
+1. Select **Activity log** to open the **Activity log** pane.
+1. Clear any filters for **Resource**. 
+1. Search for operations with the name `Failover Azure SQL Database failover group`: 
+
+   :::image type="content" source="media/failover-group-configure-sql-mi/failover-in-activity-log.png" alt-text="Screenshot of the activity log for your SQL managed instance in the Azure portal, with a failover operation highlighted." lightbox="media/failover-group-configure-sql-mi/failover-in-activity-log.png":::
+
+   
+
 ## Modify existing failover group 
 
 You can modify an existing failover group, such as to change the [failover policy](failover-group-sql-mi.md#failover-policy), by using the Azure portal, PowerShell, Azure CLI and the REST APIs. 

azure-sql/managed-instance/failover-group-sql-mi.md

@@ -116,12 +116,13 @@ Connectivity between the virtual network subnets hosting primary and secondary i
 
 ## Initial seeding
 
-When establishing a failover group between managed instances, there's an initial seeding phase before data replication starts. The initial seeding phase is the longest and most expensive part of the operation. Once initial seeding completes data is synchronized, and only subsequent data changes are replicated. The time it takes for the initial seeding to complete depends on the size of data, number of replicated databases, workload intensity on the primary databases, and the speed of the link between the virtual networks hosting primary and secondary instance that mostly depends on the way connectivity is established. Under normal circumstances, and when connectivity is established using recommended global virtual network peering, seeding speed is up to 360 GB an hour for SQL Managed Instance. Seeding is performed for a batch of user databases in parallel - not necessarily for all databases at the same time. Multiple batches might be needed if there are many databases hosted on the instance.
+When establishing a failover group between managed instances, there's an initial seeding phase before data replication starts. The initial seeding phase is the longest and most expensive part of the operation. Once initial seeding completes, data is synchronized, and only subsequent data changes are replicated. The time it takes for the initial seeding to complete depends on the size of data, number of replicated databases, workload intensity on the primary databases, and the speed of the link between the virtual networks that hosts the primary and secondary instance - which mostly depends on the way connectivity is established. Under normal circumstances, and when connectivity is established using recommended global virtual network peering, seeding speed is up to 360 GB an hour for SQL Managed Instance. Seeding is performed for a batch of user databases in parallel - not necessarily for all databases at the same time. Multiple batches might be needed if there are many databases hosted on the instance.
 
 If the speed of the link between the two instances is slower than what is necessary, the time to seed is likely to be noticeably affected. You can use the stated seeding speed, number of databases, total size of data, and the link speed to estimate how long the initial seeding phase will take before data replication starts. For example, for a single 100-GB database, the initial seed phase would take about 1.2 hours if the link is capable of pushing 84 GB per hour, and if there are no other databases being seeded. If the link can only transfer 10 GB per hour, then seeding a 100-GB database can take about 10 hours. If there are multiple databases to replicate, seeding will be executed in parallel, and, when combined with a slow link speed, the initial seeding phase might take considerably longer, especially if the parallel seeding of data from all databases exceeds the available link bandwidth.
 
 > [!IMPORTANT]  
-> In case of an extremely low-speed or busy link causing the initial seeding phase to take days the creation of a failover group can time out. The creation process will be automatically canceled after 6 days.
+> The initial seeding phase can take days with extremely low-speed or busy links. In this case, creating the failover group can time out. Creating the failover group is automatically canceled after 6 days. 
+
 
 ## Manage geo-failover to a geo-secondary instance
 

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

@@ -154,7 +154,6 @@ After you configure a link with Azure SQL Managed Instance, databases on the man
 
 You can reduce your on-premises management and operation costs while enjoying the reliability of Azure backups for your replicated databases. You can then perform a [point-in-time restore](point-in-time-restore.md) of your replicated database to any SQL Managed Instance deployment in the same region, as with any other [automated backup](automated-backups-overview.md). 
 
-
 ## License-free passive DR replica
 
 You can save on vCore licensing costs if you activate the [hybrid failover benefit](business-continuity-high-availability-disaster-recover-hadr-overview.md#license-free-dr-replicas) for secondary passive disaster recovery only SQL managed instances that don't have any workloads. 
@@ -198,7 +197,7 @@ Configuration limitations include:
 
   - If there are multiple SQL Server instances on a server, it's possible to configure a link with each instance, but each instance must be configured 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. 
   - Only one database can be placed into a single availability group for one Managed Instance link. However, it's possible to replicate multiple databases in a single SQL Server instance by establishing multiple links. 
-  - A single managed instance supports up to 100 links from multiple SQL Server instances. 
+  - 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.
   - Managed Instance link authentication between SQL Server and SQL Managed Instance is certificate-based and available only through an exchange of certificates. Using Windows authentication to establish the link between the SQL Server instance and the managed instance isn't supported.
   - Only [VNet-local endpoint](connectivity-architecture-overview.md#vnet-local-endpoint) is supported to establish a link with SQL Managed Instance. 
@@ -210,7 +209,9 @@ Feature limitations include:
 
 - [Failover groups](failover-group-sql-mi.md) aren't supported with instances that use the link feature. You can't establish a link on a managed instance that's part of a failover group, and conversely, you can't configure a failover group on an instance that has a link established.
 - If you're using Change Data Capture (CDC), log shipping, or a service broker with databases that are replicated on the SQL Server instance, when the database is migrated to a SQL Managed Instance deployment, during a failover to Azure, clients need to connect by using the instance name of the current global primary replica. These settings should be manually reconfigured. 
-- If you're using transactional replication with a database on a SQL Server instance in a migration scenario, during failover to Azure, transactional replication on the SQL Managed Instance deployment will fail and should be manually reconfigured. 
+- If you're using [transactional replication](/sql/relational-databases/replication/transactional/transactional-replication) on a database with an established link, consider the following: 
+   - The linked database on the secondary replica can't be a Publisher in a transactional replication topology.
+   - If you're migrating a database that is configured as a Publisher in a transactional replication topology by using the link, you must reconfigure the database as a Publisher on the target instance after the migration is complete.
 - If you're using distributed transactions with a database that's replicated from the SQL Server instance and, in a migration scenario, on the cutover to the cloud, Distributed Transaction Coordinator capabilities won't be transferred. It's not possible for the migrated database to get involved in distributed transactions with the SQL Server instance, because the SQL Managed Instance deployment doesn't support distributed transactions with SQL Server at this time. For reference, SQL Managed Instance today supports distributed transactions only between other managed instances. For more information, see [Distributed transactions across cloud databases](../database/elastic-transactions-overview.md#transactions-for-sql-managed-instance).
 - If you're using Transparent Data Encryption (TDE) to encrypt SQL Server databases, the database encryption key from SQL Server needs to be exported and uploaded to Azure Key Vault, and you need to also configure the BYOK TDE option on SQL Managed Instance before creating the link.
 - SQL Managed Instance databases that are encrypted with service-managed TDE keys can't be linked to SQL Server. You can link an encrypted database to SQL Server only if it was encrypted with a customer-managed key and the destination server has access to the same key that's used to encrypt the database. For more information, see [Set up SQL Server TDE with Azure Key Vault](/sql/relational-databases/security/encryption/setup-steps-for-extensible-key-management-using-the-azure-key-vault). 
@@ -220,7 +221,7 @@ Feature limitations include:
 
 Trying to add an unsupported functionality to a replicated database in: 
    - SQL Server 2017, 2019 and 2022 fails with an error. 
-   - SQL Server 2016 results in breaking the link, which will then need to be deleted and recreated. 
+   - SQL Server 2016 results in breaking the link, which you then need to delete and recreate.
 
 For the full list of differences between SQL Server and SQL Managed Instance, see [T-SQL differences between SQL Server and Azure SQL Managed Instance](./transact-sql-tsql-differences-sql-server.md).