Pages and Extents

Pages and Extents are core concept of data storage in SQL Server. A Page is a 8Kb space allocated in physical drive to be used by SQL Server. Managing these 8Kb Pages would have been difficult and so to help in it we have Extent which is a collection 8 Pages.

As stated before a page is 8Kb drive space, but how will SQL Server know what is in there, a single instance of SQL Server can have multiple databases and in each database there will be multiple tables of any size. In this billions of pages how can SQL Server know which page belongs to which table? Even if it is able to find a page how will it come to know which page it has to go to next (if it is doing range search)? and many more things that SQL Server can encounter when traversing the data.

The SQL Server page structure is as below:

Taken from docs.

It’s the page header where SQL Server stores all the internal and critical information about that specific page, which is used for proper management and access.

Lets see what all is in there.

USE AdventureWorks2017
Go;
DBCC TRACEON (3604);
DBCC IND (0,'Person.Address',0)

When we run this we’ll be able to see what all pages are allocated to the table Person.Address.

Page information for a table

To see the content of a page we will be using the DBCC PAGE.

DBCC PAGE('Adventureworks2017',1,11712,2)

By using 2 in DBCC PAGE I can see the slot array, which is “Row offset” in the image from ms docs. It is used by Database Engine to seek to the exact location of a particular row inside a page. It looks like below:

Row offset

If you want to see how a data is stored in a slot use ‘3’ as the last parameter in DBCC PAGE.

DBCC PAGE('Adventureworks2017',1,11712,3)

Now coming to the page header, in the page header the below information is stored.

Page header

Allocation status is the information from allocation bitmaps and is not stored on a page, but all the information above it is the actual header information formatted in readable format when using DBCC PAGE. (except metadata ones)

The information in the header is:

  • m_pageId
    • This identifies the file number the page is part of and the position within the file. In this example, (1:143) means page 143 in file 1.
  • m_headerVersion
    • This is the page header version. Since version 7.0 this value has always been 1.
  • m_type
    • This is the page type. The values you’re likely to see are:
      • 0 – On a allocated page means corruption. (taken from comments in the Pauls blog reference in the end)
      • 1 – data page. This holds data records in a heap or clustered index leaf-level.
      • 2 – index page. This holds index records in the upper levels of a clustered index and all levels of non-clustered indexes.
      • 3 – text mix page. A text page that holds small chunks of LOB values plus internal parts of text tree. These can be shared between LOB values in the same partition of an index or heap.
      • 4 – text tree page. A text page that holds large chunks of LOB values from a single column value.
      • 7 – sort page. A page that stores intermediate results during a sort operation.
      • 8 – GAM page. Holds global allocation information about extents in a GAM interval (every data file is split into 4GB chunks – the number of extents that can be represented in a bitmap on a single database page). Basically whether an extent is allocated or not. GAM = Global Allocation Map. The first one is page 2 in each file.
      • 9 – SGAM page. Holds global allocation information about extents in a GAM interval. Basically whether an extent is available for allocating mixed-pages. SGAM = Shared GAM. the first one is page 3 in each file.
      • 10 – IAM page. Holds allocation information about which extents within a GAM interval are allocated to an allocation unit (portion of a table or index). IAM = Index Allocation Map.
      • 11 – PFS page. Holds allocation and free space information about pages within a PFS interval (every data file is also split into approx 64MB chunks – the number of pages that can be represented in a byte-map on a single database page. PFS = Page Free Space.
      • 13 – boot page. Holds information about the database. There’s only one of these in the database. It’s page 9 in file 1.
      • 15 – file header page. Holds information about the file. There’s one per file and it’s page 0 in the file.
      • 16 – diff map page. Holds information about which extents in a GAM interval have changed since the last full or differential backup. The first one is page 6 in each file.
      • 17 – ML map page. Holds information about which extents in a GAM interval have changed while in bulk-logged mode since the last backup. This is what allows you to switch to bulk-logged mode for bulk-loads and index rebuilds without worrying about breaking a backup chain. The first one is page 7 in each file.
      • 18 – a page that’s be deallocated by DBCC CHECKDB during a repair operation.
      • 19 – the temporary page that ALTER INDEX … REORGANIZE (or DBCC INDEXDEFRAG) uses when working on an index.
      • 20 – a page pre-allocated as part of a bulk load operation, which will eventually be formatted as a ‘real’ page.
  • m_typeFlagBits
    • This stores a few values about the page. For data and index pages, if the field is 4, that means all the rows on the page are the same fixed size. If a PFS page has m_typeFlagBits of 1, that means that at least one of the pages in the PFS interval mapped by the PFS page has at least one ghost record.
  • m_level
    • This is the level that the page is part of in the b-tree.
    • Levels are numbered from 0 at the leaf-level and increase to the single-page root level (i.e. the top of the b-tree).
    • In SQL Server 2000, the leaf level of a clustered index (with data pages) was level 0, and the next level up (with index pages) was also level 0. The level then increased to the root. So to determine whether a page was truly at the leaf level in SQL Server 2000, you need to look at the m_type as well as the m_level.
    • For all page types apart from index pages, the level is always 0.
  • m_flagBits
    • This stores a number of different flags that describe the page. For example, 0x200 means that the page has a page checksum on it (as our example page does) and 0x100 means the page has torn-page protection on it.
    • Some bits are no longer used from SQL Server 2005 onward.
  • m_objId
  • m_indexId
    • In SQL Server 2000, these identified the actual relational object and index IDs to which the page is allocated. In SQL Server 2005 this is no longer the case. The allocation metadata totally changed so these instead identify what’s called the allocation unit that the page belongs to. 
  • m_prevPage
  • m_nextPage
    • These are pointers to the previous and next pages at this level of the b-tree and store 6-byte page IDs.
    • The pages in each level of an index are joined in a doubly-linked list according to the logical order (as defined by the index keys) of the index. The pointers do not necessarily point to the immediately adjacent physical pages in the file (because of fragmentation).
    • The pages on the left-hand side of a b-tree level will have the m_prevPage pointer be NULL, and those on the right-hand side will have the m_nextPage be NULL.
    • In a heap, or if an index only has a single page, these pointers will both be NULL for all pages. There’s a special case when they won’t be NULL – if the heap is rebuilt using ALTER TABLE … REBUILD. This uses the index rebuild code to build the leaf-level of a clustered index, but the linkages aren’t actually used for anything
  • pminlen
    • This is the size of the fixed-length portion of the records on the page.
  • m_slotCnt
    • This is the count of records on the page.
  • m_freeCnt
    • This is the number of bytes of free space in the page.
  • m_freeData
    • This is the offset from the start of the page to the first byte after the end of the last record on the page. It doesn’t matter if there is free space nearer to the start of the page.
  • m_reservedCnt
    • This is the number of bytes of free space that has been reserved by active transactions that freed up space on the page. It prevents the free space from being used up and allows the transactions to roll-back correctly. There’s a very complicated algorithm for changing this value.
  • m_lsn
    • This is the Log Sequence Number of the last log record that changed the page.
  • m_xactReserved
    • This is the amount that was last added to the m_reservedCnt field.
  • m_xdesId
    • This is the internal ID of the most recent transaction that added to the m_reservedCnt field.
  • m_ghostRecCnt
    • The is the count of ghost records on the page.
  • m_tornBits
    • This holds either the page checksum or the bits that were displaced by the torn-page protection bits – depending on what form of page protection is turned on for the database.

The above page information is taken from Paul Randal’s blog.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s