Merge branch 'main' of https://github.com/MicrosoftDocs/sql-docs-pr into release-arc-data-known-issues

Author: MikeRayMSFT

.openpublishing.redirection.azure-sql.json

@@ -155,6 +155,46 @@
       "redirect_url": "/azure/azure-sql/migration-guides/managed-instance/sql-server-to-managed-instance-guide",
       "redirect_document_id": false
     },
+    {
+      "source_path_from_root": "/azure-sql/database/auto-failover-group-configure-sql-db.md",
+      "redirect_url": "/azure/azure-sql/database/failover-group-configure-sql-db",
+      "redirect_document_id": true
+    },
+    {
+      "source_path_from_root": "/azure-sql/database/auto-failover-group-sql-db.md",
+      "redirect_url": "/azure/azure-sql/database/failover-group-sql-db",
+      "redirect_document_id": true
+    },
+    {
+      "source_path_from_root": "/azure-sql/database/failover-group-add-single-database-tutorial.md",
+      "redirect_url": "/azure/azure-sql/database/failover-group-configure-sql-db",
+      "redirect_document_id": false
+    },
+    {
+      "source_path_from_root": "/azure-sql/database/failover-group-add-elastic-pool-tutorial.md",
+      "redirect_url": "/azure/azure-sql/database/failover-group-configure-sql-db",
+      "redirect_document_id": false
+    },
+    {
+      "source_path_from_root": "/azure-sql/managed-instance/failover-group-add-instance-tutorial.md",
+      "redirect_url": "/azure/azure-sql/managed-instance/failover-group-configure-sql-mi",
+      "redirect_document_id": false
+    },
+    {
+      "source_path_from_root": "/azure-sql/managed-instance/auto-failover-group-configure-sql-mi.md",
+      "redirect_url": "/azure/azure-sql/managed-instance/failover-group-configure-sql-mi",
+      "redirect_document_id": true
+    },
+    {
+      "source_path_from_root": "/azure-sql/managed-instance/auto-failover-group-sql-mi.md",
+      "redirect_url": "/azure/azure-sql/managed-instance/failover-group-sql-mi",
+      "redirect_document_id": true
+    },
+    {
+      "source_path_from_root": "/azure-sql/managed-instance/auto-failover-group-standby-replica-how-to-configure.md",
+      "redirect_url": "/azure/azure-sql/managed-instance/failover-group-standby-replica-how-to-configure",
+      "redirect_document_id": true
+    },
     {
       "source_path_from_root": "/azure-sql/virtual-machines/linux/sql/sql-server-linux-faq.md",
       "redirect_url": "/azure/azure-sql/virtual-machines/linux/frequently-asked-questions-faq",

.openpublishing.redirection.json

@@ -59584,6 +59584,116 @@
       "source_path": "docs/ssdt/release-notes-ssdt.md",
       "redirect_url": "/sql/ssdt/previous-releases-of-sql-server-data-tools-ssdt-and-ssdt-bi",
       "redirect_document_id": false
+    },    
+    {
+      "source_path": "docs/odbc/microsoft/aggregate-function-limitations.md",
+      "redirect_url": "/sql/odbc/microsoft/limitations",
+      "redirect_document_id": false
+    },
+    {
+      "source_path": "docs/odbc/microsoft/and-predicate-limitations.md",
+      "redirect_url": "/sql/odbc/microsoft/limitations",
+      "redirect_document_id": false
+    },
+    {
+      "source_path": "docs/odbc/microsoft/call-statement-limitations.md",
+      "redirect_url": "/sql/odbc/microsoft/limitations",
+      "redirect_document_id": false
+    },
+    {
+      "source_path": "docs/odbc/microsoft/convert-function-limitations.md",
+      "redirect_url": "/sql/odbc/microsoft/limitations",
+      "redirect_document_id": false
+    },
+    {
+      "source_path": "docs/odbc/microsoft/date-arithmetic-limitations.md",
+      "redirect_url": "/sql/odbc/microsoft/limitations",
+      "redirect_document_id": false
+    },
+    {
+      "source_path": "docs/odbc/microsoft/distinct-keyword-limitations.md",
+      "redirect_url": "/sql/odbc/microsoft/limitations",
+      "redirect_document_id": false
+    },
+    {
+      "source_path": "docs/odbc/microsoft/drop-index-statement-limitations.md",
+      "redirect_url": "/sql/odbc/microsoft/limitations",
+      "redirect_document_id": false
+    },
+    {
+      "source_path": "docs/odbc/microsoft/drop-table-statement-limitations.md",
+      "redirect_url": "/sql/odbc/microsoft/limitations",
+      "redirect_document_id": false
+    },
+    {
+      "source_path": "docs/odbc/microsoft/from-clause-limitations.md",
+      "redirect_url": "/sql/odbc/microsoft/limitations",
+      "redirect_document_id": false
+    },
+    {
+      "source_path": "docs/odbc/microsoft/having-clause-limitations.md",
+      "redirect_url": "/sql/odbc/microsoft/limitations",
+      "redirect_document_id": false
+    },
+    {
+      "source_path": "docs/odbc/microsoft/index-name-limitations.md",
+      "redirect_url": "/sql/odbc/microsoft/limitations",
+      "redirect_document_id": false
+    },
+    {
+      "source_path": "docs/odbc/microsoft/not-null-limitations.md",
+      "redirect_url": "/sql/odbc/microsoft/limitations",
+      "redirect_document_id": false
+    },
+    {
+      "source_path": "docs/odbc/microsoft/order-by-clause-limitations.md",
+      "redirect_url": "/sql/odbc/microsoft/limitations",
+      "redirect_document_id": false
+    },
+    {
+      "source_path": "docs/odbc/microsoft/parameterized-query-limitations.md",
+      "redirect_url": "/sql/odbc/microsoft/limitations",
+      "redirect_document_id": false
+    },
+    {
+      "source_path": "docs/odbc/microsoft/scalar-function-limitations.md",
+      "redirect_url": "/sql/odbc/microsoft/limitations",
+      "redirect_document_id": false
+    },
+    {
+      "source_path": "docs/odbc/microsoft/select-distinct-limitations.md",
+      "redirect_url": "/sql/odbc/microsoft/limitations",
+      "redirect_document_id": false
+    },
+    {
+      "source_path": "docs/odbc/microsoft/set-functions-limitations.md",
+      "redirect_url": "/sql/odbc/microsoft/limitations",
+      "redirect_document_id": false
+    },
+    {
+      "source_path": "docs/odbc/microsoft/sorting-limitations.md",
+      "redirect_url": "/sql/odbc/microsoft/limitations",
+      "redirect_document_id": false
+    },
+    {
+      "source_path": "docs/odbc/microsoft/table-references-limitations.md",
+      "redirect_url": "/sql/odbc/microsoft/limitations",
+      "redirect_document_id": false
+    },
+    {
+      "source_path": "docs/odbc/microsoft/views-limitations.md",
+      "redirect_url": "/sql/odbc/microsoft/limitations",
+      "redirect_document_id": false
+    },
+    {
+      "source_path": "docs/odbc/microsoft/where-clause-limitations.md",
+      "redirect_url": "/sql/odbc/microsoft/limitations",
+      "redirect_document_id": false
+    },
+    {
+      "source_path": "docs/odbc/microsoft/where-current-of-clause-limitations.md",
+      "redirect_url": "/sql/odbc/microsoft/limitations",
+      "redirect_document_id": false
     },
     {
       "source_path": "docs/ssms/f1-help/connect-to-server-database-engine.md",

azure-sql/database/active-geo-replication-configure-portal.md

@@ -16,7 +16,7 @@ ms.custom: sqldbrb=1, devx-track-azurecli, ignite-2023, devx-track-azurepowershe
 
 This article shows you how to configure [active geo-replication for Azure SQL Database](active-geo-replication-overview.md#active-geo-replication-terminology-and-capabilities) using the [Azure portal](https://portal.azure.com) or Azure CLI and to initiate failover.
 
-For best practices using auto-failover groups, see [Auto-failover groups with Azure SQL Database](auto-failover-group-sql-db.md) and [Auto-failover groups with Azure SQL Managed Instance](../managed-instance/auto-failover-group-sql-mi.md).
+For failover groups, see [Failover groups with Azure SQL Database](failover-group-sql-db.md) and [Failover groups with Azure SQL Managed Instance](../managed-instance/failover-group-sql-mi.md).
 
 ## Prerequisites
 
@@ -185,9 +185,6 @@ The command immediately switches the secondary database into the primary role. T
 
 There's a short period during which both databases are unavailable, on the order of 0 to 25 seconds, while the roles are switched. If the primary database has multiple secondary databases, the command automatically reconfigures the other secondaries to connect to the new primary. The entire operation should take less than a minute to complete under normal circumstances.
 
-> [!NOTE]
-> This command is designed for quick recovery of the database in case of an outage. It triggers failover without data synchronization, or forced failover.  If the primary is online and committing transactions when the command is issued some data loss may occur.
-
 ## Remove secondary database
 
 This operation permanently stops the replication to the secondary database, and changes the role of the secondary to a regular read-write database. If the connectivity to the secondary database is broken, the command succeeds but the secondary doesn't become read-write until after connectivity is restored.
@@ -302,6 +299,7 @@ Use Transact-SQL (T-SQL) create a geo-secondary in a subscription different from
 ## Next steps
 
 * To learn more about active geo-replication, see [active geo-replication](active-geo-replication-overview.md).
-* To learn about auto-failover groups, see [Auto-failover groups](auto-failover-group-sql-db.md)
+* To learn about failover groups, see [Failover groups](failover-group-sql-db.md)
 * For a business continuity overview and scenarios, see [Business continuity overview](business-continuity-high-availability-disaster-recover-hadr-overview.md).
 * Save on licensing costs by designating your secondary DR replica for [standby](standby-replica-how-to-configure.md).
+1

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

@@ -16,13 +16,10 @@ ms.custom: sqldbrb=1, ignite-2023
 
 Active geo-replication is a feature that lets you create a continuously synchronized readable secondary database for a primary database. The readable secondary database might 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 configured per database, and only supports manual failover. To automatically fail over a group of databases, or if your application requires a stable connection endpoint, consider [Auto-failover groups](auto-failover-group-sql-db.md) instead. [Compare geo-replication with failover groups](business-continuity-high-availability-disaster-recover-hadr-overview.md#compare-geo-replication-with-failover-groups) to learn more. 
+Active geo-replication is configured per database, and only supports manual failover. To fail over a group of databases, or if your application requires a stable connection endpoint, consider [Failover groups](failover-group-sql-db.md) instead.
 
 You can also use [Migrate SQL Database with active geo-replication](/azure/germany/germany-migration-databases#migrate-sql-database-using-active-geo-replication). 
 
-> [!NOTE]
-> Azure SQL Managed Instance doesn't support active geo-replication, see [Auto-failover groups](../managed-instance/auto-failover-group-sql-mi.md) instead. 
-
 ## Overview
 
 Active geo-replication is designed as a business continuity solution. Active geo-replication lets you perform quick disaster recovery of individual databases if there's 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.
@@ -73,20 +70,20 @@ To achieve full business continuity, adding database regional redundancy is only
    > You can use geo-replication to create secondary replicas in the same region as the primary. You can use these secondaries to satisfy read scale-out scenarios in the same region. However, a secondary replica in the same region does not provide additional resilience to catastrophic failures or large scale outages, and therefore is not a suitable failover target for disaster recovery purposes. It also does not guarantee availability zone isolation. Use Business Critical or Premium service tiers [zone redundant configuration](high-availability-sla.md#zone-redundant-availability) or General Purpose service tier [zone redundant configuration](high-availability-sla.md#zone-redundant-availability) to achieve availability zone isolation.
    >
 
-- **Planned geo-failover**
+- **Failover (no data loss)**
 
-  Planned geo-failover switches the roles of primary and geo-secondary databases after completing full data synchronization. A planned failover doesn't result in data loss. The duration of planned geo-failover depends on the size of transaction log on the primary that needs to be synchronized to the geo-secondary. Planned geo-failover is designed for the following scenarios:
+  Failover switches the roles of primary and geo-secondary databases after completing full data synchronization so there's no data loss. Duration of the failover depends on the size of the transaction log on the primary that needs to be synchronized to the geo-secondary. Failover is designed for the following scenarios:
 
-  - Perform DR drills in production when the data loss isn't acceptable; 
-  - Relocate the database to a different region; 
+  - Perform DR drills in production when the data loss isn't acceptable
+  - Relocate the database to a different region
   - Return the database to the primary region after the outage has been mitigated (known as failback).
 
-- **Unplanned geo-failover**
+- **Forced failover (potential data loss)**
 
-  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 isn't accessible, but database availability must be quickly restored. When the original primary is back online, it is automatically reconnected, reseeded using the current primary data, and become a new geo-secondary.
+  Forced failover immediately switches the geo-secondary to the primary role without waiting for 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 isn't accessible, but database availability must be quickly restored. When the original primary is back online, it's automatically reconnected, reseeded using current data from the primary, and become the 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.
+  > After either failover or forced failover, the connection endpoint for the new primary changes because the new primary is now located on a different logical server.
 
 - **Multiple readable geo-secondaries**
 
@@ -101,7 +98,7 @@ To achieve full business continuity, adding database regional redundancy is only
 
 - **User-controlled geo-failover and failback**
 
-  A geo-secondary that has finished initial seeding can be explicitly switched to the primary role (failed over) at any time by the application or the user. During an outage where the primary is inaccessible, only an unplanned geo-failover can be used. That immediately promotes a geo-secondary to be the new primary. When the outage is mitigated, the system automatically makes the recovered primary a geo-secondary, and brings it up-to-date with the new primary. Due to the asynchronous nature of geo-replication, recent transactions might be lost during unplanned geo-failovers if the primary fails before these transactions are replicated to a geo-secondary. When a primary with multiple geo-secondaries fail over, the system automatically reconfigures replication relationships and links the remaining geo-secondaries to the newly promoted primary, without requiring any user intervention. After the outage that caused the geo-failover is mitigated, it might be desirable to return the primary to its original region. To do that, invoke a planned geo-failover.
+  A geo-secondary that has finished initial seeding can be explicitly switched to the primary role (failed over) at any time by the application or the user. During an outage where the primary is inaccessible, only forced failover can be used, which immediately promotes a geo-secondary to be the new primary. When the outage is mitigated, the system automatically makes the recovered primary a geo-secondary, and brings it up-to-date with the new primary. Due to the asynchronous nature of geo-replication, recent transactions might be lost during forced failovers if the primary fails before these transactions are replicated to a geo-secondary. When a primary with multiple geo-secondaries fails over, the system automatically reconfigures replication relationships and links the remaining geo-secondaries to the newly promoted primary, without requiring any user intervention. After the outage that caused the geo-failover is mitigated, it might be desirable to return the primary to its original region. To do that, perform a manual failover.
 
 - **Standby replica** 
 
@@ -112,7 +109,7 @@ To achieve full business continuity, adding database regional redundancy is only
 To ensure that your application can immediately access the new primary after geo-failover, validate that authentication and network access for your secondary server are properly configured. For details, see [SQL Database security after disaster recovery](active-geo-replication-security-configure.md). Also validate that backup retention policy on the secondary database matches that of the primary. This setting isn't a part of the database and isn't replicated from the primary. By default, the geo-secondary is configured with a default PITR retention period of seven days. For details, see [SQL Database automated backups](automated-backups-overview.md).
 
 > [!IMPORTANT]
-> If your database is a member of a failover group, you cannot initiate its failover using the geo-replication failover command. Use the failover command for the group. If you need to failover an individual database, you must remove it from the failover group first. See  [Auto-failover groups](auto-failover-group-sql-db.md) for details.
+> If your database is a member of a failover group, you cannot initiate its failover using the geo-replication failover command. Use the failover command for the group. If you need to failover an individual database, you must remove it from the failover group first. See  [Failover groups](failover-group-sql-db.md) for details.
 
 ## <a name="configuring-secondary-database"></a> Configure geo-secondary
 
@@ -228,7 +225,7 @@ As discussed previously, active geo-replication can also be managed programmatic
 - For sample scripts, see:
   - [Configure and failover a single database using active geo-replication](scripts/setup-geodr-and-failover-database-powershell.md).
   - [Configure and failover a pooled database using active geo-replication](scripts/setup-geodr-and-failover-elastic-pool-powershell.md).
-- SQL Database also supports auto-failover groups. For more information, see using [auto-failover groups](auto-failover-group-sql-db.md).
+- SQL Database also supports failover groups. For more information, see using [failover groups](failover-group-sql-db.md).
 - For a business continuity overview and scenarios, see [Business continuity overview](business-continuity-high-availability-disaster-recover-hadr-overview.md).
 - Save on licensing costs by designating your secondary DR replica for [standby](standby-replica-how-to-configure.md).
 - To learn about Azure SQL Database Hyperscale Geo-replica see [Hyperscale Geo-replica](service-tier-hyperscale-replicas.md#geo-replica)