Apply suggestions from code review

MashaMSFT · WilliamDAssafMSFT · web-flow · commit cfc8d2b99a56 · 2021-12-09T11:02:33.000-08:00
comitting william's suggestions

Co-authored-by: William Assaf MSFT &lt;wiassaf@microsoft.com&gt;
diff --git a/azure-sql/database/cost-management.md b/azure-sql/database/cost-management.md
@@ -73,7 +73,7 @@ Billing depends on the SKU of your product, the generation hardware of your SKU,
 - And for storage: geo-redundant storage (GRS), locally redundant storage (LRS), and zone-redundant storage (ZRS)
 - It's also possible to have a deprecated SKU from deprecated resource offerings
 
-To learn more, see [service tiers](service-tiers-sql-database-vcore.md#service-tiers). 
+For more information, see [purchasing models](purchasing-models.md). For more information on service tiers, see [DTU service tiers](service-tiers-dtu.md#compare-service-tiers) and [vCore service tiers](service-tiers-sql-database-vcore.md#service-tiers), or the [Hyperscale service tier](service-tier-hyperscale.md).
 
 The following table shows the most common billing meters and their possible SKUs for **single databases**: 
 
diff --git a/azure-sql/database/purchasing-models.md b/azure-sql/database/purchasing-models.md
@@ -1,7 +1,7 @@
 ---
 title: Purchasing models
 titleSuffix: Azure SQL Database 
-description: Learn about the purchasing models that are available for Azure SQL Database and Azure SQL Managed Instance - the vCore purchasing model, and the DTU purchasing model.  
+description: Learn about the purchasing models that are available for Azure SQL Database: the vCore purchasing model and the DTU purchasing model.  
 services: sql-database
 ms.service: sql-database
 ms.subservice: service-overview
@@ -13,8 +13,8 @@ ms.author: kendralittle
 ms.reviewer: mathoma
 ms.date: 12/15/2021
 ---
-# Compare vCore and DTU purchasing models (Azure SQL Database)
-[!INCLUDE[appliesto-sqldb-sqlmi](../includes/appliesto-sqldb.md)]
+# Compare vCore and DTU purchasing models of Azure SQL Database
+[!INCLUDE[appliesto-sqldb](../includes/appliesto-sqldb.md)]
 
 Azure SQL Database lets you easily purchase a fully managed platform as a service (PaaS) database engine that fits your performance and cost needs. Depending on the deployment model you've chosen for Azure SQL Database, you can select the purchasing model that works for you:
 
@@ -64,7 +64,7 @@ The following table and chart compare and contrast the vCore-based and the DTU-b
 |vCore-based|This model allows you to independently choose compute and storage resources. The vCore-based purchasing model also allows you to use [Azure Hybrid Benefit](https://azure.microsoft.com/pricing/hybrid-benefit/) for SQL Server to save costs.|Customers who value flexibility, control, and transparency|
 ||||  
 
-![Pricing model comparison](./media/purchasing-models/pricing-model.png)
+:::image type="content" source="./media/purchasing-models/pricing-model.png" alt-text="Pricing model comparison" lightbox="./media/purchasing-models/pricing-model.png":::
 
 Want to optimize and save on your cloud spending?
 
@@ -92,7 +92,7 @@ Storage costs are calculated differently based on each purchasing model.
 
 ### DTU storage costs
 
-Since storage is included in the price of the DTU, the price of the DTU reflects the storage costs as is calculated by reads and writes. It's possible to add extra storage in the standard and premium tiers. Long-term backup retention is not included, and is billed separately. 
+Since storage is included in the price of the DTU, the price of the DTU reflects the storage costs as is calculated by reads and writes. It's possible to add extra storage in the standard and premium tiers. See the [Azure SQL Database pricing options](https://azure.microsoft.com/pricing/details/sql-database/single/) for details on provisioning extra storage. [Long-term backup retention](long-term-retention-overview.md) is not included, and is billed separately. 
 
 ## vCore storage costs 
 
diff --git a/azure-sql/database/service-tier-business-critical.md b/azure-sql/database/service-tier-business-critical.md
@@ -47,9 +47,9 @@ The key reasons why you should choose business critical service tier instead of
 -    **Long running transactions that modify data**. Transactions that are opened for a longer time prevent log file truncation, which might increase log size and number of [Virtual log files (VLF)](/sql/relational-databases/sql-server-transaction-log-architecture-and-management-guide#physical_arch). High number of VLFs can slow down recovery of database after failover.
 -    **Workload with reporting and analytic queries** that can be redirected to the free-of-charge secondary read-only replica.
 - **Higher resiliency and faster recovery from failures**. In a case of system failure, the database on primary instance will be disabled and one of the secondary replicas will be immediately became new read-write primary database that is ready to process queries. The database engine doesn't need to analyze and redo transactions from the log file and load all data in the memory buffer.
-- **Advanced data corruption protection**. business critical tier leverages database replicas behind-the-scenes for business continuity purposes, and so the service also then leverages automatic page repair, which is the same technology used for SQL Server database [mirroring and availability groups](/sql/sql-server/failover-clusters/automatic-page-repair-availability-groups-database-mirroring). In the event that a replica cannot read a page due to a data integrity issue, a fresh copy of the page will be retrieved from another replica, replacing the unreadable page without data loss or customer downtime. This functionality is applicable in general purpose tier if the database has geo-secondary replica.
-- **Higher availability** - business critical tier in Multi-AZ configuration guarantees 99.995% availability, compared to 99.99% of general purpose tier.
-- **Fast geo-recovery** - business critical tier configured with geo-replication has a guaranteed Recovery point objective (RPO) of 5 sec and Recovery time objective (RTO) of 30 sec for 100% of deployed hours.
+- **Advanced data corruption protection**. The business critical tier leverages database replicas behind-the-scenes for business continuity purposes, and so the service also then leverages automatic page repair, which is the same technology used for SQL Server database [mirroring and availability groups](/sql/sql-server/failover-clusters/automatic-page-repair-availability-groups-database-mirroring). In the event that a replica cannot read a page due to a data integrity issue, a fresh copy of the page will be retrieved from another replica, replacing the unreadable page without data loss or customer downtime. This functionality is applicable in general purpose tier if the database has geo-secondary replica.
+- **Higher availability** - The business critical tier in Multi-AZ configuration guarantees 99.995% availability, compared to 99.99% of general purpose tier.
+- **Fast geo-recovery** - The business critical tier configured with geo-replication has a guaranteed Recovery Point Objective (RPO) of 5 seconds and Recovery Time Objective (RTO) of 30 seconds for 100% of deployed hours.
  
 ## Compare products
 
diff --git a/azure-sql/database/service-tier-general-purpose.md b/azure-sql/database/service-tier-general-purpose.md
@@ -48,8 +48,8 @@ The following table shows resource limits for both Azure SQL Database and Azure
 |:--|:--|:--|
 | **Compute size**| 1 - 80 vCores | 4, 8, 16, 24, 32, 40, 64, 80 vCores| 
 | **Storage type** | Remote storage | Remote storage| 
-| **Database size** | 1 GB - 4 TB | 32 GB – 16 TB |
-| **Storage size** | 1 GB - 4 TB | 32 GB - 16 TB| 
+| **Database size** | 1 GB - 4 TB | 2 GB – 16 TB |
+| **Storage size** | 1 GB - 4 TB | 2 GB - 16 TB| 
 | **Tempdb size** | [32 GB per vCore](resource-limits-vcore-single-databases.md) | [24 GB per vCore](../managed-instance/resource-limits.md#service-tier-characteristics) |
 | **Log write throughput** | Single databases: [4.5 MB/s per vCore (max 50 MB/s)](resource-limits-vcore-single-databases.md) <br> Elastic pools: [6 MB/s per vCore (max 62.5 MB/s)](resource-limits-vcore-elastic-pools.md) | [3 MB/s per vCore (max 22 MB/s)](../managed-instance/resource-limits.md#service-tier-characteristics)|
 | **Availability** | 99.99% | 99.99% |
diff --git a/azure-sql/database/service-tiers-dtu.md b/azure-sql/database/service-tiers-dtu.md
@@ -12,10 +12,10 @@ ms.author: dfurman
 ms.reviewer: kendralittle, mathoma
 ms.date: 12/15/2021
 ---
-# DTU-based purchase model overview 
+# DTU-based purchasing model overview 
 [!INCLUDE[appliesto-sqldb](../includes/appliesto-sqldb.md)]
 
-Service tiers in the DTU-based purchase model are differentiated by a range of compute sizes with a fixed amount of included storage, fixed retention period for backups, and fixed price. All service tiers in the DTU-based purchase model provide flexibility of changing compute sizes with minimal [downtime](https://azure.microsoft.com/support/legal/sla/azure-sql-database); however, there is a switch over period where connectivity is lost to the database for a short amount of time, which can be mitigated using retry logic. Single databases and elastic pools are billed hourly based on service tier and compute size.
+Service tiers in the DTU-based purchasing model are differentiated by a range of compute sizes with a fixed amount of included storage, fixed retention period for backups, and fixed price. All service tiers in the DTU-based purchasing model provide flexibility of changing compute sizes with minimal [downtime](https://azure.microsoft.com/support/legal/sla/azure-sql-database); however, there is a switch over period where connectivity is lost to the database for a short amount of time, which can be mitigated using retry logic. Single databases and elastic pools are billed hourly based on service tier and compute size.
 
 
 > [!NOTE]
diff --git a/azure-sql/database/service-tiers-sql-database-vcore.md b/azure-sql/database/service-tiers-sql-database-vcore.md
@@ -73,7 +73,9 @@ For information on selecting a service tier for your particular workload, see th
 
 Compute tier options in the vCore model include the provisioned and serverless compute tiers.
 
-The **provisioned compute tier** provides a specific amount of compute resources that are continuously provisioned independent of workload activity, and bills for the amount of compute provisioned at a fixed price per hour. The [serverless compute tier](serverless-tier-overview.md) auto-scales compute resources based on workload activity, and bills for the amount of compute used per second.
+- While the **provisioned compute tier** provides a specific amount of compute resources that are continuously provisioned independent of workload activity, the **serverless compute tier** auto-scales compute resources based on workload activity. 
+
+- While the **provisioned compute tier** bills for the amount of compute provisioned at a fixed price per hour, the **serverless compute tier** bills for the amount of compute used, per second.
 
 
 ## Hardware generations
@@ -209,7 +211,7 @@ If you need DC-series in a currently unsupported region, [submit a support ticke
 
 ## Compute and memory 
 
-The following table compares compute and  memroy between the different generations and compute tiers: 
+The following table compares compute and memory between the different generations and compute tiers: 
 
 |Hardware generation  |Compute  |Memory  |
 |:---------|:---------|:---------|
diff --git a/azure-sql/database/service-tiers-vcore.md b/azure-sql/database/service-tiers-vcore.md
@@ -74,7 +74,7 @@ The following factors affect the amount of storage used for data and log files,
 > [!IMPORTANT]
 > In the general purpose and business critical tiers, you are charged for the maximum storage size configured for a database, elastic pool, or managed instance. In the Hyperscale tier, you are charged for the allocated data storage.
 
-To monitor the current allocated and used data storage size in SQL Database, use *allocated_data_storage* and *storage* Azure Monitor [metrics](../../azure-monitor/essentials/metrics-supported.md#microsoftsqlserversdatabases) respectively. To monitor the current allocated and used storage size of individual data and log files in a database using T-SQL, use the [sys.database_files](/sql/relational-databases/system-catalog-views/sys-database-files-transact-sql) view and the [FILEPROPERTY(... , 'SpaceUsed')](/sql/t-sql/functions/fileproperty-transact-sql) function.
+To monitor the current allocated and used data storage size in SQL Database, use the *allocated_data_storage* and *storage* Azure Monitor [metrics](../../azure-monitor/essentials/metrics-supported.md#microsoftsqlserversdatabases) respectively. To monitor the current allocated and used storage size of individual data and log files in a database using T-SQL, use the [sys.database_files](/sql/relational-databases/system-catalog-views/sys-database-files-transact-sql) view and the [FILEPROPERTY(... , 'SpaceUsed')](/sql/t-sql/functions/fileproperty-transact-sql) function.
 
 > [!TIP]
 > Under some circumstances, you may need to shrink a database to reclaim unused space. For more information, see [Manage file space in Azure SQL Database](file-space-manage.md).
diff --git a/azure-sql/managed-instance/doc-changes-updates-release-notes-whats-new.md b/azure-sql/managed-instance/doc-changes-updates-release-notes-whats-new.md
@@ -16,7 +16,7 @@ ms.date: 11/02/2021
 [!INCLUDE[appliesto-sqldb-sqlmi](../includes/appliesto-sqlmi.md)]
 
 > [!div class="op_single_selector"]
-[Azure SQL Database](../database/doc-changes-updates-release-notes-whats-new.md)
+> * [Azure SQL Database](../database/doc-changes-updates-release-notes-whats-new.md)
 > * [Azure SQL Managed Instance](../managed-instance/doc-changes-updates-release-notes-whats-new.md)
 
 This article summarizes the documentation changes associated with new features and improvements in the recent releases of [Azure SQL Managed Instance](https://azure.microsoft.com/updates/?product=sql-database&query=sql%20managed%20instance). To learn more about Azure SQL Managed Instance, see the [overview](sql-managed-instance-paas-overview.md).
diff --git a/azure-sql/managed-instance/resource-limits.md b/azure-sql/managed-instance/resource-limits.md
@@ -124,7 +124,7 @@ Find more information about the [resource limits in SQL Managed Instance pools i
 
 The following factors affect the amount of storage used for data and log files, and apply to general purpose and business critical tiers. 
 
-- Each compute size supports a maximum data size, with a default of 32 GB.
+- Each compute size supports a maximum data size, with a default of 16 GB. For more information on resource limits in Azure SQL Managed Instance, see [resource-limits.md].
 - When you configure maximum data size, an additional 30 percent of storage is automatically added for log files.
 - You can select any maximum data size between 1 GB and the supported storage size maximum, in 1 GB increments.
 - In the general purpose service tier, `tempdb` uses local SSD storage, and this storage cost is included in the vCore price.
