SQL Server modo “Dry Run”? memorias intermedias de datos de carga, sin necesidad de sostener cerraduras o cambiar los datos de

Question

Voy a ejecutar algunas consultas en una base de datos SQL Server, seguido de una eliminación. Idealmente todo esto ocurre dentro de una transacción (es decir atómica).

Pero en la práctica, ya que los datos hace mucho tiempo ha sido purgado de los tampones, SQL Server tendrá que realizar una gran cantidad de S física con el fin de completar la transacción T-SQL. Esto puede ser un problema, ya que si el lote completo tarda más de 30 segundos para correr, a continuación, los usuarios experimentarán problemas de tiempo de espera.

Me di cuenta de que si corro mis selects en pedazos, cada vez que se ejecuta cada vez más de la SQL final, dejando de SQL Server llenar los topes con más y más de los datos requeridos. por ejemplo:.

Primera corrida

 BEGIN TRANSACTION
 SELECT ... WHERE ...
 ROLLBACK

Segundo plazo

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

...

n-ésimo de ejecución :

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

Y en el momento en que alcance la tramo final

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

Todo el lote corre rápido, ya que los tampones se precargada.

¿Hay un modo de SQL Server (es decir SET NOEXEC ON) que hacer que SQL Server no realice ninguna modificación de datos reales, no tome ningún bloqueo, pero llenar los tampones con los datos necesarios? por ejemplo.

SET NOEXEC ON
EXECUTE ThatThingYouDo

SET NOEXEC OFF
EXECUTE ThatThingYouDo

o

SET DRYRUN ON
EXECUTE ThatThingYouDo

SET DRYRUN OFF
EXECUTE ThatThingYouDo

Answer 1

No.
Digamos que usted tiene INSERT seguido por UPDATE en las filas insertadas. Nunca serás capaz de emular la actualización porque no existen las filas insertadas. Ahora, en este caso, ¿por qué son sus selecciona en una transacción? Por defecto (es decir, a menos que utilice HOLDLOCK o similar), no se está fijando las filas durante la duración de la transacción.

Si cree que el grupo de búferes (también conocido como la caché de datos) es "completo", entonces necesita más memoria RAM o alguna otra actualización / Scale Up.

Answer 2

he encontrado que cada vez que intente hacer algo extremadamente fuera de lo normal para resolver un problema, que el diseño básico es muy probablemente el problema. Esto es extremadamente fuera de lo normal.

Tal vez usted podría proporcionar más información sobre la ELIMINAR (tamaño de la tabla, la actividad, el índice, las filas para borrar, otros procesos en ejecución, etc) que está tomando tanto tiempo y no habrá una solución convencional, utilizando un índice o de bloqueo, etc. para responder al problema.