Hi, I am IAM. IAM the Page Type
Hi, I am IAM. IAM the Page Type
Chronicles of SQL Server's Storage Internals - Part 9
Previous post discussed three types of Data Pages. But how does SQL Server know WHERE to find these pages and how they are organized? Because, if you recall past articles - GAM, SGAM and PFS pages have no clue about your table data. They only track which Pages are free and which ones are allocated.
That's where Index Allocation Maps (IAM) come into play!
IAM pages track which extents contain data from your table(s). As simple as that!
More specifically - each table will have at least ONE IAM page - the one that tracks IN_ROW data.
If you happen to have OVERFLOW and LOB data as well, there will be one (or more) IAM pages created for those as well.
What’s important to remember is that ONE IAM tracks ONE ALLOCATION UNIT. And by “Allocation Unit” I mean - IN_ROW, ROW_OVERFLOW or LOB data.
If you need to refresh your memory on Allocation Units, do check the previous article:
Finally, as a single IAM page can store only 8KBs of info, in case that more IAMs are needed - they end up being chained in a linked list (as in - each IAM page has pointer to the next page). Easy peasy!
And that’s all there is to it, really! We covered Global Allocation Maps (GAM), Shared Global Allocation Maps (SGAM), Page Free Space (PFS) and now we wrap up the story with IAM pages.
In the upcoming article we will dig into FileGroups & Partitions, before we wrap-up the Storage Engine story and proceed to talk more about Indexes!