Manter instâncias do SQL Server de alto desempenho é uma grande parte das responsabilidades de trabalho de um DBA. A falha em detectar e corrigir atividades incomuns pode afetar as operações internas e prejudicar os resultados da empresa.
Se você notar alterações de atividade de pico ou anomalias em uma instância do SQL Server, aqui estão três lugares para iniciar sua busca por respostas.
Expectativa de vida da página
A expectativa de vida da página (PLE) de uma instância deve manter um intervalo de valores bastante consistente. Se esse valor cair e permanecer baixo, isso é um sinal de que o pool de buffers está com uma demanda aumentada.
Antes de esgotar e aumentar a memória, dê uma olhada na atividade da carga de trabalho. Se a carga de trabalho aumentou, isso explicaria a pressão adicional no conjunto de buffers. Mas se a carga de trabalho não mudou, você precisará olhar mais de perto para identificar o que está usando a memória extra.
Os possíveis motivos para uma queda no PLE incluem trabalhos de manutenção em execução ativa, recompilações de índice ou atualizações de estatísticas, operações DBCC e alterações no plano de consulta.
Se você notar uma queda no PLE que não está associada a um aumento na carga de trabalho, há algumas coisas que você pode tentar para melhorar o PLE de uma instância:
- Eliminar índices não utilizados
- Mesclar índices duplicados
- Atente para grandes consultas
- Desfragmentar
- Limpar dados
Tempo de espera WRITELOG
Quando o tempo de espera WRITELOG é uma proporção muito grande do tempo total de espera, você provavelmente tem um afunilamento em sua instância do SQL Server. O gargalo provavelmente é causado por um problema no disco onde o log de transações está armazenado ou por dados sendo confirmados de forma ineficiente.
Para determinar com que tipo de gargalo você está lidando, comece analisando o número de instruções SQL aguardando o evento WRITELOG. Se houver muitas instruções esperando, você terá um gargalo de disco. Se houver apenas algumas instruções esperando, os dados provavelmente estão sendo confirmados com muita frequência.
Existem várias maneiras de resolver o alto tempo de espera do WRITELOG depois de descobrir se o gargalo está relacionado ao disco ou ao commit:
- Adicione largura de banda de E/S ao disco onde o log de transações está armazenado
- Mover E/S de log de não transação do disco
- Mova o log de transações para um disco menos ocupado
- Reduza o tamanho do log de transações
- Certifique-se de que a instrução COMMIT esteja inserida no código para que os dados não sejam confirmados com muita frequência
TempDB
TempDB é um espaço de trabalho temporário no SQL Server que contém objetos temporários. Como os objetos mantidos no TempDB são transitórios, uma instância do SQL Server recria o TempDB sempre que é reiniciado. Isso torna a otimização do TempDB essencial para manter o desempenho e evitar gargalos operacionais.
A contenção do TempDB é um dos principais culpados pela degradação do desempenho. A contenção ocorre quando vários recursos precisam acessar o TempDB, mas há apenas um arquivo de dados do TempDB. Isso causa um gargalo porque os processos não podem acessar o TempDB com rapidez suficiente, levando ao tempo limite das conexões e aos processos sendo desalocados.
Felizmente, os gargalos do TempDB podem ser resolvidos com bastante facilidade ajustando o número e o tamanho dos arquivos TempDB. Após a instalação, o padrão do SQL Server é um arquivo de dados TempDB. Se você perceber a ocorrência de contenção, é recomendável adicionar oito novos arquivos de dados e determinar se isso corrige o problema. Se o problema não for resolvido, tente adicionar arquivos de dados adicionais em múltiplos de quatro até que o desempenho seja restaurado.
Embora seja ótimo saber por onde começar a procurar quando você tiver problemas de desempenho, cada um dos problemas acima e os gargalos resultantes podem ser mitigados ou evitados completamente implementando uma regra rígida e rápida:monitorar as métricas de desempenho não é opcional. Aqui estão alguns exemplos de métricas-chave para acompanhar:
Expectativa de vida útil da página:acompanhe o PLE com monitoramento contínuo e seja proativo quando ele cair e ficar abaixo do valor típico para uma instância específica do SQL Server.
Tempos de espera WRITELOG:monitore métricas como crescimento de log, redução de log, porcentagem de log usado e esperas de liberação de log/s.
Ineficiência do TempDB:Monitore o que está sendo alocado para objetos de usuário, armazenamento de versão ou objetos internos. Acompanhe como eles estão tendendo ao longo do tempo e determine quais sessões estão consumindo TempDB e quanto.
Existem algumas excelentes ferramentas de monitoramento de desempenho do SQL Server acessíveis e ricas em recursos no mercado que podem ajudá-lo a ficar na frente de problemas que degradam o desempenho. Torne-se o DBA MVP da empresa pesquisando proativamente soluções que mantêm as operações internas e os serviços de negócios externos funcionando com desempenho máximo.
