Embora todos saibamos que o bloqueio é essencial para a integridade dos dados, isso não muda o fato de que pode ser um espinho sério no seu lado!
Quando vemos bloqueios em nosso banco de dados, geralmente assumimos que algo está errado – nem sempre é esse o caso. Na minha experiência, a maioria dos bloqueios do SQL Server é legítima, mas precisa ser investigada e compreendida. Os impasses, por outro lado, raramente são legítimos! Os deadlocks são considerados críticos no mundo do SQL Server porque os processos são encerrados automaticamente, pois o SQL Server resolve os deadlocks sem exigir intervenção manual. Novamente, mesmo que estejam “resolvidos”, eles definitivamente precisam ser investigados e compreendidos.
Existem algumas estratégias de design que podem ajudar a reduzir as ocorrências de bloqueios e deadlocks do SQL Server em seu banco de dados:
- Use índices clusterizados em tabelas de alto uso
- Evite instruções SQL de alta contagem de linhas
- Divida transações longas em muitas transações mais curtas
- Certifique-se de que as instruções UPDATE e DELETE usem índices
- Não programe trabalhos de atualização em lote para sobreposição
- Mantenha suas estatísticas atualizadas
E tenho certeza de que há muito mais, mas a realidade é que você pode seguir todas as melhores práticas que puder imaginar e ainda ter bloqueios e impasses. Isso ocorre porque, na maioria dos casos, os deadlocks são causados por código de aplicativo mal projetado. (A toca do coelho do design de aplicativos:codificação, isolamento de transações e padrões de acesso. Mas, por enquanto, vamos nos concentrar em investigar e entender bloqueios e impasses).
Bloqueio e impasses do SQL Server
O primeiro desafio com bloqueios e deadlocks é identificar quando e onde eles estão acontecendo porque geralmente não são relatados, relatados após o fato ou resolvidos automaticamente. Para obter uma compreensão real do que está acontecendo em seu banco de dados em relação a bloqueios e impasses, você precisa ver suas ocorrências ao longo do tempo. Além disso, para corrigir o problema e interromper ocorrências futuras, você precisa chegar à causa raiz do bloqueio - armando-se com informações que você precisa retransmitir aos desenvolvedores do aplicativo e, assim, acabar com o jogo de culpa entre os desenvolvedores. e DBAs.
É por isso que gosto muito do Workload Analyzer em Spotlight Cloud. Posso selecionar um intervalo de tempo – uma hora, um dia ou um intervalo personalizado – e visualizar o Bloqueio -atividade relacionada para esse intervalo. Imediatamente, eu tenho uma melhor compreensão do que está acontecendo! Posso ver padrões de bloqueio, comparar a taxa de bloqueio ao longo do tempo com um intervalo de tempo anterior, ver a taxa de bloqueio em um período de tempo específico e exibir KPIs de bloqueio, como Bloquear Exclusivo, Compartilhado e Atualizar.
Então agora eu quero chegar à causa raiz – é onde Árvore de Dimensões Eu posso detalhar e filtrar as informações para um período de tempo específico, o que me permite ver as mesmas informações em dimensões mais profundas, como Bancos de dados , Usuários , Programas e Instruções SQL , enquanto filtra o “ruído branco” à medida que progrido – identificando claramente a(s) fonte(s) do meu problema.
Aqui estou vendo quais Bancos de dados estão experimentando o maior bloqueio durante o intervalo de tempo:
Agora, detalharei os Usuários dentro do banco de dados selecionado:
Em seguida, escolherei ver a lista de Instruções SQL causando bloqueio que foi executado pelo Usuário selecionado no Banco de dados selecionado para o Intervalo de tempo especificado .
Agora, posso ver todos os Bloqueios informações relacionadas para a Instrução SQL selecionada .
Portanto, se você deseja chegar ao fundo de seus problemas de bloqueio, bloqueio e impasse, recomendo que você verifique o Spotlight Cloud. O Spotlight Cloud torna mais fácil do que nunca investigar e entender os problemas de bloqueio no banco de dados e, por fim, garantir que o código do aplicativo esteja livre de deadlock.
