Merge pull request #36134 from dimitri-furman/dfurman/pages

Update page architecture guide

Author: JamesJBarnett

docs/relational-databases/databases/tempdb-database.md

@@ -4,9 +4,9 @@ description: This article provides details about the configuration and use of th
 author: WilliamDAssafMSFT
 ms.author: wiassaf
 ms.reviewer: randolphwest, dfurman
-ms.date: 11/18/2025
+ms.date: 12/29/2025
 ms.service: sql
-ms.topic: conceptual
+ms.topic: article
 ms.custom:
   - P360
   - ignite-2025
@@ -42,7 +42,7 @@ The `tempdb` system database is a global resource that holds:
   - Work files for hash match or hash aggregate operations.
   - Intermediate sort results for operations such as creating or rebuilding indexes (if `SORT_IN_TEMPDB` is specified), or certain `GROUP BY`, `ORDER BY`, or `UNION` queries.
 
-  Each internal object uses a minimum of nine pages: an IAM page and an eight-page extent. For more information about pages and extents, see [Pages and extents](../pages-and-extents-architecture-guide.md#pages-and-extents).
+  Each internal object uses a minimum of nine pages: an IAM page and an eight-page extent. For more information about pages and extents, see the [Page and extent architecture guide](../pages-and-extents-architecture-guide.md).
 
 - **Version stores**, which are collections of data pages that hold the data rows that support [row versioning](../sql-server-transaction-locking-and-row-versioning-guide.md#Row_versioning). The version stores contain:
   - Row versions that are generated by data modification transactions in a database that uses row versioning-based `READ COMMITTED` or `SNAPSHOT` isolation transactions.

docs/relational-databases/media/pages-and-extents-architecture-guide/page-architecture.svg

@@ -3,10 +3,10 @@ title: Memory Management Architecture Guide
 description: Learn about memory management architecture in SQL Server, including changes to memory management in previous versions.
 author: rwestMSFT
 ms.author: randolphwest
-ms.date: 11/18/2025
+ms.date: 12/29/2025
 ms.service: sql
 ms.subservice: supportability
-ms.topic: conceptual
+ms.topic: article
 ms.custom:
   - ignite-2025
 helpviewer_keywords:
@@ -257,7 +257,7 @@ A buffer is an 8-KB page in memory, the same size as a data or index page. Thus,
 
 When [!INCLUDE [ssNoVersion](../includes/ssnoversion-md.md)] starts, it computes the size of virtual address space for the buffer cache based on several parameters such as the amount of physical memory on the system, the configured number of maximum server threads, and various startup parameters. [!INCLUDE [ssNoVersion](../includes/ssnoversion-md.md)] reserves this computed amount of its process virtual address space (called the memory target) for the buffer cache, but it acquires (commits) only the required amount of physical memory for the current load. You can query the `committed_target_kb` and `committed_kb` columns in the [sys.dm_os_sys_info](system-dynamic-management-views/sys-dm-os-sys-info-transact-sql.md) catalog view to return the number of pages reserved as the memory target and the number of pages currently committed in the buffer cache, respectively.
 
-The interval between [!INCLUDE [ssNoVersion](../includes/ssnoversion-md.md)] startup and when the buffer cache obtains its memory target is called ramp-up. During this time, read requests fill the buffers as needed. For example, a single 8-KB page read request fills a single buffer page. This means the ramp-up depends on the number and type of client requests. Ramp-up is expedited by transforming single page read requests into aligned eight page requests (making up one extent). This allows the ramp-up to finish much faster, especially on machines with a lot of memory. For more information about pages and extents, see [Pages and Extents Architecture Guide](pages-and-extents-architecture-guide.md#pages-and-extents).
+The interval between [!INCLUDE [ssNoVersion](../includes/ssnoversion-md.md)] startup and when the buffer cache obtains its memory target is called ramp-up. During this time, read requests fill the buffers as needed. For example, a single 8-KB page read request fills a single buffer page. This means the ramp-up depends on the number and type of client requests. Ramp-up is expedited by transforming single page read requests into aligned eight page requests (making up one extent). This allows the ramp-up to finish much faster, especially on machines with a lot of memory. For more information about pages and extents, see [Page and extent architecture guide](pages-and-extents-architecture-guide.md).
 
 Because the buffer manager uses most of the memory in the [!INCLUDE [ssNoVersion](../includes/ssnoversion-md.md)] process, it cooperates with the memory manager to allow other components to use its buffers. The buffer manager interacts primarily with the following components:
 

docs/relational-databases/memory-management-architecture-guide.md

@@ -4,7 +4,7 @@ description: "Transact-SQL reference for the BIT_COUNT function."
 author: thesqlsith
 ms.author: derekw
 ms.reviewer: randolphwest
-ms.date: 02/03/2025
+ms.date: 12/29/2025
 ms.service: sql
 ms.subservice: t-sql
 ms.topic: reference
@@ -53,7 +53,7 @@ For example, `SELECT BIT_COUNT (CAST (-1 AS SMALLINT))` and `SELECT BIT_COUNT (C
 
 Distributed Query functionality for the bit manipulation functions within linked server or ad hoc queries (`OPENQUERY`) aren't supported.
 
-Large object (LOB) data types in the Database Engine can store data that exceeds 8,000 bytes. These data types store data on a [row-overflow](../../relational-databases/pages-and-extents-architecture-guide.md#row-overflow-considerations) data page. A LOB also encompasses data types that store data on dedicated LOB page structures, which use a text or an image pointer of in-row references to LOB data pages. For more information about data storage, see the [Pages and extents architecture guide](../../relational-databases/pages-and-extents-architecture-guide.md).
+Large object (LOB) data types in the Database Engine can store data that exceeds 8,000 bytes. These data types store data on a [row-overflow](../../relational-databases/pages-and-extents-architecture-guide.md#large-row-support) data page. A LOB also encompasses data types that store data on dedicated LOB page structures, which use a text or an image pointer of in-row references to LOB data pages. For more information about data storage, see the [Page and extent architecture guide](../../relational-databases/pages-and-extents-architecture-guide.md).
 
 The bit manipulation functions operate on the **tinyint**, **smallint**, **int**, **bigint**, **binary(*n*)**, and **varbinary(*n*)** data types. Large object (LOB) data types, such as **varchar(max)**, **nvarchar(max)**, **varbinary(max)**, **image**, **ntext**, **text**, **xml**, and common language runtime (CLR) BLOB types, aren't supported.
 
@@ -86,4 +86,3 @@ The result is `2`. This is because `17` in binary is `0001 0001`, and there are
 - [SET_BIT (Transact SQL)](set-bit-transact-sql.md)
 - [GET_BIT (Transact SQL)](get-bit-transact-sql.md)
 - [Bit manipulation functions](bit-manipulation-functions-overview.md)
-

docs/relational-databases/pages-and-extents-architecture-guide.md

@@ -4,7 +4,7 @@ description: "Transact-SQL reference for the GET_BIT function."
 author: thesqlsith
 ms.author: derekw
 ms.reviewer: randolphwest
-ms.date: 02/03/2025
+ms.date: 12/29/2025
 ms.service: sql
 ms.subservice: t-sql
 ms.topic: reference
@@ -32,7 +32,7 @@ monikerRange: ">=sql-server-ver16 || >=sql-server-linux-ver16 || =azuresqldb-mi-
 ## Syntax
 
 ```syntaxsql
-GET_BIT ( expression_value, bit_offset )
+GET_BIT ( expression_value , bit_offset )
 ```
 
 ## Arguments
@@ -57,7 +57,7 @@ The *bit_offset* parameter in `GET_BIT` is used to identify the *n*th bit of the
 
 Distributed Query functionality for the bit manipulation functions within linked server or ad hoc queries (`OPENQUERY`) aren't supported.
 
-Large object (LOB) data types in the Database Engine can store data that exceeds 8,000 bytes. These data types store data on a [row-overflow](../../relational-databases/pages-and-extents-architecture-guide.md#row-overflow-considerations) data page. A LOB also encompasses data types that store data on dedicated LOB page structures, which use a text or an image pointer of in-row references to LOB data pages. For more information about data storage, see the [Pages and extents architecture guide](../../relational-databases/pages-and-extents-architecture-guide.md).
+Large object (LOB) data types in the Database Engine can store data that exceeds 8,000 bytes. These data types store data on a [row-overflow](../../relational-databases/pages-and-extents-architecture-guide.md#large-row-support) data page. A LOB also encompasses data types that store data on dedicated LOB page structures, which use a text or an image pointer of in-row references to LOB data pages. For more information about data storage, see the [Page and extent architecture guide](../../relational-databases/pages-and-extents-architecture-guide.md).
 
 The bit manipulation functions operate on the **tinyint**, **smallint**, **int**, **bigint**, **binary(*n*)**, and **varbinary(*n*)** data types. Large object (LOB) data types, such as **varchar(max)**, **nvarchar(max)**, **varbinary(max)**, **image**, **ntext**, **text**, **xml**, and common language runtime (CLR) BLOB types, aren't supported.
 
@@ -66,24 +66,23 @@ The bit manipulation functions operate on the **tinyint**, **smallint**, **int**
 In this example, the second and fourth bits are returned.
 
 ```sql
-SELECT GET_BIT ( 0xabcdef, 2 ) as Get_2nd_Bit,
-GET_BIT ( 0xabcdef, 4 ) as Get_4th_Bit;
+SELECT GET_BIT(0xabcdef, 2) AS Get_2nd_Bit,
+       GET_BIT(0xabcdef, 4) AS Get_4th_Bit;
 ```
 
 The results are as follows:
 
-|Get_2nd_Bit|Get_4th_Bit|
-|---|---|
+| Get_2nd_Bit | Get_4th_Bit |
+| --- | --- |
 | 1 | 0 |
 
 > [!NOTE]  
 > `0xabcdef` in binary is 1010 1011 1100 1101 111**0** 1**1**11. The second and fourth bits are highlighted.
 
-## Related Content
+## Related content
 
 - [SET_BIT (Transact SQL)](set-bit-transact-sql.md)
 - [LEFT_SHIFT (Transact SQL)](left-shift-transact-sql.md)
 - [RIGHT_SHIFT (Transact SQL)](right-shift-transact-sql.md)
 - [BIT_COUNT (Transact SQL)](bit-count-transact-sql.md)
 - [Bit manipulation functions](bit-manipulation-functions-overview.md)
-

docs/t-sql/functions/bit-count-transact-sql.md

@@ -4,7 +4,7 @@ description: "Transact-SQL reference for the SET_BIT function."
 author: thesqlsith
 ms.author: derekw
 ms.reviewer: randolphwest
-ms.date: 02/03/2025
+ms.date: 12/29/2025
 ms.service: sql
 ms.subservice: t-sql
 ms.topic: reference
@@ -32,8 +32,8 @@ monikerRange: ">=sql-server-ver16 || >=sql-server-linux-ver16 || =azuresqldb-mi-
 ## Syntax
 
 ```syntaxsql
-SET_BIT ( expression_value, bit_offset ) 
-SET_BIT ( expression_value, bit_offset, bit_value )
+SET_BIT ( expression_value , bit_offset )
+SET_BIT ( expression_value , bit_offset , bit_value )
 ```
 
 ## Arguments
@@ -60,7 +60,7 @@ SET_BIT will throw an error if *bit_offset* is negative or greater than the last
 
 Distributed Query functionality for the bit manipulation functions within linked server or ad hoc queries (`OPENQUERY`) aren't supported.
 
-Large object (LOB) data types in the Database Engine can store data that exceeds 8,000 bytes. These data types store data on a [row-overflow](../../relational-databases/pages-and-extents-architecture-guide.md#row-overflow-considerations) data page. A LOB also encompasses data types that store data on dedicated LOB page structures, which use a text or an image pointer of in-row references to LOB data pages. For more information about data storage, see the [Pages and extents architecture guide](../../relational-databases/pages-and-extents-architecture-guide.md).
+Large object (LOB) data types in the Database Engine can store data that exceeds 8,000 bytes. These data types store data on a [row-overflow](../../relational-databases/pages-and-extents-architecture-guide.md#large-row-support) data page. A LOB also encompasses data types that store data on dedicated LOB page structures, which use a text or an image pointer of in-row references to LOB data pages. For more information about data storage, see the [Page and extent architecture guide](../../relational-databases/pages-and-extents-architecture-guide.md).
 
 The bit manipulation functions operate on the **tinyint**, **smallint**, **int**, **bigint**, **binary(*n*)**, and **varbinary(*n*)** data types. Large object (LOB) data types, such as **varchar(max)**, **nvarchar(max)**, **varbinary(max)**, **image**, **ntext**, **text**, **xml**, and common language runtime (CLR) BLOB types, aren't supported.
 
@@ -71,7 +71,7 @@ The bit manipulation functions operate on the **tinyint**, **smallint**, **int**
 In this example, the third bit (at offset 2, zero-based index) is being set to `1`.
 
 ```sql
-SELECT SET_BIT ( 0x00, 2 ) as VARBIN1;
+SELECT SET_BIT(0x00, 2) AS VARBIN1;
 ```
 
 The result is `0x04`. This is because the *expression_value* of `0x00` is converted to `0000`. SET_BIT changes its third bit (offset 2) to 1, making it `0100`. This binary value is then returned as `4` in hexadecimal representation.
@@ -81,16 +81,15 @@ The result is `0x04`. This is because the *expression_value* of `0x00` is conver
 In this example, the *bit_value* is being set to 0 instead of the default of 1.
 
 ```sql
-SELECT SET_BIT ( 0xabcdef, 0, 0 ) as VARBIN2;
+SELECT SET_BIT(0xabcdef, 0, 0) AS VARBIN2;
 ```
 
 The result is `0xABCDEE`. The *expression_value* is converted to binary, which is `1010 1011 1100 1101 1110 1111`. SET_BIT changes the first bit to a 0, and the result is returned in hexadecimal format.
 
-## Related Content
+## Related content
 
 - [LEFT_SHIFT (Transact SQL)](left-shift-transact-sql.md)
 - [RIGHT_SHIFT (Transact SQL)](right-shift-transact-sql.md)
 - [BIT_COUNT (Transact SQL)](bit-count-transact-sql.md)
 - [GET_BIT (Transact SQL)](get-bit-transact-sql.md)
 - [Bit manipulation functions](bit-manipulation-functions-overview.md)
-