Forzar un tiempo de espera de consulta en SQL Server

79

Hemos tenido un problema con un bloque de código que responde mal frente a bases de datos lentas (caga la cama en un tiempo de espera de consulta). Hemos creado un parche y estamos en proceso de ejecutarlo mediante regresión.

No podemos conseguir un tiempo de espera. Abrí una transacción de SQL Mgmt Studio y actualicé cada fila para bloquearlas, pero eso no hace que los INSERTs se agoten (que es lo que necesito).

¿Puedo obtener un bloqueo a nivel de tabla fácilmente a través de T-SQL? ¿O tengo que jugar con el maestro? ¿O puedo forzar fácilmente el tiempo de espera sin bloquear? Se agradece cualquier aporte.

sql-server testing timeout locking Bn Wasteland
fuente

Respuestas:

131

ejecuta esto y luego prueba tu inserto ...

select * from yourTable with (holdlock,tablockx)

aquí, puede bloquearlo durante 5 minutos:

BEGIN TRANSACTION

SELECT * FROM yourTable WITH (TABLOCKX, HOLDLOCK)

WHERE 0 = 1

WAITFOR DELAY '00:05'

ROLLBACK TRANSACTION
KM.
fuente
¿Hay alguna manera de hacer esto desde C # /. NET sin bloquear el hilo que realizó esta llamada a SQL Server? Estoy tratando de probar el comportamiento de mi aplicación cuando se agota el tiempo de espera de la conexión. Pero si llamo a este código desde C #, no sé cómo ejecutar otra consulta, experimentando el tiempo de espera a propósito.
Jake Smith
33

Puede decirle a su código SQL que espere un minuto antes de regresar:

WaitFor Delay '00:01:00'
David
fuente
Votó por la sencillez de la respuesta. Lo he probado y funciona
Mikel
Estaba rellenando una tabla y creando consultas recursivas complejas, mejoras, tonterías. Éstos hacen el truco.
DanielV
10

Por otro lado: si la conexión es configurable, reduzca el tiempo de espera de la cadena de conexión a 1 segundo; eso lo hará más fácil. Llene la tabla con montones de datos y haga que otros 3 procesos giren en un ciclo actualizando fragmentos de esa tabla con una transacción alrededor del ciclo. No modifique el procedimiento real llamado por la aplicación (inyectando waitfor). Eso invalida una prueba de integración.

Pero realmente, este es un estudio de caso a favor de las pruebas unitarias y la inyección de dependencia. Algunas cosas son difíciles de probar de integración. Prueba unitaria + inyección de dependencia .

  • Real: Código que se estropea -> Tiempo de espera de la base de datos (difícil de reproducir).
  • Refactorización: Código que craps -> Repositorio (solo tiene acceso a datos) -> Base de datos
  • Prueba unitaria: Código que craps> Repositorio simulado para lanzar -> null
  • Ahora tiene una prueba fallida para el código que se estropea y puede solucionarlo.

Esta es la inyección de "dependencia". El desarrollador puede inyectar la dependencia a la base de datos, sustituyendo algo que simule el comportamiento de una dependencia. Bueno para todas las pruebas de bases de datos. De todos modos, con la prueba unitaria implementada, sabe que la solución hace lo que debería, pero aún necesita una prueba de integración. En este caso, es mejor que se centre en la regresión, lo que significa que probarlo no rompió nada más y la función aún funciona.

Ya ha creado su parche, así que supongo que mi respuesta es demasiado tarde.

Precipitado
fuente