Merge pull request #24370 from MicrosoftDocs/main

Sync from main.

Author: MikeRayMSFT

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

@@ -209,7 +209,7 @@ 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). Databases in the Hyperscale service tier don't currently support long-term retention.
+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). 
 
 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. 
 

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

@@ -33,15 +33,16 @@ The following table lists the features of Azure SQL Database that are currently
 | [Elastic jobs](elastic-jobs-overview.md) | The elastic jobs feature is the SQL Server Agent replacement for Azure SQL Database as a PaaS offering.  |
 | [Elastic queries](elastic-query-overview.md) | The elastic queries feature allows for cross-database queries in Azure SQL Database. |
 | [Elastic transactions](elastic-transactions-overview.md) | Elastic transactions allow you to execute transactions distributed among cloud databases in Azure SQL Database. |
-| [Hyperscale short-term retention](hyperscale-automated-backups-overview.md#data-and-backup-storage-redundancy) | Retain backups from 1 up to 35 days for Hyperscale databases, and perform a point-in-time restore within the configured retention period. |
-| [JavaScript & Python bindings](/azure/azure-functions/functions-bindings-azure-sql)| Use JavaScript or Python SQL bindings with Azure Functions. |
+| [Azure SQL Database Hyperscale tier short-term retention](hyperscale-automated-backups-overview.md#data-and-backup-storage-redundancy) | Retain backups from 1 up to 35 days for Hyperscale databases, and perform a point-in-time restore within the configured retention period. |
+| [JavaScript & Python bindings](/azure/azure-functions/functions-bindings-azure-sql)| Use JavaScript or Python SQL bindings with Azure Functions. | 
 | [Maintenance window advance notifications](../database/advance-notifications.md)| Advance notifications are available for databases configured to use a non-default [maintenance window](maintenance-window.md). Advance notifications for maintenance windows are in public preview for Azure SQL Database. |
 | [Query editor in the Azure portal](connect-query-portal.md) | The query editor in the portal allows you to run queries against your Azure SQL Database directly from the [Azure portal](https://portal.azure.com).|
 | [SQL Analytics](/azure/azure-monitor/insights/azure-sql)|Azure SQL Analytics is an advanced cloud monitoring solution for monitoring performance of all of your Azure SQL databases at scale and across multiple subscriptions in a single view. Azure SQL Analytics collects and visualizes key performance metrics with built-in intelligence for performance troubleshooting.|
 | [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.|
-| [UMI for auditing](auditing-overview.md) | Configure the storage account for your SQL auditing logs by using User Managed Identity (UMI). |
+| [UMI for auditing](auditing-overview.md) | Configure the storage account for your SQL auditing logs by using User Managed Identity (UMI). | 
+| [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)
 
@@ -74,6 +75,8 @@ Learn about significant changes to the Azure SQL Database documentation.
 | **Cross-subscription failover group with Azure PowerShell** | It's now possible to deploy your auto-failover group for a single database across subscriptions by using Azure PowerShell. To learn more, review [Configure auto-failover group](auto-failover-group-configure-sql-db.md?view=azuresql&tabs=azure-powershell&pivots=azure-sql-single-db&preserve-view=true#create-failover-group). |
 | **UMI support for auditing preview** | It's now possible to configure the storage account used for SQL auditing logs by using User Managed Identity (UMI). This feature is currently in preview. Review [auditing](auditing-overview.md) to learn more. |
 | Reverse migrate from Hyperscale |  This feature allows customers who have recently migrated an existing database in Azure SQL Database to the Hyperscale service tier to move back in an emergency, 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. [Reverse migration to the General Purpose service tier is now generally available](manage-hyperscale-database.md#reverse-migrate-from-hyperscale).|
+| **Read-Access geo-zone redundant storage(RA-GZRS) option for Hyperscale databases** | It's now possible to choose read access geo-zone-redundancy as backup storage redundancy for Hyperscale databases. To learn more, review [Hyperscale backup storage redundancy](hyperscale-automated-backups-overview.md#data-and-backup-storage-redundancy). |
+| [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
 

azure-sql/database/features-comparison.md

@@ -69,7 +69,7 @@ The following table lists the major features of SQL Server and provides informat
 | [Extended stored procedures](/sql/relational-databases/extended-stored-procedures-programming/creating-extended-stored-procedures) | No | No |
 | [Files and file groups](/sql/relational-databases/databases/database-files-and-filegroups) | Primary file group only | Yes. File paths are automatically assigned and the file location can't be specified in `ALTER DATABASE ADD FILE` [statement](../managed-instance/transact-sql-tsql-differences-sql-server.md#alter-database-statement).  |
 | [Filestream](/sql/relational-databases/blob/filestream-sql-server) | No | [No](../managed-instance/transact-sql-tsql-differences-sql-server.md#filestream-and-filetable) |
-| [Full-text search (FTS)](/sql/relational-databases/search/full-text-search) |  Yes, but third-party word breakers are not supported | Yes, but [third-party word breakers are not supported](../managed-instance/transact-sql-tsql-differences-sql-server.md#full-text-semantic-search) |
+| [Full-text search (FTS)](/sql/relational-databases/search/full-text-search) |  Yes, but third-party filters and word breakers are not supported | Yes, but [third-party filters and word breakers are not supported](../managed-instance/transact-sql-tsql-differences-sql-server.md#full-text-semantic-search) |
 | [Functions](/sql/t-sql/functions/functions) | Most - see individual functions | Yes - see [Stored procedures, functions, triggers differences](../managed-instance/transact-sql-tsql-differences-sql-server.md#stored-procedures-functions-and-triggers) |
 | [In-memory optimization](/sql/relational-databases/in-memory-oltp/in-memory-oltp-in-memory-optimization) | Yes in [Premium and Business Critical service tiers](../in-memory-oltp-overview.md).</br> Limited support for non-persistent In-Memory OLTP objects such as memory-optimized table variables in [Hyperscale service tier](service-tier-hyperscale.md).| Yes in [Business Critical service tier](../managed-instance/sql-managed-instance-paas-overview.md) |
 | [Language elements](/sql/t-sql/language-elements/language-elements-transact-sql) | Most - see individual elements |  Yes - see [T-SQL differences](../managed-instance/transact-sql-tsql-differences-sql-server.md) |

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

@@ -42,10 +42,11 @@ 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. Long-term retention (LTR) policies aren't currently supported.
+Default short-term retention of backups for Hyperscale databases is 7 days.
 
 > [!NOTE]
 > - Short-term retention of backups in the range of 1 to 35 days for Hyperscale databases is now in preview.
+> - Long-term backup retention (LTR) capability for Hyperscale databases is now in preview.
 
 ## Backup scheduling
 
@@ -119,7 +120,13 @@ The following screenshot shows an example cost analysis.
 
 ## Data and backup storage redundancy
 
-Hyperscale supports configurable storage redundancy. When you're creating a Hyperscale database, you can choose your preferred storage type: read-access geo-redundant storage (RA-GRS), zone-redundant storage (ZRS), or locally redundant storage (LRS). The selected storage redundancy option is used for the lifetime of the database for both data storage redundancy and backup storage redundancy. 
+Hyperscale supports configurable storage redundancy. When you're creating a Hyperscale database, you can choose your preferred storage type:  read-access geo-zone-redundant storage (RA-GZRS), read-access geo-redundant storage (RA-GRS), zone-redundant storage (ZRS), or locally redundant storage (LRS). 
+
+- **Geo-zone-redundant storage**: Copies your backups synchronously across three Azure availability zones in the primary region. similar to zone-redundant storage(ZRS).  In addition,copies your data asynchronously three times to a single physical location in the [paired](/azure/availability-zones/cross-region-replication-azure#azure-cross-region-replication-pairings-for-all-geographies) secondary region. It's currently available in only [certain regions](/azure/storage/common/storage-redundancy#geo-zone-redundant-storage).
+
+To learn how the backups are replicated for other storage types, see [backup storage redundancy](automated-backups-overview.md#backup-storage-redundancy)
+
+Since Hyperscale uses storage snapshots for backups, data and backups share the same storage account. As a result the selected backup storage redundancy is applicable for both data and backups. 
 
 Consider backup storage redundancy carefully when you create a Hyperscale database, because you can set it only during database creation. You can't modify this setting after the resource is provisioned. 
 
@@ -128,6 +135,7 @@ Use [active geo-replication](active-geo-replication-overview.md) to update backu
 > [!WARNING]
 > - [Geo-restore](recovery-using-backups.md#geo-restore) is disabled as soon as a database is updated to use locally redundant or zone-redundant storage. 
 > - Zone-redundant storage is currently available in only [certain regions](/azure/storage/common/storage-redundancy#zone-redundant-storage). 
+> - Geo-zone-redundant storage is currently available in only [certain regions](/azure/storage/common/storage-redundancy#geo-zone-redundant-storage). 
 
 ## Restore a Hyperscale database to a different region
 

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

@@ -19,7 +19,8 @@ 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 backup retention for Hyperscale databases is now in preview.
 
 ## How long-term retention works
      

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 is not currently supported. Hyperscale has a snapshot-based backup architecture, different than other service tiers.|
+| Long-term backup retention | Long-term backup retention for Hyperscale databases is now in preview.|
 | 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.|

azure-sql/database/transparent-data-encryption-byok-overview.md

@@ -199,6 +199,26 @@ It may happen that someone with sufficient access rights to the key vault accide
 
 Learn more about [the common causes for database to become inaccessible](/sql/relational-databases/security/encryption/troubleshoot-tde?view=azuresqldb-current&preserve-view=true#common-errors-causing-databases-to-become-inaccessible).
 
+### Blocked connectivity between SQL Managed Instance and Key Vault
+
+On SQL Managed Instance, network errors while trying to access TDE protector in Azure Key Vault may not cause the databases to change its state to *Inaccessible* but will render the instance unavailable afterwards. This happens mostly when the key vault resource exists but it's endpoint cannot be reached from the managed instance. All scenarios where the key vault endpoint can be reached but connection is denied, missing permissions, etc., will cause the databases to change its state to *Inaccessible*.
+
+The most common causes for lack of networking connectivity to Key Vault are:
+
+- Key Vault is exposed via private endpoint and the private IP address of the AKV service is not allowed in the outbound rules of the Network Security Group (NSG) associated with the managed instance subnet.
+- Bad DNS resolution, like when the key vault FQDN is not resolved or resolves to an invalid IP address.
+
+[Test the connectivity](https://techcommunity.microsoft.com/t5/azure-sql-blog/how-to-test-tcp-connectivity-from-a-sql-managed-instance/ba-p/3058458) from Managed Instance to the Key Vault hosting the TDE protector.
+    - The endpoint is your vault FQDN, like *<vault_name>.vault.azure.net* (without the https://).
+    - The port to be tested is 443.
+    - The result for RemoteAddress should exist and be the correct IP address
+    - The result for TCP test should be *TcpTestSucceeded : True*.
+
+In case the test returns *TcpTestSucceeded : False*, review the networking configuration:
+    - Check the resolved IP address, confirm it's valied. A missing value means there's issues with DNS resolution.
+    - Confirm that the network security group on the managed instance has an **outbound** rule that covers the resolved IP address on port 443, especially when the resolved address belongs to the key vault's private endpoint.
+    - Check other networking configurations like route table, existence of virtual appliance and its configuration, etc.
+
 ## Monitoring of the customer-managed TDE
 
 To monitor database state and to enable alerting for loss of TDE protector access, configure the following Azure features:

azure-sql/managed-instance/transact-sql-tsql-differences-sql-server.md

@@ -226,6 +226,7 @@ For more information, see [ALTER DATABASE SET PARTNER and SET WITNESS](/sql/t-sq
 The following limitations apply to `CREATE DATABASE`:
 
 - Files and filegroups can't be defined. 
+- A memory-optimized filegroup and file are automatically added and are called XTP.
 - The `CONTAINMENT` option isn't supported. 
 - `WITH` options aren't supported. 
    > [!TIP]
@@ -242,6 +243,7 @@ Some file properties can't be set or changed:
 
 - A file path can't be specified in the `ALTER DATABASE ADD FILE (FILENAME='path')` T-SQL statement. Remove `FILENAME` from the script because SQL Managed Instance automatically places the files. 
 - A file name can't be changed by using the `ALTER DATABASE` statement.
+- Altering XTP file or filegroup is not allowed.
 
 The following options are set by default and can't be changed:
 

azure-sql/virtual-machines/windows/availability-group-az-commandline-configure.md

@@ -1,8 +1,8 @@
 ---
 title: Configure an availability group (PowerShell & Az CLI)
 description: "Use either PowerShell or the Azure CLI to create the Windows failover cluster, the availability group listener, and the internal load balancer on a SQL Server VM in Azure."
-author: adbadram
-ms.author: adbadram
+author: tarynpratt
+ms.author: tarynpratt
 ms.reviewer: mathoma
 ms.date: 11/10/2021
 ms.service: virtual-machines-sql