SQL Server modalità “Dry Run”? buffer di dati di carico, senza tenere serrature o modifica dei dati

Question

Ho intenzione di correre alcune query in un database di SQL Server, seguita da una cancellazione. Idealmente tutto questo avviene all'interno di una transazione (cioè atomico).

Ma in pratica, perché i dati è stato da tempo purgato dai buffer, SQL Server dovrà eseguire un sacco di IO fisica al fine di completare la transazione T-SQL. Questo può essere un problema, perché se l'intero lotto richiede più di 30 secondi per l'esecuzione, gli utenti sperimenteranno problemi di timeout.

Ho notato che se eseguo il mio selects a pezzi, ogni tempo di esecuzione più del SQL finale, lasciando che SQL Server riempire i buffer con più e più dei dati richiesti. per esempio:.

Prima esecuzione :

 BEGIN TRANSACTION
 SELECT ... WHERE ...
 ROLLBACK

Seconda manche :

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

...

n-esimo run :

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

E quando raggiungo il corsa finale :

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

L'intera partita corre veloce, dal momento che i buffer sono pre-riempite.

C'è un modo di SQL Server (vale a dire SET NOEXEC ON) che potrebbe causare SQL Server per non eseguire alcuna modifica dei dati effettivi, senza prendere alcun blocco, ma riempire i buffer con i dati necessari? per es.

SET NOEXEC ON
EXECUTE ThatThingYouDo

SET NOEXEC OFF
EXECUTE ThatThingYouDo

o

SET DRYRUN ON
EXECUTE ThatThingYouDo

SET DRYRUN OFF
EXECUTE ThatThingYouDo

Answer 1

No.
Diciamo che avete INSERT seguita da aggiornamento sulle righe inserite. Non sarai mai in grado di emulare l'aggiornamento perché non esistono le righe inserite. Ora, in questo caso, perché sono i tuoi seleziona in una transazione? Per impostazione predefinita (vale a dire a meno di utilizzare HOLDLOCK o simili), non si sta bloccando il file per la durata della transazione.

Se si pensa che il pool di buffer (anche noto come la cache di dati) è "piena", allora avete bisogno di più RAM o qualche altro aggiornamento / scale-up.

Answer 2

ho trovato che ogni volta che si tenta di fare qualcosa di estremamente fuori dal normale per risolvere un problema, che è progetto di base è più probabile il problema. Questo è estremamente fuori dal normale.

Forse si potrebbe fornire maggiori informazioni sul DELETE (dimensione della tabella, l'attività, indice, righe da cancellare, altri processi in esecuzione, ecc) che sta prendendo così tanto tempo e ci sarà una soluzione convenzionale, utilizzando un indice o di blocco, ecc per affrontarlo.