Isso vai te levar a OUTRO PATAMAR

Fala pessoal, no post de hoje vou falar sobre wait types. Eles são muito importantes para realizar uma atividade que chamamos de troubleshooting. Nossa Caio, o que é esse palavrão ai? Calma, não se preocupe que não é nada de outro mundo.

No SQL Server o termo troubleshooting(solução de problemas) esta relacionado a uma habilidade que o DBA tem para identificar, diagnosticar e resolver um problema de performance (principalmente) no banco de dados.

Para poder identificar e diagnosticar o DBA avalia uma serie de indicadores tanto do ambiente como um todo, como memória, cpu, disco, rede, como alguns dentro do SQL Server. E é exatamente nessa analise que entram os Wait types (tipos de espera).

Mesmo sendo jr, começando sua carreira, isso que eu vou te ensinar vai fazer com que você suba mais um nível. E você que já é um pouco mais experiente vai poder aprender uma nova perspectiva sobre o assunto.

Os Wait types são como computador de bordo de um carro, aquelas luzes que acendem e apagam do painel. Algumas são apenas um alerta como a do sinto de segurança, alguns carros até ficam com uma campainha também tocando, a do tanque na reserva que indica que o combustível esta acabando, outras indicam um problema mecânico mais grave que inclusive pode fazer o carro parar de funcionar. No SQL Server, os tipos de espera indicam algum ponto de problema dentro do banco de dados. Também existem alguns waits que servem de alerta e outros que apontam problemas mais graves com o banco.

Quando você avalia uma query e durante a execução dela você observa um wait type especifico, ele vai te direcionar para o ponto exato de onde esta vindo aquela possível demora ou até mesmo problema. Existem dezenas de wait types e cada um é especifico para cada caso. Por isso entender e conhecer sobre os principais vai te ajudar muito a melhorar o seu poder de troubleshooting.

Eu preparei aqui uma lista baseado na minha experiência do que eu chamo de WT4 - conjunto dos 4 wait types mais comuns. Se você souber o que cada um deles representa e quais são as possíveis soluções para cada um, você vai estar apto a resolver muitos problemas de desempenho no SQL Server e com isso ter uma habilidade que é muito procurada.

PAGEIOLATCH - Existem algumas variações desse wait mas essa família esta vinculada a leitura de paginas no disco, quando aparecem indicam que o SQL esta demorando para conseguir ler os dados no disco, e ele precisa ler do disco porque os dados não estavam em memória.

Imagine se você esta no sofá da sua casa com o controle remoto da TV na sua mão, de uma forma bem rápida e sem esforço você consegue mudar os canais e aumentar o volume, mas se a pilha acabar, você vai começar a precisar levantar e ir até a TV para apertar os botões, mudar de canal, por exemplo. Funciona da mesma forma, porém o esforço e demora é muito maior.

Se o buffer do SQL (que é a memória alocada para o banco guardar os dados e não precisar ficar indo no disco toda hora buscar aquele dado) estiver cheio, muitos processos simultâneos lendo dados podem ter o wait pageiolatch com tempo alto. Partindo do principio que ler dados que estejam em memoria é mais rápido destaco duas possibilidades para resolver o problema.

1 - Aumentar o tamanho do cache, se a pilha do controle zerou, você tem mais algumas reservas, da mesma forma, se tiver memória livre disponível no ambiente, libere mais para o SQL, com isso vai conseguir guardar mais dados em memória evitando ter que ir no disco.

2 - Melhorar o desempenho da query para que consuma menos memória para executar o processo e com isso tenha mais espaço para dados.

ASYNC_NETWORK_IO - Algumas aplicações trabalham no formato cliente-servidor, em que a conexão entre aplicação e banco é realizada pela rede, por uma conexão de rede. Quando uma query apresenta um tempo de espera alto para esse wait type indica que esta ocorrendo uma grande transferência de dados via rede ou que o ambiente esta com problemas de desempenho na rede. Sabe quando você esta conversando com alguém por aplicativo, trocando áudio que são pequenos, é praticamente instantâneo e de repente e pessoa te manda um vídeo bem grande e demora alguns minutos pra baixar ele, pensa em uma query que vai retornar milhões de linhas e vai trafegar elas via rede para serem exibidas em um painel na maquina do usuário. É ai que vem o ASYNC NETWORK IO. Algumas sugestões para melhorar são :

1 - Identificar quais as querys que estão apontando esse wait

2 - Levantar o volume de informação que elas retornarão

3 - Avaliar se existe algo errado na query, um parâmetro informado errado que não deveria ou até mesmo a possibilidade de inserir algum filtro para reduzir a quantidade de dados

4 - Solicitar ajuda da equipe de infra para avaliar se não existe algum problema na rede

WRITELOG - Esse tipo de espera ocorre quando você fica aguardando que um bloco de log seja gravado no disco no log de transações, é o momento onde o SQL pega os dados de log em memória e guarda eles no disco, como se você tivesse com vários documentos em cima da sua mesa e resolvesse guardar eles em uma pasta no seu armário porque não cabem mais na mesa, geralmente esse processo ocorre quando o bloco de log enche ou quando uma transação é confirmada.

O problema é que quando você recebe uma espera alta ou muito frequente para esse processo significa que o desempenho do disco onde o log de transação esta alocado esta ruim, ou o banco esta executando muitas vezes seguidas o processo de gravação no disco. Imagina um loop de 10 mil linhas a cada passagem no loop ele confirma uma transação, serão 10 mil vezes que o SQL irá registrar os blocos de log no disco. Para diminuir esse wait você pode seguir dois caminhos, começando por por:

1 - Identificar se existe algum processo realizando muitas vezes seguidas a confirmação de transação como no exemplo do loop. Nesse caso, você pode agrupar essas transações em um bloco apenas e "committar" todas as alterações de uma só vez.

2 - O segundo caminho é avaliar a possibilidade de melhorar o desempenho do disco onde o log de transações esta alocado.

LCK - É a família dos locks, tem muita gente que acha o lock ruim, mas ele tem o seu valor. Pensa numa prateleira cheia de livros, quando você vai pegar um livro, o Caio chega mais rápido e pega o livro na sua frente, começa a folhar ali o livro e você fica do lado aguardando, depois de uns 30 segundos ela devolve o livro na prateleira e então você consegue pegar ele pra ver. Nessa história a prateleira é a tabela, o livro é o dado, o Caio é um usuário e você é outro usuário, o dado estava lá disponível, quando você foi acessa-lo outro usuário chegou primeiro e começou a usar aquele dado, somente quando ele terminou você conseguiu acessar e ler o dado, durante aqueles 30 segundos que ficou aguardando você ficou "sofrendo lock". Quando a query no banco esta com o wait que começa com LCK significa que aquela query esta aguardando outro processo terminar de usar a tabela ou o dado em si para poder de fato executar.

Os locks podem ocorrer em vários níveis, mas o que você precisa saber é que a query que esta sofrendo o lock esta demorando porque esta aguardando e não necessariamente porque esta lenta.

Para resolver esse caso, você deve identificar qual é a query que esta causando o lock e avaliar ela, se esta demorando demais e precisa/pode ser otimizada, ou se uma transação ficou aberta no banco e não finalizou gerando o bloqueio ou até mesmo se a tabela que vai ser usada esta sofrendo algum tipo de manipulação, como a troca de um tipo de campo.

Resumindo o WT4

PAGEIOLTACH - leitura no disco porque não tem memória

ASYNC_NETWORK_IO - grande volume de dados trafegando na rede, diminuir isso e ver se a rede tem algum problema

WRITELOG - demorando para registrar no log de transações os dados, desempenho do disco ou realizar commit em bloco

LCK - transações demorando e bloqueando processos, otimizar ofensores ou derrubar transação que ficou aberta

Outros waits que você deve ter atenção também são

RESOURCE_SEMAPHORE - Quando o plano de execução de uma query é gerado ele informa ao SQL quanto de memória ele precisa pra conseguir entregar aquela query, quando uma query esta muito ruim com um plano que consome muita memória ou se surgem outras querys ruins quando ela for entrar em execução, o SQL pode não ter a memória suficiente disponível para que ela execute, essa query vai ter esse wait e pra resolver isso você precisa avaliar a query que esta sendo impactada se é possível ajustar índices ou até mesmo mudar a estrutura da query para que consuma menos, outra opção é aumentar recurso no servidor.

CXPACKET - quando você tem uma consulta muito grande que precisa reunir muita informação o SQL pode optar por criar um paralelismo, ou seja, dividir essa carga de trabalho em varias threads, como um trabalho de equipe na cpu do servidor. Esse wait pode aparecer quando nesse processo algumas threads já terminaram o seu trabalho e estão esperando outras que ainda não finalizaram sua etapa. A solução passa por ajuste do MAXDOP, mas pra mudar essa configuração você precisa saber muito bem o que esta fazendo. Não significa algo ruim, mas deve ter atenção a esse wait.

Você pode acompanhar quais os maiores waits do seu ambiente usando a dmv sys.dm_os_wait_stats

Eu vou disponibilizar um material extra sobre esse assunto(scripts) lá no meu canal do telegram, como você pode identificar com essa dmv e algumas outras querys.

Com esse conhecimento sobre wait types você já é capaz de analisar um ambiente com problemas de performance e direcionar as analises, note que entender para onde você deve olhar vai tornar o seu trabalho mais assertivo e ágil.

Você pode se deparar com outros waits, e então pode consultar o material da propria microsoft que explica, mas vai por mim, dominando esses você já pode tratar a grande maioria dos casos.

O DBA que é bom de troubleshooting é bem valorizado e é isso que eu quero fazer por você! Fazer você se destacar!

Nos acompanhe em nossas redes sociais!

Grupo VIP Telegram: DBA On boarding

Youtube(vídeos novos todas as quartas): DBA On boarding

Face & Instagram(conteúdo diário): DBA On boarding

Até a próxima, tchau!

#CG_Administration