Addressing PR comments.

Author: sasapopo

articles/azure-sql/managed-instance/managed-instance-link-use-scripts-to-failover-database.md

@@ -1,7 +1,7 @@
 ---
-title: Failover database with link feature with T-SQL and PowerShell scripts
+title: Fail over database with link feature with T-SQL and PowerShell scripts
 titleSuffix: Azure SQL Managed Instance
-description: This guide teaches you how to use the SQL Managed Instance link with scripts to failover database from SQL Server to Azure SQL Managed Instance.
+description: This guide teaches you how to use the SQL Managed Instance link with scripts to fail over database from SQL Server to Azure SQL Managed Instance.
 services: sql-database
 ms.service: sql-managed-instance
 ms.subservice: data-movement
@@ -18,7 +18,7 @@ ms.date: 03/15/2022
 
 [!INCLUDE[appliesto-sqlmi](../includes/appliesto-sqlmi.md)]
 
-This article teaches you to use scripts, T-SQL and PowerShell, to use [Managed Instance link feature](link-feature.md), more specifically to failover (migrate) your database from SQL Server to Azure SQL Managed Instance.
+This article teaches you to use T-SQL and PowerShell scripts for [Managed Instance link feature](link-feature.md) to fail over (migrate) your database from SQL Server to Azure SQL Managed Instance.
 
 > [!NOTE]
 > The link feature for Azure SQL Managed Instance is currently in preview.
@@ -29,16 +29,16 @@ This article teaches you to use scripts, T-SQL and PowerShell, to use [Managed I
 > [!TIP]
 > SQL Managed Instance link database failover can be set up with [SSMS wizard](managed-instance-link-use-ssms-to-failover-database.md).
 
-Failing over your database from your SQL Server instance to your SQL Managed Instance breaks the link between the two databases, stopping replication, and leaving both databases in an independent state, ready for individual read-write workloads.
+Database failover from SQL Server instance to SQL Managed Instance breaks the link between the two databases. Failover stops replication and leaves both databases in an independent state, ready for individual read-write workloads.
 
 To start migrating database to the SQL Managed Instance, first stop the application workload to the SQL Server during your maintenance hours. This is required to enable SQL Managed Instance to catchup with the database replication and make migration to Azure without any data loss.
 
-Note that while database is a part of Always On Availability Group, it is not possible to set it to read-only mode. You will need to ensure that your applications(s) are not committing transactions to SQL Server.
+While database is a part of Always On Availability Group, it isn't possible to set it to read-only mode. You'll need to ensure that your application(s) aren't committing transactions to SQL Server.
 
 ## Switch the replication mode from asynchronous to synchronous
 
-The replication between SQL Server and SQL Managed Instance is asynchronous by default. Before migrating databse to Azure, link needs to be switched to synchronous mode. Synchronous replication across distances might slow down transactions on the primary SQL Server.
-Switching from Async to Sync mode requires replication mode change on SQL Managed Instance as well as on SQL Server.
+The replication between SQL Server and SQL Managed Instance is asynchronous by default. Before you perform database migration to Azure, the link needs to be switched to synchronous mode. Synchronous replication across distances might slow down transactions on the primary SQL Server.
+Switching from async to sync mode requires replication mode change on SQL Managed Instance and SQL Server.
 
 ## Switch replication mode on Managed Instance
 
@@ -107,7 +107,7 @@ Invoke-WebRequest -Method PATCH -Headers $headers -Uri $uriFull -ContentType "ap
 ## Switch replication mode on SQL Server
 
 Use the following T-SQL script to change the replication mode of Distributed Availability Group on SQL Server from async to sync. Replace `<DAGName>` with the name of Distributed Availability Group, and replace `<AGName>` with the name of Availability Group created on SQL Server. In addition, replace `<ManagedInstanceName>` with the name of your SQL Managed Instance.
-With this step, the migration of the database from SQL Server to SQL Managed Instance is been completed.
+With this step, the migration of the database from SQL Server to SQL Managed Instance is completed.
 
 ```sql
 -- Sets the Distributed Availability Group to synchronous commit.
@@ -123,7 +123,7 @@ AVAILABILITY GROUP ON
     (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);
 ```
 
-To validate change of the link replication, execute the following DMV, and expected results are shown below. They are indicating SYNCHRONOUS_COMIT state.
+To validate change of the link replication, execute the following DMV, and expected results are shown below. They're indicating SYNCHRONOUS_COMIT state.
 
 ```sql
 -- Verifies the state of the distributed availability group
@@ -141,11 +141,11 @@ WHERE
     ag.is_distributed=1
 ```
 
-With both SQL Managed Instance, and SQL Server being switched to Sync mode, the replication between the two entities is now synchronous. If you require to reverse this state, follow the same steps by setting async state in properties for both SQL Server and SQL Managed Instance.
+With both SQL Managed Instance, and SQL Server being switched to Sync mode, the replication between the two entities is now synchronous. If you require to reverse this state, follow the same steps and set async state for both SQL Server and SQL Managed Instance.
 
 ## Check LSN values on both SQL Server and Managed Instance
 
-To complete the migration, we need to ensure that the replication has completed. For this we need to ensure that LSNs (Log Sequence Numbers) indicating the log records written for both SQL Server and SQL Managed Instance are the same. Initially, it is expected that SQL Server LSN will be higher than LSN number on SQL Managed Instance. The difference is caused by the fact that SQL Managed Instance might be lagging somewhat behind the primary SQL Server due to network latency. After some time, LSNs on SQL Managed Instance and SQL Server should match and stop changing, as the workload on SQL Server should be stopped.
+To complete the migration, we need to ensure that the replication has completed. For this, you need to ensure that LSNs (Log Sequence Numbers) indicating the log records written for both SQL Server and SQL Managed Instance are the same. Initially, it's expected that SQL Server LSN will be higher than LSN number on SQL Managed Instance. The difference is caused by the fact that SQL Managed Instance might be lagging somewhat behind the primary SQL Server due to network latency. After some time, LSNs on SQL Managed Instance and SQL Server should match and stop changing, as the workload on SQL Server should be stopped.
 
 Use the following T-SQL query on SQL Server to read the LSN number of the last recorded transaction log. Replace `<DatabaseName>` with your database name and look for the last hardened LSN number, as shown below.
 
@@ -170,9 +170,9 @@ WHERE
 
 Use the following T-SQL query on SQL Managed Instance to read the LSN number of the last hardened LSN number for your database. Replace `<DatabaseName>` with your database name.
 
-Query shown below will work on General Purpose SQL Managed Instance. For Business Critical Managed Instance, you will need to uncomment `and drs.is_primary_replica = 1` at the end of the script. On Business Critical, this will read only primary replica details.
+Query shown below will work on General Purpose SQL Managed Instance. For Business Critical Managed Instance, you will need to uncomment `and drs.is_primary_replica = 1` at the end of the script. On Business Critical, this filter will make sure that only primary replica details are read.
 
-```
+```sql
 -- Obtain LSN for a database on SQL Managed Instance.
 SELECT
     db.name AS [Database name],
@@ -199,7 +199,7 @@ SQL Managed Instance link database failover and migration to Azure is accomplish
 
 Use the following API to initiate database failover to Azure. Replace `<YourSubscriptionID>` with your actual Azure subscription ID. Replace `<RG>` with the resource group where your SQL Managed Instance is deployed and replace `<ManagedInstanceName>` with the name of our SQL Managed Instance. In addition, replace `<DAGName>` with the name of Distributed Availability Group made on SQL Server.
 
-```
+```PowerShell
 # ====================================================================================
 # POWERSHELL SCRIPT TO FAILOVER AND MIGRATE DATABASE WITH SQL MANAGED INSTANCE LINK
 # USER CONFIGURABLE VALUES
@@ -246,7 +246,7 @@ Invoke-WebRequest -Method DELETE -Headers $headers -Uri $uriFull -ContentType "a
 
 ## Cleanup Availability Group and Distributed Availability Group on SQL Server
 
-After breaking the link and migrating database to Azure SQL Managed Instance, consider cleaning up Availability Group and Distributed Availability Group on SQL Server if they are not used otherwise.
+After breaking the link and migrating database to Azure SQL Managed Instance, consider cleaning up Availability Group and Distributed Availability Group on SQL Server if they aren't used otherwise.
 Replace `<DAGName>` with the name of the Distributed Availability Group on SQL Server and replace `<AGName>` with Availability Group name on the SQL Server.
 
 ``` sql
@@ -260,7 +260,7 @@ With this step, the migration of the database from SQL Server to Managed Instanc
 
 ## Next steps
 
-For more information on the link feature, see the following:
+For more information on the link feature, see the following resources:
 
 - [Managed Instance link – connecting SQL Server to Azure reimagined](https://aka.ms/mi-link-techblog).
 - [Prepare for SQL Managed Instance link](./managed-instance-link-preparation.md).

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

@@ -60,7 +60,7 @@ This first step in creating SQL Managed Instance link is establishing the trust
 
 Certificates-based trust is the only supported way to secure database mirroring endpoints on SQL Server and SQL Managed Instance. In case you've existing Availability Groups that are using Windows Authentication, certificate based trust needs to be added to the existing mirroring endpoint as a secondary authentication option. This can be done by using ALTER ENDPOINT statement.
 
-> [IMPORTANT]
+> [!IMPORTANT]
 > Certificates are generated with an expiry date and time, and they need to be rotated before they expire.
 
 Here's the overview of the process to secure database mirroring endpoints for both SQL Server and SQL Managed Instance:
@@ -100,7 +100,7 @@ GO
 SELECT * FROM sys.certificates
 ```
 
-In the query results you'll find the certificate and will see that is has been encrypted with the master key.
+In the query results you'll find the certificate and will see that it has been encrypted with the master key.
 
 Now you can get the public key of the generated certificate.
 
@@ -115,7 +115,7 @@ SELECT @PUBLICKEYENC AS PublicKeyEncoded;
 
 Save the value of PublicKeyEncoded from the output, as it will be needed for the next step.
 
-Next step should be executed in PowerShell, with installed Az.Sql module, version 3.5.1 or higher, or use Azure Cloud shell online to run the commands as it's always updated wit the latest module versions.
+Next step should be executed in PowerShell, with installed Az.Sql module, version 3.5.1 or higher, or use Azure Cloud Shell online to run the commands as it's always updated wit the latest module versions.
 
 Execute the following PowerShell script in Azure Cloud Shell (fill out necessary user information, copy, paste into Azure Cloud Shell and execute).
 Replace `<SubscriptionID>` with your Azure Subscription ID. Replace `<ManagedInstanceName>` with the short name  of your managed instance. Replace `<PublicKeyEncoded>` below with the public portion of the SQL Server certificate in binary format generated in the previous step. That will be a long string value starting with 0x, that you've obtained from SQL Server.
@@ -197,7 +197,7 @@ EXEC sp_get_endpoint_certificate @endpoint_type = 4
 
 Copy the entire public key from Managed Instance starting with “0x” shown in the previous step and use it in the below query by replacing `<InstanceCertificate>` with the key value. No quotations need to be used.
 
-> [IMPORTANT]
+> [!IMPORTANT]
 > Name of the certificate must be SQL Managed Instance FQDN.
 
 ```sql
@@ -254,7 +254,7 @@ New mirroring endpoint was created with CERTIFICATE authentication, and AES encr
 
 ### Altering existing database mirroring endpoint
 
-> [NOTE] SKIP this step if you've just created a new mirroring endpoint.
+> [!NOTE] SKIP this step if you've just created a new mirroring endpoint.
 > Use this step only if using existing Availability Groups with existing database mirroring endpoint. 
 > 
 
@@ -343,14 +343,14 @@ WITH (CLUSTER_TYPE = NONE)
 GO
 ```
 
->[NOTE]
+> [!NOTE]
 > One database per single Availability Group is the current product limitation for replication to SQL Managed Instance using the link feature.
 > If you get the Error 1475 you'll have to create a full backup without COPY ONLY option, that will start new backup chain.
 > As the best practice it's highly recommended that collation on SQL Server and SQL Managed Instance is the same. This is because depending on collation settings, AG and DAG names could, or could not be case sensitive. If there's a mismatch with this, there could be issues in ability to successfully connect SQL Server to Managed Instance.
 
 ### Verify AG and distributed AG
 
-Use the following script to list all available Availability Groups and Distributed Availability Groups on the SQL Server. Availability Group state needs to be connected, and Distributed Availability Group state disconnected at this point. Distributed Availability Group state will move to connected only when it has been joined with SQL Managed Instance. This will be explained in one of the next steps.
+Use the following script to list all available Availability Groups and Distributed Availability Groups on the SQL Server. Availability Group state needs to be connected, and Distributed Availability Group state disconnected at this point. Distributed Availability Group state will move to `connected` only when it has been joined with SQL Managed Instance. This will be explained in one of the next steps.
 
 ```sql
 -- This will show that Availability Group and Distributed Availability Group have been created on SQL Server.
@@ -365,7 +365,7 @@ Alternatively, in SSMS object explorer, expand the “Always On High Availabilit
 
 ## Creating SQL Managed Instance link
 
-The final step of the set up is to create the SQL Managed Instance link. To accomplish this, a REST API call will be made. Invoking direct API calls will be replaced with PowerShell and CLI clients, which will be delivered in one of our next releases.
+The final step of the setup process is to create the SQL Managed Instance link. To accomplish this, a REST API call will be made. Invoking direct API calls will be replaced with PowerShell and CLI clients, which will be delivered in one of our next releases.
 
 Invoking direct API call to Azure can be accomplished with various API clients. However, for simplicity of the process, execute the below PowerShell script from Azure Cloud Shell.
 
@@ -462,10 +462,10 @@ FROM
 
 In addition, once the connection is established, Managed Instance Databases view in SSMS will initially show replicated database as “Restoring…”. This is because the initial seeding is in progress moving the full backup of the database, which is followed by the catchup replication. Once the seeding process is done, the database will no longer be in “Restoring…” state. For small databases, seeding might finish quickly so you might not see the initial “Restoring…” state in SSMS.
 
->[IMPORTANT]
+> [!IMPORTANT]
 > The link will not work unless network connectivity exists between SQL Server and Managed Instance. To troubleshoot the network connectivity following steps described in [test bidirectional network connectivity](managed-instance-link-preparation.md#test-bidirectional-network-connectivity).
 
->[IMPORTANT]
+> [!IMPORTANT]
 > Make regular backups of the log file on SQL Server. If the log space used reaches 100%, the replication to SQL Managed Instance will stop until this space use is reduced. It is highly recommended that you automate log backups through setting up a daily job. For more details on how to do this see [Backup log files on SQL Server](link-feature-best-practices.md#take-log-backups-regularly).
 
 ## Next steps
@@ -474,6 +474,6 @@ For more information on the link feature, see the following:
 
 - [Managed Instance link – connecting SQL Server to Azure reimagined](https://aka.ms/mi-link-techblog).
 - [Prepare for SQL Managed Instance link](./managed-instance-link-preparation.md).
-- [Use SQL Managed Instance link via SSMS to migrate database](./managed-instance-link-use-scripts-to-failover-database.md).
+- [Use SQL Managed Instance link wity scripts to migrate database](./managed-instance-link-use-scripts-to-failover-database.md).
 - [Use SQL Managed Instance link via SSMS to replicate database](./managed-instance-link-use-ssms-to-replicate-database.md).
 - [Use SQL Managed Instance link via SSMS to migrate database](./managed-instance-link-use-ssms-to-failover-database.md).

articles/azure-sql/toc.yml

@@ -1243,7 +1243,7 @@
         href: managed-instance/link-feature-best-practices.md
       - name: Replicate databases with scripts
         href: managed-instance/managed-instance-link-use-scripts-to-replicate-database.md
-      - name: Failover databases with scripts
+      - name: Fail over databases with scripts
         href: managed-instance/managed-instance-link-use-scripts-to-failover-database.md
 
     - name: Configure business continuity