Como eu diagnosticei problemas de bloqueio. Como diagnostiquei problemas de bloqueio 1c conflito de bloqueio de erro ao executar uma transação

Não consegui anotar as alterações para transferência para um banco de dados distribuído, entrei em contato com o suporte 1c e ofereci o seguinte. Decidi simplesmente reiniciar o servidor de aplicativos e o servidor com SQL. Em geral, você pode marcar a caixa “Bloqueio agendado
tarefas incluídas"
Também ajudou sem reiniciar.

Operações agendadas no nível DBMS para MS SQL Server

Instruções para executar operações de rotina no nível do DBMS.

As informações são aplicáveis ​​à versão cliente-servidor de 1C:Enterprise 8 ao usar o MS SQL Server DBMS.

Informação geral

Uma das causas mais comuns de operação não otimizada do sistema é a execução incorreta ou inoportuna de operações de rotina no nível do DBMS. É especialmente importante realizar esses procedimentos de rotina em grandes sistemas de informação que operam sob carga significativa e atendem simultaneamente a um grande número de usuários. A especificidade de tais sistemas é que as ações usuais executadas automaticamente pelo DBMS (com base nas configurações) não são suficientes para uma operação eficiente.

Se um sistema em execução apresentar algum sintoma de problemas de desempenho, você deve verificar se o sistema está configurado corretamente e executa regularmente todas as manutenções de rotina recomendadas no nível do DBMS.

A execução de procedimentos de rotina deve ser automatizada. Para automatizar essas operações, é recomendável usar as ferramentas internas do MS SQL Server: Plano de manutenção. Existem também outras maneiras de automatizar esses procedimentos. Neste artigo, para cada procedimento agendado, é dado um exemplo de sua configuração utilizando o Plano de Manutenção para MS SQL Server 2005.

Recomenda-se monitorar regularmente a pontualidade e correção da implementação desses procedimentos de rotina.

Atualização de estatísticas

O MS SQL Server constrói um plano de consulta com base em informações estatísticas sobre a distribuição de valores em índices e tabelas. As informações estatísticas são coletadas com base em uma parte (amostra) de dados e são atualizadas automaticamente quando esses dados mudam. Às vezes, isso não é suficiente para o MS SQL Server criar consistentemente o plano ideal para executar todas as consultas.

Nesse caso, podem ocorrer problemas de desempenho da consulta. Ao mesmo tempo, sinais característicos de trabalho não ideal (operações não ideais) são observados nos planos de consulta.

Para garantir o funcionamento mais correto do otimizador MS SQL Server, é recomendável atualizar regularmente as estatísticas do banco de dados MS SQL.

Para atualizar as estatísticas de todas as tabelas do banco de dados, você deve executar a seguinte consulta SQL:

exec sp_msforeachtable N"ATUALIZAR ESTATÍSTICAS ? COM FULLSCAN"

A atualização de estatísticas não leva ao bloqueio de tabelas e não interfere no trabalho de outros usuários. As estatísticas podem ser atualizadas sempre que necessário. Lembre-se de que a carga no servidor DBMS durante a atualização das estatísticas aumentará, o que pode afetar adversamente o desempenho geral do sistema.

A frequência ótima de atualização das estatísticas depende da magnitude e natureza da carga no sistema e é determinada experimentalmente. Recomenda-se atualizar as estatísticas Pelo menos uma vez ao dia.

A consulta acima atualiza as estatísticas de todas as tabelas no banco de dados. Em um sistema real, diferentes tabelas requerem diferentes taxas de atualização de estatísticas. Ao analisar os planos de consulta, você pode determinar quais tabelas precisam de atualizações mais frequentes de estatísticas e configurar dois (ou mais) procedimentos de rotina diferentes: para tabelas atualizadas com frequência e para todas as outras tabelas. Essa abordagem reduzirá significativamente o tempo de atualização das estatísticas e o impacto do processo de atualização das estatísticas na operação do sistema como um todo.

Configurando atualização automática de estatísticas (MS SQL 2005)

Inicie o MS SQL Server Management Studio e conecte-se ao servidor DBMS. Abra a pasta Management e crie um novo plano de manutenção:

Crie um subplano (Adicionar subplano) e nomeie-o como "Atualização de estatísticas". Adicione a Tarefa Atualizar estatísticas a ele na barra de tarefas:

Configure um cronograma de atualização de estatísticas. Recomenda-se atualizar as estatísticas pelo menos uma vez por dia. Se necessário, a frequência de atualização das estatísticas pode ser aumentada.

Defina as configurações da tarefa. Para fazer isso, clique duas vezes na tarefa no canto inferior direito da janela. No formulário que aparece, especifique o nome do banco de dados (ou vários bancos de dados) para os quais as estatísticas serão atualizadas. Além disso, você pode especificar para quais tabelas atualizar as estatísticas (se não souber exatamente quais tabelas precisa especificar, defina o valor como All).

A atualização das estatísticas deve ser feita com a opção Full Scan habilitada.

Salve o plano criado. Quando chegar a hora especificada na programação, as estatísticas serão atualizadas automaticamente.

Limpando o cache processual

O otimizador do MS SQL Server armazena em cache os planos de consulta para reexecução. Isso é feito para economizar tempo gasto compilando uma consulta se a mesma consulta já tiver sido executada e seu plano for conhecido.

É possível que o MS SQL Server, contando com informações estatísticas desatualizadas, crie um plano de consulta não ideal. Esse plano será armazenado no cache processual e usado quando a mesma consulta for invocada novamente. Se você atualizou as estatísticas, mas não limpou o cache processual, o SQL Server pode escolher o plano de consulta antigo (não ideal) do cache em vez de criar um novo plano (melhor).

Para limpar o cache processual do MS SQL Server, você deve executar a seguinte consulta SQL:

Esta consulta deve ser executada imediatamente após a atualização das estatísticas. Consequentemente, a frequência de sua execução deve corresponder à frequência de atualização das estatísticas.

Configurando a limpeza de cache processual (MS SQL 2005)

Como o cache processual precisa ser limpo toda vez que as estatísticas são atualizadas, é recomendável adicionar esta operação ao subplano "Atualizar estatísticas" já criado. Para fazer isso, abra o subplano e inclua a Tarefa Executar Instrução T-SQL em seu esquema. Em seguida, você deve conectar a Tarefa de atualização de estatísticas com uma seta à nova tarefa.

No texto da Tarefa Execute T-SQL Statement criada, você deve especificar a consulta "DBCC FREEPROCCACHE":

Desfragmentação de índice

Quando você trabalha intensamente com tabelas de banco de dados, ocorre o efeito de fragmentação dos índices, o que pode levar a uma diminuição na eficiência das consultas.

sp_msforeachtable N"DBCC INDEXDEFRAG (<имя базы данных>, ""?"")"

A desfragmentação do índice não bloqueia as tabelas e não interfere no trabalho de outros usuários; no entanto, cria uma carga adicional no SQL Server. A frequência ideal de execução deste procedimento de rotina deve ser selecionada de acordo com a carga do sistema e o efeito obtido da desfragmentação. Recomendamos que você desfragmente seus índices pelo menos uma vez por semana.

É possível desfragmentar uma ou mais tabelas, não todas as tabelas do banco de dados.

Configurando a desfragmentação do índice (MS SQL 2005)

No plano de manutenção criado anteriormente, crie um novo subplano chamado "Reindexar". Adicione uma tarefa de índice de reconstrução a ele:

Defina o cronograma de execução para a tarefa de desfragmentação do índice. Recomenda-se executar a tarefa pelo menos uma vez por semana e, se os dados no banco de dados forem altamente voláteis, com mais frequência - até uma vez por dia.

Reindexando tabelas do banco de dados

A reindexação da tabela inclui uma reconstrução completa dos índices da tabela do banco de dados, o que leva a uma otimização significativa de seu trabalho. Recomenda-se executar a reindexação regular das tabelas do banco de dados. Para reindexar todas as tabelas do banco de dados, você deve executar a seguinte consulta SQL:

sp_msforeachtable N"DBCC DBREINDEX(""?"")"

A reindexação de tabelas os bloqueia durante o trabalho, o que pode afetar significativamente o trabalho dos usuários. Nesse sentido, recomenda-se que a reindexação seja realizada durante a carga mínima do sistema.

Após a reindexação, não há necessidade de desfragmentar os índices.

Configurando a reindexação de tabelas (MS SQL 2005)

No plano de manutenção criado anteriormente, crie um novo subplano denominado "Index Defragmentation". Adicione uma tarefa de índice de reconstrução a ele:

Defina o planejamento de execução para a tarefa de reindexação da tabela. Recomenda-se executar a tarefa durante a carga mínima do sistema, pelo menos uma vez por semana.

Personalize a tarefa especificando o banco de dados (ou vários bancos de dados) e selecionando as tabelas necessárias. Se você não souber exatamente quais tabelas especificar, defina o valor como All.

Quando centenas de usuários trabalham com programas e dados ao mesmo tempo, surgem problemas inerentes apenas a soluções de larga escala. Estamos falando de problemas causados ​​por bloqueios de dados.

Às vezes, os usuários descobrem bloqueios de mensagens que indicam a incapacidade de gravar dados ou executar alguma outra operação. Às vezes devido a uma queda muito significativa no desempenho do programa (por exemplo, quando o tempo necessário para realizar uma operação aumenta dezenas ou centenas de vezes).

Os problemas causados ​​pelo bloqueio não têm solução geral. Portanto, tentaremos analisar as causas de tais problemas e sistematizar opções para sua solução.

MOTIVOS PARA O BLOQUEIO DA TRANSAÇÃO

Vamos primeiro lembrar o que são bloqueios e, ao mesmo tempo, descobriremos se eles são necessários. Vejamos alguns exemplos clássicos de bloqueio que encontramos na vida.

Exemplo 1: Comprar uma passagem de avião ou trem. Suponha que expressamos nossos desejos ao caixa. A caixa indica-nos a disponibilidade de lugares, de entre os quais podemos escolher o que mais gostamos (se forem vários, claro). Até que escolhamos e confirmemos o nosso acordo com a opção proposta, estes lugares não podem ser vendidos a mais ninguém, ou seja, temporariamente bloqueado. Se eles não foram bloqueados, no momento da confirmação pode haver uma situação em que os ingressos que escolhemos já foram vendidos. E neste caso, o ciclo de seleção pode ser um número imprevisível de repetições. Enquanto estamos escolhendo lugares, mas eles já foram vendidos! .. Enquanto estamos escolhendo outros, e eles não estão mais lá ...

Exemplo 2: comprar algo em uma loja ou mercado. Subimos ao balcão, escolhemos a maçã mais bonita entre as cem disponíveis. Eles escolheram e enfiaram a mão no bolso para pegar dinheiro. Como será se, enquanto contamos o dinheiro, for a maçã que escolhemos que será vendida ao comprador que veio depois de nós?

Assim, o bloqueio em si é um fenômeno necessário e útil. É graças ao bloqueio que garantimos a execução das ações em uma etapa. E, na maioria das vezes, nem a implementação de software mais bem-sucedida leva à negatividade, quando, por exemplo:

• um número excessivo de objetos (bilhetes, maçãs) está bloqueado;
• o tempo de bloqueio é excessivamente prolongado.

INTERTRAVAMENTOS EXCESSIVOS EM CONFIGURAÇÕES 1C TÍPICAS

Em grandes projetos, como regra, usamos 1C:Enterprise. Portanto, tentaremos descrever recomendações práticas para resolver problemas de bloqueio usando o exemplo do pacote 1C:Enterprise + MS-SQL.

A 8ª geração do 1C:Enterprise fornece um paralelismo de uso muito, muito bom. Simultaneamente com uma configuração (ou seja, em uma base), com servidores normais e canais de comunicação, um grande número de usuários pode trabalhar. Por exemplo, centenas de lojistas processam a emissão ou recebimento de mercadorias, os economistas calculam simultaneamente o custo dos salários de vários departamentos, os contadores calculam e calculam os salários, etc.

Mas há uma razão pela qual existe uma opinião contrária - o mito de que, com uso simultâneo intensivo, é desconfortável ou impossível trabalhar com soluções baseadas em 1C: Enterprise. Afinal, assim que centenas de usuários começam a usar soluções padrão para 1C:Enterprise em escala industrial, cada vez mais uma janela aparece na tela com uma inscrição orgulhosa: “Erro ao chamar o método de contexto (Registro): Bloquear conflito durante a execução de uma transação: ...” e, dependendo do tipo de servidor SQL usado, algo como “Microsoft OLE DB Provider para SQL Server: período de tempo limite da solicitação de bloqueio excedido. ...".

Quase todas as soluções padrão na implementação "pronta para uso" proposta são configuradas para gerenciamento de bloqueio automático. "Automático" aqui pode ser considerado "paranóico". Por precaução, ao conduzir qualquer documento, bloqueamos tudo o que possa estar de alguma forma relacionado a ele. Acontece que quando um usuário gasta alguma coisa (e às vezes apenas escreve), o resto só pode esperar.

Expressarei minha opinião por que a 1C decidiu não customizar suas soluções padrão para alto paralelismo de uso. Os custos de mão de obra para tal refinamento não são altos - alguns "meses-pessoa", o que não é significativo em termos de escala 1C. Acho que o motivo é diferente.

Em primeiro lugar, tal refinamento complica significativamente os processadores para postar todos os documentos. Isso significa que para os consumidores que usam 1C para pequenas tarefas, sem nenhum ganho, haverá apenas uma desvantagem - a complexidade de finalizar uma configuração típica ficará mais complicada. Ao mesmo tempo, as estatísticas sugerem qual categoria de clientes é o principal alimentador do 1C ...

O segundo motivo está enterrado nas configurações básicas típicas dos servidores SQL, por exemplo, MS-SQL, que ainda é usado com mais frequência do que outros. Acontece que as prioridades nas configurações são dadas para salvar a RAM do servidor e não para reduzir o bloqueio. Isso leva ao fato de que, se for necessário travar várias linhas, o servidor SQL toma uma decisão “econômica” para memória e processador - travar a tabela inteira de uma vez!..

São essas deficiências nas soluções padrão ou as especificidades das configurações do servidor de banco de dados usadas que geralmente são identificadas com problemas causados ​​pelo bloqueio. Como resultado, deficiências técnicas levam a problemas organizacionais muito significativos. Afinal, se um funcionário receber um motivo para se distrair do trabalho ou justificar por que o trabalho não pôde ser feito, uma minoria trabalhará com eficiência. Bem, uma mensagem sobre o bloqueio de transações ou um programa de “desaceleração” é uma justificativa ideal para que nada possa ser feito.

RECOMENDAÇÕES PARA ELIMINAÇÃO DE BLOQUEIO EXCESSIVO PARA 1C:ENTERPRISE

O que fazer se a solução de problemas de bloqueio excessivo é tão importante?

Na fase final de implementação de todos os grandes complexos, é necessário realizar um refinamento fino para eliminar bloqueios de transações desnecessários. É fundamental resolver problemas que possam surgir de condições de bloqueio ou metodologia de implementação insuficientemente desenvolvidas.

Porque Esta operação é extremamente importante, deve ser realizada constantemente. Portanto, para simplificar a implementação de tal refinamento, desenvolvemos uma série de recomendações básicas que tentamos seguir. Recomendações recebidas e testadas na experiência de um número significativo de implementações em larga escala.

1. Se seu DBMS ou sistema de desenvolvimento (por exemplo, 1C:Enterprise) usar o bloqueio automático de dados por padrão, desative o gerenciamento de bloqueio automático. Configure você mesmo as regras de bloqueio, descreva os critérios de bloqueio para tabelas inteiras ou linhas individuais.
2. Ao desenvolver um programa, sempre que possível, consulte as tabelas na mesma ordem.
3. Tente não gravar na mesma tabela várias vezes na mesma transação. Se isso for difícil, pelo menos minimize a quantidade de tempo entre a primeira e a última operação de gravação.
4. Analise a possibilidade de desabilitar o escalonamento de bloqueio no nível do servidor SQL.
5. Informe claramente os usuários sobre os motivos da impossibilidade de realizar quaisquer ações se forem devido ao bloqueio. Dê recomendações acessíveis e compreensíveis sobre o que fazer a seguir.

Se você olhar atentamente para as recomendações, fica claro que tal desenvolvimento é apropriado não apenas para 1C:Enterprise, mas para qualquer sistema. Não importa em qual idioma eles estão escritos e com qual servidor de banco de dados eles trabalham. A maioria das recomendações é de natureza universal e, portanto, são igualmente válidas ao usar 1C: Enterprise e para programas "auto-escritos" ou outros sistemas ERP "in a box".

PS Você sabia que oferecemos assistência profissional para atualizar 1C ao melhor preço?

Marcas de pesquisa:

• bloqueios de transação
• Removendo bloqueios
• Bloqueio 1C
• bloqueio
• Conflito de Bloqueio
• Conflito de bloqueio durante a execução de uma transação

Olá a todos!

Outro dia no trabalho, encontrei um problema com bloqueios, ou seja, a mensagem "Conflito de bloqueio ao executar uma transação. O tempo limite máximo para conceder um bloqueio foi excedido" começou a aparecer.

Obviamente, não há problema de impasse aqui, apenas alguma sessão colocou um bloqueio e "esqueceu" de removê-lo. Ao mesmo tempo, o problema ameaçava com sérias consequências - o documento Vendas de bens e serviços não foi realizado. Cerca de 100 pessoas trabalham no banco de dados por vez e é impossível realizar uma operação típica e frequente!

Havia duas soluções - reinicializar o servidor ou procurar uma sessão com falha. A primeira solução é simples e rápida, mas, como alguém já escreveu aqui, você pode reiniciar o servidor até ser demitido. Decidiu seguir o segundo caminho.

No primeiro dia - o problema apareceu à tarde, a princípio parecia que o problema estava no usuário remoto que estava preso no Configurador. Parecia que a execução parou em um ponto e a trava, é claro, não foi liberada. Depois de algumas horas, conseguimos liberar o configurador, mas o problema não desapareceu. Era extremamente indesejável matar o configurador à força, talvez eles trabalhassem nele. Depois disso, o Google assumiu. Encontrei um artigo neste site, que diz como encontrar bloqueios no MS SQL DBMS, verificado, não havia bloqueios no nível do DBMS. Esquisito. Além disso, houve tentativas de ajustá-los. revista. Configurar, o que vem a seguir? Em 15 minutos, alguns shows de logs! Como lê-los, o que procurar? Desconhecido.

Encontrei um artigo sobre como ver o que está bloqueado pelo SQL Trace. Mesmo que eu encontre, e daí? Eu preciso de uma sessão!

Mais perto das 16h, quando percebi que não conseguiria mais, reiniciei. Na esperança de que isso não aconteça novamente (e este foi o primeiro caso em seis meses de trabalho), respirei aliviado, deu tudo certo. Mas em vão ... O segundo dia - a mesma situação. Eu cavei por uma hora e meia, novamente tentativas incompreensíveis de google e assim por diante. Sem resultados. Reinício. No final do dia, aconteceu de novo. Bem, acho ótimo, vou voltar para casa com calma e sentar, cavar mais fundo. Chego em casa, está tudo bem. Infelizmente.

No terceiro dia, assisti a um webinar e falei sobre uma maneira interessante e eficaz de encontrar um problema. Lembrou, mas o problema não surgiu mais. Uma semana se passou e aqui está - novamente bloqueando! Eu esfrego minhas mãos e começo a agir.

A primeira é configurar o log. Sim, não posso ficar sem ele, mas agora posso lê-lo. Definimos dois eventos: o primeiro é TLOCK, o segundo é TTIMEOUT. O primeiro exibe todos os eventos de bloqueio, o segundo mostra os bloqueios que não puderam ser estabelecidos no tempo alocado. Na verdade, muito provavelmente, apenas TTIMEOUT é suficiente.

Copiamos o arquivo de log técnico para o local designado, voamos para o programa, chamamos o bloqueio, recebemos uma mensagem e removemos ou renomeamos o arquivo de log técnico. Não precisamos de toneladas de informações sobre outros bloqueios!

Vá para a pasta rphost_PID, localize os arquivos de texto e procure a palavra TTIMEOUT. Vemos a linha:

53:16.789126-0,TTIMEOUT,5,process=rphost,p:processName=*****,t:clientID=16536,t:applicationName=1CV8,t:computerName=ASUSM,t:connectID=17272,SessionID= 2242,Usr=*********,WaitConnections=8239

A propósito, pode haver várias pastas rphost_PID, tudo depende de quantos processos de trabalho estão sendo executados no servidor.

E aí tudo é simples: olhe no final da linha - WaitConnections = 8239, esse é o nosso número de CONNECTION. Vamos ao console do servidor, vamos a Conexões, encontramos esse número e verificamos o número da sessão. No meu caso, houve duas sessões por usuário - uma com falha e outra. Travou a sessão indicada pelo log técnico. E sobre um milagre! Tudo funcionou, não há limite para a alegria! Mas, como descobri depois, a sessão não foi travada :), eles trabalharam nela. Portanto, para o futuro, é aconselhável entrar em contato com o usuário e avisar.

Na minha opinião, uma solução bastante típica para um problema bastante típico. Não se sabe por que não o encontrei, talvez pelo fato de ter que procurá-lo em alarme, e quando os usuários não pressionavam, não era possível fazer testes - não havia erro.

Não raramente, ao trabalhar em 1C, ocorre o erro “Conflito de bloqueio ao executar transações: o tempo máximo de espera para conceder um bloqueio foi excedido”. Sua essência reside no fato de várias sessões tentarem realizar simultaneamente ações semelhantes, afetando o mesmo recurso. Hoje vamos descobrir como corrigir esse erro.

Um grande número de operações

Em primeiro lugar, ao procurar os motivos, você deve esclarecer quantos usuários trabalhando simultaneamente estão na infobase em que esse erro é gerado. Como sabemos, seu número máximo pode ser bastante grande. São mil e cinco mil.

O mecanismo de bloqueios e transações é descrito no guia do desenvolvedor. Eles são usados ​​quando várias sessões acessam os mesmos dados ao mesmo tempo. É lógico que os mesmos dados não podem ser alterados por diferentes usuários ao mesmo tempo.

Você também deve verificar se algum dos usuários iniciou o processamento para alteração de dados em massa. Pode ser tipo , fechamento do mês e afins. Nesse caso, após o término do processamento, o erro desaparecerá por si só.

Atribuições agendadas

Não é incomum que a causa do erro esteja no processamento de uma grande quantidade de dados. Recomenda-se fazer essas coisas à noite. Agende a execução de tais tarefas agendadas fora do horário de trabalho.

Assim, ambos os usuários trabalharão em um sistema estável e as próprias tarefas agendadas serão concluídas com sucesso, pois a probabilidade de conflitos com as sessões do usuário diminuirá.

"Sessões bloqueadas"

O problema das "sessões travadas" dos usuários é familiar para quase todos que encontraram o serviço 1C. O usuário pode ter saído do programa há muito tempo ou fechado um documento, mas sua sessão ainda permanece no sistema. O problema geralmente é único e basta encerrar essa sessão por meio do console do administrador. Os mesmos problemas podem ocorrer com trabalhos em segundo plano.

De acordo com vários comentários na Internet, essas situações são mais comuns ao usar chaves de segurança de rede. Caso a situação de "sessões travadas" se repita sistematicamente, este é o motivo de uma verificação e manutenção minuciosa do sistema e servidores (se a base for cliente-servidor).

Erros ao escrever a configuração

Todas as configurações típicas são desenvolvidas por especialistas e especialistas qualificados. Cada sistema é cuidadosamente testado e otimizado para um trabalho mais rápido e correto.

Nesse sentido, a causa do erro pode estar em um código abaixo do ideal escrito por um desenvolvedor terceirizado. Essa pode ser uma solicitação "pesada" que bloqueará os dados por um longo período de tempo. Também não é incomum construir algoritmos com baixo desempenho e violação de lógica.

É altamente provável que um conflito de bloqueio tenha surgido justamente por causa de erros do desenvolvedor, caso tenha surgido após a atualização do programa. Para verificar, você pode simplesmente “reverter” as melhorias ou refatorar o código.