1. SQL Server Storage Inside

2. 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.

3. 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

4. SQL Server Storage  Pages  Extents  Uniform  Mixed  Special Type of Pages  Global Allocation Map  Shared Global Allocation MAP

5. 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

6. 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

7. 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 Row- Overflow. 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

8. 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)

9. 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.

10. 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

11. 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.

12. 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:

13. 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

14. 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.

15. 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-allocation- maps/

16. Contact Information  Twitter : twitter.com/ghemant  Facebook : facebook.com/sqlservercitation  Email : Hemantgiri [at] sql-server-citation.com  Blog : http://www.sql-server-citation.comhttp://www.sql-server-citation.com  Linkedin : https://www.linkedin.com/in/hemantgirisgoswami