At what point is a (disk-based) table removed from memory after data is read from it?

Question

Are (disk-based, so no Hekaton) tables persisted in memory for longer than the lifespan of the query that is reading data from them?

If so, what determines how long they stay in memory for?

Is there a way to manage how long they persist in memory for?

Answer 1

This is a complicated topic, much of which is covered in this Microsoft Docs article.

To answer a couple of points:

Are (disk-based, so no Hekaton) tables persisted in memory for longer than the lifespan of the query that is reading data from them?

Sort of. Entire tables aren't necessarily persisted in memory. Individual pages from a table or index are stored in memory - it could be the entire table, or just a portion of it.

If so, what determines how long they stay in memory for?

You'll have to reference the article I linked to, but lots of things can cause "memory pressure" which will lead to data pages being "evicted" from the cache.

Things like the amount of memory available to SQL Server, other data and index pages being pulled into memory, other SQL Server data caches needing memory, "external" pressure from the OS and other processes on the box, etc can all result in pages being kicked out of cache.

SQL Server uses a "least recently used" cache, so the least recently referenced pages will generally get kicked out first.

Is there a way to manage how long they persist in memory for?

Only by making sure SQL Server has enough memory to keep the pages in the buffer pool, and making sure other processes don't put pressure on SQL Server.

One thing that can help prevent the OS from taking memory back from SQL Server is turning on the Lock Pages in Memory (LPIM) feature.

---

As a historical note, DBCC PINTABLE used to work for keeping a table in memory, however, it was deprecated as of SQL Server 2005 (and now does nothing at all).