sql deadlocking e tempo limite quase constantemente

Question

Parece que hoje vai ser outro lixo. Nós atualizamos recentemente nossa caixa sql com um monstro completo, com muitos núcleos e ram, no entanto estamos presos ao nosso antigo esquema DB que é crapola.

Nossa velha caixa sql teve problemas, mas nada como o que estamos experimentando com a nova, embora no dia do lançamento ela estivesse rodando rápido, dentro de uma semana é uma bagunça completa ...

Nosso aplicativo .net usado por algumas centenas de pessoas está gerando uma enorme quantidade de deadlocks e timeouts na caixa SQL e estamos nos esforçando para descobrir o motivo. Verificamos todos os índices e eles são tão bons quanto podem ser agora. Algumas das principais tabelas são muito grandes e têm uma quantidade estúpida de gatilhos, mas não há nada que possamos fazer sobre isso agora.

Muitos dos pids parecem ser os mesmos para os mesmos usuários que estão tentando várias vezes.

Então, por exemplo ...

User: user1
Time: 09:21
Error Message: Transaction (Process ID 76) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

User: user1
Time: 09:22
Error Message: Transaction (Process ID 76) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

etc ....

Quando movemos o banco de dados para a nova caixa, fizemos o backup do antigo e restauramos para o novo.

Se alguém tiver alguma sugestão sobre algo que possamos fazer, comprarei várias canecas.

    

Answer 1

Isso é realmente mais um problema de desenvolvimento. Você pode querer consultar seus desenvolvedores para determinar qual nível de isolamento de transação está em uso.

O nível de isolamento padrão do Microsoft SQL Server é Read Committed. O desenvolvedor deve conhecer e definir o nível apropriado para a transação. Geralmente é aconselhável usar o nível de isolamento menos restritivo possível e evitar o uso dos níveis de isolamento Repetível Leitura e Serializável, se possível.

Se eles estiverem usando um nível de isolamento mais restritivo do que o padrão, como Leitura repetível ou Serializável, o aplicativo estará mais predisposto a problemas de bloqueio. Se eles estiverem usando um nível de isolamento mais restritivo do que o padrão e não estiverem cientes de que estão fazendo isso, é ainda pior.

A principal tecnologia de acesso a dados da Microsoft, o Entity Framework, usa o nível de isolamento Serializable por padrão. Isso não é muito bem documentado ou divulgado. Se o aplicativo usar o Entity Framework e o desenvolvedor não tiver conhecimento desse fato, talvez o desenvolvedor queira revisar o design do banco de dados para determinar se ele pode definir o nível de isolamento da transação como Read Committed.

Mais informações:

AJUSTE O NÍVEL DE ISOLAMENTO DA TRANSAÇÃO (Transact-SQL) em link

Transações e conexões no Entity Framework 4.0
link

    

Answer 2

Eu não gosto de cerveja, mas você deve olhar seriamente para o profiler do SQL Server - é uma ferramenta valiosa para analisar sua carga de trabalho, incluindo algumas ferramentas para ajudar a descobrir as razões para as condições de deadlock.

Existem vários artigos escritos sobre este tópico, este é suficientemente abrangente. A documentação oficial no MSDN também contém algumas informações, embora não sejam bem escritas.

    

Answer 3

Se você tiver os índices apropriados, não há uma boa maneira de resolver isso sem corrigir o esquema e / ou as consultas do banco de dados: em particular, testando com SNAPSHOT ISOLATION e READ COMMITTED SNAPSHOT . Eles não são soluções rápidas.

Se você não se importar em transformar o novo monstro em um porker lento, você pode desativar o paralelismo . É incerto o quanto isso vai ajudar.

Em última análise, os deadlocks frequentes são o resultado de um design inadequado do banco de dados, e não há como evitar isso.

    

Answer 4

Você já conseguiu pelo menos registrar as consultas que causaram os problemas? Minha experiência tem sido muito poucas dúvidas são responsáveis pela grande maioria dos problemas.

Nas mensagens de erro, parece que você está executando o SQL Server. Se você estiver executando 2005 ou melhor ativar o sinalizador de rastreamento 1222 DBCC TRACEON (1222, -1) , ele deverá fornecer algumas informações sobre as consultas. Um esquema de baixa qualidade pode causar problemas, mas eu nunca vi um esquema de baixa qualidade causar diretamente impasses. Geralmente há uma solução alternativa. Uma consulta lenta é muito melhor que uma consulta causando deadlocks constantes.

Obtenha algumas das consultas que estão interferindo e poderemos sugerir algumas alterações nelas.