Merge pull request #191416 from sasapopo/main

Addressing Acrolinx suggestions in SQL MI link articles.

Author: PRMerger17

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

@@ -33,13 +33,13 @@ To use the link feature, you'll need:
 
 The underlying technology of near real-time data replication between SQL Server and SQL Managed Instance is based on distributed availability groups, part of the well-known and proven Always On availability group technology stack. Extend your SQL Server on-premises availability group to SQL Managed Instance in Azure in a safe and secure manner. 
 
-There's no need to have an existing availability group or multiple nodes. The link supports single node SQL Server instances without existing availability groups, and also multiple-node SQL Server instances with existing availability groups. Through the link, you can leverage the modern benefits of Azure without migrating your entire SQL Server data estate to the cloud.
+There's no need to have an existing availability group or multiple nodes. The link supports single node SQL Server instances without existing availability groups, and also multiple-node SQL Server instances with existing availability groups. Through the link, you can use the modern benefits of Azure without migrating your entire SQL Server data estate to the cloud.
 
 You can keep running the link for as long as you need it, for months and even years at a time. And for your modernization journey, if or when you're ready to migrate to Azure, the link enables a considerably-improved migration experience with the minimum possible downtime compared to all other options available today, providing a true online migration to SQL Managed Instance.
 
 ## Supported scenarios
 
-Data replicated through the link feature from SQL Server to Azure SQL Managed Instance can be used with a number of scenarios, such as: 
+Data replicated through the link feature from SQL Server to Azure SQL Managed Instance can be used with several scenarios, such as: 
 
 - **Use Azure services without migrating to the cloud** 
 - **Offload read-only workloads to Azure** 
@@ -54,7 +54,7 @@ Use the link feature to leverage Azure services using SQL Server data without mi
 
 ### Offload workloads to Azure 
 
-You can also use the link feature to offload workloads to Azure. For example, an application could use SQL Server for read / write workloads, while offloading read-only workloads to SQL Managed Instance in any of Azure's 60+ regions worldwide. Once the link is established, the primary database on SQL Server is read/write accessible, while replicated data to SQL Managed Instance in Azure is read-only accessible. This allows for various scenarios where replicated databases on SQL Managed Instance can be used for read scale-out and offloading read-only workloads to Azure. SQL Managed Instance, in parallel, can also host independent read/write databases. This allows for copying the replicated database to another read/write database on the same managed instance for further data processing.
+You can also use the link feature to offload workloads to Azure. For example, an application could use SQL Server for read-write workloads, while offloading read-only workloads to SQL Managed Instance in any of Azure's 60+ regions worldwide. Once the link is established, the primary database on SQL Server is read/write accessible, while replicated data to SQL Managed Instance in Azure is read-only accessible. This allows for various scenarios where replicated databases on SQL Managed Instance can be used for read scale-out and offloading read-only workloads to Azure. SQL Managed Instance, in parallel, can also host independent read/write databases. This allows for copying the replicated database to another read/write database on the same managed instance for further data processing.
 
 The link is database scoped (one link per one database), allowing for consolidation and deconsolidation of workloads in Azure. For example, you can replicate databases from multiple SQL Servers to a single SQL Managed Instance in Azure (consolidation), or replicate databases from a single SQL Server to multiple managed instances via a 1 to 1 relationship between a database and a managed instance -  to any of Azure's regions worldwide (deconsolidation). The latter provides you with an efficient way to quickly bring your workloads closer to your customers in any region worldwide, which you can use as read-only replicas.
 
@@ -93,8 +93,8 @@ Managed Instance link has a set of general limitations, and those are listed in
   - Replicating Databases using Hekaton (In-Memory OLTP) isn't supported on Managed Instance General Purpose service tier. Hekaton is only supported on Managed Instance Business Critical service tier.
   - For the full list of differences between SQL Server and Managed Instance, see [this article](./transact-sql-tsql-differences-sql-server.md).
 - In case Change data capture (CDC), log shipping, or service broker are used with database replicated on the SQL Server, and in case of database migration to Managed Instance, on the failover to the Azure, clients will need to connect using instance name of the current global primary replica. you'll need to manually re-configure these settings.
-- In case Transactional Replication is used with database replicated on the SQL Server, and in case of migration scenario, on failover to Azure, transactional replication on Azure SQL Managed instance will not continue. you'll need to manually re-configure Transactional Replication.
-- In case distributed transactions are used with database replicated from the SQL Server, and in case of migration scenario, on the cutover to the cloud, the DTC capabilities will not be transferred. There will be no possibility for migrated database to get involved in distributed transactions with SQL Server, as Managed Instance doesn't support distributed transactions with SQL Server at this time. For reference, Managed Instance today supports distributed transactions only between other Managed Instances, see [this article](../database/elastic-transactions-overview.md#transactions-for-sql-managed-instance).
+- In case Transactional Replication is used with database replicated on the SQL Server, and in case of migration scenario, on failover to Azure, transactional replication on Azure SQL Managed instance won't continue. you'll need to manually re-configure Transactional Replication.
+- In case distributed transactions are used with database replicated from the SQL Server, and in case of migration scenario, on the cutover to the cloud, the DTC capabilities won't be transferred. There will be no possibility for migrated database to get involved in distributed transactions with SQL Server, as Managed Instance doesn't support distributed transactions with SQL Server at this time. For reference, Managed Instance today supports distributed transactions only between other Managed Instances, see [this article](../database/elastic-transactions-overview.md#transactions-for-sql-managed-instance).
 - Managed Instance link can replicate database of any size if it fits into chosen storage size of target Managed Instance.
 
 ### Additional limitations
@@ -105,11 +105,11 @@ Some Managed Instance link features and capabilities are limited **at this time*
 - Managed Instance Link authentication between SQL Server instance and Managed Instance is certificate-based, available only through exchange of certificates. Windows authentication between instances isn't supported.
 - Replication of user databases from SQL Server to Managed Instance is one-way. User databases from Managed Instance can't be replicated back to SQL Server.
 - Auto failover groups replication to secondary Managed Instance can't be used in parallel while operating the Managed Instance Link with SQL Server.
-- Replicated databases are not part of auto-backup process on SQL Managed Instance.
+- Replicated databases aren't part of auto-backup process on SQL Managed Instance.
 
 ## Next steps
 
-If you are interested in using Link feature for Azure SQL Managed Instance with versions and editions that are currently not supported, sign-up [here](https://aka.ms/mi-link-signup).
+If you're interested in using Link feature for Azure SQL Managed Instance with versions and editions that are currently not supported, sign-up [here](https://aka.ms/mi-link-signup).
 
 For more information on the link feature, see the following:
 

articles/azure-sql/managed-instance/managed-instance-link-preparation.md

@@ -17,7 +17,7 @@ ms.date: 03/07/2022
 # Prepare environment for link feature - Azure SQL Managed Instance
 [!INCLUDE[appliesto-sqlmi](../includes/appliesto-sqlmi.md)]
 
-This article teaches you to prepare your environment for the [Managed Instance link feature](link-feature.md) so that you can replicate your databases from your instance of SQL Server to your instance of Azure SQL Managed Instance. 
+This article teaches you to prepare your environment for the [Managed Instance link feature](link-feature.md) so that you can replicate databases from SQL Server instance to Azure SQL Managed Instance.
 
 > [!NOTE]
 > The link feature for Azure SQL Managed Instance is currently in preview. 
@@ -34,7 +34,13 @@ To use the Managed Instance link feature, you need the following prerequisites:
 
 ## Prepare your SQL Server instance
 
-To prepare your SQL Server instance, you need to validate you're on the minimum supported version, you've enabled the availability group feature, and you've added the proper trace flags at startup. You will need to restart SQL Server for these changes to take effect. 
+To prepare your SQL Server instance, you need to validate:
+- you're on the minimum supported version;
+- you've enabled the availability group feature;
+- you've added the proper trace flags at startup;
+- your databases are in full recovery mode and backed up.
+
+You'll need to restart SQL Server for these changes to take effect.
 
 ### Install CU15 (or higher)
 
@@ -47,7 +53,7 @@ To check your SQL Server version, run the following Transact-SQL (T-SQL) script:
 SELECT @@VERSION
 ```
 
-If your SQL Server version is lower than CU15 (15.0.4198.2), either install the minimally supported [CU15](https://support.microsoft.com/topic/kb5008996-cumulative-update-15-for-sql-server-2019-4b6a8ee9-1c61-482d-914f-36e429901fb6), or the current latest cumulative update. Your SQL Server instance will be restarted during the update. 
+If your SQL Server version is lower than CU15 (15.0.4198.2), either install the [CU15](https://support.microsoft.com/topic/kb5008996-cumulative-update-15-for-sql-server-2019-4b6a8ee9-1c61-482d-914f-36e429901fb6), or the current latest cumulative update. Your SQL Server instance will be restarted during the update. 
 
 ### Create database master key in the master database
 
@@ -59,15 +65,15 @@ USE MASTER
 CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<strong_password>'
 ```
 
-To check if you have database master key, use follwing T-SQL script.
+To check if you have database master key, use the following T-SQL script.
 
 ```sql
 SELECT * FROM sys.symmetric_keys WHERE name LIKE '%DatabaseMasterKey%'
 ```
 
 ### Enable availability groups feature
 
-The link feature for SQL Managed Instance relies on the Always On availability groups feature, which is not enabled by default. To learn more, review [enabling the Always On availability groups feature](/sql/database-engine/availability-groups/windows/enable-and-disable-always-on-availability-groups-sql-server). 
+The link feature for SQL Managed Instance relies on the Always On availability groups feature, which isn't enabled by default. To learn more, review [enabling the Always On availability groups feature](/sql/database-engine/availability-groups/windows/enable-and-disable-always-on-availability-groups-sql-server). 
 
 To confirm the Always On availability groups feature is enabled, run the following Transact-SQL (T-SQL) script: 
 
@@ -83,7 +89,7 @@ select
     end as 'HadrStatus'
 ```
 
-If the availability groups feature is not enabled, follow these steps to enable it: 
+If the availability groups feature isn't enabled, follow these steps to enable it: 
 
 1. Open the **SQL Server Configuration Manager**. 
 1. Choose the SQL Server service from the navigation pane. 
@@ -102,8 +108,8 @@ If the availability groups feature is not enabled, follow these steps to enable
 
 To optimize Managed Instance link performance, enabling trace flags `-T1800` and `-T9567` at startup is highly recommended: 
 
-- **-T1800**: This trace flag optimizes SQL Server performance when the disks hosting the log files for the primary and secondary replica in an availability group have different sector sizes, such as 512 bytes and 4k. If both primary and secondary replicas have a disk sector size of 4k, this trace flag isn't required. To learn more, review [KB3009974](https://support.microsoft.com/topic/kb3009974-fix-slow-synchronization-when-disks-have-different-sector-sizes-for-primary-and-secondary-replica-log-files-in-sql-server-ag-and-logshipping-environments-ed181bf3-ce80-b6d0-f268-34135711043c). 
-- **-T9567**: This trace flag enables compression of the data stream for availability groups during automatic seeding, which increases the load on the processor but can significantly reduce transfer time during seeding. 
+- **-T1800**: This trace flag optimizes performance when the log files for the primary and secondary replica in an availability group are hosted on disks with different sector sizes, such as 512 bytes and 4k. If both primary and secondary replicas have a disk sector size of 4k, this trace flag isn't required. To learn more, review [KB3009974](https://support.microsoft.com/topic/kb3009974-fix-slow-synchronization-when-disks-have-different-sector-sizes-for-primary-and-secondary-replica-log-files-in-sql-server-ag-and-logshipping-environments-ed181bf3-ce80-b6d0-f268-34135711043c).
+- **-T9567**: This trace flag enables compression of the data stream for availability groups during automatic seeding. The compression increases the load on the processor but can significantly reduce transfer time during seeding.
 
 To enable these trace flags at startup, follow these steps: 
 
@@ -122,10 +128,8 @@ To enable these trace flags at startup, follow these steps:
 
 To learn more, review [enabling trace flags](/sql/t-sql/database-console-commands/dbcc-traceon-transact-sql). 
 
-
 ### Restart SQL Server and validate configuration
 
-
 After you've validated you're on a supported version of SQL Server, enabled the Always On availability groups feature, and added your startup trace flags, restart your SQL Server instance to apply all of these changes. 
 
 To restart your SQL Server instance, follow these steps:
@@ -136,7 +140,7 @@ To restart your SQL Server instance, follow these steps:
 
     :::image type="content" source="./media/managed-instance-link-preparation/sql-server-configuration-manager-sql-server-restart.png" alt-text="Screenshot showing S Q L Server restart command call.":::
 
-After the restart, use Transact-SQL to validate the configuration of your SQL Server. Your SQL Server version should be 15.0.4198.2 or greater, the Always On availability groups feature should be enabled, and you should have the Trace flags -T1800 and -T9567 enabled. 
+After the restart, use Transact-SQL to validate the configuration of your SQL Server. Your SQL Server version should be 15.0.4198.2 or greater, the Always On availability groups feature should be enabled, and you should have the Trace flags -T1800 and -T9567 enabled.
 
 To validate your configuration, run the following Transact-SQL (T-SQL) script: 
 
@@ -196,7 +200,7 @@ If your SQL Server is hosted outside of Azure, establish a VPN connection betwee
 
 ### Open network ports between the environments
 
-Port 5022 needs to allow inbound and outbound traffic between SQL Server and SQL Managed Instance. Port 5022 is the standard port used for availability groups, and cannot be changed or customized. 
+Port 5022 needs to allow inbound and outbound traffic between SQL Server and SQL Managed Instance. Port 5022 is the standard port used for availability groups, and can't be changed or customized. 
 
 The following table describes port actions for each environment: 
 
@@ -221,7 +225,7 @@ Bidirectional network connectivity between SQL Server and SQL Managed Instance i
 
 ### Test connection from SQL Server to SQL Managed Instance 
 
-To check if SQL Server can reach your SQL Managed Instance use the `tnc` command in PowerShell from the SQL Server host machine. Replace `<ManagedInstanceFQDN>` with the fully qualified domain name of the Azure SQL Managed Instance.
+To check if SQL Server can reach your SQL Managed Instance, use the `tnc` command in PowerShell from the SQL Server host machine. Replace `<ManagedInstanceFQDN>` with the fully qualified domain name of the Azure SQL Managed Instance.
 
 ```powershell
 tnc <ManagedInstanceFQDN> -port 5022
@@ -232,9 +236,9 @@ A successful test shows `TcpTestSucceeded : True`:
 
 :::image type="content" source="./media/managed-instance-link-preparation/powershell-output-tnc-command.png" alt-text="Screenshot showing output of T N C command in PowerShell.":::
 
-If the response is unsuccessful, verify the following:
+If the response is unsuccessful, verify the following network settings:
 - There are rules in both the network firewall *and* the windows firewall that allow traffic to the *subnet* of the SQL Managed Instance. 
-- There is an NSG rule allowing communication on port 5022 for the virtual network hosting the SQL Managed Instance. 
+- There's an NSG rule allowing communication on port 5022 for the virtual network hosting the SQL Managed Instance. 
 
 
 #### Test connection from SQL Managed Instance to SQL Server
@@ -331,10 +335,10 @@ DROP CERTIFICATE TEST_CERT
 GO
 ```
 
-If the connection is unsuccessful, verify the following: 
+If the connection is unsuccessful, verify the following items: 
 - The firewall on the host SQL Server allows inbound and outbound communication on port 5022. 
-- There is an NSG rule for the virtual network hosting the SQL Managed instance that allows communication on port 5022. 
-- If your SQL Server is on an Azure VM, there is an NSG rule allowing communication on port 5022 on the virtual network hosting the VM.
+- There's an NSG rule for the virtual network hosting the SQL Managed instance that allows communication on port 5022. 
+- If your SQL Server is on an Azure VM, there's an NSG rule allowing communication on port 5022 on the virtual network hosting the VM.
 - SQL Server is running. 
 
 > [!CAUTION]

articles/azure-sql/managed-instance/managed-instance-link-use-ssms-to-replicate-database.md

@@ -42,7 +42,7 @@ Use the **New Managed Instance link** wizard in SQL Server Management Studio (SS
 To set up the Managed Instance link, follow these steps: 
 
 1. Open SQL Server Management Studio (SSMS) and connect to your instance of SQL Server. 
-1. In **Object Explorer**, right-click your database, hover over **Azure SQL Managed Instance link** and select **Replicate database** to open the **New Managed Instance link** wizard. In case you are using a version of SQL Server that is not supported, this option will not be available in the context menu.
+1. In **Object Explorer**, right-click your database, hover over **Azure SQL Managed Instance link** and select **Replicate database** to open the **New Managed Instance link** wizard. If SQL Server version isn't supported, this option won't be available in the context menu.
 
     :::image type="content" source="./media/managed-instance-link-use-ssms-to-replicate-database/link-replicate-ssms-database-context-replicate-database.png" alt-text="Screenshot showing database's context menu option to replicate database after hovering over Azure SQL Managed Instance link.":::