Merge branch 'main' of https://github.com/MicrosoftDocs/sql-docs-pr into 20231004-cls-rls

Author: WilliamDAssafMSFT

.openpublishing.redirection.json

@@ -41325,6 +41325,11 @@
       "redirect_url": "/sql/dma/dma-consolidatereports",
       "redirect_document_id": false
     },
+    {
+      "source_path": "docs/sql-server/azure-arc/connect-at-scale-autodeploy.md",
+      "redirect_url": "/sql/sql-server/azure-arc/manage-autodeploy",
+      "redirect_document_id": false
+    },
     {
       "source_path": "docs/sql-server/azure-arc/quick-enabled-sql-server.md",
       "redirect_url": "/sql/sql-server/azure-arc/automatically-connect",

azure-sql/database/connect-github-actions-sql-db.md

@@ -8,9 +8,7 @@ ms.date: 02/15/2023
 ms.service: sql-database
 ms.subservice: connect
 ms.topic: quickstart
-ms.custom:
-  - github-actions-azure
-  - mode-other
+ms.custom: github-actions-azure, mode-other, devx-track-azurecli
 ---
 
 # Use GitHub Actions to connect to Azure SQL Database

azure-sql/database/connectivity-settings.md

@@ -9,7 +9,7 @@ ms.date: 10/21/2022
 ms.service: sql-database
 ms.subservice: connect
 ms.topic: how-to
-ms.custom: devx-track-azurepowershell
+ms.custom: devx-track-azurepowershell, devx-track-azurecli
 ms.devlang: azurecli
 ---
 

azure-sql/database/database-import-export-azure-services-off.md

@@ -8,7 +8,9 @@ ms.date: 01/08/2020
 ms.service: sql-database
 ms.subservice: migration
 ms.topic: how-to
-ms.custom: sqldbrb=1
+ms.custom:
+  - sqldbrb=1
+  - sql-migration-content
 ---
 # Import or export an Azure SQL Database without allowing Azure services to access the server
 [!INCLUDE[appliesto-sqldb](../includes/appliesto-sqldb.md)]

azure-sql/database/database-import-export-private-link.md

@@ -8,7 +8,9 @@ ms.date: 12/22/2022
 ms.service: sql-database
 ms.subservice: migration
 ms.topic: how-to
-ms.custom: sqldbrb=1
+ms.custom:
+  - sqldbrb=1
+  - sql-migration-content
 ---
 # Import or export an Azure SQL Database using private link
 

azure-sql/database/database-import.md

@@ -4,7 +4,7 @@ description: Create a new database in Azure SQL Database or Azure SQL Managed In
 author: WilliamDAssafMSFT
 ms.author: wiassaf
 ms.reviewer: jeschult, mathoma
-ms.date: 08/25/2023
+ms.date: 10/05/2023
 ms.service: sql-db-mi
 ms.subservice: backup-restore
 ms.topic: quickstart
@@ -124,6 +124,9 @@ while ($importStatus.Status -eq "InProgress") {
 $importStatus
 ```
 
+> [!TIP]  
+> For another script example, see [Import a database from a BACPAC file](scripts/import-from-bacpac-powershell.md).
+
 # [Azure CLI](#tab/azure-cli)
 
 Use the [az-sql-db-import](/cli/azure/sql/db#az-sql-db-import) command to submit an import database request to Azure. Depending on database size, the import may take some time to complete. The DTU based provisioning model supports select database max size values for each tier. When importing a database [use one of these supported values](/sql/t-sql/statements/create-database-transact-sql).
@@ -138,8 +141,7 @@ az sql db import --resource-group "<resourceGroup>" --server "<server>" --name "
     -u "<userId>" -p "<password>"
 ```
 
-> [!TIP]  
-> For another script example, see [Import a database from a BACPAC file](scripts/import-from-bacpac-powershell.md).
+---
 
 ## Cancel the import request
 
@@ -177,7 +179,7 @@ You can also use these wizards.
 - [Import Data-tier Application Wizard in SQL Server Management Studio](/sql/relational-databases/data-tier-applications/import-a-bacpac-file-to-create-a-new-user-database#using-the-import-data-tier-application-wizard).
 - [SQL Server Import and Export Wizard](/sql/integration-services/import-export-data/start-the-sql-server-import-and-export-wizard).
 
-## Next steps
+## Related content
 
 - To learn how to connect to and query Azure SQL Database from Azure Data Studio, see [Quickstart: Use Azure Data Studio to connect and query Azure SQL Database](/sql/azure-data-studio/quickstart-sql-database).
 - To learn how to connect to and query a database in Azure SQL Database, see [Quickstart: Azure SQL Database: Use SQL Server Management Studio to connect to and query data](connect-query-ssms.md).

azure-sql/database/doc-changes-updates-release-notes-whats-new.md

@@ -3,53 +3,57 @@ title: Hyperscale distributed functions architecture
 description: Learn how Hyperscale databases are architected to scale out storage and compute resources for Azure SQL Database.
 author: dimitri-furman
 ms.author: dfurman
-ms.reviewer: wiassaf, mathoma
-ms.date: 8/4/2023
+ms.reviewer: wiassaf, mathoma, randolphwest
+ms.date: 10/04/2023
 ms.service: sql-database
 ms.subservice: service-overview
-ms.custom: build-2023, build-2023-dataai
 ms.topic: conceptual
+ms.custom:
+  - build-2023
+  - build-2023-dataai
 ---
 
 # Hyperscale distributed functions architecture
 
-[!INCLUDE[appliesto-sqldb](../includes/appliesto-sqldb.md)]
+[!INCLUDE [appliesto-sqldb](../includes/appliesto-sqldb.md)]
 
 The [Hyperscale service tier](service-tier-hyperscale.md) utilizes an architecture with highly scalable and separate storage and compute tiers. This article describes the components that enable customers to quickly scale Hyperscale databases while benefiting from nearly instantaneous backups and highly scalable transaction logging.
 
 ## Hyperscale architecture overview
 
-Traditional database engines centralize data management functions in a single process: even so called distributed databases in production today have multiple copies of a monolithic data engine.
+Traditional database engines centralize data management functions in a single process: even so-called distributed databases in production today have multiple copies of a monolithic data engine.
 
 Hyperscale databases follow a different approach. Hyperscale separates the query processing engine, where the semantics of various data engines diverge, from the components that provide long-term storage and durability for the data. In this way, storage capacity can be smoothly scaled out as far as needed. The initially supported storage limit is 100 TB.
 
 All network communication among Hyperscale components uses Azure network infrastructure with built-in redundancy.
 
-High availability secondary replicas and named replicas are optional compute nodes which can be added on-demand. Both share the same storage components, so no data copy is required to spin up a new replica. A geo secondary replica can be added on-demand in same or different Azure region. For data protection and redundancy, geo secondary replicas have storage components that are separate from those used by primary replica.
+High-availability secondary replicas and named replicas are optional compute nodes that can be added on demand. Both share the same storage components, so no data copy is required to spin up a new replica. A geo-secondary replica can be added on demand in the same or a different Azure region. For data protection and redundancy, geo-secondary replicas have storage components that are separate from those used by the primary replica.
 
 The following diagram illustrates the functional Hyperscale architecture:
 
-:::image type="content" source="./media/service-tier-hyperscale/hyperscale-architecture.png" alt-text="Diagram that shows that Hyperscale's compute tier consists of a primary compute note and secondary compute nodes, each with RBPEX data cache. The log service communicates both with compute notes and page servers. Page servers exist in their own tier, and also have RBPEX data cache." lightbox="./media/service-tier-Hyperscale/Hyperscale-architecture.png":::
+:::image type="complex" source="media/service-tier-hyperscale/hyperscale-architecture.png" alt-text="Diagram showing Hyperscale's compute tier." lightbox="media/service-tier-Hyperscale/Hyperscale-architecture.png":::
+Diagram that shows that Hyperscale's compute tier consists of a primary compute note and secondary compute nodes, each with RBPEX data cache. The log service communicates both with compute notes and page servers. Page servers exist in their own tier and also have RBPEX data cache.
+:::image-end:::
 
 A Hyperscale database contains the following types of components: compute nodes, page servers, the log service, and Azure storage.
 
 ## Compute
 
-The compute node is where the relational engine lives. The compute node is where language, query, and transaction processing occur. All user interactions with a Hyperscale database happen through compute nodes.  Compute nodes can either be configured to use serverless or provisioned compute.
+The compute node is where the relational engine lives. The compute node is where language, query, and transaction processing occur. All user interactions with a Hyperscale database happen through compute nodes. Compute nodes can either be configured to use serverless or provisioned compute.
 
-Compute nodes have local SSD-based caches called Resilient Buffer Pool Extension (RBPEX Data Cache). RBPEX Data Cache is an intelligent low latency data cache that minimizes the need to fetch data from remote page servers.
+Compute nodes have local SSD-based caches called Resilient Buffer Pool Extension (RBPEX Data Cache). RBPEX Data Cache is an intelligent low-latency data cache that minimizes the need to fetch data from remote page servers.
 
-Hyperscale databases have one primary compute node where the read-write workload and transactions are processed. Up to four high availability secondary compute nodes can be added on-demand. They act as hot standby nodes for failover purposes, and may serve as read-only compute nodes to offload read workloads when desired. [Named replicas](service-tier-hyperscale-replicas.md#named-replica) are secondary compute nodes designed to enable a variety of additional OLTP [read-scale out](read-scale-out.md) scenarios and to better support Hybrid Transactional and Analytical Processing (HTAP) workloads. A [geo secondary](active-geo-replication-overview.md) compute node can be added for disaster recovery purposes and to serve as a read-only compute node to offload read workloads in a different Azure region.
+Hyperscale databases have one primary compute node where the read-write workload and transactions are processed. Up to four high-availability secondary compute nodes can be added on demand. They act as hot standby nodes for failover purposes and may serve as read-only compute nodes to offload read workloads when desired. [Named replicas](service-tier-hyperscale-replicas.md#named-replica) are secondary compute nodes designed to enable various additional OLTP [read-scale out](read-scale-out.md) scenarios and to better support Hybrid Transactional and Analytical Processing (HTAP) workloads. A [geo secondary](active-geo-replication-overview.md) compute node can be added for disaster recovery purposes and to serve as a read-only compute node to offload read workloads in a different Azure region.
 
-In serverless, the primary replica and any high availability replicas or named replicas each independently auto-scale based on their usage.  The compute auto-scaling range for the primary replica and any named replicas are configured independently.  The auto-scaling range of any high availability replicas is inherited from the auto-scaling configuration specified by their associated primary replica or named replica.    
+In serverless, the primary replica and any high availability replicas or named replicas each independently autoscale based on their usage. The compute autoscaling range for the primary replica and any named replicas are configured independently. The autoscaling range of any high-availability replicas is inherited from the autoscaling configuration specified by their associated primary replica or named replica.
 
-The database engine running on Hyperscale compute nodes is the same as in other Azure SQL Database service tiers. When users interact with the database engine on Hyperscale compute nodes, the supported surface area and engine behavior are the same as in other service tiers, with the exception of [known limitations](service-tier-hyperscale.md#known-limitations).
+The database engine running on Hyperscale compute nodes is the same as in other Azure SQL Database service tiers. When users interact with the database engine on Hyperscale compute nodes, the supported surface area and engine behavior are the same as in other service tiers, except for [known limitations](service-tier-hyperscale.md#known-limitations).
 
 ## Page server
 
 Page servers are systems representing a scaled-out storage engine. Each page server is responsible for a subset of the pages in the database. Each page server also has a replica that is kept for redundancy and availability.
 
-The job of a page server is to serve database pages out to the compute nodes on demand, and to keep the pages updated as transactions update data. Page servers are kept up to date by replaying transaction log records from the log service. 
+The job of a page server is to serve database pages out to the compute nodes on demand, and to keep the pages updated as transactions update data. Page servers are kept up to date by replaying transaction log records from the log service.
 
 Page servers also maintain covering SSD-based caches to enhance performance. Long-term storage of data pages is kept in Azure Storage for durability.
 
@@ -59,7 +63,7 @@ The log service accepts transaction log records that correspond to data changes
 
 Finally, transaction log records are pushed out to long-term storage in Azure Storage, which is a virtually infinite storage repository. This mechanism removes the need for frequent log truncation. The log service has local memory and SSD caches to speed up access to log records.
 
-The log-on Hyperscale is practically infinite, with the restriction that a single transaction cannot generate more than 1 TB of log. Additionally, if using [Change Data Capture](/sql/relational-databases/track-changes/about-change-data-capture-sql-server), at most 1 TB of log can be generated since the start of the oldest active transaction. Avoid unnecessarily large transactions to stay below this limit.
+The log for Hyperscale is practically infinite, with the restriction that a single transaction can't generate more than 1 TB of log. Additionally, if using [Change Data Capture](/sql/relational-databases/track-changes/about-change-data-capture-sql-server), at most 1 TB of log can be generated since the start of the oldest active transaction. Avoid unnecessarily large transactions to stay below this limit.
 
 ## Azure storage
 
@@ -76,11 +80,9 @@ Hyperscale supports configurable storage redundancy. When creating a Hyperscale
 
 Zone-redundant storage options are available in Azure [regions with availability zones](/azure/reliability/availability-zones-service-support).
 
-The selected storage redundancy option will be used for the lifetime of the database for both data storage redundancy and [backup storage redundancy](automated-backups-overview.md#backup-storage-redundancy).
+The selected storage redundancy option is used for the lifetime of the database, for both data storage redundancy and [backup storage redundancy](automated-backups-overview.md#backup-storage-redundancy).
 
-## Next steps
-
-Learn more about Hyperscale in the following articles:
+## Related content
 
 - [Hyperscale service tier](service-tier-hyperscale.md)
 - [Azure SQL Database Hyperscale FAQ](service-tier-hyperscale-frequently-asked-questions-faq.yml)