Merge pull request #34592 from MicrosoftDocs/main

Merged by Learn.Build PR Management system

Author: learn-build-service-prod[bot]

azure-sql/database/auditing-analyze-audit-logs.md

@@ -26,9 +26,10 @@ If you chose to write audit logs to Log Analytics:
 
 1. Use the [Azure portal](https://portal.azure.com).
 1. Go to the relevant database resource.
-1. At the top of the database's **Auditing** page, select **View audit logs**.
+1. At the top of the database's **Auditing** page, select **View audit logs** to display a sample of audit logs with a limited set of fields that cover activity from up to 2 hours prior to the selected **End Time** (which defaults to 'now'):
 
    :::image type="content" source="media/auditing-analyze-audit-logs/view-audit-logs.png" alt-text="Screenshot of the Auditing menu in the Azure portal where you can select the View audit logs option." lightbox="media/auditing-analyze-audit-logs/view-audit-logs.png":::
+   
 
 You have two ways to view the logs:
 

azure-sql/database/convert-to-hyperscale.md

@@ -4,7 +4,7 @@ description: How to convert an Azure SQL Database to the Hyperscale tier.
 author: WilliamDAssafMSFT
 ms.author: wiassaf
 ms.reviewer: dfurman, blakhani
-ms.date: 04/06/2025
+ms.date: 07/02/2025
 ms.service: azure-sql-database
 ms.topic: how-to
 ms.custom:
@@ -15,24 +15,35 @@ monikerRange: "=azuresql || =azuresql-db"
 
 # Convert an existing database to Hyperscale
 
+[!INCLUDE [appliesto-sqldb](../includes/appliesto-sqldb.md)]
+
 You can convert an existing database in Azure SQL Database to Hyperscale using the Azure portal, the Azure CLI, PowerShell, or Transact-SQL.
 
+## Prerequisites
+
+ - To convert a database that is a part of a [geo-replication](active-geo-replication-overview.md) relationship, either as the primary or as a secondary, to Hyperscale, you must first terminate geo-replication between the primary and secondary replica. Databases in a [failover group](failover-group-sql-db.md) must be removed from the group first. Once a database is converted to Hyperscale, you can create a new Hyperscale geo-replica for that database or add the database to a failover group.
+     - The ability to [convert a geo-replicated non-Hyperscale database to Hyperscale](#convert-database-with-geo-replicas-preview) using T-SQL, REST API, PowerShell, or Azure CLI is currently a [preview feature](#convert-database-with-geo-replicas-preview).
+- Direct conversion from the Basic service tier to Hyperscale is not supported. To perform this conversion, first change the database to any service tier other than Basic (for example, General Purpose), and then proceed with the conversion to Hyperscale.  
+- You can monitor the progress of the conversion with T-SQL. To run T-SQL commands on your Azure SQL Database, use [SQL Server Management Studio (SSMS)](https://aka.ms/ssms), the [MSSQL extension for Visual Studio Code](/sql/tools/visual-studio-code-extensions/mssql/mssql-extension-visual-studio-code), [sqlcmd](/sql/tools/sqlcmd/sqlcmd-utility), or your favorite T-SQL querying tool.
+
+### Convert database with geo-replicas (preview)
+
+The ability to convert a [geo-replicated](active-geo-replication-overview.md) non-Hyperscale database to Hyperscale using T-SQL, REST API, PowerShell, or Azure CLI is currently a preview feature. For more information, see [Blog: Hyperscale conversion support for geo-replicas](https://aka.ms/hs-conversion-geodr-preview).
+
+- Conversion to Hyperscale must be initiated from the primary geo-replica. 
+- The number of geo-secondary replicas should be reduced to one because Hyperscale doesn't support more than one geo-secondary.
+- Creating geo-replica of a geo-replica (also known as "geo-replica chaining") isn't supported in Hyperscale. If a chained geo-replication configuration exists, it must be removed before starting the conversion to Hyperscale.
+- A planned failover isn't possible while the conversion of the geo-primary database to Hyperscale is in progress. A forced failover to a geo-secondary replica is possible. However, depending on the state of the conversion when the forced failover occurs, the new geo-primary after failover might use either the Hyperscale service tier, or its original service tier.
+If a geo-primary database is in an elastic pool, it can be moved to an existing Hyperscale elastic pool as part of the conversion or can be made a standalone Hyperscale database. However, if a geo-secondary database is in an elastic pool, conversion to Hyperscale always moves it out of the pool. You can move the geo-secondary database to a Hyperscale elastic pool in a separate step once conversion completes.
+
 ## Cutover
 
 The conversion process is divided into two stages - the conversion of database, which occurs while the existing database is online, and then a cutover to the new Hyperscale database. 
 
 - The time required to move an existing database to Hyperscale consists of the time to copy data and the time to replay the changes made in the source database while copying data. The data copy time is proportional to data size. We recommend converting to Hyperscale during a lower write activity period so that the time to replay accumulated changes is shorter.
 - You have the ability to choose when the cutover occurs - as soon as the database is ready, or manually at a time of your choosing. By default, the process to convert to Hyperscale will cutover automatically.
     - If you choose to manually cutover at a time of your choosing, you have 24 hours to initiate a manual cutover after the point when the database ready for cutover. You can initiate a manual cutover via the Azure portal, Azure CLI, PowerShell, or T-SQL.
-- During the final cutover to Hyperscale, your applications will only experience a short period of downtime, generally less than a minute.
-
-## Prerequisites
-
-To convert a database that is a part of a [geo-replication](active-geo-replication-overview.md) relationship, either as the primary or as a secondary, to Hyperscale, you need to first terminate geo-replication between the primary and secondary replica. Databases in a [failover group](failover-group-sql-db.md) must be removed from the group first.
-
-Once a database has been moved to Hyperscale, you can create a new Hyperscale geo-replica for that database or add the database to a failover group.
-
-Direct conversion from the Basic service tier to Hyperscale is not supported. To perform this conversion, first change the database to any service tier other than Basic (for example, General Purpose), and then proceed with the conversion to Hyperscale.  
+- During the final cutover to Hyperscale, your applications only experience a short period of downtime, usually less than a minute.
 
 ## Convert a database to Hyperscale
 
@@ -108,7 +119,7 @@ databaseName="mySampleDatabase"
 az sql db op list -g $resourceGroupName -s $serverName -n $databaseName
 ```
 
-Use `--perform-cutover` to initiate the cutover (within 3 days) once the Hyperscale database is ready:
+Use `--perform-cutover` to initiate the cutover (within 24 hours) once the Hyperscale database is ready:
 
 ```azurecli-interactive
 az sql db update -g $resourceGroupName -s $serverName -n $databaseName --perform-cutover
@@ -177,7 +188,7 @@ Set-AzSqlDatabase -ResourceGroupName $resourceGroupName `
 
 # [Transact-SQL](#tab/t-sql)
 
-To convert an existing Azure SQL Database to Hyperscale with Transact-SQL, first connect to the `master` database on your [logical SQL server](logical-servers.md) using the [Azure portal Query editor for Azure SQL Database](query-editor.md), [SQL Server Management Studio (SSMS)](/sql/ssms/download-sql-server-management-studio-ssms), or [the mssql extension for Visual Studio Code](/sql/tools/visual-studio-code-extensions/mssql/mssql-extension-visual-studio-code).
+To convert an existing Azure SQL Database to Hyperscale with Transact-SQL, first connect to the `master` database on your [logical SQL server](logical-servers.md) using [SQL Server Management Studio (SSMS)](/sql/ssms/download-sql-server-management-studio-ssms) or [the mssql extension for Visual Studio Code](/sql/tools/visual-studio-code-extensions/mssql/mssql-extension-visual-studio-code).
 
 You must specify both the edition and service objective in the [ALTER DATABASE](/sql/t-sql/statements/alter-database-transact-sql?view=azuresqldb-current&preserve-view=true) statement.
 
@@ -197,14 +208,15 @@ ALTER DATABASE [mySampleDatabase]
    WITH MANUAL_CUTOVER;
 ```
 
-To monitor operations for a Hyperscale database, connect to the `master` database of your [logical server](logical-servers.md) and query [sys.dm_operation_status](/sql/relational-databases/system-dynamic-management-views/sys-dm-operation-status-azure-sql-database?view=azuresqldb-current&preserve-view=true). The `sys.dm_operation_status` makes reports the progress of database operations including the conversion to Hyperscale. If you chose `MANUAL_CUTOVER`, the `sys.dm_operation_status` view includes additional information.
+To monitor all operations for a Hyperscale database, including the conversion to Hyperscale, connect to the `master` database of your geo-primary [logical server](logical-servers.md) and execute T-SQL queries on the [sys.dm_operation_status](/sql/relational-databases/system-dynamic-management-views/sys-dm-operation-status-azure-sql-database?view=azuresqldb-current&preserve-view=true) dynamic management view. The `sys.dm_operation_status` makes reports the progress of database operations including the conversion to Hyperscale. If you chose `MANUAL_CUTOVER`, the `sys.dm_operation_status` view includes additional information.
+
+For example,
 
 ```sql
 SELECT *
 FROM sys.dm_operation_status
 WHERE major_resource_id = 'mySampleDatabase'
 ORDER BY start_time DESC;
-GO
 ```
 
 When ready for manual cutover, the `phase_desc` will be `WaitingForCutover`. Use the `PERFORM_CUTOVER` argument to initiate the cutover:
@@ -218,4 +230,4 @@ ALTER DATABASE [mySampleDatabase] PERFORM_CUTOVER;
 ## Related content
 
 - [How to manage a Hyperscale database](manage-hyperscale-database.md)
-- [How to reverse migrate a database from Hyperscale](reverse-migrate-from-hyperscale.md)
+- [Reverse migrate a database from Hyperscale](reverse-migrate-from-hyperscale.md)

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

@@ -5,7 +5,7 @@ description: Learn about the new features and documentation improvements for Azu
 author: WilliamDAssafMSFT
 ms.author: wiassaf
 ms.reviewer: mathoma, randolphwest
-ms.date: 06/17/2025
+ms.date: 07/02/2025
 ms.service: azure-sql-database
 ms.subservice: service-overview
 ms.topic: whats-new
@@ -43,6 +43,7 @@ The following table lists the features of Azure SQL Database that are currently
 | **ABORT_QUERY_EXECUTION** | The new `ABORT_QUERY_EXECUTION` [query hint](/sql/t-sql/queries/hints-transact-sql-query?view=azuresqldb-current&preserve-view=true#use_hint_abort_query_execution), currently in preview, can block future execution of known problematic queries, for example nonessential queries causing high resource consumption and impacting critical application workloads. For more information, see [Query Store hints: Block future execution of problematic queries](/sql/relational-databases/performance/query-store-hints-best-practices?view=azuresqldb-current&preserve-view=true#block-future-execution-of-problematic-queries).|
 | **Approximate or fuzzy string matching**| Check if two strings are similar, and calculate the difference between two strings. Use this capability to identify strings that might be different because of character corruption. [What is fuzzy string matching?](/sql/relational-databases/fuzzy-string-match/overview)|
 | **Availability metric**| Availability is now a metric in the Azure Monitor metrics. Driven by a variety of user connection failures, you can [monitor and configure alerts on Azure SQL Database Availability](monitoring-metrics-alerts.md#availability-metric). |
+| **Convert to Hyperscale with geo-replicas (preview)** |The ability to [convert a geo-replicated database non-Hyperscale database to Hyperscale](convert-to-hyperscale.md) using T-SQL, REST API, PowerShell, or Azure CLI is currently a preview feature. For more information, see [Blog: Hyperscale conversion support for geo-replicas](https://aka.ms/hs-conversion-geodr-preview). |
 | **DATEADD number allows bigint** | For `DATEADD (datepart , number , date )`, number can be expressed as a **bigint**. For more information, see [DATEADD (Transact-SQL)](/sql/t-sql/functions/dateadd-transact-sql).|
 | **Database watcher for Azure SQL** |[Database watcher](../database-watcher-overview.md) is a managed monitoring solution for database services in the Azure SQL family. Database watcher collects in-depth workload monitoring data to give you a detailed view of database performance, configuration, and health. Learn more about [database watcher](https://aka.ms/dbwatcher-preview-announcement). |
 | **Data Virtualization for Azure SQL Database** |Data virtualization, now in preview in Azure SQL Database, enables you to leverage all the power of Transact-SQL (T-SQL) and seamlessly query external data from Azure Data Lake Storage Gen2 or Azure Blob Storage. For more information, see [Data virtualization with Azure SQL Database (Preview)](data-virtualization-overview.md).|
@@ -96,6 +97,12 @@ The following table lists features of Azure SQL Database that have been made gen
 
 Learn about significant changes to the Azure SQL Database documentation. For previous years, see the [What's new archive](doc-changes-updates-release-notes-whats-new-archive.md).
 
+### July 2025
+
+| Changes | Details |
+| --- | --- |
+| **Convert to Hyperscale with geo-replicas (preview)** |The ability to [convert a geo-replicated database non-Hyperscale database to Hyperscale](convert-to-hyperscale.md) using T-SQL, REST API, PowerShell, or Azure CLI is currently a preview feature. For more information, see [Blog: Hyperscale conversion support for geo-replicas](https://aka.ms/hs-conversion-geodr-preview). |
+
 ### June 2025
 
 | Changes | Details |

azure-sql/database/firewall-configure.md

@@ -26,7 +26,7 @@ When you create a new server in Azure SQL Database or Azure Synapse Analytics na
 
 Connection attempts from the internet and Azure must pass through the firewall before they reach your server or database, as the following diagram shows.
 
-   ![Firewall configuration diagram][1]
+:::image type="content" source="media/firewall-configure/sqldb-firewall-1.png" alt-text="Diagram of the Azure SQL Database firewall.":::
 
 > [!IMPORTANT]  
 > Azure Synapse only supports server-level IP firewall rules. It doesn't support database-level IP firewall rules.

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, randolphwest
-ms.date: 07/22/2024
+ms.date: 06/30/2025
 ms.service: azure-sql-database
 ms.subservice: service-overview
 ms.topic: upgrade-and-migration-article
@@ -17,7 +17,7 @@ This article describes how to migrate your database in Azure SQL Database from t
 
 ## Migrate a database
 
-Migrating a database from the DTU-based purchasing model to the vCore-based purchasing model is similar to scaling between service objectives in the Basic, Standard, and Premium service tiers, with similar [duration](single-database-scale.md#latency) and a [minimal downtime](scale-resources.md) at the end of the migration process. A database migrated to the vCore-based purchasing model can be migrated back to the DTU-based purchasing model at any time using the same steps, except for databases migrated to the [Hyperscale](service-tier-hyperscale.md) service tier.
+Migrating a database from the DTU-based purchasing model to the vCore-based purchasing model is similar to scaling between service objectives in the Basic, Standard, and Premium service tiers, with similar [duration](single-database-scale.md#latency) and a [minimal downtime](scale-resources.md) at the end of the migration process. A database migrated to the vCore-based purchasing model can be migrated back to the DTU-based purchasing model at any time using the same steps, except for databases migrated to the [Hyperscale service tier](service-tier-hyperscale.md).
 
 You can migrate your database to a different purchasing model by using the Azure portal, PowerShell, the Azure CLI, and Transact-SQL.
 
@@ -67,7 +67,7 @@ ALTER DATABASE <database name> MODIFY (EDITION = '<service tier, such as Hypersc
 
 ## Choose the vCore service tier and service objective
 
-For most DTU to vCore migration scenarios, databases and elastic pools in the Basic and Standard service tiers map to the [General Purpose](service-tiers-sql-database-vcore.md#general-purpose) service tier. Databases and elastic pools in the Premium service tier map to the [Business Critical](service-tiers-sql-database-vcore.md#business-critical) service tier. Depending on application scenario and requirements, the [Hyperscale](service-tier-hyperscale.md) service tier can often be used as the migration target for databases and elastic pools in all DTU service tiers.
+For most DTU to vCore migration scenarios, databases and elastic pools in the Basic and Standard service tiers map to the [General Purpose](service-tiers-sql-database-vcore.md#general-purpose) service tier. Databases and elastic pools in the Premium service tier map to the [Business Critical](service-tiers-sql-database-vcore.md#business-critical) service tier. Depending on application scenario and requirements, the [Hyperscale service tier](service-tier-hyperscale.md) can often be used as the migration target for databases and elastic pools in all DTU service tiers.
 
 To choose the service objective, or compute size, for the migrated database in the vCore model, you can use a basic but approximate rule of thumb: every 100 DTUs in the Basic or Standard tiers require *at least* 1 vCore, and every 125 DTUs in the Premium tier require *at least* 1 vCore.
 
@@ -188,7 +188,7 @@ The mapping query returns the following result (some columns not shown for brevi
 | --- | --- | --- | --- | --- | --- | --- |
 | 0.25 | 1.3 | 0.500 | 5.05 |
 
-We see that the DTU database has the equivalent of 0.25 logical CPUs (vCores), with 1.3 GB of memory per vCore. The smallest vCore service objectives in the standard-series (Gen5) hardware configuration, **GP_Gen5_2**, provides more compute resources than the Standard S0 database, so a direct match isn't possible. The **GP_Gen5_2** option is preferred. Additionally, if the workload is well-suited for the [Serverless](serverless-tier-overview.md) compute tier, then **GP_S_Gen5_1** would be a closer match.
+We see that the DTU database has the equivalent of 0.25 logical CPUs (vCores), with 1.3 GB of memory per vCore. The smallest vCore service objectives in the standard-series (Gen5) hardware configuration, **GP_Gen5_2**, provides more compute resources than the Standard S0 database, so a direct match isn't possible. The **GP_Gen5_2** option is preferred. Additionally, if the workload is well-suited for the [Serverless compute tier](serverless-tier-overview.md), then **GP_S_Gen5_1** would be a closer match.
 
 **Migrating a Premium P15 database**
 
@@ -217,7 +217,7 @@ Migrating from the DTU-based model to the vCore-based purchasing model is simila
 - When upgrading, you must upgrade the secondary database first, and then upgrade the primary.
 - When downgrading, reverse the order: you must downgrade the primary database first, and then downgrade the secondary.
 
-To convert a database to the Hyperscale service tier, geo-replication should be temporarily removed. For more information, see [Convert an existing database to Hyperscale](convert-to-hyperscale.md).
+To convert a database to the Hyperscale service tier, geo-replication should be temporarily removed. The ability to convert a geo-replicated database non-Hyperscale database to Hyperscale using T-SQL, REST API, PowerShell, or Azure CLI is currently a preview feature. For more information, see [Convert an existing database to Hyperscale](convert-to-hyperscale.md).
 
 When you use geo-replication between two elastic pools, we recommend that you designate one pool as the primary and the other as the secondary. In that case, when you migrate elastic pools you should use the same sequencing guidance. However, if you have elastic pools that contain both primary and secondary databases, treat the pool with the higher utilization as the primary and follow the sequencing rules accordingly.