Artigos práticos sobre ClickHouse, SQL Server, arquitetura analítica, desempenho, migração e operações de banco de dados.
Um guia prático para identificar planos sensíveis a parâmetros no SQL Server, comprovar a causa e escolher a correção de menor risco.
Ler artigoUm job pode indicar sucesso mesmo pulando bancos, processando zero linhas ou terminando tarde. O status final não prova o resultado esperado.
Ler artigoAmbas guardam linhas intermediárias, mas estatísticas, compilação, índices e transações podem gerar planos de execução muito diferentes.
Ler artigoCompressão row e page reduz armazenamento e I/O, mas adiciona CPU e não beneficia todas as tabelas igualmente. A decisão depende dos dados e da carga.
Ler artigoParticionamento é frequentemente apresentado como ganho automático. Seus maiores benefícios aparecem em ciclo de vida, janela deslizante, arquivamento e limites de manutenção.
Ler artigoSQL dinâmico ajuda em filtros opcionais e formatos variáveis, mas concatenar texto introduz injeção, erros de aspas, pouco reuso de planos e diagnóstico difícil.
Ler artigoFalhas de armazenamento, memória, firmware ou software podem danificar páginas sem parar a aplicação. Backups podem preservar corrupção não detectada.
Ler artigoLeitores e escritores podem se bloquear no read committed com locks. RCSI usa versões de linha para reduzir isso, mas altera recursos e concorrência.
Ler artigoUm índice não ajuda quando o predicado esconde a coluna em uma função ou cálculo. O SQL Server pode escanear todas as linhas candidatas.
Ler artigoCom tipos incompatíveis, o SQL Server pode converter uma coluna indexada durante a execução. Isso causa scans, estimativas ruins e CPU desnecessária.
Ler artigoCrescimento inesperado pode encher o volume, atrasar transações e réplicas e prolongar a recuperação. Reduzir o arquivo trata apenas o sintoma.
Ler artigoO padrão de max server memory pode deixar Windows e outros serviços sem memória. Um valor baixo causa leituras, compilações e pressão de grants desnecessárias.
Ler artigoValores padrão raramente representam um projeto intencional. Paralelismo excessivo aumenta pressão de CPU e workers; restrição demais atrasa consultas analíticas.
Ler artigoUma longa lista de sessões bloqueadas faz todas parecerem culpadas. Normalmente uma transação no início da cadeia controla duração e impacto.
Ler artigoUm job concluído prova que o SQL Server gravou um backup. Não prova que bancos, chaves, cadeia de logs e dependências serão restaurados dentro do prazo.
Ler artigoUm grupo de disponibilidade pode mostrar réplicas saudáveis enquanto os objetivos de recuperação continuam em risco. Filas, listener, backups e failover exigem monitoramento explícito.
Ler artigoO otimizador escolhe joins, acessos e memória a partir das linhas estimadas. Quando a estimativa diverge da realidade, um plano razoável pode ficar caro.
Ler artigoO TempDB atende ordenações, hashes, versionamento de linhas, objetos temporários, spills e tabelas internas. Uma configuração ruim pode criar um gargalo compartilhado.
Ler artigoDeadlock é um ciclo em que sessões mantêm recursos necessários umas às outras. O SQL Server encerra uma participante, mas a vítima não é necessariamente a causa.
Ler artigoMuitos incidentes desaparecem antes da captura do plano. O Query Store preserva consultas, planos, tempos e esperas para análise posterior.
Ler artigoReconstruir todos os índices em um cronograma fixo consome CPU, I/O, log e janela de manutenção sem garantir benefício mensurável.
Ler artigo