51% dos incidentes aconteceram de madrugada. Veja o painel completo de 4 instâncias, com 2.824 incidentes registrados.
Dados reais anonimizados com autorização do cliente. Instâncias, volumes e bancos foram renomeados; nenhum nome, caminho ou consulta real aparece aqui.
15/06/2026 a 18/10/2026 · 120 dias · 4 instâncias · dados anonimizados
Saúde média
93,6
▲ 1,8Disponibilidade medida
99,97%
Incidentes
2.824
51% de madrugada
Alertas evitados
471
789 → 318
Oportunidades
105 GB
528 índices de 1.326 sem leitura
Servidor C
tempdb escreve a 280 ms
Latência de escrita do tempdb em 280 ms no Servidor C; o recomendado é abaixo de 20 ms.
Ação sugerida: Mover o tempdb para armazenamento dedicado de baixa latência.
Servidor B
Uma query consome 80% da CPU
A query nº 1 do Servidor B concentra 80% da CPU consumida por queries.
Ação sugerida: Revisar plano de execução e índices dessa query.
Servidor A
Volume com 86% de uso
O maior volume do host on-premise está em 86% de ocupação.
Ação sugerida: Planejar expansão ou limpeza antes de atingir o limite.
528 índices sem leitura (105 GB)
Índices que nenhuma query lê ocupam espaço e custam escrita.
Ação sugerida: Revisar e remover os índices sem uso.
Azure SQL
Estatísticas desatualizadas
94 de 100 tabelas do Azure SQL com estatísticas velhas.
Ação sugerida: Agendar atualização de estatísticas.
Como cada instância está em seis dimensões. O ícone e o texto indicam o estado, além da cor.
Estabilidade
Disponibilidade
I/O
Capacidade
Eficiência
Manutenção
Servidor A
Servidor B
Servidor C
Azure SQL
Servidor C concentra quase metade dos incidentes. 51% acontecem de madrugada e 69% têm causa em gargalo de I/O, só 4% em CPU.
Incidentes por semana
Índice de saúde semanal (0–100)
Causa raiz dos incidentes
Gargalo de I/O
69,2% · 1.933
Pressão de memória
20,5% · 573
CPU saturada
3,9% · 109
Inacessível
3% · 84
Restart
1,8% · 50
Outros
1,6% · 45
Incidentes por dia da semana e hora
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
seg.
ter.
qua.
qui.
sex.
sáb.
dom.
Os bloqueios acompanham o horário comercial no Servidor A.
Conexões médias por hora
Bloqueios por hora
Os servidores A, B e C rodam no mesmo host (875 GB de RAM). O maior volume está em 86% de uso.
Volumes
Volume 1 · 2 TB
86%
Volume 2 · 1 TB
64%
Volume 3 · 126 GB
63%
Volume 4 · 1 TB
45%
Volume 5 · 128 GB
31%
Volume 6 · 256 GB
12%
Volume 7 · 64 GB
9%
Volume 8 · 512 GB
6%
Crescimento e autonomia
GB/mês
Autonomia
Servidor A
—
—
Servidor B
16 GB
—
Servidor C
—
—
Azure SQL
—
—
Dias com log em 80% ou mais
0 d
Uma query consome 80% da CPU do Servidor B. 528 índices (105 GB) nunca são lidos.
Concentração de CPU nas queries
Servidor A
22% · 63%
Servidor B
80% · 96%
Servidor C
16% · 64%
Azure SQL
38% · 63%
Índices sem leitura
528
de 1.326 · 105 GB
Sugestões de índice
0
0 de alto impacto
Estatísticas desatualizadas
94
de 100 tabelas
O tempdb escreve a 280 ms no Servidor C e 104 ms no A; o recomendado é abaixo de 20 ms.
Servidor A
Bancos
31
Tamanho
1,8 TB
Conexões
429 · máx 925
Memória SQL
288 GB
PLE médio
39 mil s
Amostras c/ bloqueio
26%
Índices sem leitura
453 de 928
Servidor B
Bancos
8
Tamanho
592 GB
Conexões
140 · máx 329
Memória SQL
95 GB
PLE médio
63 mil s
Crescimento
16 GB/mês
Query nº 1
80% da CPU
Servidor C
Bancos
8
Tamanho
503 GB
Conexões
25 · máx 50
Memória SQL
63 GB
PLE médio
28 mil s
Incidentes
1.375
tempdb escrita
280 ms
Azure SQL
Bancos
2
Tamanho
430 GB
Conexões
17 · máx 32
Espera dominante
CPU 69%
Leitura de dados
128 ms
Estatísticas velhas
94 de 100
Índices sem leitura
60 GB
Dos 2.824 incidentes em 4 instâncias, 51% ocorreram entre 0h e 7h, quando ninguém está olhando. Sem monitoramento contínuo e alerta imediato, o problema só aparece na manhã seguinte, como reclamação de usuário.
A causa raiz mais comum foi gargalo de I/O, não falta de processador. Comprar mais CPU não resolveria; o caminho é olhar armazenamento, latência e queries que leem demais.
O recomendado para o tempdb é abaixo de 20 ms de latência de escrita. Em um dos servidores ele chegou a 280 ms, o que atrasa qualquer consulta que ordena, agrupa ou usa tabelas temporárias.
Em um dos servidores, uma única query concentra 80% de toda a CPU gasta por queries. Corrigir um plano de execução ou criar um índice nela libera mais capacidade que qualquer upgrade de hardware.
De 1.326 índices analisados, 528 não tiveram nenhuma leitura no período. Eles ocupam 105 GB e ainda custam escrita a cada alteração de dados. Remover os índices sem uso reduz backup, manutenção e latência.
O codeDB gera este mesmo panorama para a sua empresa, todo dia, automaticamente. 30 dias grátis, sem cartão de crédito.
Monitoramento inteligente de SQL Server com agente local seguro e diagnósticos em tempo real.
© 2026 codeDB. Todos os direitos reservados.
Powered by codeDB
codeDB Informática Ltda — CNPJ 18.953.756/0001-10 — Florianópolis/SC