Forzando un tiempo de espera de consulta en SQL Server

Question

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

No podemos obtener un tiempo de espera. Abrí una transacción de SQL Mgmt Studio y actualicé cada fila para bloquearlos, pero eso no hace que INSERT agote el tiempo de espera (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 bloqueo? Cualquier entrada es apreciada.

Answer 1

plazo esto y luego intentar su inserción ...

select * from yourTable with (holdlock,tablockx) 

aquí, se puede bloquear durante 5 minutos:

BEGIN TRANSACTION 

SELECT * FROM yourTable WITH (TABLOCKX, HOLDLOCK) 

WHERE 0 = 1 

WAITFOR DELAY '00:05' 

ROLLBACK TRANSACTION 

Answer 2

Se puede decir que su código SQL que esperar un minuto antes de regresar:

WaitFor Delay '00:01:00' 

Answer 3

Mira esta publicación del blog. Básicamente SQL Server no tiene tiempos de espera de consulta. Los clientes pueden exigir el tiempo de espera de SQL, pero el motor no lo hace.

http://blogs.msdn.com/khen1234/archive/2005/10/20/483015.aspx

Answer 4

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

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

• Real: Código que craps -> Tiempo de espera de la base de datos (difícil de reproducir).
• Refactor: Código que los dados -> Repositorio (hace acceso a datos solamente) -> Base de datos
• Unidad de prueba: código que los dados>Mock repository para lanzar -> nula
• Ahora usted tiene una prueba en su defecto para el código que dados y puede arreglarlo

Esto es inyección de "dependencia". El desarrollador puede inyectar la dependencia a la base de datos, sustituyendo algo que simula el comportamiento de una dependencia. Es bueno hacerlo para todas las pruebas de bases de datos. De todos modos, con la prueba de la unidad en su lugar, sabrá que la solución funciona como debería, pero aún necesita una prueba de integración. En este caso, puede centrarse mejor en la regresión, lo que significa que probarla no rompió ninguna otra cosa y la función aún funciona.

Ya ha creado su parche, por lo que supongo que mi respuesta es demasiado tarde.