Error de "tiempo de espera de solicitud de bloqueo excedido" al intentar ver jerarquías de base de datos

Estoy teniendo problemas con una base de datos.

1. Puedo ejecutar consultas básicas, aunque mucho más lento de lo normal.

2. Cuando intento ver los árboles de jerarquía para tablas, vistas o procedimientos en el Explorador de objetos SSMS, obtengo lock request time out period exceeded.

3. Mis informes SSRS que se ejecutan en objetos en esta base de datos ya no se están completando.

4. Los trabajos asociados con los procedimientos almacenados en esta base de datos tampoco se ejecutan.

Intenté usar sp_who2para encontrar y eliminar todas las conexiones en la base de datos, sin embargo, esto no ha resuelto el problema.

¿Que esta pasando aqui? ¿Cómo puedo resolver esto?

Fue causado por una reversión perpetua de una transacción. Finalmente tuve que reiniciar mi clúster de servidores

Excluyendo la consideración de Harware, tal vez necesite ejecutar el script para verificar cuáles son las actividades que retienen la Sesión SQL, uno de los escenarios comunes es no usar un Implicit transactions Optionen SQL Server Management Studio.

Recibí este problema cuando comencé una transacción explícita en la que creé una tabla en tempdb a partir de un script que se ejecuta en otra base de datos (no tempdb). Cuando comprometí la transacción, la confirmación no parecía liberar el bloqueo en la tabla que había creado en tempdb.

Gracias a esta página , hice USEtempdb y ejecuté y DBCC OPENTRANobtuve el SPID de la conexión a tempdb que estaba causando el bloqueo. Entonces yo KILL <SPID number>para matarlo.

No es muy elegante, y perdí toda la información en la tabla que había creado en tempdb, pero eso estaba bien en mi caso.

Hay tantas cosas que esto podría ser que todo lo que puedo ofrecer son algunas preguntas para ayudarlo a orientarse hacia una respuesta.

1. ¿Está la base de datos en un servidor dedicado solo a ejecutar SQL Server? De lo contrario, otros procesos podrían estar interfiriendo al robar el valioso tiempo del procesador.

2. ¿Está el servidor de base de datos esencialmente sin memoria? SQL Server intentará asignar cada byte que pueda, pero si está lleno y sus consultas requieren que se carguen más datos, entonces tiene que recurrir al uso de memoria virtual, lo que aumenta radicalmente la cantidad de tiempo que pueden tomar incluso consultas simples.

3. ¿El ancho de banda de la red del servidor DB es pequeño para manejar la transferencia de datos de manera oportuna?

Al final del día, parece que la máquina en la que aloja SQL Server es de tamaño inferior a lo que está tratando de hacer. Es completamente posible que finalmente haya alcanzado esos límites de hardware donde el rendimiento está disminuyendo radicalmente. Si este es el caso (las preguntas anteriores lo ayudarán a determinarlo), entonces querrá mover la base de datos a un servidor que tenga el tamaño adecuado para la cantidad de datos (y consultas) que está tratando de procesar.

Esto podría significar usar procesadores más rápidos, unidades más rápidas o simplemente instalar más RAM.

"Cuando intento ver los árboles de jerarquía de tablas, vistas o procedimientos en el Explorador de objetos de SSMS, obtengo un tiempo de espera de solicitud de bloqueo excedido".

Tuve exactamente el mismo problema. Fui a la ventana de ejecución de consultas y; ROLLBACKdeclaración escrita y ejecutada .

Parece que algunas de las series de declaraciones que estaba ejecutando antes de eso, tenían una transacción abierta. Específicamente, porque algunos de ellos eran declaraciones DDL. Una vez que emití la reversión, las jerarquías de objetos comenzaron a funcionar.

Como muchos ya lo habían señalado, por lo general, hay una transacción duradera, que en su mayoría causó que mi señorita usara SET IMPLICIT TRANSACTIONS ON, que no debe usarse en absoluto. Para ver por qué revisa el perspicaz artículo de Brent Ozar

De todos modos, puede obtener una lista de transacciones pendientes de larga duración utilizando la siguiente consulta.

SELECT
    [s_tst].[session_id],
    [s_es].[login_name] AS [Login Name],
    DB_NAME (s_tdt.database_id) AS [Database],
    [s_tdt].[database_transaction_begin_time] AS [Begin Time],
    [s_tdt].[database_transaction_log_bytes_used] AS [Log Bytes],
    [s_tdt].[database_transaction_log_bytes_reserved] AS [Log Rsvd],
    [s_est].text AS [Last T-SQL Text],
    [s_eqp].[query_plan] AS [Last Plan]
FROM
    sys.dm_tran_database_transactions [s_tdt]
JOIN
    sys.dm_tran_session_transactions [s_tst]
ON
    [s_tst].[transaction_id] = [s_tdt].[transaction_id]
JOIN
    sys.[dm_exec_sessions] [s_es]
ON
    [s_es].[session_id] = [s_tst].[session_id]
JOIN
    sys.dm_exec_connections [s_ec]
ON
    [s_ec].[session_id] = [s_tst].[session_id]
LEFT OUTER JOIN
    sys.dm_exec_requests [s_er]
ON
    [s_er].[session_id] = [s_tst].[session_id]
CROSS APPLY
    sys.dm_exec_sql_text ([s_ec].[most_recent_sql_handle]) AS [s_est]
OUTER APPLY
    sys.dm_exec_query_plan ([s_er].[plan_handle]) AS [s_eqp]
where [s_tdt].[database_transaction_begin_time] is not null
ORDER BY
    [Begin Time] ASC;

https://www.brentozar.com/archive/2018/02/set-implicit_transactions-one-hell-bad-idea/