Confirm merge from FromPublicRepo to main to sync with https://github.com/MicrosoftDocs/sql-docs (branch live) (#28718)

learn-build-service-prod[bot] · erikdarlingdata · SalmanAA · web-flow · commit 46b39fe8f9d7 · 2023-10-09T19:59:57.000-06:00
Co-authored-by: Erik Darling &lt;2136037+erikdarlingdata@users.noreply.github.com&gt;
Co-authored-by: Salman Arab Ameri &lt;fanus84@yahoo.com&gt;
Co-authored-by: KoprowskiT &lt;KoprowskiT@users.noreply.github.com&gt;
Co-authored-by: 0x7FFFFFFFFFFFFFFF &lt;39968+0x7FFFFFFFFFFFFFFF@users.noreply.github.com&gt;
Co-authored-by: Randolph West MSFT &lt;97149825+rwestMSFT@users.noreply.github.com&gt;
Co-authored-by: PhilBarry-MSFT &lt;52750646+PhilB-MSFT@users.noreply.github.com&gt;
diff --git a/azure-sql/database/reserved-capacity-overview.md b/azure-sql/database/reserved-capacity-overview.md
@@ -17,9 +17,9 @@ monikerRange: "=azuresql||=azuresql-db||=azuresql-mi"
 
 Save money with Azure SQL Database or SQL Managed Instance by committing to a reservation for compute resources compared to pay-as-you-go prices. With reserved capacity, you make a commitment for SQL Database and/or SQL Managed Instance use for a period of one or three years to get a significant discount on the compute costs. To purchase reserved capacity, you need to specify the Azure region, deployment type, performance tier, and term.
 
-You do not need to assign the reservation to a specific database or managed instance. Matching existing deployments that are already running or ones that are newly deployed automatically get the benefit. Hence, by purchasing a reserved capacity, existing resources infrastructure would not be modified and thus no failover/downtime is triggered on existing resources. By purchasing a reservation, you commit to usage for the compute costs for a period of one or three years. As soon as you buy a reservation, the compute charges that match the reservation attributes are no longer charged at the pay-as-you go rates. 
+You do not need to assign the reservation to a specific database or managed instance. Matching existing deployments that are already running, or ones that are newly deployed automatically, get the benefit. Hence, by purchasing a reserved capacity, existing resources infrastructure would not be modified and thus no failover/downtime is triggered on existing resources. By purchasing a reservation, you commit to usage for the compute costs for a period of one or three years. As soon as you buy a reservation, the compute charges that match the reservation attributes are no longer charged at the pay-as-you-go rates.
 
-A reservation applies to both primary and billable secondary compute replicas, but does not cover software, networking, or storage charges associated with the service. At the end of the reservation term, the billing benefit expires and the database or managed instance is billed at the pay-as-you go price. Reservations do not automatically renew. For pricing information, see the [reserved capacity offering](https://azure.microsoft.com/pricing/details/sql-database/managed/).
+A reservation applies to both primary and billable secondary compute replicas, but does not cover software, networking, or storage charges associated with the service. At the end of the reservation term, the billing benefit expires and the database or managed instance is billed at the pay-as-you-go price. Reservations do not automatically renew. For pricing information, see the [reserved capacity offering](https://azure.microsoft.com/pricing/details/sql-database/managed/).
 
 You can buy reserved capacity in the [Azure portal](https://portal.azure.com). Pay for the reservation [up front or with monthly payments](/azure/cost-management-billing/reservations/prepare-buy-reservation). To buy reserved capacity:
 
@@ -31,7 +31,7 @@ For more information about how enterprise customers and Pay-As-You-Go customers
 > [!NOTE]
 > Purchasing reserved capacity does not pre-allocate or reserve specific infrastructure resources (virtual machines or nodes) for your use.
 
-## Determine correct size before purchase
+## Determine the correct size before purchase
 
 The size of reservation should be based on the total amount of compute used by the existing or soon-to-be-deployed database or managed instance within a specific region and using the same performance tier and hardware configuration.
 
@@ -56,7 +56,7 @@ Also, let's suppose that you know that you will need these resources for at leas
 
     :::image type="content" source="./media/reserved-capacity-overview/sql-reserved-vcores-purchase.png" alt-text="Screenshot before submitting the reserved capacity purchase.":::
 
-    The following table describes required fields.
+    The following table describes the required fields.
     
     | Field      | Description|
     |------------|--------------|
diff --git a/azure-sql/database/service-tier-hyperscale-replicas.md b/azure-sql/database/service-tier-hyperscale-replicas.md
@@ -29,7 +29,7 @@ Each type has a different architecture, feature set, purpose, and cost. Based on
 
 ## High Availability replica
 
-A High Availability (HA) replica uses the same page servers as the primary replica, so no data copy is required to add an HA replica. HA replicas are mainly used to increase database availability; they act as hot standbys for failover purposes. If the primary replica becomes unavailable, failover to one of the existing HA replicas is automatic and quick. Connection string doesn't need to change; during failover applications may experience minimal downtime due to active connections being dropped. As usual for this scenario, proper retry logic is recommended. Several drivers already provide some degree of automatic retry logic. If you are using .NET, the [latest Microsoft.Data.SqlClient](https://devblogs.microsoft.com/azure-sql/configurable-retry-logic-for-microsoft-data-sqlclient/) library provides native full support for configurable automatic retry logic.
+A High Availability (HA) replica uses the same page servers as the primary replica, so no data copy is required to add an HA replica. HA replicas are mainly used to increase database availability; they act as hot standbys for failover purposes. If the primary replica becomes unavailable, failover to one of the existing HA replicas is automatic and quick. The connection string doesn't need to change; during failover applications may experience minimal downtime due to active connections being dropped. As usual for this scenario, proper retry logic is recommended. Several drivers already provide some degree of automatic retry logic. If you are using .NET, the [latest Microsoft.Data.SqlClient](https://devblogs.microsoft.com/azure-sql/configurable-retry-logic-for-microsoft-data-sqlclient/) library provides native full support for configurable automatic retry logic.
 
 HA replicas use the same server and database name as the primary replica. Their Service Level Objective is also always the same as for the primary replica. HA replicas are not visible or manageable as a stand-alone resource from the portal or from any API.
 
@@ -60,8 +60,8 @@ There are differences between HA replicas and named replicas:
 
 As a result, named replicas offer several benefits over HA replicas, for what concern read-only workloads:
 
-- Users connected to a named replica will suffer no disconnection if the primary replica is scaled up or down; at the same time, users connected to primary replica will be unaffected by named replicas scaling up or down.
-- Workloads running on any replica, primary or named, will be unaffected by long running queries running on other replicas.
+- Users connected to a named replica will suffer no disconnection if the primary replica is scaled up or down; at the same time, users connected to the primary replica will be unaffected by named replicas scaling up or down.
+- Workloads running on any replica, primary or named, will be unaffected by long-running queries running on other replicas.
 
 The main goal of named replicas is to enable a broad variety of [read scale-out](read-scale-out.md) scenarios, and to improve Hybrid Transactional and Analytical Processing (HTAP) workloads. Examples of how to create such solutions are available here:
 
diff --git a/docs/relational-databases/accelerated-database-recovery-concepts.md b/docs/relational-databases/accelerated-database-recovery-concepts.md
@@ -128,7 +128,7 @@ The four key components of ADR are:
 
 - **Cleaner**
 
-  The cleaner is the asynchronous process that wakes up periodically and cleans page versions that aren't needed.
+  The cleaner is the asynchronous process that wakes up periodically and cleans obsolete row versions from PVS.
 
 ## ADR improvements in [!INCLUDE[sssql22-md](../includes/sssql22-md.md)]
 
diff --git a/docs/relational-databases/system-tables/dbo-systargetservers-transact-sql.md b/docs/relational-databases/system-tables/dbo-systargetservers-transact-sql.md
@@ -33,6 +33,6 @@ dev_langs:
 |**status**|**int**|Status of the target server:<br /><br /> **1** = Normal<br /><br /> **2** = Re-sync Pending<br /><br /> **4** = Suspected Offline|  
 |**local_time_at_last_poll**|**datetime**|Date and time the target server was last polled for job operations.|  
 |**enlisted_by_nt_user**|**nvarchar(100)**|Username of the person executing **sp_msx_enlist** on the target server.|  
-|**poll_internal**|**int**|Number of seconds to elapse before the target server polls the master server for new download instructions.|  
+|**poll_interval**|**int**|Number of seconds to elapse before the target server polls the master server for new download instructions.|  
   
   
diff --git a/docs/relational-databases/user-defined-functions/scalar-udf-inlining.md b/docs/relational-databases/user-defined-functions/scalar-udf-inlining.md
@@ -134,7 +134,7 @@ Depending upon the complexity of the logic in the UDF, the resulting query plan
   - `IF`/`ELSE`: Branching with arbitrary levels of nesting.
   - `RETURN`: Single or multiple return statements. Starting with [!INCLUDE[sql-server-2019](../../includes/sssql19-md.md)] CU5, the UDF can only contain a single RETURN statement to be considered for inlining <sup>6</sup>.
   - `UDF`: Nested/recursive function calls <sup>2</sup>.
-  - Others: Relational operations such as `EXISTS`, `ISNULL`.
+  - Others: Relational operations such as `EXISTS`, `IS NULL`.
 - The UDF doesn't invoke any intrinsic function that is either time-dependent (such as `GETDATE()`) or has side effects <sup>3</sup> (such as `NEWSEQUENTIALID()`).
 - The UDF uses the `EXECUTE AS CALLER` clause (default behavior if the `EXECUTE AS` clause isn't specified).
 - The UDF doesn't reference table variables or table-valued parameters.
diff --git a/docs/sql-server/compute-capacity-limits-by-edition-of-sql-server.md b/docs/sql-server/compute-capacity-limits-by-edition-of-sql-server.md
@@ -83,6 +83,9 @@ The following table specifies the compute capacity limits for a single instance
 
 <sup>1</sup> Enterprise Edition with Server + Client Access License (CAL) licensing is limited to 20 cores per [!INCLUDE [ssNoVersion](../includes/ssnoversion-md.md)] instance. (This licensing isn't available for new agreements.) There are no limits under the Core-based Server Licensing model.
 
+> [!NOTE]  
+> [!INCLUDE [ssNoVersion](../includes/ssnoversion-md.md)] limits the number of logical processors per NUMA node to 64.
+
 In a virtualized environment, the compute capacity limit is based on the number of logical processors, not cores. The reason is that the processor architecture isn't visible to the guest applications.
 
 For example, a server that has four sockets populated with quad-core processors and the ability to enable two SMT threads per core contains 32 logical processors with SMT enabled. But it contains only 16 logical processors with SMT disabled. These logical processors can be mapped to virtual machines on the server. The virtual machines' compute load on that logical processor is mapped to a thread of execution on the physical processor in the host server.
