Merge pull request #24453 from MicrosoftDocs/main

10/04 PM Publish

Author: huypub

azure-sql/database/active-geo-replication-overview.md

@@ -4,7 +4,7 @@ description: Use active geo-replication to create readable secondary databases o
 author: rajeshsetlem
 ms.author: rsetlem
 ms.reviewer: wiassaf, mathoma
-ms.date: 4/14/2022
+ms.date: 10/04/2022
 ms.service: sql-database
 ms.subservice: high-availability
 ms.topic: conceptual
@@ -14,13 +14,12 @@ ms.custom: sqldbrb=1
 # Active geo-replication
 [!INCLUDE[appliesto-sqldb](../includes/appliesto-sqldb.md)]
 
-Active geo-replication is a feature that lets you to create a continuously synchronized readable secondary database for a primary database. The readable secondary database may be in the same Azure region as the primary, or, more commonly, in a different region. This kind of readable secondary databases are also known as geo-secondaries, or geo-replicas.
+Active geo-replication is a feature that lets you create a continuously synchronized readable secondary database for a primary database. The readable secondary database may be in the same Azure region as the primary, or, more commonly, in a different region. This kind of readable secondary database is also known as a geo-secondary or geo-replica.
 
 Active geo-replication is designed as a business continuity solution that lets you perform quick disaster recovery of individual databases in case of a regional disaster or a large scale outage. Once geo-replication is set up, you can initiate a geo-failover to a geo-secondary in a different Azure region. The geo-failover is initiated programmatically by the application or manually by the user.
 
-
 > [!NOTE]
-> Active geo-replication is not supported by Azure SQL Managed Instance. For geographic failover of instances of SQL Managed Instance, use [Auto-failover groups](auto-failover-group-sql-db.md).
+> For geographic failover of instances of SQL Managed Instance, use [Auto-failover groups](../managed-instance/auto-failover-group-sql-mi.md). For more information, [Compare geo-replication with failover groups](business-continuity-high-availability-disaster-recover-hadr-overview.md#compare-geo-replication-with-failover-groups). Active geo-replication is not supported by Azure SQL Managed Instance. 
 
 > [!NOTE]
 > To migrate SQL databases from Azure Germany using active geo-replication, see [Migrate SQL Database using active geo-replication](/azure/germany/germany-migration-databases#migrate-sql-database-using-active-geo-replication).
@@ -83,7 +82,7 @@ To achieve full business continuity, adding database regional redundancy is only
 
 - **Unplanned geo-failover**
 
-  Unplanned, or forced, geo-failover immediately switches the geo-secondary to the primary role without any synchronization with the primary. Any transactions committed on the primary but not yet replicated to the secondary are lost. This operation is designed as a recovery method during outages when the primary is not accessible, but database availability must be quickly restored. When the original primary is back online, it will be automatically re-connected, reseeded using the current primary data, and become a new geo-secondary.
+  Unplanned, or forced, geo-failover immediately switches the geo-secondary to the primary role without any synchronization with the primary. Any transactions committed on the primary but not yet replicated to the secondary are lost. This operation is designed as a recovery method during outages when the primary is not accessible, but database availability must be quickly restored. When the original primary is back online, it will be automatically reconnected, reseeded using the current primary data, and become a new geo-secondary.
 
   > [!IMPORTANT]
   > After either planned or unplanned geo-failover, the connection endpoint for the new primary changes because the new primary is now located on a different logical server.
@@ -135,9 +134,9 @@ To create a geo-secondary in a subscription different from the subscription of t
    select client_net_address from sys.dm_exec_connections where session_id = @@SPID;
    ``` 
 
-   For more information see, [Configure firewall](firewall-configure.md).
+   For more information, see [Configure firewall](firewall-configure.md).
 
-2. In the master database on the **primary** server, create a SQL authentication login dedicated to active geo-replication setup. Adjust login name and password as needed.
+2. In the `master` database on the **primary** server, create a SQL authentication login dedicated to active geo-replication setup. Adjust login name and password as needed.
 
    ```sql
    create login geodrsetup with password = 'ComplexPassword01';
@@ -156,7 +155,7 @@ To create a geo-secondary in a subscription different from the subscription of t
    select sid from sys.sql_logins where name = 'geodrsetup';
    ```
 
-5. Connect to the **primary** database (not the master database), and create a user for the same login.
+5. Connect to the **primary** database (not the `master` database), and create a user for the same login.
 
    ```sql
    create user geodrsetup for login geodrsetup;
@@ -192,13 +191,13 @@ To create a geo-secondary in a subscription different from the subscription of t
 > [!NOTE]
 > Cross-subscription geo-replication operations including setup and geo-failover are only supported using REST API & T-SQL commands.
 > 
-> Adding a geo-secondary using T-SQL is not supported when connecting to the primary server over a [private endpoint](private-endpoint-overview.md). If a private endpoint is configured but public network access is allowed, adding a geo-secondary is supported when connected to the primary server from a public IP address. Once a geo-secondary is added, public access can be [denied](connectivity-settings.md#deny-public-network-access).
+> Adding a geo-secondary using T-SQL is not supported when connecting to the primary server over a [private endpoint](private-endpoint-overview.md). If a private endpoint is configured but public network access is allowed, adding a geo-secondary is supported when connected to the primary server from a public IP address. Once a geo-secondary is added, [public network access can be denied](connectivity-settings.md#deny-public-network-access).
 > 
 > Creating a geo-secondary on a logical server in a different Azure tenant is not supported when [Azure Active Directory only](https://techcommunity.microsoft.com/t5/azure-sql/azure-active-directory-only-authentication-for-azure-sql/ba-p/2417673) authentication for Azure SQL is active (enabled) on either primary or secondary logical server.
 
 ## <a name="keeping-credentials-and-firewall-rules-in-sync"></a> Keep credentials and firewall rules in sync
 
-When using public network access for connecting to the database, we recommend using [database-level IP firewall rules](firewall-configure.md) for geo-replicated databases. These rules are replicated with the database, which ensures that all geo-secondaries have the same IP firewall rules as the primary. This approach eliminates the need for customers to manually configure and maintain firewall rules on servers hosting the primary and secondary databases. Similarly, using [contained database users](logins-create-manage.md) for data access ensures both primary and secondary databases always have the same authentication credentials. This way, after a geo-failover, there is no disruptions due to authentication credential mismatches. If you are using logins and users (rather than contained users), you must take extra steps to ensure that the same logins exist for your secondary database. For configuration details see [How to configure logins and users](active-geo-replication-security-configure.md).
+When using public network access for connecting to the database, we recommend using [database-level IP firewall rules](firewall-configure.md) for geo-replicated databases. These rules are replicated with the database, which ensures that all geo-secondaries have the same IP firewall rules as the primary. This approach eliminates the need for customers to manually configure and maintain firewall rules on servers hosting the primary and secondary databases. Similarly, using [contained database users](logins-create-manage.md) for data access ensures both primary and secondary databases always have the same authentication credentials. This way, after a geo-failover, there are no disruptions due to authentication credential mismatches. If you are using logins and users (rather than contained users), you must take extra steps to ensure that the same logins exist for your secondary database. For configuration details, see [How to configure logins and users](active-geo-replication-security-configure.md).
 
 ## <a name="upgrading-or-downgrading-primary-database"></a> Scale primary database
 
@@ -280,7 +279,6 @@ As discussed previously, active geo-replication can also be managed programmatic
 | [Replication Links - List By Database](/rest/api/sql/replicationlinks/listbydatabase) | Gets all replication links for a given database in a geo-replication partnership. It retrieves the information visible in the sys.geo_replication_links catalog view. |
 | [Delete Replication Link](/rest/api/sql/replicationlinks/delete) | Deletes a database replication link. Cannot be done during failover. |
 
-
 ## Next steps
 
 - For sample scripts, see:
@@ -290,4 +288,4 @@ As discussed previously, active geo-replication can also be managed programmatic
 - For a business continuity overview and scenarios, see [Business continuity overview](business-continuity-high-availability-disaster-recover-hadr-overview.md).
 - To learn about Azure SQL Database automated backups, see [SQL Database automated backups](automated-backups-overview.md).
 - To learn about using automated backups for recovery, see [Restore a database from the service-initiated backups](recovery-using-backups.md).
-- To learn about authentication requirements for a new primary server and database, see [SQL Database security after disaster recovery](active-geo-replication-security-configure.md).
+- To learn about authentication requirements for a new primary server and database, see [SQL Database security after disaster recovery](active-geo-replication-security-configure.md).

azure-sql/database/long-term-backup-retention-configure.md

@@ -4,7 +4,7 @@ description: Learn how to store and restore automated backups for Azure SQL Data
 author: SudhirRaparla
 ms.author: nvraparl
 ms.reviewer: wiassaf, mathoma
-ms.date: 07/20/2022
+ms.date: 10/4/2022
 ms.service: sql-database
 ms.subservice: backup-restore
 ms.topic: how-to
@@ -323,6 +323,11 @@ Restore-AzSqlDatabase -FromLongTermRetentionBackup -ResourceId $ltrBackup.Resour
 ## Limitations
 - When restoring from an LTR backup, the read scale property is disabled. To enable, read scale on the restored database, update the database after it has been created.
 - You need to specify the target service level objective, when restoring from an LTR backup, which was created when the database was in an elastic pool. 
+- LTR in the Hyperscale service tier is in limited public preview
+
+> [!NOTE]
+> LTR can be enabled for Hyperscale databases created or migrated from other service tiers after June 2022. LTR support for all other Hyperscale databases will be added over the next several weeks. If you attempt to enable LTR for a Hyperscale database where it is not yet supported, you will receive the following error: “Long Term Retention is not supported: Long-term retention on Hyperscale is currently in limited preview and cannot be enabled as yet for your database. To enable long-term retention please reach out to Microsoft support.” Please create a support ticket to resolve this, or wait until LTR support is enabled for your database.
+
 
 ## Next steps
 

azure-sql/database/service-tier-hyperscale-replicas.md

@@ -4,7 +4,7 @@ description: This article describes the different types of secondary replicas av
 author: yorek
 ms.author: damauri
 ms.reviewer: wiassaf, mathoma
-ms.date: 9/24/2021
+ms.date: 10/04/2022
 ms.service: sql-database
 ms.subservice: service-overview
 ms.topic: overview
@@ -194,7 +194,6 @@ Geo-replicas are used to maintain a transactionally consistent copy of the datab
 Geo-replication for Hyperscale database has following current limitations:
 - Only one geo-replica can be created (in the same or different region).
 - Point in time restore of the geo-replica is not supported.
-- Creating a database copy of the geo-replica is not supported. 
 - Secondary of a secondary (also known as "geo-replica chaining") is not supported. 
 
 ## Next steps

azure-sql/database/transparent-data-encryption-byok-key-rotation.md

@@ -5,7 +5,7 @@ description: Learn how to rotate the Transparent data encryption (TDE) protector
 author: rwestMSFT
 ms.author: randolphwest
 ms.reviewer: wiassaf, vanto, mathoma
-ms.date: 08/18/2022
+ms.date: 10/04/2022
 ms.service: sql-database
 ms.subservice: security
 ms.topic: how-to
@@ -16,7 +16,7 @@ ms.custom:
 ---
 # Rotate the Transparent data encryption (TDE) protector
 
-[!INCLUDE[appliesto-sqldb-asa](../includes/appliesto-sqldb-asa.md)]
+[!INCLUDE[appliesto-sqldb-sqlmi-asa](../includes/appliesto-sqldb-sqlmi-asa.md)]
 
 This article describes key rotation for a [server](logical-servers.md) using a TDE protector from Azure Key Vault. Rotating the logical TDE protector for a server means to switch to a new asymmetric key that protects the databases on the server. Key rotation is an online operation and should only take a few seconds to complete, because this only decrypts and re-encrypts the database's data encryption key, not the entire database.
 

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

@@ -3,7 +3,7 @@ title: Configure an auto-failover group
 description: Learn how to configure an auto-failover group for Azure SQL Managed Instance by using the Azure portal, and Azure PowerShell.
 author: MladjoA
 ms.author: mlandzic
-ms.reviewer: kendralittle, mathoma
+ms.reviewer: mathoma
 ms.date: 07/09/2022
 ms.service: sql-managed-instance
 ms.subservice: high-availability
@@ -240,10 +240,14 @@ The listener endpoint is in the form of `fog-name.database.windows.net`, and is
 
 ## <a name="creating-a-failover-group-between-managed-instances-in-different-subscriptions"></a> Create group between instances in different subscriptions
 
-You can create a failover group between SQL Managed Instances in two different subscriptions, as long as subscriptions are associated to the same [Azure Active Directory Tenant](/azure/active-directory/fundamentals/active-directory-whatis#terminology). When using PowerShell API, you can do it by specifying the `PartnerSubscriptionId` parameter for the secondary SQL Managed Instance. When using REST API, each instance ID included in the `properties.managedInstancePairs` parameter can have its own Subscription ID.
+You can create a failover group between SQL Managed Instances in two different subscriptions, as long as subscriptions are associated to the same [Azure Active Directory Tenant](/azure/active-directory/fundamentals/active-directory-whatis#terminology). 
+
+- When using PowerShell API, you can do it by specifying the `PartnerSubscriptionId` parameter for the secondary SQL Managed Instance. 
+- When using REST API, each instance ID included in the `properties.managedInstancePairs` parameter can have its own Subscription ID.
+- Azure portal does not support creation of failover groups across different subscriptions. 
 
 > [!IMPORTANT]
-> Azure portal does not support creation of failover groups across different subscriptions. Also, for the existing failover groups across different subscriptions and/or resource groups, failover can't be initiated manually via portal from the primary SQL Managed Instance. Initiate it from the geo-secondary instance instead.
+> Azure portal does not support creation of failover groups across different subscriptions. For failover groups across different subscriptions and/or resource groups, failover can't be initiated manually via the Azure portal from the primary SQL managed instance. Initiate it from the geo-secondary instance instead.
 
 ## Change the secondary region