In this context, multi-page allocations means SQL Server needs more than 8K of memory, and it will allocate multiple 8K pages to hold that data.
How, in future, SQL determine if page, which Storage Engine asks, is already in memory?
To balance CPU and I/O throughput to achieve good performance and maximize hardware utilization, SQL Server includes 2 asynchronous I/O mechanisms - sequential read ahead and random prefetching
When SQL Server has to scan a large table, the storage engine will initiate the read ahead mechanism to ensure that pages are in memory and they are ready to scan before they are needed by the Query Optimizer.
If you are using Enterprise edition, then there is a mechanism called advanced scanning or merry-go-round scanning that will allow multiple tasks to share full table scans. This advance scanning avoids users to compete for buffer space and taxing other resources on the server.
And which algorithm it uses to keep some free space for new pages?
SQL Server (and Sybase as well :-) ) uses LRU (Least Recently Used) algorithm to keep track of pages that are aged in the buffer pool. It increments a counter every time a page is referenced and decrements the counter every time the lazy writer process sweeps the page.
Any worker thread will check the memory status of Buffer Pool to make sure that there are healthy number of Free pages to honor incoming new requests.
Note that : SQL Server will always keep a minimum number of free pages on the free list, so that it can serve incoming requests without any significant delay. The amount of free space is calculated based on Buffer Pool and amount of incoming requests.
IF there are no free buffers or very little left then :
- If Max Memory is reached then
- If Max Memory is not reached then
- SQL Server will commit more reserved pages into the buffer pool.
You can use DMV (in 2005 and up) - sys.dm_os_buffer_descriptors
to find the pages in the buffer pool.
Also, there are Memory Manager surface area changes in SQL Server 2012.
KB 2663912 :
Starting with SQL Server 2012, Multi-Page allocations and CLR allocations are also included in memory limits that are controlled by max server memory (MB) and min server memory (MB). This change provides a more accurate sizing ability for all memory requirements that go through the SQL Server memory manager. Carefully review your current max server memory (MB) and min server memory (MB) values after you upgrade to SQL Server 2012.
Highly recommend to read :
Best Answer
This extent allocation seen in your transaction log file is a uniform extent allocation for your allocation unit.
This page allocation seen in your transaction log file is a page that is part of a mixed extent, as you noted this page is used by your IAM page.
Mixed extents
IAM pages are always part of mixed extents.
Proof of IAM pages always being part of mixed extents by Paul S. Randal on:
Inside the Storage Engine: IAM pages, IAM chains, and allocation units
And another article by Paul S. Randal:
Inside the Storage Engine: Anatomy of an extent
How are IAM pages allocated
In Pages and Extents Architecture Guide
IAM pages are located randomly in the file but are chained together per allocation unit.
Dependent on version and traceflag 1118
With this information at hand and knowing that pre sql server 2016 (without TF 1118) tables could get mixed extents for the first 8 pages allocated, one extent could in fact hold both IAM pages & data pages.
Again proven in the previously mentioned article: Inside the Storage Engine: Anatomy of an extent
By default starting with SQL Server 2016 (or with TF 1118 enabled) data pages will be part of uniform extents and IAM pages will be part of a different, mixed extent.
This should explain why your IAM page is mapped differently from your data page and it's uniform extent that was allocated.
Testing mixed extent allocation
Creating some test tables & inserting one row per table on a SQL Server 2012 instance without TF 1118.
We can then use
DBCC IND
to map these allocated uniform pages, in the 150 - 180 range on my end.If we then check the SGAM settings for the database that only has one SGAM page allocated, on page id 3:
We get this information for our page ranges
We see that two uniform extents, from 152 to 168 are full.
We could then check the PFS to see if these are IAM pages or not.
This is the result
5 IAM pages, not enough to get a full uniform extent of only IAM pages. With one data page of one of the tables:
And 10 System data pages.
You will also see these single page allocations when uniform extents are used by reading the transaction log file:
EDIT
IAM / Mixed page allocation
Below quote that explains tempdb contention when using mixed pages should have the same application for user databases and it's IAM page allocation.
Source
Correct me if im wrong but the mechanism it looks like it uses to allocate IAM pages is to check the
SGAM
page to get a mixed extent with free pages (SGAM bit = 1) and then uses thePFS
page to find the first unallocated mixed extent page to allocate the IAM page.(If there are mixed extents with free pages, if not, it also has to search the GAM page).
This statement is built upon the understanding that allocating a new IAM page should be the same as allocating new mixed extent data pages.
Managing space used by objects
And Paul S. Randal Why PFS pages cannot be repaired
Managing Extent Allocations