Home/ Questions/Q 641975
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T21:07:16+00:00

i’m going to running some queries against an SQL Server database, followed by a

  • 0

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
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0