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

17

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?

Lloyd Banks
fonte
Consulte também: stackoverflow.com/questions/12167570/… ; não tenho certeza se isso conta como duplicado ou não.
LittleBobbyTables
Com base no seu comentário à minha resposta abaixo, acho que você precisa fornecer muito mais informações. Como o servidor é dimensionado, você assistiu aos contadores de desempenho, está trocando para o disco ou de outra forma os recursos passam fome? Certifique-se de verificar o que foi exposto acima e não apenas assumir qualquer coisa. Além disso, isso acontece quando você se conecta enquanto está remotamente conectado à área de trabalho? O problema ocorre apenas ao acessar a partir de um único local? Como está o clima da rede para esse servidor (e sua conexão com ele)?
NotMe
3
Parece que você possui transações abertas que estão bloqueando o acesso de leitura às tabelas.
precisa saber é o seguinte

Respostas:

11

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

Lloyd Banks
fonte
2
Reiniciar o serviço resolveu isso para mim.
HerrimanCoder
Reiniciando em tal situação pode levar você a base de dados Recuperação
MaazKhan47
dbcc OPENTRAN vai dizer se houverem transações abertas
Nate Anderson
Acho estranho que, enquanto uma transação esteja em execução, não posso expandir a seção de tabelas, por exemplo. Sem dados lidos, sem DDL, nada, apenas a lista de tabelas.
gerleim
5

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.

Rodovalho
fonte
Oi pregado, você pode entrar em mais detalhes sobre o que está sugerindo?
Parece que, embora isso não seja totalmente explicado, pode ser uma resposta melhor, reversão perpétua de transações que não retrocedem e só são ativadas devido a transações implícitas.
ConstantineK
olhando para trás, a pergunta que eu não poderia dizer que deve ser uma reversão perpétua de uma transação. A julgar pelo que locking request time out period exceedeu diria, a corrida implicit transaction optiondaria uma pista melhor das causas.
Turbot
Ferramentas / Opções / Consulta execução / SQL Server / ANSI / SET transações implícitas
Tadej
3

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.

Baodad
fonte
No nosso caso, um comando DML (redefinição de exibição) foi emitido contra um banco de dados usando SET IMPLICIT TRANSACTIONS ON sem COMMIT TRANSACTION , o que causou acidentalmente uma transação duradoura. O uso do DBCC OPENTRAN ajudou a rastrear rapidamente esse problema.
Julio Nobre
1

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.

Eu não
fonte
Não é um problema de hardware. O cluster do servidor hospeda vários bancos de dados. Este é o único banco de dados com problemas.
@LoydBanks: Isso não significa que isso não seja um problema de hardware. Se eu tiver dois bancos de dados, um com 20 GB de tamanho e alta taxa de transações e outro com 1 GB com uma taxa de transações menor, esperaria que o banco de dados de 1 GB fosse trocado pela memória virtual; o que aumentaria o tempo de consulta. Se o db de 20 GB estiver sendo atingido com força suficiente, isso poderá levar a problemas de conectividade com o menor.
NotMe
1

"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.

TS
fonte
0

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/

Julio Nobre
fonte