esta bloqueando variosdos recursos, a cada meio segundo um bloqueio ira surgir. E possivel verificaras conexoes e os bloqueios utilizando a consulta abaixo:Verifica as sessoes e os bloqueiosSELECT s.session_id As Sessao, program_name As Aplicacao, R.status As StatusRequisicao,blocking_session_id As SessaoBloqueadoraFROM sys.dm_exec_sessions As SLEFTOUTER JOIN sys.dm_exec_requests As R ON S.session_id= R.session_idWHERE S.session_id> 50 and S.session_id != @@spid Aconsulta acima mostra todas as sessoes e suas respectivas requisicoes (sehouver) conforme a tabela abaixo: Sessao Aplicacao Status da Requisicao Sessao Bloqueadora 51 Microsoft SQL Server Management Studio NULL NULL 52 Microsoft SQL Server Management Studio Query NULL NULL 54 App00 suspended 52 55 App01 suspended 52 56 App02 suspended 55 57 App03 suspended 52 58 App04 suspended 57 59 App05 suspended 52 60 App06 suspended 55 61 App07 suspended 52 62 App08 suspended 57 63 App09 suspended 54 64 App10 suspended 59 65 App11 suspended 54 66 App12 suspended 55 67 App13 suspended 62 68 App14 suspended 55 69 App15 suspended 54 70 App16 suspended 54 71 App17 suspended 57 72 App18 suspended 57 73 App19 suspended 54 74 App20 suspended 55 75 App21 suspended 54 76 App22 suspended 59 77 App23 suspended 59 78 App24 suspended 62 Paraque as sessoes sejam mantidas exatamente com os mesmos IDs e importante que oSQL Server Management Studio possua apenas tres conexoes (uma para o objectexplorer, uma para a transacao e uma para as consultas. As conexoes devem serabertas exatamente nessa ordem e nao deve haver ninguem conectado).Comopode ser observado, algumas sessoes nao possuem bloqueios enquanto outrasencontram-se bloqueadas. A coluna "Sessao Bloqueadora" mostra o ID dasessao que esta bloqueando uma outra sessao. Como pode ser observado, algumassessoes como a 52 e a 54 sao responsaveis por bloquear varias requisicoes quepor sua vez acabam bloqueandos outras e assim e montada uma cadeia debloqueios. E possivel por exemplo visualizar que a sessao 52 bloqueia a sessao54 que bloqueia a sessao 73 por exemplo. Isso mostra uma cadeia em tres niveisembora haja mais niveis na cadeia de bloqueios.Emum cenario desses, os iniciantes optariam por parar o servico ou ainda eliminaraleatoriamente algumas sessoes ate que um nivel de estabilidade fosse obtido.Tais medidas podem nao ser muito efetivas para resolver o problema. Parar oservico por exemplo provocara uma indisponibilidade nas aplicacoes que dependemdo SQL Server. Eliminar sessoes de forma aleatoria provocara a reversao detransacoes que podem significar graves problemas futuros (imagine um usuarioque mandou efetivar uma aplicacao financeira ter a sua requisicao cancelada).Ainda que funcionem, evitar descobrir a causa real dos bloqueios pode fazer comeles voltem mesmo apos reiniciar um servico por exemplo. Tais solucoes saoainda pouco factiveis em ambientes de missao critica.Amedida mais eficiente e identificar a sessao que esta no topo da cadeia, ouseja, qual a requisicao que esta provocando o bloqueio de outras sessoes eassim sucessivamente. Uma primeira tentativa, e identificar o maior bloqueador,pois, tratar o maior bloqueador significa pode significar liberar uma grandequantidade de sessoes. A consulta abaixo mostra a lista do maior bloqueador.SELECT blocking_session_id As Sessao, COUNT(session_id) As TotalBloqueiosFROM sys.dm_exec_requestsWHERE blocking_session_id> 0GROUPBY blocking_session_idORDERBY TotalBloqueios DESCAlista abaixo mostra as quantidades de bloqueio: Sessao Total de Bloqueios 54 6 55 5