Uma equipe de infraestrutura de um Ministério Público gerencia um sistema de gestão de documentos crítico baseado no SQL Server. O banco de dados opera com alta concorrência, e o DBA notou que as transações estão sofrendo com esperas (waits) excessivas, principalmente devido a deadlocks e longas durações de consultas. A equipe precisa implementar uma solução proativa e técnica para diagnosticar e mitigar a degradação de desempenho.
Considerando as ferramentas de monitoramento e as práticas avançadas de administração do SQL Server, a combinação de ações mais eficaz e tecnicamente correta para resolver o problema de latência e concorrência é:
AUtilizar exclusivamente o Monitor de Atividade no SQL Server Management Studio (SSMS) para identificar as consultas mais lentas e, em seguida, simplesmente adicionar índices clustered em todas as colunas de todas as tabelas para otimizar o acesso.
BFocar na inspeção dos logs de erro do Windows e no Performance Monitor (Perfmon) para verificar a utilização do disco e da CPU. As estatísticas internas do SQL Server (DMVs) seriam desabilitadas para reduzir a sobrecarga de monitoramento.
CImplementar uma política de Isolation Level READ UNCOMMITTED para todas as transações, eliminando totalmente os bloqueios e deadlocks. O diagnóstico seria feito por meio de traces de rede para isolar o tempo de latência entre o cliente e o servidor.
DUtilizar a ferramenta SQL Server Profiler para capturar todas as transações em tempo real. Os deadlocks seriam resolvidos apenas reiniciando o serviço do SQL Server durante os picos de espera para liberar os recursos bloqueados.
EAnalisar as Dynamic Management Views (DMVs), como sys.dm_os_wait_stats para identificar as classes de espera predominantes, e sys.dm_exec_requests para sessões ativas. Para resolver os deadlocks de forma proativa, configurar o Deadlock Graph usando Extended Events e ajustar o Isolation Level das transações.
Revelar gabarito e comentário▾
GabaritoE — Analisar as Dynamic Management Views (DMVs), como sys.dm_os_wait_stats para identificar as classes de espera predominantes, e sys.dm_exec_requests para sessões ativas. Para resolver os deadlocks de forma proativa, configurar o Deadlock Graph usando Extended Events e ajustar o Isolation Level das transações.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
SQL Server: diagnóstico de desempenho e deadlocks
Gabarito: letra E. A combinação mais eficaz e tecnicamente correta envolve o uso de Dynamic Management Views (DMVs) — como sys.dm_os_wait_stats para identificar as classes de espera predominantes e sys.dm_exec_requests para sessões ativas —, a configuração do Deadlock Graph via Extended Events para captura proativa de deadlocks e o ajuste do Isolation Level das transações. Essa abordagem é proativa, baseada em dados reais do motor e ataca diretamente as causas de latência e concorrência.
O problema descrito é clássico em bancos de dados relacionais: alta concorrência gera esperas (waits), e esperas excessivas degradam o desempenho. Para diagnosticar, o SQL Server expõe uma série de DMVs que funcionam como "painéis de controle" internos do motor. sys.dm_os_wait_stats agrega, desde a última inicialização do serviço, o tempo total que o servidor passou esperando por diferentes tipos de recurso (CPU, disco, bloqueios, etc.). Analisar essa DMV é o primeiro passo para saber onde está o gargalo: se a maior espera é por LCK_M_*, o problema é de bloqueio/concorrência; se é por PAGEIOLATCH_*, o problema é de I/O de disco; se é por CXPACKET, pode ser paralelismo. Já sys.dm_exec_requests mostra as sessões ativas no momento, permitindo identificar consultas em execução, o que estão esperando e por quanto tempo.
Para resolver deadlocks de forma proativa, a ferramenta moderna é o Extended Events, que substituiu o SQL Server Profiler como a solução recomendada de monitoramento. Com o Extended Events, é possível configurar o evento sqlserver.xml_deadlock_report (o famoso Deadlock Graph) para capturar, em tempo real, a ocorrência de deadlocks, incluindo as duas transações envolvidas, os recursos disputados e as instruções SQL. Isso permite analisar a causa raiz e ajustar a aplicação ou o banco. Além disso, o ajuste do Isolation Level é uma prática correta: níveis mais altos de isolamento (como SERIALIZABLE) aumentam o bloqueio e a chance de deadlock; níveis mais baixos (como READ COMMITTED, o padrão, ou SNAPSHOT) reduzem o bloqueio. A escolha do nível deve equilibrar consistência e concorrência, conforme a necessidade de cada transação.
A banca explora aqui o conhecimento das ferramentas nativas do SQL Server e das boas práticas de administração. As alternativas incorretas misturam ferramentas inadequadas, soluções drásticas e até mesmo conceitos errados, como desabilitar DMVs ou usar READ UNCOMMITTED para "eliminar" deadlocks. A pegadinha central é distinguir o que é uma prática técnica e proativa (DMVs + Extended Events + ajuste de isolamento) do que é uma solução paliativa, reativa ou até mesmo prejudicial.
Guarde o trio de ouro para diagnóstico e mitigação de problemas de concorrência no SQL Server: DMVs para diagnosticar, Extended Events para capturar eventos específicos (como deadlocks) e ajuste de Isolation Level para mitigar. É exatamente essa combinação que a alternativa E apresenta, e é nela que as demais alternativas falham.
Diagnóstico de desempenho (SQL Server)
1DMVs (diagnosticar)
sys.dm_os_wait_stats
LCK_M_* → bloqueio/concorrência
PAGEIOLATCH_* → I/O de disco
CXPACKET → paralelismo
sys.dm_exec_requests
sessões ativas
o que esperam e por quanto tempo
2Extended Events (capturar)
Deadlock Graph (xml_deadlock_report)
transações envolvidas
recursos disputados
instruções SQL
3Isolation Level (mitigar)
READ COMMITTED (padrão) reduz bloqueio
SNAPSHOT reduz bloqueio
SERIALIZABLE aumenta bloqueio e deadlock
LEVEL · soulevel.com.br
Alternativa A — ❌ Incorreta
O Monitor de Atividade do SSMS é uma ferramenta útil para uma visão geral, mas usá-lo exclusivamente é insuficiente para um diagnóstico profundo. Além disso, a proposta de "adicionar índices clustered em todas as colunas de todas as tabelas" é um erro grave: índices em excesso degradam a performance de operações de escrita (INSERT, UPDATE, DELETE) e consomem espaço em disco. A criação de índices deve ser seletiva, baseada nas consultas reais e no plano de execução, não uma ação automática e indiscriminada.
Alternativa B — ❌ Incorreta
Inspecionar logs do Windows e usar o Perfmon para CPU e disco é uma prática complementar válida, mas desabilitar as DMVs para reduzir sobrecarga é um equívoco técnico. As DMVs são a principal fonte de diagnóstico interno do SQL Server e têm sobrecarga mínima; desabilitá-las eliminaria justamente a capacidade de identificar as causas de espera. A alternativa ignora a ferramenta mais poderosa de diagnóstico do próprio banco.
Alternativa C — ❌ Incorreta
O Isolation Level READ UNCOMMITTED não elimina deadlocks — ele elimina bloqueios de leitura, permitindo leituras sujas (dirty reads), mas transações de escrita continuam bloqueando umas às outras e podem gerar deadlocks. Além disso, usar READ UNCOMMITTED para todas as transações compromete a consistência dos dados, o que é inaceitável em um sistema crítico de gestão de documentos. O diagnóstico por "traces de rede" é irrelevante para o problema de concorrência interna do banco.
Alternativa D — ❌ Incorreta
O SQL Server Profiler é uma ferramenta legada e de alta sobrecarga, não recomendada para capturar "todas as transações em tempo real" em produção. E a proposta de "reiniciar o serviço do SQL Server durante os picos" é uma solução drástica e reativa que causa indisponibilidade total do sistema, não resolve a causa raiz dos deadlocks e ainda pode corromper transações em andamento. É exatamente o oposto de uma abordagem proativa.
Alternativa E — ✅ Correta ⟵ GABARITO
Esta alternativa combina corretamente as ferramentas e práticas adequadas: (1) DMVs (sys.dm_os_wait_stats e sys.dm_exec_requests) para diagnóstico baseado em dados reais de espera e sessões ativas; (2) Extended Events com o Deadlock Graph para captura proativa e detalhada de deadlocks; e (3) ajuste do Isolation Level para mitigar a contenção de bloqueios. Essa é a abordagem técnica, proativa e recomendada pela Microsoft para diagnosticar e resolver problemas de latência e concorrência.
NÃO CAIA NESSA!
A banca tenta confundir o candidato com soluções extremas e reativas. A alternativa C promete "eliminar totalmente" deadlocks com READ UNCOMMITTED — impossível, pois escritas continuam bloqueando. A alternativa D sugere reiniciar o serviço, o que é uma medida drástica de indisponibilidade, não uma solução. A pegadinha é reconhecer que a resposta correta combina diagnóstico (DMVs) + captura de eventos (Extended Events) + mitigação (Isolation Level), e não uma única ferramenta milagrosa.
PEGA ESSA DICA!
Para questões de desempenho no SQL Server, lembre-se do fluxo: 1) Diagnosticar com DMVs (sys.dm_os_wait_stats, sys.dm_exec_requests, sys.dm_exec_query_stats); 2) Capturar eventos específicos com Extended Events (Deadlock Graph, bloqueios longos); 3) Mitigar ajustando índices, reescrevendo consultas e configurando o Isolation Level adequado. Essa sequência resolve a maioria das questões sobre o tema.