SQL Server Health Check 1.6
Procedimento para coletar evidências de saúde em instâncias SQL Server e consolidar o resultado no navegador.
1. Fluxo recomendado
- Abra a ferramenta e copie cada consulta SQL.
- Execute a consulta no contexto indicado, preferencialmente em janela de coleta documentada.
- Exporte o resultado como CSV, mantendo os nomes das colunas.
- Importe cada CSV no bloco correspondente. Para várias instâncias, consolide arquivos com cabeçalho idêntico e mantenha
server_name. - Gere o Health Check, revise os achados e aplique filtros.
- Exporte os achados em CSV ou baixe o relatório HTML para revisão e compartilhamento controlado.
2. Contexto e permissões
- Instância e bancos: execute em master. Consulta
sys.databasese propriedades do servidor. Permissões de metadados podem limitar visibilidade. - AlwaysOn: execute em master em cada réplica que deseja observar. Requer HADR habilitado e permissões para consultar DMVs de AlwaysOn. Inclui modo de disponibilidade/failover e prontidão da secundária por banco; a prontidão não substitui validação de todas as databases, quorum e procedimento de mudança.
- SQL Agent Jobs: consulta msdb, última execução, contagem de falhas em 7 dias, schedules habilitados e próxima execução. O calendário de schedules pode ter atualização defasada pelo SQL Agent; confira o job diretamente antes de agir.
- Backups: consulta msdb.dbo.backupset. O histórico pode ser limpo, limitado por retenção ou não registrar operações feitas por ferramentas externas.
- Arquivos: consulta sys.master_files e DBCC SQLPERF(LOGSPACE). Apresenta tamanho alocado, growth, maxsize e percentual de uso do log. O espaço livre interno dos arquivos DATA é coletado em uma consulta separada, executada no contexto de cada banco.
- Configurações: consulta sys.configurations e mostra valores configurados/em uso para opções selecionadas.
3. Como interpretar a severidade
| Nível | Interpretação |
|---|---|
| CRÍTICO | Sinal que merece investigação prioritária, como banco offline, AG desconectado, job com falha ou backup ausente/atrasado conforme limites padrão. |
| ATENÇÃO | Condição que pode representar risco operacional ou merece revisão, como AUTO_SHRINK, PAGE_VERIFY diferente de CHECKSUM, filas grandes ou log com alta utilização. |
| INFO | Contexto, ausência de dados ou recomendação não universal. Não significa necessariamente falha. |
| OK | Verificação pontual sem alerta pela regra implementada. Não representa certificação de saúde. |
4. Limites e regras padrão
- Backup FULL: alerta crítico quando não há registro no msdb ou a última conclusão ultrapassa 24 horas.
- Backup LOG: para recovery FULL/BULK_LOGGED, alerta crítico quando não há registro ou quando ultrapassa 2 horas.
- Backup DIFFERENTIAL: ausência é apenas informativa; não é requisito universal.
- AlwaysOn: estado NOT_HEALTHY, desconexão, suspensão ou NOT SYNCHRONIZING gera alerta crítico. Filas de envio/redo acima de 1 GB geram atenção.
- Log: utilização a partir de 85% gera atenção; a partir de 95% gera crítico.
- Os limites são defaults de triagem, não políticas universais. Ajuste a interpretação ao RPO, RTO, janela de backup e criticidade do banco.
5. Cuidados operacionais
- Um registro ausente no msdb não prova que não existe backup. Ferramentas como Veeam ou soluções de terceiros podem manter o histórico fora do msdb; confira o catálogo da ferramenta e os arquivos.
- Backup concluído não garante restore válido. Faça testes de restauração periódicos, valide a cadeia de FULL/DIFF/LOG e execute DBCC CHECKDB conforme política.
- Filas de AG e estado de sincronização são snapshots. Correlacione com tendência, geração de log, throughput de rede, I/O e redo.
- MAXDOP, Cost Threshold, memória e configurações de segurança dependem de workload, CPU/NUMA, memória do host e arquitetura. A ferramenta evita prescrever mudanças automáticas.
- Não execute shrink, failover, alteração de configuração, rebuild de índice ou correção de job com base apenas no relatório.
6. Espaço interno DATA e limites
Execute a consulta da categoria Espaço interno DATA individualmente no contexto de cada banco. Ela usa FILEPROPERTY(name,'SpaceUsed') para estimar páginas ocupadas e espaço livre dentro do arquivo. Não representa espaço livre no volume nem espaço disponível no storage. Não é recomendação automática de shrink.
Os limites da tela permitem ajustar FULL, LOG, filas AG, utilização do log e espaço livre interno DATA. O score de 0 a 100 é uma métrica heurística de triagem, não um SLA nem certificação de saúde.
7. SQL Agent e AlwaysOn
O bloco de SQL Agent alerta sobre falhas registradas nos últimos sete dias e jobs habilitados sem schedule ativo. Jobs executados sob demanda podem ser intencionais. A próxima execução é informativa e depende da atualização de msdb.dbo.sysjobschedules.
O bloco AlwaysOn avalia desconexão, saúde, suspensão, filas de envio/redo e o indicador is_failover_ready para secundárias síncronas. A indicação é por database e não certifica o cluster inteiro, quorum, conectividade de rede ou prontidão operacional do failover.
8. Revisão de configurações e score
A revisão inclui alertas pontuais para opções de segurança, compressão, MAXDOP e Max Server Memory em relação à memória física. São heurísticas para revisão, não recomendações universais. O score de 0 a 100 combina severidade e cobertura das sete categorias; interprete-o junto com os achados individuais e o contexto do ambiente.
9. Fora do escopo da versão 1.6
- Conexão direta ao SQL Server, agendamento ou coleta automática.
- Validação de restore, integridade física/lógica, cadeia de backup ou consistência transacional.
- Capacidade dos volumes, latência de storage e previsão estatística de crescimento.
- Validação completa de WSFC/quorum, latência de rede, latência de storage, bloqueios e waits globais.
- Recomendações automáticas de MAXDOP/memória com base no hardware.