Our application has a very large, wide table of transactional data. We have a “core” covered index which is used for 90% of the SELECT queries executed against this table. Our application performs very, very well when this index remains in the buffer pool (data cache). If other data pages push the index’s pages out of the data cache, then our application slows down considerably.
So my challenge is: I have some overnight batch processes which manage the transactional data. They work on the table in a different way than the daytime application. I can create additional covered indexes to help my batch processes to run faster. But we’ve found that the “core” covered index falls out of cache when my additional covered indexes are deployed.
I plan to create and drop my additional covered indexes at the start and finish of the overnight batch processes.
It would be extra good if, at the finish of batch processes, I could pull the “core” covered index into the buffer pool (data cache).
I don’t want to use “pin table” or some such. I just want to read all the pages of the “core” covered index at the end of batch processing, so that when the day begins, the “core” covered index is already in memory.
DBCC PINTABLE is a no-op. You can run it, but it doesn’t do anything. I’m sure you could come up with some scripts that would significantly query the daytime data after the nighttime process such that it takes over the buffer pool, but have you considered a much cheaper option: add memory?