Merge pull request #260929 from deborahc/dech-elasticity-updates-dec2023

Updates to elasticity docs

Author: v-dirichards

articles/cosmos-db/hierarchical-partition-keys.md

@@ -585,6 +585,7 @@ while (queryIterator.hasMoreResults()) {
 - You can specify hierarchical partition keys only up to three layers in depth.
 - Hierarchical partition keys can currently be enabled only on new containers. You must set partition key paths at the time of container creation, and you can't change them later. To use hierarchical partitions on existing containers, create a new container with the hierarchical partition keys set and move the data by using [container copy jobs](container-copy.md).
 - Hierarchical partition keys are currently supported only for the API for NoSQL accounts. The APIs for MongoDB and Cassandra aren't currently supported.
+- Hierarchical partition keys aren't currently supported with the [Permissions feature](secure-access-to-data.md#permissions). You can't assign a permission to a partial prefix of the hierarchical partition key path. Permissions can only be assigned to the entire logical partition key path. For example, if you have partitioned by ``TenantId`` - > ``UserId``, you can't assign a permission that is for a specific value of ``TenantId``. However, you can assign a permission for a partition key if you specify both the value for ``TenantId`` and ``UserId```.
 
 ## Next steps
 

articles/cosmos-db/merge.md

@@ -183,7 +183,7 @@ az cosmosdb mongodb collection merge \
 
 Partition merge is a long-running operation and there's no SLA on how long it takes to complete. The time depends on the amount of data in the container and the number of physical partitions. It's recommended to allow at least 5-6 hours for merge to complete.
 
-While partition merge is running on your container, it isn't possible to change the throughput or any container settings (TTL, indexing policy, unique keys, etc.). Wait until the merge operation completes before changing your container settings.
+While partition merge is running on your container, if you change container settings (TTL, indexing policy, unique keys, etc.), the ongoing merge operation will be cancelled. If you increase your RU/s while a merge is running, the ongoing merge operation will be cancelled and your container's RU/s will be updated with your new value. Depending on the RU/s requested, your [scale-up may be instant or take longer](scaling-provisioned-throughput-best-practices.md#step-2-calculate-the-default-maximum-throughput). If you decrease your RU/s while a merge is running, the RU/s will be instantly updated to the new RU/s. The in-progress merge will continue, with the same target partition count based on the RU/s set at the time the merge was triggered. As a best practice, it is recommended to wait until the merge operation completes before changing your container or throughput settings. 
 
 You can track whether merge is still in progress by checking the **Activity Log** and filtering for the events **Merge the physical partitions of a MongoDB collection** or **Merge the physical partitions of a SQL container**.
 

articles/cosmos-db/monitor-reference.md

@@ -34,6 +34,8 @@ All the metrics corresponding to Azure Cosmos DB are stored in the namespace **A
 | MongoRequestCharge (Mongo Request Charge) | Count (Total) |Mongo Request Units Consumed| DatabaseName, CollectionName, Region, CommandName, ErrorCode| All |Mongo Query Request Charge, Mongo Update Request Charge, Mongo Delete Request Charge, Mongo Insert Request Charge, Mongo Count Request Charge| Used to monitor Mongo resource RUs in a minute.|
 | TotalRequestUnits (Total Request Units)| Count (Total) | Request Units consumed| DatabaseName, CollectionName, Region, StatusCode |All| TotalRequestUnits| Used to monitor Total RU usage at a minute granularity. To get average RU consumed per second, use Sum aggregation at minute interval/level and divide by 60.|
 | ProvisionedThroughput (Provisioned Throughput)| Count (Maximum) |Provisioned throughput at container granularity| DatabaseName, ContainerName| 5M| | Used to monitor provisioned throughput per container.|
+| AutoscaleMaxThroughput (Autoscale Max Throughput)| Count (Maximum) |Autoscale max throughput at container granularity| DatabaseName, ContainerName| 5M| | Used to monitor autoscale max throughput per container.|
+| PhysicalPartitionThroughputInfo (Physical Partition Throughput Info)| Count (Maximum) |Provisioned throughput at physical partition granularity| DatabaseName, ContainerName, PhysicalPartitionId, Region| 5M| | Used to monitor provisioned throughput per physical partition. If resource is autoscale, represents autoscale max RU/s per physical partition. To see provisioned throughput for all physical partitions, split by dimension Physical Partition Id.|
 
 ### Storage metrics
 
@@ -44,6 +46,7 @@ All the metrics corresponding to Azure Cosmos DB are stored in the namespace **A
 | IndexUsage (Index Usage) | Bytes (Total) |Total Index usage reported at 5-minutes granularity per region| DatabaseName, CollectionName, Region| 5M| Index Size| Used to monitor total data usage at container and region, minimum granularity should be 5 minutes. |
 | DocumentQuota (Document Quota) | Bytes (Total) | Total storage quota reported at 5-minutes granularity per region.| DatabaseName, CollectionName, Region| 5M |Storage Capacity| Used to monitor total quota at container and region, minimum granularity should be 5 minutes.|
 | DocumentCount (Document Count) | Count (Total) |Total document count reported at 5-minutes granularity per region| DatabaseName, CollectionName, Region| 5M |Document Count|Used to monitor document count at container and region, minimum granularity should be 5 minutes.|
+| PhysicalPartitionSizeInfo (Physical Partition Size Info) | Count (Maximum) | Storage at physical partition granularity| DatabaseName, ContainerName, PhysicalPartitionId, Region| 5M | |Used to monitor physical partition size (bytes) at physical partition granularity. To see storage for all physical partitions, split by dimension Physical Partition Id.|
 
 ### Latency metrics
 

articles/cosmos-db/nosql/distribute-throughput-across-partitions-faq.yml

@@ -8,7 +8,7 @@ metadata:
   ms.custom: event-tier1-build-2022
   ms.topic: faq
   ms.reviewer: dech
-  ms.date: 05/09/2022
+  ms.date: 12/18/2023
 title: Frequently asked questions on distributing throughput across partitions in Azure Cosmos DB (preview)
 summary: |
   [!INCLUDE[NoSQL, MongoDB](../includes/appliesto-nosql-mongodb.md)]
@@ -21,11 +21,15 @@ sections:
       - question: |
           What resources can I use this feature on?
         answer: |
-          The feature is only supported for SQL and API for MongoDB accounts and on collections with dedicated throughput (either manual or autoscale). Shared throughput databases aren't supported in the preview. The feature doesn't apply to serverless accounts.
+          The feature is only supported for SQL and API for MongoDB accounts. It is supported for shared throughput databases and containers/collections with dedicated throughput (either manual or autoscale). The feature doesn't apply to serverless accounts.
       - question: |
-          Which version of the Azure Cosmos DB functionality in Azure PowerShell supports this feature?
+          How do I enroll in the preview feature?
         answer: |
-          The ability to redistribute RU/s across physical partitions is only supported in the latest preview version of Azure PowerShell.
+          You don't have to enroll in the preview. To use the feature, just use the relevant commands in the Azure PowerShell or Azure CLI to redistribute throughput across your resources' physical partitions.
+      - question: |
+          Which version of the Azure Cosmos DB functionality in Azure PowerShell and Azure CLI supports this feature?
+        answer: |
+          The ability to redistribute RU/s across physical partitions is only supported in the  preview version of Azure PowerShell (version 2.0.2-preview or higher)[https://www.powershellgallery.com/packages/Az.CosmosDB/2.0.2-preview] and latest preview version of the Azure CLI.
       - question: |
           What is the maximum number of physical partitions I can change in one request?
         answer: |