Erro "tempo limite da solicitação de bloqueio excedido" Erro ao tentar ver as hierarquias do banco de dados

Estou tendo problemas com um banco de dados.

1. Eu posso executar consultas básicas, embora muito mais lentas que o normal.

2. Quando tento visualizar as árvores hierárquicas de tabelas, visualizações ou procedimentos no SSMS Object Explorer, recebo lock request time out period exceeded.

3. Meus relatórios do SSRS que são executados nos objetos desse banco de dados não estão mais sendo concluídos.

4. Os trabalhos associados aos procedimentos armazenados neste banco de dados também não são executados.

Eu tentei usar sp_who2para encontrar e matar todas as conexões no banco de dados, no entanto, isso não resolveu o problema.

O que está acontecendo aqui? Como posso resolver isto?

Isso estava sendo causado por uma reversão perpétua de uma transação. Acabei reiniciando meu cluster de servidores

Excluindo a consideração do Harware, talvez você precise executar o script para verificar quais são as atividades que retêm a Sessão SQL, um dos cenários comuns é não usar Implicit transactions Optionno SQL Server Management Studio.

Eu tive esse problema quando iniciei uma transação explícita na qual criei uma tabela no tempdb a partir de um script executado em outro banco de dados (não no tempdb). Quando confirmei a transação, o commit não parecia liberar o bloqueio na tabela que eu havia criado no tempdb.

Graças a esta página , eu USEd tempdb, executei DBCC OPENTRANe obtive o SPID da conexão com o tempdb que estava causando o bloqueio. Então eu KILL <SPID number>matá-lo.

Não muito elegante e perdi todas as informações da tabela que criei no tempdb, mas isso foi bom no meu caso.

Pode haver muitas coisas que tudo o que posso oferecer são algumas perguntas para ajudar você a encontrar uma resposta.

1. O banco de dados está em um servidor dedicado apenas à execução do SQL Server? Caso contrário, outros processos podem estar interferindo, roubando um tempo precioso do processador.

2. O servidor de banco de dados está essencialmente sem memória? O SQL Server tentará alocar todos os bytes que puder, mas se estiver em capacidade e suas consultas exigirem o carregamento de mais dados, será necessário usar a memória virtual, o que aumenta radicalmente a quantidade de tempo que as consultas simples podem levar.

3. A largura de banda da rede do servidor DB é pequena para lidar com a transferência de dados em tempo hábil?

No final do dia, parece que a máquina em que você está hospedando o SQL Server está abaixo do tamanho do que você está tentando fazer. É perfeitamente possível que você finalmente tenha atingido os limites de hardware em que o desempenho está caindo radicalmente. Se for esse o caso (as perguntas acima ajudarão você a determinar isso), convém mover o banco de dados para um servidor dimensionado corretamente para a quantidade de dados (e consultas) que você está tentando processar.

Isso pode significar o uso de processadores mais rápidos, unidades mais rápidas ou apenas a instalação de mais RAM.

"Quando tento visualizar as árvores hierárquicas para tabelas, visualizações ou procedimentos no SSMS Object Explorer, o tempo limite da solicitação de bloqueio é excedido."

Eu tive exatamente o mesmo problema. Eu fui para a janela de execução da consulta e; ROLLBACKdeclaração digitada e executada .

Parece que algumas das séries de instruções que eu estava executando antes disso, mantinham uma transação aberta. Especificamente, porque alguns deles onde instruções DDL. Depois de emitir a reversão, as hierarquias de objetos começaram a funcionar.

Como muitos já haviam apontado, geralmente há uma transação duradoura, causada principalmente pelo erro usado por SET IMPLICIT TRANSACTIONS ON, que não deve ser usado. Para saber por que, consulte o artigo de Brent Ozar

De qualquer forma, você pode obter uma lista de transações pendentes duradouras usando a consulta a seguir.

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/