SQL Server “Dry Run” mode? Load data buffers, without holding locks or changing data

Question

i'm going to running some queries against an SQL Server database, followed by a delete. Ideally all this happens inside a transaction (i.e. atomic).

But practically, because the data has long since been purged from the buffers, SQL Server will have to perform a lot of physical IO in order to complete the transacted T-SQL. This can be a problem, because if the entire batch takes longer than 30 seconds to run, then users will experience timeout problems.

i noticed that if i run my selects in pieces, each time running more and more of the final SQL, letting SQL Server fill the buffers with more and more of the required data. e.g.:

First run:

 BEGIN TRANSACTION
 SELECT ... WHERE ...
 ROLLBACK

Second run:

 BEGIN TRANSACTION
 SELECT ... WHERE ...
 SELECT ... WHERE ...
 ROLLBACK

...

n-th run:

BEGIN TRANSACTION
SELECT ... WHERE ...
SELECT ... WHERE ...
...
SELECT ... WHERE ...
ROLLBACK

And by the time i reach the final run:

BEGIN TRANSACTION
SELECT ... WHERE ...
SELECT ... WHERE ...
...
SELECT ... WHERE ...
DELETE FROM ... WHERE ...
COMMIT

The entire batch runs fast, since the buffers are pre-filled.

Is there a mode of SQL Server (i.e. SET NOEXEC ON) that would cause SQL Server to not perform any actual data modifications, not take any locks, but fill the buffers with needed data? e.g.

SET NOEXEC ON
EXECUTE ThatThingYouDo

SET NOEXEC OFF
EXECUTE ThatThingYouDo

or

SET DRYRUN ON
EXECUTE ThatThingYouDo

SET DRYRUN OFF
EXECUTE ThatThingYouDo

Answer 1

No.
Let's say you have INSERT followed by UPDATE on the inserted rows. You'll never be able to emulate the UPDATE because the inserted rows don't exist. Now, in this case, why are your selects in a transaction? By default (i.e. unless you use HOLDLOCK or similar), you are not locking the rows for the duration of the transaction.

If you think the buffer pool (a.k.a. the data cache) is "full," then you need more RAM or some other upgrade/scale up.

Answer 2

I have found that whenever you try to do something extremely out of the normal to solve a problem, that you basic design is most likely the problem. This is extremely out of the normal.

Perhaps you could provide more info on the DELETE (table size, activity, index, rows to delete, other processes running, etc) that is taking so long and there will be a conventional solution, using an index or locking , etc to address it.