In this post, I am sharing a script to check the available allocation units on a Table in SQL Server. When you create a table and stored data, it stored into different types of allocation units like IN_ROW_DATA, LOB_DATA, ROW_OVERFLOW_DATA.

Already shared a couple of articles on the importance of allocation units like ROW_OVERFLOW_DATA. When your data are exceeding 8KB pages, it stores into ROW_OVERFLOW_DATA which is also called internal fragmentation.

Using this script, you will get to know different allocations related information including page start number which helps you to do further require analysis on your table.

DECLARE @object SYSNAME = 'table_name'

SELECT
    OBJECT_NAME ([sp].[object_id]) AS [Object Name],
    [sp].[index_id] AS [Index ID],
    [sp].[partition_id] AS [Partition ID],
        [sa].[allocation_unit_id] AS [Alloc Unit ID],
    [sa].[type_desc] AS [Alloc Unit Type],
    '(' + CONVERT (VARCHAR (6),
        CONVERT (INT,
            SUBSTRING ([sa].[first_page], 6, 1) +
            SUBSTRING ([sa].[first_page], 5, 1))) +
    ':' + CONVERT (VARCHAR (20),
        CONVERT (INT,
            SUBSTRING ([sa].[first_page], 4, 1) +
            SUBSTRING ([sa].[first_page], 3, 1) +
            SUBSTRING ([sa].[first_page], 2, 1) +
            SUBSTRING ([sa].[first_page], 1, 1))) +
    ')' AS [First Page],
    '(' + CONVERT (VARCHAR (6),
        CONVERT (INT,
            SUBSTRING ([sa].[root_page], 6, 1) +
            SUBSTRING ([sa].[root_page], 5, 1))) +
    ':' + CONVERT (VARCHAR (20),
        CONVERT (INT,
            SUBSTRING ([sa].[root_page], 4, 1) +
            SUBSTRING ([sa].[root_page], 3, 1) +
            SUBSTRING ([sa].[root_page], 2, 1) +
            SUBSTRING ([sa].[root_page], 1, 1))) +
    ')' AS [Root Page],
    '(' + CONVERT (VARCHAR (6),
        CONVERT (INT,
            SUBSTRING ([sa].[first_iam_page], 6, 1) +
            SUBSTRING ([sa].[first_iam_page], 5, 1))) +
    ':' + CONVERT (VARCHAR (20),
        CONVERT (INT,
            SUBSTRING ([sa].[first_iam_page], 4, 1) +
            SUBSTRING ([sa].[first_iam_page], 3, 1) +
            SUBSTRING ([sa].[first_iam_page], 2, 1) +
            SUBSTRING ([sa].[first_iam_page], 1, 1))) +
    ')' AS [First IAM Page]
FROM
    sys.system_internals_allocation_units AS [sa],
    sys.partitions AS [sp]
WHERE
    [sa].[container_id] = [sp].[partition_id]
AND [sp].[object_id] =
(CASE WHEN (@object IS NULL)
    THEN [sp].[object_id]
    ELSE OBJECT_ID (@object)
END)

Reference is taken from sqlskills.com:

In the previous article, I discussed the 8KB data page of the SQL Server, but what happened when the row is larger and cannot fit into a single 8KB page?

Each row is strictly prohibited to use only 8KB size per data page, but the data type like char, varchar, nvarchar, and varbinary require more space to store data into data page.

Sometimes, the individual column may fit in the limit of 8KB, but if we have multiple columns and the combination of all these types of columns exceeds the limit of 8KB, SQL Server moves data in different allocation unit or raise an error.

e.g. we have three separate columns like VARCHAR(MAX), CHAR(6000) and TEXT so combination of these all columns cannot fit in the 8KB size.

The SQL Server Database Engine moves the record column with the largest width to another page in the ROW_OVERFLOW_DATA allocation unit, and it is maintaining a 24-byte pointer on the original page.

To moving of the large records to another page is a dynamic process because records can become a larger at any point of time while executing UPDATE operations.

If the UPDATE operation makes a small size of the record, it backs to the original page in the IN_ROW_DATA allocation unit.

Whenever we are combining VARCHAR, NVARCHAR, BLOB, VARBINARY kind of data column in a table, internally SQL Server separates the data pages because it may exceed the 8KB row size.

My suggestion is: if we have large size of data columns, we should create a separate table for those columns. Because asynchronously, we can perform JOIN operations, which is performing better than selecting data from internal fragmented pages.