Download Shared Global Allocation Map (SGAM)

SQL Server Storage Inside
About Hemantgiri S. Goswami
Hemantgiri S. Goswami is a Lead Database Consultant for Pythian, a company head
quartered in Ottawa, Canada. Hemantgiri has close to 17 years of experience and
has worked for fortune 500 companies. Hemantgiri has been awarded Most Valuable
Professional (MVP) award by MS for his contribution to community. Hemantgiri is a
published author, MSDN Moderator and active blogger. Hemantgiri is a founder and
leader of Surat SQLPASS Chapter.
Agenda

We will understand SQL Server Storage

How the data is stored inside

What is PAGE

What is Extent

What is Mixed Extent

TIP: SQL Server storage best practice
SQL Server Storage

Pages

Extents


Uniform

Mixed
Special Type of Pages

Global Allocation Map

Shared Global Allocation MAP
Pages

They are logical

Each page are 8KB in size

They are stored and numbered sequentially from 0 to N in each file

There will be 128 Pages per MB

When a space is added or shrink in a database file, SQL Server ensures page
number are contiguous
Pages

Mainly 3 Section
1.
Page Header
2.
Data Row
3.
Row Offset
8 KB = 8192 Bytes
Page Header = 96 Bytes
Row Offset = 36 Bytes
Data Row = 8060 Bytes
Page – What it contains
1.
96 Byte for Header Information such as type of page, amount of free space,
object owing
2.
Data Row which is place serially
3.
At the bottom of the row, there will be a row offset – one for every row, and
its offset from start of the page.
4.
Row Offset = Information which will let you know how far the row is from
start of the page. And, Row Offsets are in reverse sequence from the
sequence of the Row
5.
Maximum amount of data in single row is 8060 bytes and is called In-Row
Data. This limit is relaxed in SQL Server 2008 onwards, and is called RowOverflow.
6.
Row-Overflow Data, SQL Server will still have 8KB Pages but what it will do is
that when table have varchar, nvarchar, varbinary or sql_variant or CLR UD
columns it will have 24 byte pointer value in original page and move largest
width column to another page in ROW_OVERFLOW_DATA unit
Basic Layout of Page
1.
Page 0 is the File Header
2.
Page 1 is the Page Free Space (PFS)
3.
Page 2 is GAM
4.
Page 3 is SGAM
5.
Page 6 is Differential Changed Map (DCM)
6.
Page 7 is Bulk Changed Map (BCM)
Global Allocation Map (GAM)

These pages record which extents have been allocated for any type of use.

GAM has a bit to indicate value 0 means in use and 1 means free extent.

After header and other overhead are accounted, there are 8000 bytes or
64000 bits to cover 64000 extents.

Each GAM page covers 4 GB of data and a GAM page exists in a file for every 4
GB of file size.
Shared Global Allocation Map (SGAM)

Record which extents are currently used as mixed events and have at least
one unused page.

Similar to GAM, it covers 64000 extents every 4GB of data.

Has a bit for each extent in the interval it covers: 1 if the extent is being used
a mixed extent and has free pages, 0 if the extent isn’t being used a mixed
extent or it’s a mixed extent with no free pages
Differential Changed Map (DCM)

This tracks the extents that have changed since the last BACKUP DATABASE
statement. If the bit for an extent is 1, the extent has been modified since
the last BACKUP DATABASE statement. If the bit is 0, the extent has not been
modified.

Differential backups read just the DCM pages to determine which extents
have been modified. This greatly reduces the number of pages that a
differential backup must scan. The length of time that a differential backup
runs is proportional to the number of extents modified since the last BACKUP
DATABASE statement and not the overall size of the database.
Bulk Changed Map (BCM)

This tracks the extents that have been modified by bulk logged operations
since the last BACKUP LOG statement. If the bit for an extent is 1, the extent
has been modified by a bulk logged operation after the last BACKUP LOG
statement. If the bit is 0, the extent has not been modified by bulk logged
operations.

Although BCM pages appear in all databases, they are only relevant when the
database is using the bulk-logged recovery model. In this recovery model,
when a BACKUP LOG is performed, the backup process scans the BCMs for
extents that have been modified. It then includes those extents in the log
backup. This lets the bulk logged operations be recovered if the database is
restored from a database backup and a sequence of transaction log backups.
BCM pages are not relevant in a database that is using the simple recovery
model, because no bulk logged operations are logged. They are not relevant
in a database that is using the full recovery model, because that recovery
model treats bulk logged operations as fully logged operations.

The interval between DCM pages and BCM pages is the same as the interval
between GAM and SGAM page, 64,000 extents. The DCM and BCM pages are
located behind the GAM and SGAM pages in a physical file:
Extents

Is a unit

Extent is made up of 8 logically contiguous pages

Extent = 8 Pages of 8 KB each thus 64 KB in size
Types of Extent

Uniform Extents – Owned by Single Object, all eight pages in the extent can be used
by this single object.

Mixed Extents – Shared between objects, up to eight objects can share extent
Whenever a new table or index needs allocation it is given a mixed extents; when the table or index
grows to eight pages, future allocations can use uniform extents. Between versions of SQL Server the #
of pages post which uniform extents are given may vary.
If a table or index needs more space and is still less than 8 pages total, SQL Server must find a mixed
extent with space available, else if it is 8 pages or larger, uniform extents are located.
When there is no mixed extents with free space, a new extent marked as mixed extent is allocated and
SGAM updated accordingly.
Reference & Further Reading
http://blogs.extremeexperts.com/2012/11/22/sql-server-database-page-basics/
https://technet.microsoft.com/en-us/library/ms190950(v=sql.105).aspx
http://www.sqlskills.com/blogs/paul/inside-the-storage-engine-gam-sgam-pfs-and-other-allocationmaps/
Contact Information

Twitter : twitter.com/ghemant

Facebook : facebook.com/sqlservercitation

Email : Hemantgiri [at] sql-server-citation.com

Blog : http://www.sql-server-citation.com

Linkedin : https://www.linkedin.com/in/hemantgirisgoswami