Consultoria SQL Server: o que avaliar antes de contratar suporte especializado.

Duas e meia da manhã. O job de index rebuild estourou a janela noturna. O log de transações cresceu 80GB em uma hora, o disco encheu, e o ambiente de produção parou. Ninguém testou aquela manutenção contra o volume real do mês corrente.

Outro cenário comum: uma stored procedure que rodava em segundos passa a levar minutos depois de um update de estatísticas rotineiro. O plano de execução foi recompilado com base num conjunto de parâmetros atípico e ficou em cache — parameter sniffingclássico, e ninguém liga a degradação ao update porque "estatísticas não deveriam causar isso".

Boa parte do parque SQL Server no Brasil ainda roda em versões antigas (2012, 2014, 2016), com dívida técnica acumulada e licenciamento Core-based mal dimensionado. Isso tem custo direto: em licença paga sem necessidade, em risco operacional, e em janelas de manutenção que ficam cada mês mais apertadas. Consultoria SQL Server séria existe justamente para reverter esse acúmulo — antes do próximo incidente.

Os sintomas abaixo aparecem quase sempre juntos em ambientes que ficaram sem cuidado técnico de fundo por mais de um ou dois anos:

1. Jobs de manutenção que ultrapassam a janela disponível

Index rebuild, reorganize, atualização de estatísticas, checkdb e backup full passam a competir pela mesma janela noturna. Quando a tabela cresce, o tempo do job cresce junto, até estourar. A solução não é "rodar de madrugada mais cedo" — é separar manutenção por critério (apenas índices com fragmentação acima do threshold), trocar REBUILD por REORGANIZE onde cabe, e dimensionar corretamente o MAXDOP da operação.

2. Deadlocks frequentes entre transações concorrentes

Deadlock não é falha do produto — é a aplicação adquirindo locks em ordens diferentes entre transações simultâneas. O caminho técnico é ligar trace flag 1222 ou capturar o evento xml_deadlock_report em Extended Events, ler o deadlock graph (quais recursos, quais sessões, qual o ciclo de espera) e ajustar a ordem de acesso nas transações da aplicação. Em alguns casos, o ajuste passa por mudar o isolation level (de READ COMMITTED para READ COMMITTED SNAPSHOT ISOLATION) — decisão que precisa considerar o impacto em tempdb (item 7).

3. Parameter sniffing causando planos inconsistentes

O otimizador compila o plano da stored procedure usando o primeiro conjunto de parâmetros recebido e o coloca em cache. Se esse conjunto era atípico (data muito antiga, cliente com volume fora da média), todas as execuções seguintes usam um plano péssimo. Soluções variam por caso: OPTION (RECOMPILE) em queries específicas, OPTIMIZE FOR com valor representativo, reescrita para usar variáveis locais, ou Query Store fixando o plano bom.

4. Crescimento descontrolado do log de transações

Banco em recovery model FULL sem backup de log roda rumo ao infinito — o motor não tem como reutilizar espaço sem o backup. Em muitos ambientes, o recovery foi configurado como FULL "porque o template veio assim", e ninguém configurou a estratégia de log backup correspondente. O resultado é log de 200GB com 5% de uso real, e nenhuma capacidade de point-in-time recovery.

5. Licenciamento Core-based mal dimensionado

Edição Enterprise custa múltiplas vezes a Standard, e em muitos ambientes a Enterprise foi escolhida por um recurso usado uma vez, anos atrás. Pior: instâncias rodando em VMs com mais núcleos do que a carga exige, pagando licença por cada núcleo visível à instância. Auditoria de licenciamento bem feita olha edição, núcleos licenciados, Software Assurance, e recursos efetivamente em uso — e em ambientes médios costuma pagar a própria consultoria.

6. Ausência de Always On / failover testado de verdade

"Temos Always On configurado" é uma frase que precisa ser seguida da pergunta: quando foi o último failover real exercitado, e quanto tempo a aplicação levou para reconectar? Sem teste periódico de failover, com cronômetro e validação pós-falha, a alta disponibilidade existe no papel — não no incidente.

7. tempdb mal configurado e contention

tempdb é compartilhado por toda a instância. Configuração padrão com um único arquivo de dados, sem trace flag 1117/1118 (ou propriedades equivalentes no SQL 2016+) e sem múltiplos arquivos proporcionais aos núcleos causa contention em páginas PFS, GAM e SGAM em ambientes com muitas sessões concorrentes — visível em PAGELATCH_* nos wait stats.

"Em SQL Server, custo silencioso é o que mata o budget — não o incidente visível."

Cada um dos blocos abaixo precisa entregar evidência (DMV, query, plano de execução, métrica) — não conclusão isolada.

Auditoria de índices e estatísticas

Fragmentação de índice impacta leitura sequencial; em discos SSD/NVMe o impacto é menor do que era em HDD, mas existe. A regra prática consagrada usa thresholds: fragmentação abaixo de 5% ignora, entre 5% e 30% aplica REORGANIZE (online, leve, sem liberar espaço), acima de 30% aplica REBUILD (pesado, libera espaço, pode ser online em Enterprise).

Estatísticas desatualizadas são causa frequente de planos ruins. O otimizador estima cardinalidade com base no histograma da estatística; se a tabela cresceu 50% desde o último UPDATE STATISTICS, as estimativas viram chute, e o plano escolhido pode usar nested loop onde deveria usar hash match. Em tabelas grandes, atualização com FULLSCAN é cara mas necessária periodicamente.

Tuning de queries e planos de execução

Plano estimated (antes da execução) vs. actual (depois) é o primeiro lugar para olhar. Divergência grande entre linhas estimadas e linhas reais aponta estatística desatualizada ou predicado complexo. Operadores caros para procurar:

Key lookup recorrente em query quente custa muito mais do que parece — é um seek no índice não-clusterizado seguido de um seek no clusterizado, por linha. Em queries com milhões de execuções por dia, transformar em covering index (incluindo as colunas acessadas via INCLUDE) muda a ordem de grandeza do consumo de CPU e I/O.

Alta disponibilidade: Always On Availability Groups

Always On síncrono espera o commit ser confirmado na réplica antes de devolver o OK para a aplicação — RPO zero entre primária e réplica síncrona, ao custo de latência adicional a cada transação. Assíncrono não espera — latência mínima, mas há janela de perda em failover não planejado. Em grupos com réplicas geograficamente distantes, o uso típico é síncrono no mesmo data center e assíncrono para o DR remoto.

O listener é o ponto de conexão único: a aplicação conecta no nome do listener, e a infraestrutura roteia para a primária atual. Sem listener configurado corretamente — e sem string de conexão usando MultiSubnetFailover=True em ambientes multi-subnet — o failover funciona no servidor mas a aplicação não acompanha.

Alta disponibilidade só conta como tal depois de testada em exercício de failover periódico. O guia de disaster recovery alinhado à LGPD cobre como estruturar o plano de DR e validar RTO/RPO contra os requisitos do negócio e do regulador.

Auditoria de licenciamento

SQL Server Standard atende a esmagadora maioria dos workloads OLTP de pequeno e médio porte. Enterprise se justifica para recursos específicos — Always On com mais de duas réplicas, partitioning avançado, compressão de dados, online index rebuild em índices clusterizados, alguns recursos de segurança. Pagar Enterprise sem usar nenhum desses recursos é um dos desperdícios mais comuns e silenciosos em ambientes Microsoft.

Licenciamento Core-based exige no mínimo 4 núcleos por instância e cobra por todos os núcleos visíveis ao SQL Server. Em VMs superdimensionadas, isso vira pagamento por núcleo ocioso — redimensionar a VM (e reconfigurar o MAXDOP de acordo) é, com frequência, a entrega que mais devolve dinheiro num Health Check.

O Health Check de banco de dados é um diagnóstico fechado em até 48h: auditoria de configuração de instância e tempdb, análise via Query Store e DMVs, revisão de Wait Stats, validação de backup/restore e de Always On, auditoria de licenciamento, e relatório com plano de ação priorizado. Resolve "preciso entender em que estado meu ambiente está, e o que faz sentido atacar primeiro".

O DBA Remoto é sustentação contínua: NOC 24/7 com SLA por severidade, monitoramento proativo, tuning recorrente, gestão de backup e Always On, e atuação preventiva. É o que evita que o problema identificado no Health Check volte na próxima janela de manutenção, com mais um ano de dívida em cima.

Confundir T-SQL de aplicação com DBA de produção. Saber escrever uma stored procedure não é o mesmo que operar uma instância sob carga real. DBA de produção lê wait stats, interpreta Extended Events, dimensiona memória/MAXDOP/cost threshold, configura tempdb para o número certo de núcleos, e reconhece um deadlock graph em segundos. São conjuntos de habilidades quase disjuntos.

Ignorar a auditoria de licenciamento. Consultor que não toca em licenciamento está deixando dinheiro na mesa do cliente. Em ambientes Microsoft médios, a auditoria de Core-based e edição (Standard vs. Enterprise) sozinha já paga o Health Check em muitos casos — e o cliente não tem ideia disso até ver o número.

Contratar sem SLA para incidentes críticos. "Atendimento sob demanda" sem tempo de resposta documentado e sem penalidade por descumprimento é discurso comercial, não contrato. Incidente crítico em produção precisa de SLA com cronômetro — e de processo de escalonamento claro.

Se o seu ambiente é MySQL ou PostgreSQL em vez de SQL Server, veja nosso guia específico de consultoria MySQL e o de consultoria PostgreSQL, que aplicam o mesmo método de diagnóstico aos dois RDBMSs.

A HTI Tecnologia é "The Database Company" desde 1990, com mais de 35 anos sustentando ambientes SQL Server críticos. Alguns indicadores diretos do nível de operação:

Operação de SQL Server em e-commerce de alta sazonalidade. Sustentação de ambientes em Black Friday e Natal — picos do ano em que qualquer instabilidade tem impacto financeiro direto — com zero downtime documentado em clientes como Cappta.

SLA de 99,9999% sustentado em produção. Em operações como Infracommerce, com ambientes Microsoft de alta criticidade — o tipo de SLA que só fecha com infraestrutura, processo e equipe maduros nos três pilares simultaneamente.

Atendimento a ambientes de defesa nacional. Operação sob requisitos de segurança e auditoria compatíveis com ambiente sensível — disciplina operacional que se reflete em todo o portfólio comercial.

Operacionalmente, todo atendimento crítico ocorre a partir de sala física controlada com acesso biométrico, NOC 24/7, NDA padrão antes de qualquer acesso, e trilha de auditoria por operador.

Consultoria SQL Server bem feita combina três entregas: diagnóstico técnico com evidência (DMVs, Query Store, planos de execução), auditoria de licenciamento que pode pagar o próprio trabalho, e plano de ação priorizado com janela e risco documentados.

Se algum dos sinais descritos no início descreve o seu ambiente, faz sentido conversar com um DBA Senior antes da próxima janela de manutenção — ou da próxima renovação de licença.