Como um DBA, lidar com problemas de desempenho geralmente é um evento reativo; problema ocorrer, você tem que responder. Às vezes, você está olhando para uma instância do SQL Server que conhece bem, outras vezes pode ser seu primeiro encontro com um ambiente. Isso também ocorre no mundo da consultoria. Ao ajudar um cliente de longo prazo, já tenho os detalhes sobre o ambiente arquivados. No entanto, quando recebemos um e-mail de alguém com quem não trabalhamos antes, e é uma situação de emergência em que eles querem ajuda imediata, não temos conhecimento sobre o meio ambiente e não temos ideia do que estamos enfrentando. Fornecemos assistência sem passar pelo extenso processo de coleta e análise de dados que inicia cada novo envolvimento do cliente.
Por isso, tenho um conjunto de cinco itens que verifico imediatamente quando enfrento um novo ambiente. As informações que coleto definem o cenário de como abordarei a solução de problemas daqui para frente e, embora raramente identifiquem O problema específico, isso me ajuda a descartar o que NÃO o problema, que às vezes é tão importante.
Métodos de coleta de dados
Reconheço que todos têm uma abordagem diferente ao lidar com um novo ambiente. Existem vários scripts gratuitos e amplamente disponíveis que você pode baixar e executar para fornecer a você o “lay of the land” para uma instância do SQL Server (os scripts DMV de Glenn Berry vêm à mente). O foco aqui não é como você coleta os dados, é o que dados que você coleta e o que você analisa primeiro .
Propriedades do servidor
A primeira coisa que quero saber quando olho para uma instância é a versão e a edição do SQL Server. A maneira mais rápida de obter essas informações é executar:
SELECT @@VERSION;
Com essa saída, posso verificar a compilação para determinar os service packs, atualizações cumulativas e hotfixes aplicados e sei qual edição é usada. Também gosto de saber se a instância está em cluster, então também executo:
SELECT SERVERPROPERTY('IsClustered'); Às vezes, tenho essas informações do cliente, mas não custa verificar, pois a versão e a edição podem afetar as etapas e recomendações de solução de problemas subsequentes. Por exemplo, um cliente recentemente entrou em contato conosco sobre um problema de desempenho intermitente que viu com o SQL Server 2008. Uma verificação rápida da versão revelou que eles estavam executando o SQL Server 2008 SP3 e havia várias atualizações cumulativas lançadas após o SP3 que abordavam uma variedade de Problemas de desempenho. Embora eu tenha reunido mais informações antes de fazer a recomendação de que eles apliquem a CU mais recente, isso foi um alerta imediato sobre o que pode estar causando o problema.
sys.configurations
Essa exibição de catálogo ajuda a construir a base iniciada com as propriedades do servidor e nos ajuda a entender como a instância é configurada. Com essa visualização, procuro as configurações que foram alteradas dos padrões, mas não deveriam ter sido, e aquelas que não foi modificado, mas deveria.
SELECT [name], [value], [value_in_use], [description] FROM [sys].[configurations] ORDER BY [name];
Considere a configuração de memória máxima do servidor (MB), que limita a quantidade de memória disponível para o conjunto de buffers. O valor padrão é 2147483647, mas deve ser alterado para um valor menor que a memória total no servidor para garantir que haja memória suficiente para o sistema operacional, outros aplicativos e outras tarefas do SQL Server que exigem memória não retirada do pool de buffers . Para obter orientação sobre como definir o valor apropriado para a memória máxima do servidor (MB), recomendo a postagem de Jonathan, Quanta memória meu SQL Server realmente precisa?
Por outro lado, a configuração de aumento de prioridade tem um padrão de zero e deve sempre ser deixada como tal. Na verdade, a Microsoft recomenda não alterá-lo e a opção será removida em uma versão futura do SQL Server.
sys.databases
Depois de entender como a instância está configurada, procuro ver o que existe no nível do banco de dados.
SELECT * FROM [sys].[databases] ORDER BY [database_id];
Quando verifico a saída desta visualização de catálogo, procuro antipadrões – qualquer coisa que pareça inesperada ou atípica – nos dados. A saída é propícia para uma análise rápida – muitas das configurações listam 0 ou 1 para o valor (desligado ou ligado) e faço uma anotação mental do que é diferente. Espero que as estatísticas de criação automática e as estatísticas de atualização automática sejam habilitadas (definidas como 1). Espero que o fechamento automático e a redução automática sejam desabilitados (definidos como 0). Procuro ver qual é o agrupamento para os bancos de dados do usuário, especificamente se todos têm o mesmo agrupamento e se esse agrupamento é o mesmo que tempdb. Também observo opções de segurança, como encadeamento entre bancos de dados e a opção is_trustworthy, ambas desabilitadas (0) por padrão. Se eu achar que qualquer uma dessas configurações se desvia do que eu esperava, eu anoto e sigo em frente. Em nenhum momento eu interrompo minha coleta ou análise para fazer uma mudança, pois estou simplesmente coletando informações o mais rápido que posso para obter uma boa compreensão do ambiente.
Além de verificar as configurações dos bancos de dados, também tomo nota do número de bancos de dados de usuários. Não existe um “número certo” de bancos de dados de usuário para uma instância – uma instância pode ter um desempenho ruim com um banco de dados e pode funcionar maravilhosamente com 100. Há uma infinidade de fatores em jogo, e o número de bancos de dados é simplesmente um ponto de dados Vale nada.
Registros de erros
Eu admito, eu costumava negligenciar o SQL Server ERRORLOG; foi como uma reflexão tardia quando investiguei um problema do SQL Server. Então eu percebi o erro dos meus caminhos, e eu não tenho dado como certo desde então. Costumo navegar pelo Management Studio para acessar o log (em Management | SQL Server Logs), embora você possa usar o procedimento armazenado sp_readerrorlog ou navegar até o arquivo e abri-lo em seu editor de texto favorito.
Dentro do ERRORLOG, procuro erros recentes - por exemplo, qualquer coisa relacionada à memória - e também procuro ver quais sinalizadores de rastreamento, se houver, estão em uso. Também verifico se Lock Pages in Memory está ativado, se o cache está sendo liberado (propositalmente ou não) e se qualquer outra atividade incomum ocorre com regularidade. Dependendo da urgência do problema, também observo os logs do Windows (Evento, Aplicativo e Segurança), novamente não apenas procurando erros, mas também padrões de mensagens inesperados.
Estatísticas de espera
A área final do SQL Server que reviso ao analisar um problema de desempenho em uma instância desconhecida é a estatística de espera. Cada instância do SQL Server terá esperas – não importa quão bem ajustado seja o código, não importa quanto hardware esteja por trás dele. Como um DBA, você deseja saber quais são suas esperas típicas para uma instância e, quando estou analisando um novo ambiente, não sei imediatamente se as esperas que vejo são típicas ou devido ao problema de desempenho. Eu pergunto ao cliente se ele tem estatísticas de espera de base e, se não, eu pergunto se posso limpá-las e deixá-las começar a se acumular enquanto o problema de desempenho ocorre. Para verificar as estatísticas de espera, você pode usar o script na postagem frequentemente referenciada de Paul Randal ou a versão nas consultas de DMV de Glenn.
Depois de revisar as estatísticas de espera acumuladas, você terá a parte final que fornece o “quadro geral” da instância do SQL Server e as informações necessárias para iniciar a solução de problemas. Não é incomum verificar as estatísticas de espera primeiro ao solucionar problemas, mas as esperas por si só não são informações suficientes para determinar o que você precisa investigar em seguida, a menos que você também entenda a configuração básica do SQL Server.
Próximas etapas
Como mencionei anteriormente, normalmente não há um dado que diga onde está o problema de desempenho, são vários pontos de dados obtidos que apontam na direção certa. Como você captura essas informações depende de você, mas depois de revisar a saída, você deve ter um bom entendimento de como o ambiente do SQL Server está configurado e esse conhecimento, combinado com as estatísticas de espera, pode ajudá-lo a decidir o que investigar em seguida. A solução de problemas funciona melhor com uma abordagem metódica, então comece com o básico e trabalhe, e quando você achar que determinou a causa raiz, cave um pouco mais e encontre uma ou duas evidências adicionais que suportem sua descoberta. Depois de ter esses dados, você pode fazer uma recomendação para ajudar a melhorar ou resolver o problema.
