Existem muitos fatores que influenciam quando se trata de desempenho de banco de dados. Conhecer as flutuações normais de sua instância específica monitorando seu SQL Server ajuda a identificar quando o comportamento está fora de controle e a antecipar problemas antes que eles ocorram.
Ele também ajuda a distinguir entre o que são dores de crescimento naturais causadas pelo aumento da carga de trabalho ou picos sazonais que podem exigir mais recursos versus problemas de desempenho mais profundos que exigem ajuste de código, otimização de índice ou ajuste de configuração.
Depois de estabelecer uma lista de servidores SQL em seu ambiente, você deve fazer algumas perguntas críticas:
- Qual é a integridade dessa instância?
- Quando foi o último backup?
- Ele tem CPU, memória e armazenamento suficientes para atender ao SLA?
- Que tipo de carga de trabalho é executada nesta instância?
- Quais aplicativos e usuários usam esta instância?
- Quando a carga de trabalho é mais movimentada?
- Existe uma estratégia de failover?
- Esta é uma instância de missão crítica?
- Ele precisa estar disponível 24 horas por dia, 7 dias por semana?
- Que tipo de desafios de desempenho essa instância apresenta?
Essas podem parecer perguntas óbvias, mas se você começar a monitorar suas cargas de trabalho do SQL Server pela primeira vez, ficará surpreso e possivelmente um pouco horrorizado ao ver quantas delas têm problemas fundamentais.
Definir metas de desempenho para monitoramento do SQL Server
Pense no que você deseja alcançar com seus esforços de monitoramento do servidor SQL e priorize essas metas. Ao enquadrar suas atividades em termos de indicadores-chave de desempenho, você facilita a articulação do valor da energia e de quaisquer investimentos necessários. A lista a seguir irá ajudá-lo a começar.
Alta disponibilidade
Quais são suas estatísticas de disponibilidade? Lembre-se que indisponibilidade para o usuário é quando ele não consegue acessar o serviço. Isso pode ser causado por uma interrupção completa ou por um gargalo de desempenho que efetivamente torna o serviço indisponível. Você tem uma configuração sempre ativa? Em caso afirmativo, sabe o seu estado?
Tempo de resposta
A partir do momento em que um problema é relatado, com que rapidez você pode isolar a fonte, diagnosticar os sintomas e responder aos afetados?
Tempo de resolução
Com que rapidez você pode resolver o sintoma para restaurar a operação normal? A solução de “gesso pegajoso” é um começo importante, mas não deve representar o fim da questão. Você explorou a causa raiz do problema? Você pode ter certeza de que não verá uma recorrência?
Compreendendo o custo de propriedade de suas instâncias do SQL Server
O custo de propriedade é um fator crítico ao decidir onde suas instâncias do SQL Server devem residir. É importante avaliar os custos iniciais de investimento associados à infraestrutura e licenciamento, os custos de manutenção contínua e quaisquer custos baseados em consumo associados a uma carga de trabalho baseada em nuvem.
Se você estiver tentando decidir quanto custará sua instância na nuvem, as métricas críticas incluem uso da CPU, atividade de leitura e gravação e armazenamento. Você precisará medi-los durante um longo período para descobrir seus limites de carga de trabalho e garantir que você tenha recursos para o espectro de carga de trabalho que você espera para uma instância específica.
Familiarizar-se com as características específicas das cargas de trabalho executadas em suas instâncias do SQL Server o colocará em um lugar muito melhor para garantir que tudo continue funcionando como deveria e para atender às necessidades atuais e futuras de seus negócios.
Estude o desempenho ao longo do tempo com o monitoramento do SQL Server
Bancos de dados são sistemas fluidos. Muito poucos têm cargas de trabalho constantes, repetitivas e previsíveis. É muito mais comum ver grandes variações ao longo do tempo que flutuam com base no número de usuários, trabalhos automatizados, número de transações, volume de dados e assim por diante.
Um banco de dados de vendas ficará ocupado no final do mês. Também verá um aumento na atividade em torno de eventos sazonais ou impulsionados por promoções de marketing.
Classificar seu desempenho com base em pequenos instantâneos não é uma boa política. Quanto mais histórico você puder coletar e analisar, mais insights você poderá obter sobre as variações e os limites de cada uma das características de suas cargas de trabalho.
Você precisará julgar quanto histórico é prático manter e se você tem os recursos para processá-lo. Há implicações de custo e desempenho a serem consideradas.
Tenha uma visão completa do seu monitoramento de banco de dados
Cada banco de dados é um sistema complexo com muitas partes móveis. Muitos critérios de configuração podem afetar seu desempenho.
O design e a arquitetura do próprio banco de dados influenciarão os resultados. A eficiência do código também pode melhorar ou prejudicar o desempenho. As opções de configuração determinarão como a instância do SQL Server consome os recursos disponíveis para ela.
Considere o seguinte cenário:Uma instância está desacelerando e o DBA detecta um pico na espera de CXPACKET ou CXCONSUMER. A reação automática é acabar com o paralelismo. As esperas desaparecem e o gargalo atual é aliviado temporariamente. Agora toda a instância está rodando mais devagar, mas o DBA não quer reativar o paralelismo. Se alguma investigação adicional tivesse sido feita, teria revelado que uma consulta estava sendo executada de forma particularmente lenta e a causa era um índice ausente.
O monitoramento de muitas métricas diferentes em paralelo ajuda a identificar com precisão a causa raiz e evitar erros de diagnóstico caros que podem causar uma repetição ou até mesmo uma escalada do mesmo problema.
