Merge pull request #84669 from MicrosoftDocs/repo_sync_working_branch

Confirm merge from repo_sync_working_branch to master to sync with https://github.com/Microsoft/azure-docs (branch master)

Author: huypub

articles/api-management/api-management-sample-flexible-throttling.md

@@ -26,7 +26,7 @@ To date, the rate throttling capabilities have been limited to being scoped to a
 ## Custom key based throttling
 
 > NOTE:
-> The `rate-limit-by-key` policy is not available when in the Consumption tier of Azure API Management. 
+> The `rate-limit-by-key` and `quota-by-key` policies are not available when in the Consumption tier of Azure API Management. 
 
 The new [rate-limit-by-key](/azure/api-management/api-management-access-restriction-policies#LimitCallRateByKey) and [quota-by-key](/azure/api-management/api-management-access-restriction-policies#SetUsageQuotaByKey) policies provide a more flexible solution to traffic control. These new policies allow you to define expressions to identify the keys that are used to track traffic usage. The way this works is easiest illustrated with an example. 
 

articles/azure-resource-manager/authenticate-multi-tenant.md

@@ -19,7 +19,7 @@ The request has the following authentication header values:
 | Header name | Description | Example value |
 | ----------- | ----------- | ------------ |
 | Authorization | Primary token | Bearer <primary-token> |
-| x-ms-authorization-auxiliary | Auxiliary tokens | Bearer <auxiliary-token1>; EncryptedBearer <auxiliary-token2>; Bearer <auxiliary-token3> |
+| x-ms-authorization-auxiliary | Auxiliary tokens | Bearer <auxiliary-token1>, EncryptedBearer <auxiliary-token2>, Bearer <auxiliary-token3> |
 
 The auxiliary header can hold up to three auxiliary tokens. 
 

articles/sql-database/sql-database-paas-vs-sql-server-iaas.md

@@ -29,7 +29,7 @@ The main differences between these options are listed in the following table:
 
 | SQL Server on VM | Managed instance in SQL Database | Single database / elastic pool in SQL Database |
 | --- | --- | --- |
-|You have full control over the SQL Server engine.<br/>Up to 99.95% availability.<br/>Full parity with the matching version of on-premises SQL Server.<br/>Fixed, well-known database engine version.<br/>Easy migration from SQL Server on-premises.<br/>Private IP address within Azure VNet.<br/>You have ability to deploy application or services on the host where SQL Server is placed.| High compatibility with SQL Server on-premises.<br/>99.99% availability guaranteed.<br/>Built-in backups, patching, recovery.<br/>Latest stable Database Engine version.<br/>Easy migration from SQL Server.<br/>Private IP address within Azure VNet.<br/>Built-in advanced intelligence and security.<br/>Online change of resources (CPU/storage).|The most commonly used SQL Server features are available.<br/>99.99% availability guaranteed.<br/>Built-in backups, patching, recovery.<br/>Latest stable Database Engine version.<br/>Ability to assign necessary resources (CPU/storage) to individual databases.<br/>Built-in advanced intelligence and security.<br/>Online change of resources (CPU/storage).|
+|You have full control over the SQL Server engine.<br/>Up to 99.99% availability.<br/>Full parity with the matching version of on-premises SQL Server.<br/>Fixed, well-known database engine version.<br/>Easy migration from SQL Server on-premises.<br/>Private IP address within Azure VNet.<br/>You have ability to deploy application or services on the host where SQL Server is placed.| High compatibility with SQL Server on-premises.<br/>99.99% availability guaranteed.<br/>Built-in backups, patching, recovery.<br/>Latest stable Database Engine version.<br/>Easy migration from SQL Server.<br/>Private IP address within Azure VNet.<br/>Built-in advanced intelligence and security.<br/>Online change of resources (CPU/storage).|The most commonly used SQL Server features are available.<br/>99.99% availability guaranteed.<br/>Built-in backups, patching, recovery.<br/>Latest stable Database Engine version.<br/>Ability to assign necessary resources (CPU/storage) to individual databases.<br/>Built-in advanced intelligence and security.<br/>Online change of resources (CPU/storage).|
 |You need to manage your backups and patches.<br>You need to implement your own High-Availability solution.<br/>There is a downtime while changing the resources(CPU/storage)|There is still some minimal number of SQL Server features that are not available.<br/>No guaranteed exact maintenance time (but nearly transparent).<br/>Compatibility with the SQL Server version can be achieved only using database compatibility levels.|Migration from SQL Server might be hard.<br/>Some SQL Server features are not available.<br/>No guaranteed exact maintenance time (but nearly transparent).<br/>Compatibility with the SQL Server version can be achieved only using database compatibility levels.<br/>Private IP address cannot be assigned (you can limit the access using firewall rules).|
 
 Learn how each deployment option fits into the Microsoft data platform and get help matching the right option to your business requirements. Whether you prioritize cost savings or minimal administration ahead of everything else, this article can help you decide which approach delivers against the business requirements you care about most.
@@ -70,7 +70,7 @@ The following table summarizes the main characteristics of SQL Database and SQL
 | **Best for:** |New cloud-designed applications that want to use the latest stable SQL Server features and have time constraints in development and marketing. | New applications or existing on-premises applications that want to use the latest stable SQL Server features and that are migrated to the cloud with minimal changes.  | Existing applications that require fast migration to the cloud with minimal changes or no changes. Rapid development and test scenarios when you do not want to buy on-premises non-production SQL Server hardware. |
 |  | Teams that need built-in high availability, disaster recovery, and upgrade for the database. | Same as SQL Database single and pooled databases. | Teams that can configure, fine tune, customize, and manage high availability, disaster recovery, and patching for SQL Server. Some provided automated features dramatically simplify this. |
 |  | Teams that do not want to manage the underlying operating system and configuration settings. | Same as SQL Database single and pooled databases. | You need a customized environment with full administrative rights. |
-|  | Databases of up to 100 TB. | Up to 8 TB. | SQL Server instances with up to 64 TB of storage. The instance can support as many databases as needed. |
+|  | Databases of up to 100 TB. | Up to 8 TB. | SQL Server instances with up to 256 TB of storage. The instance can support as many databases as needed. |
 | **Compatibility** | Supports most on-premises database-level capabilities. | Supports almost all on-premises instance-level and database-level capabilities. | Supports all on-premises capabilities. |
 | **Resources:** | You do not want to employ IT resources for configuration and management of the underlying infrastructure but want to focus on the application layer. | Same as SQL Database single and pooled databases. | You have some IT resources for configuration and management. Some provided automated features dramatically simplify this. |
 | **Total cost of ownership:** | Eliminates hardware costs and reduces administrative costs. | Same as SQL Database single and pooled databases. | Eliminates hardware costs. |
@@ -85,7 +85,7 @@ There are several factors that can influence your decision to choose PaaS or Iaa
 
 - [Cost](#cost) - Both PaaS and IaaS option include base price that cover underlying infrastructure and licensing. However, with IaaS option you need to invest additional time and resources to manage your database, while in PaaS you are getting these administration features included in the price. IaaS option enables you to shut-down your resources while you are not using them to decrease the cost, while PaaS version is always running unless if you drop and re-create your resources when they are needed.
 - [Administration](#administration) - PaaS options reduce the amount of time that you need to invest to administer the database. However, it also limits the range of custom administration tasks and scripts that you can perform or run. For example, the CLR is not supported with single or pooled databases, but is supported for a managed instance. Also, no deployment options in PaaS support the use of trace flags.
-- [Service-Level Agreement](#service-level-agreement-sla) - Both IaaS and PaaS provide high, industry standard SLA. PaaS option guarantees 99.99% SLA, while IaaS guarantees 99.95% SLA for infrastructure, meaning that you need to implement additional mechanisms to ensure availability of your databases. In the extreme case, if you want to implement High-availability solution that is matching PaaS, you might need to create additional SQL Server in VM and configure AlwaysOn Availability groups, which might double the cost of your database.
+- [Service-Level Agreement](#service-level-agreement-sla) - Both IaaS and PaaS provide high, industry standard SLA. PaaS option guarantees 99.99% SLA, while IaaS guarantees 99.95% SLA for infrastructure, meaning that you need to implement additional mechanisms to ensure availability of your databases. You can implement High-availability solution at 99.99% by creating an additional SQL Server in VM and configure AlwaysOn Availability groups.
 - [Time to move to Azure](#market) - SQL Server in Azure VM is the exact match of your environment, so migration from on-premises to Azure SQL VM is not different than moving the databases from one on-premises server to another. Managed instance also enables extremely easy migration; however, there might be some changes that you need to apply before you migrate to a managed instance.
 
 These factors will be discussed in more details in the following sections.
@@ -160,4 +160,4 @@ For **SQL Server running on Azure VMs**, Microsoft provides an availability SLA
 - See [Your first Azure SQL Database](sql-database-single-database-get-started.md) to get started with SQL Database.
 - See [SQL Database pricing](https://azure.microsoft.com/pricing/details/sql-database/).
 - See [Provision a SQL Server virtual machine in Azure](../virtual-machines/windows/sql/virtual-machines-windows-portal-sql-server-provision.md) to get started with SQL Server on Azure VMs.
-- [Identify the right Azure SQL Database/Managed Instance SKU for your on-premises database](/sql/dma/dma-sku-recommend-sql-db/).
+- [Identify the right Azure SQL Database/Managed Instance SKU for your on-premises database](/sql/dma/dma-sku-recommend-sql-db/).

articles/sql-database/sql-database-service-tier-hyperscale-faq.md

@@ -38,7 +38,7 @@ The vCore-based service tiers are primarily differentiated based upon availabili
 - The Business Critical service tier is appropriate for business workloads where IO latency is a priority.
 
 | | Resource type | General Purpose |  Hyperscale | Business Critical |
-|:---|:---:|:---:|:---:|:---:|:---:|
+|:---:|:---:|:---:|:---:|:---:|
 | **Best for** |All|  Most business workloads. Offers budget oriented balanced compute and storage options. | Data applications with large data capacity requirements and the ability to auto-scale storage and scale compute fluidly. | OLTP applications with high transaction rate and lowest latency IO. Offers highest resilience to failures using several, isolated replicas.|
 |  **Resource type** ||Single database / elastic pool / managed instance | Single database | Single database / elastic pool / managed instance |
 | **Compute size**|Single database / elastic pool * | 1 to 80 vCores | 1 to 80  vCores* | 1 to 80 vCores |
@@ -49,7 +49,7 @@ The vCore-based service tiers are primarily differentiated based upon availabili
 | **IO throughput** | Single database** | 500 IOPS per vCore with 7000 maximum IOPS | Hyperscale is a multi-tiered architecture with caching at multiple levels. Effective IOPs will depend on the workload. | 5000 IOPS with 200,000 maximum IOPS|
 | | Managed instance | Depends on size of file | N/A | Managed Instance: Depends on size of file|
 |**Availability**|All|1 replica, no read-scale, no local cache | Multiple replicas, up to 15 read-scale, partial local cache | 3 replicas, 1 read-scale, zone-redundant HA, full local cache |
-|**Backups**|All|RA-GRS, 7-35 days (7 days by default)| RA-GRS, 7-35 days (7 days by default), constant time point-in-time recovery (PITR) | RA-GRS, 7-35 days (7 days by default) |
+|**Backups**|All|RA-GRS, 7-35 days (7 days by default)| RA-GRS, 7 days, constant time point-in-time recovery (PITR) | RA-GRS, 7-35 days (7 days by default) |
 
 \* Elastic pools not supported in the Hyperscale service tier