Posterior a de esta extensa recopilación de información dimos con la respuesta esta dificultad que tienen algunos los lectores. Te ofrecemos la respuesta y nuestro deseo es que te sea de mucha apoyo.
Solución:
Bueno, desde el punto de vista de la aplicación, hay:
- tiempo de espera de conexión (cuánto tiempo está dispuesta a esperar la aplicación para establecer una conexión con SQL Server)
- tiempo de espera del comando (cuánto tiempo está dispuesta a esperar la aplicación para que se complete un comando, incluida la extracción de los resultados de SQL Server)
En mis días clásicos de ASP, los valores predeterminados para estos eran 15 y 30 segundos respectivamente, no tengo idea de cuáles son los valores predeterminados en .NET hoy.
SQL Server tiene su propio conjunto de tiempos de espera, por ejemplo:
- Tiempo de espera de consulta remota. El valor predeterminado es 600 segundos (10 minutos).
- Tiempo de espera de inicio de sesión remoto. El valor predeterminado es 10 segundos.
- Consulta espera. El valor predeterminado es -1 (25 x costo de consulta).
- Texto completo controlador de protocolo se acabó el tiempo. El valor predeterminado es 60 segundos.
Puede ver estos valores para su sistema aquí:
SELECT * FROM sys.configurations
WHERE configuration_id IN (1519,1520,1541,1557);
También hay @@LOCK_TIMEOUT (que por defecto es -1 (infinito)). Este es el tiempo que esperará SQL Server en un recurso bloqueado. Puede anular esto para una sesión en particular usando SET LOCK_TIMEOUT. Más detalles aquí.
Supongo que los interbloqueos también podrían caer en esta categoría. El sistema busca situaciones de interbloqueo cada 5 segundos, y no existe una fórmula mágica para determinar cuándo se producirá el interbloqueo en relación con el momento en que se inició alguna de las solicitudes involucradas. Esto se debe a que SQL Server no permite que gane la transacción más antigua; elige a la víctima en función de DEADLOCK_PRIORITY y la cantidad estimada de recursos necesarios para hacer retroceder a la víctima. Más detalles aquí.
También hay un tiempo de espera de concesión de memoria (que se puede personalizar mediante el regulador de recursos). Dependiendo de la concurrencia, una consulta no fallará necesariamente si alcanza el tiempo de espera antes de obtener toda la memoria solicitada, solo se ejecutará con la cantidad asignada (y, por lo tanto, podría ser menos eficiente). Si falla, es probable que vea el mensaje 8645.
Puede hacerse una idea de otros posibles escenarios de tiempo de espera que pueden ocurrir dentro de SQL Server revisando estos mensajes de error:
SELECT message_id, [text]
FROM sys.messages
WHERE language_id = 1033
AND ([text] LIKE '%timeout%' OR [text] LIKE '%time out%')
Sin embargo, no creo que sea práctico, factible o productivo que alguien intente brindarle una lista completa y exhaustiva de cada situación de tiempo de espera posible. Resuelva los problemas que tiene, en lugar de resolver prematuramente un montón de problemas que probablemente nunca tendrá…
Aquí se tocan tres conceptos diferentes. Esperemos que esto brinde una buena explicación de lo que son, y a partir de ahí puedas descubrir cómo evitarlos.
Bloqueo (también conocido como bloqueo en vivo)
El bloqueo ocurre cuando una consulta intenta adquirir un bloqueo, pero tiene que esperar en la cola de bloqueo antes de que se conceda el bloqueo. Puede parecer desde el exterior que la consulta no está haciendo nada, porque está esperando que los otros procesos liberen los bloqueos que se encuentran delante de él en la cola. Bloqueo pueden causar interbloqueos si los bloqueos se adquieren en un orden específico (lo describo a continuación).
Tiempos de espera
Los tiempos de espera se producen cuando un cliente realiza una solicitud de un recurso y espera una respuesta. Si no se recibe respuesta dentro de un período de tiempo determinado, el cliente genera un error en lugar de esperar para siempre. Los tiempos de espera pueden ocurrir por una variedad de razones (bloqueo, una consulta que estaba haciendo mucho trabajo, o la red era muy lenta, o…), pero en última instancia porque el cliente estaba esperando y decidió que no quería a esperar más.
interbloqueos
Los interbloqueos ocurren cuando dos o más procesos mantienen bloqueos en los recursos y también intentan bloquear los recursos en poder de los otros procesos. Esto crea una situación en la que ninguna consulta puede continuar a menos que una de ellas finalice o se revierta. Demostré cómo funciona esto en un video de demostración aquí.
Si guardas algún contratiempo o forma de medrar nuestro reseña eres capaz de escribir una interpretación y con placer lo interpretaremos.