Merge branch 'MicrosoftDocs:main' into main

Author: VictorBei

azure-sql/database/automated-backups-overview.md

@@ -211,15 +211,12 @@ If you delete a database, the system keeps backups in the same way that it would
 
 For SQL Database, you can configure full LTR backups for up to 10 years in Azure Blob Storage. After the LTR policy is configured, full backups are automatically copied to a different storage container weekly. 
 
-To meet various compliance requirements, you can select different retention periods for weekly, monthly, and/or yearly full backups. The frequency depends on the policy. For example, setting `W=0, M=1` would create an LTR copy monthly. For more information about LTR, see [Long-term retention](long-term-retention-overview.md).  
+To meet various compliance requirements, you can select different retention periods for weekly, monthly, and/or yearly full backups. The frequency depends on the policy. For example, setting `W=0, M=1` would create an LTR copy monthly. For more information about LTR, see [Long-term retention](long-term-retention-overview.md). Databases in the Hyperscale service tier don't currently support long-term retention.
 
 Updating the backup storage redundancy for an existing database applies the change only to subsequent backups taken in the future and not for existing backups. All existing LTR backups for the database will continue to reside in the existing storage blob. New backups will be replicated based on the configured backup storage redundancy. 
 
 Storage consumption depends on the selected frequency and retention periods of LTR backups. You can use the [LTR pricing calculator](https://azure.microsoft.com/pricing/calculator/?service=sql-database) to estimate the cost of LTR storage.
 
-> [!NOTE]
-> Long-term retention for Hyperscale databases is currently in preview.
-
 ## Backup storage costs
 
 The price for backup storage varies and depends on your [purchasing model (DTU or vCore)](purchasing-models.md), chosen backup storage redundancy option, and region. Backup storage is charged based on gigabytes consumed per month, at the same rate for all backups. 

azure-sql/database/dns-alias-overview.md

@@ -18,7 +18,7 @@ Azure SQL Database has a Domain Name System (DNS) server. PowerShell and REST AP
 A *DNS alias* can be used in place of the server name. Client programs can use the alias in their connection strings. The DNS alias provides a translation layer that can redirect your client programs to different servers. This layer spares you the difficulties of having to find and edit all the clients and their connection strings.
 
 > [!NOTE]
-> In Azure Synapse Analytics, the Azure SQL logical server DNS alias is only supported for dedicated SQL Pool (formerly DW). For dedicated SQL pools in Azure Synapse workspaces, the DNS alias is not currently supported.
+> In Azure Synapse Analytics, the Azure SQL logical server DNS alias is only supported for dedicated SQL Pool (formerly DW). For dedicated SQL pools in Azure Synapse workspaces, the DNS alias is not currently supported. [What's the difference?](https://aka.ms/dedicatedSQLpooldiff)
 
 Common uses for a DNS alias include the following cases:
 
@@ -114,4 +114,4 @@ Presently, a DNS alias has the following limitations:
 
 ## Next steps
 
-- [PowerShell for DNS Alias to Azure SQL Database](dns-alias-powershell-create.md)
+- [PowerShell for DNS Alias to Azure SQL Database](dns-alias-powershell-create.md)

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

@@ -42,7 +42,6 @@ The following table lists the features of Azure SQL Database that are currently
 | [SQL Database emulator](local-dev-experience-sql-database-emulator.md) | The Azure SQL Database emulator provides the ability to locally validate database and query design together with client application code in a simple and frictionless model as part of the application development process. | 
 | [SQL Database Projects extension](/sql/azure-data-studio/extensions/sql-database-project-extension) | An extension to develop databases for Azure SQL Database with Azure Data Studio and VS Code. A SQL project is a local representation of SQL objects that comprise the schema for a single database, such as tables, stored procedures, or functions. | 
 | [SQL Insights](/azure/azure-monitor/insights/sql-insights-overview) | SQL Insights (preview) is a comprehensive solution for monitoring any product in the Azure SQL family. SQL Insights (preview) uses dynamic management views to expose the data you need to monitor health, diagnose problems, and tune performance.|
-| [Azure SQL Database Hyperscale tier long-term retention](long-term-retention-overview.md) | Long-term retention (LTR) capability for Hyperscale databases is now in preview. | 
 
 
 ## General availability (GA)
@@ -69,12 +68,6 @@ The following table lists the features of Azure SQL Database that have transitio
 
 Learn about significant changes to the Azure SQL Database documentation.
 
-### September 2022
-
-| Changes | Details |
-| --- | --- |
-| [Azure SQL Database Hyperscale tier long-term retention](long-term-retention-overview.md) | Long-term retention (LTR) capability for Hyperscale databases is now in preview. | 
-
 ### August 2022
 
 | Changes | Details |

azure-sql/database/hyperscale-automated-backups-overview.md

@@ -42,11 +42,10 @@ Creation of new databases by restoring an existing backup or copying the databas
 
 ## Backup retention
 
-Default short-term retention of backups for Hyperscale databases is 7 days. 
+Default short-term retention of backups for Hyperscale databases is 7 days. Long-term retention (LTR) policies aren't currently supported.
 
 > [!NOTE]
 > - Short-term retention of backups in the range of 1 to 35 days for Hyperscale databases is now in preview.
-> - Long-term retention (LTR) capability for Hyperscale databases is now in preview.
 
 ## Backup scheduling
 

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

@@ -312,12 +312,12 @@ Restore-AzSqlDatabase -FromLongTermRetentionBackup -ResourceId $ltrBackup.Resour
 ```
 
 > [!IMPORTANT]
-> To restore from an LTR backup after the server or resource group has been deleted, you must have permissions scoped to the server's subscription and that subscription must be active. You must also omit the optional -ResourceGroupName parameter.
+> - To restore from an LTR backup after the server or resource group has been deleted, you must have permissions scoped to the server's subscription and that subscription must be active. You must also omit the optional `-ResourceGroupName` parameter.
+> - If you are using LTR backups to meet compliance or other mission-critical requirements, consider conducting periodic recovery drills to verify that LTR backups can be restored, and that the restore results in an expected database state.
 
 > [!NOTE]
 > From here, you can connect to the restored database using SQL Server Management Studio to perform needed tasks, such as to extract a bit of data from the restored database to copy into the existing database or to delete the existing database and rename the restored database to the existing database name. See [point in time restore](recovery-using-backups.md#point-in-time-restore).
->
-> If you are using LTR backups to meet compliance or other mission-critical requirements, consider conducting periodic recovery drills to verify that LTR backups can be restored, and that the restore results in expected database state.
+
 ---
 
 ## Limitations

azure-sql/database/long-term-retention-overview.md

@@ -19,8 +19,7 @@ Long-term retention can be enabled for Azure SQL Database and for Azure SQL Mana
 
 In Azure SQL Managed Instance, you can use SQL Agent jobs to schedule [copy-only database backups](/sql/relational-databases/backup-restore/copy-only-backups-sql-server) as an alternative to LTR beyond 35 days.
 
-> [!NOTE]
-> Long-term retention for Hyperscale databases is now in preview.
+
 
 ## How long-term retention works
      

azure-sql/database/migrate-dtu-to-vcore.md

@@ -4,7 +4,7 @@ description: Migrate a database in Azure SQL Database from the DTU model to the
 author: dimitri-furman
 ms.author: dfurman
 ms.reviewer: wiassaf, mathoma, moslake
-ms.date: 05/10/2022
+ms.date: 09/13/2022
 ms.service: sql-database
 ms.subservice: service-overview
 ms.topic: conceptual
@@ -88,10 +88,10 @@ SELECT dtu_logical_cpus,
             WHEN dtu_hardware_gen = 'Gen5' THEN dtu_logical_cpus * 0.8
        END AS Fsv2_vcores,
        1.89 AS Fsv2_memory_per_core_gb,
-       CASE WHEN dtu_hardware_gen = 'Gen4' THEN dtu_logical_cpus * 1.4
-            WHEN dtu_hardware_gen = 'Gen5' THEN dtu_logical_cpus * 0.9
-       END AS M_vcores,
-       29.4 AS M_memory_per_core_gb
+       CASE WHEN dtu_hardware_gen = 'Gen5' THEN dtu_logical_cpus * 0.7
+             WHEN dtu_hardware_gen = 'Gen4' THEN dtu_logical_cpus
+       END AS DC_vcores,
+       4.5 AS DC_memory_per_core_gb
 FROM dtu_vcore_map;
 ```
 

azure-sql/database/recovery-using-backups.md

@@ -63,8 +63,6 @@ For a single subscription, you have the following limitations on the number of c
 |Single database (per subscription)|30|100|
 |Elastic pool (per pool)|4|2,000|
 
-There's no built-in method to restore the entire server. For an example of how to accomplish this task, see [Azure SQL Database: Full server recovery](https://gallery.technet.microsoft.com/Azure-SQL-Database-Full-82941666).
-
 ## Permissions
 
 To recover by using automated backups, you must be either:

azure-sql/database/resource-limits-logical-server.md

@@ -4,7 +4,7 @@ description: This article provides an overview of resource management in Azure S
 author: dimitri-furman
 ms.author: dfurman
 ms.reviewer: wiassaf, mathoma
-ms.date: 03/31/2022
+ms.date: 09/13/2022
 ms.service: sql-database
 ms.subservice: service-overview
 ms.topic: reference
@@ -89,7 +89,7 @@ Sessions, workers, and requests are defined as follows:
 
 For more information about these concepts, see the [Thread and Task Architecture Guide](/sql/relational-databases/thread-and-task-architecture-guide).
 
-The maximum numbers of sessions and workers are determined by the service tier and compute size. New requests are rejected when session or worker limits are reached, and clients receive an error message. While the number of connections can be controlled by the application, the number of concurrent workers is often harder to estimate and control. This is especially true during peak load periods when database resource limits are reached and workers pile up due to longer running queries, large blocking chains, or excessive query parallelism.
+The maximum number of workers is determined by the service tier and compute size. New requests are rejected when session or worker limits are reached, and clients receive an error message. While the number of connections can be controlled by the application, the number of concurrent workers is often harder to estimate and control. This is especially true during peak load periods when database resource limits are reached and workers pile up due to longer running queries, large blocking chains, or excessive query parallelism.
 
 > [!NOTE]
 > The initial offering of Azure SQL Database supported only single threaded queries. At that time, the number of requests was always equivalent to the number of workers. Error message 10928 in Azure SQL Database contains the wording "The request limit for the database is *N* and has been reached" for backwards compatibility purposes.  The limit reached is actually the number of workers. If your max degree of parallelism (MAXDOP) setting is equal to zero or is greater than one, the number of workers may be much higher than the number of requests, and the limit may be reached much sooner than when MAXDOP is equal to one. Learn more about error 10928 in [Resource governance errors](troubleshoot-common-errors-issues.md#resource-governance-errors).

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

@@ -145,7 +145,7 @@ These are the current limitations of the Hyperscale service tier.  We're activel
 | Issue | Description |
 | :---- | :--------- |
 | Short-term backup retention | Short-term backup retention for 1-35 days for Hyperscale databases is now in preview. A non-Hyperscale database can't be restored as a Hyperscale database, and a Hyperscale database can't be restored as a non-Hyperscale database.<BR/><BR/>For databases migrated to Hyperscale from other Azure SQL Database service tiers, pre-migration backups are kept for the duration of [backup retention](automated-backups-overview.md#backup-retention) period of the source database, including long-term retention policies. Restoring a pre-migration backup within the backup retention period of the database is supported [via the command line](recovery-using-backups.md#point-in-time-restore). You can restore these backups to any non-Hyperscale service tier.|
-| Long-term backup retention | Long-term backup retention for Hyperscale databases is now in preview.|
+| Long-term backup retention | Long-term backup retention is not currently supported. Hyperscale has a snapshot-based backup architecture, different than other service tiers.|
 | Service tier change from Hyperscale to General Purpose tier is supported directly under limited scenarios | Reverse migration from Hyperscale allows customers who have recently migrated an existing Azure SQL Database to the Hyperscale service tier to move to General Purpose tier, should Hyperscale not meet their needs. While reverse migration is initiated by a service tier change, it's essentially a size-of-data move between different architectures. Databases created in the Hyperscale service tier aren't eligible for reverse migration. Learn the [limitations for reverse migration](manage-hyperscale-database.md#limitations-for-reverse-migration). <BR/><BR/> For databases that don't qualify for reverse migration, the only way to migrate from Hyperscale to a non-Hyperscale service tier is to export/import using a bacpac file or other data movement technologies (Bulk Copy, Azure Data Factory, Azure Databricks, SSIS, etc.) Bacpac export/import from Azure portal, from PowerShell using [New-AzSqlDatabaseExport](/powershell/module/az.sql/new-azsqldatabaseexport) or [New-AzSqlDatabaseImport](/powershell/module/az.sql/new-azsqldatabaseimport), from Azure CLI using [az sql db export](/cli/azure/sql/db#az-sql-db-export) and [az sql db import](/cli/azure/sql/db#az-sql-db-import), and from [REST API](/rest/api/sql/) isn't supported. Bacpac import/export for smaller Hyperscale databases (up to 200 GB) is supported using SSMS and [SqlPackage](/sql/tools/sqlpackage) version 18.4 and later. For larger databases, bacpac export/import may take a long time, and may fail for various reasons. |
 | Elastic Pools |  Elastic Pools aren't currently supported with Hyperscale.|
 | Migration of databases with In-Memory OLTP objects | Hyperscale supports a subset of In-Memory OLTP objects, including memory-optimized table types, table variables, and natively compiled modules. However, when any In-Memory OLTP objects are present in the database being migrated, migration from Premium and Business Critical service tiers to Hyperscale isn't supported. To migrate such a database to Hyperscale, all In-Memory OLTP objects and their dependencies must be dropped. After the database is migrated, these objects can be recreated. Durable and non-durable memory-optimized tables aren't currently supported in Hyperscale, and must be changed to disk tables.|