INF: Rollback TRANSACTION em disparadores no assinante pode quebrar a integridade transacional

Traduções deste artigo Traduções deste artigo
ID do artigo: 240025 - Exibir os produtos aos quais esse artigo se aplica.
Expandir tudo | Recolher tudo

Neste artigo

Sumário

Disparadores, às vezes, são adicionados no assinante para impor regras de negócios adicionais que não são aplicadas no Editor. Essa adição pode danificar a integridade transacional com a replicação se ROLLBACK , fazer com que os disparadores porque a tarefa de distribuição usa processamento em lotes de transações para melhorar o desempenho. Documentação do SQL Server informa que o lote todo será cancelado quando uma ROLLBACK TRANSACTION é encontrado em um disparador. Consulte SQL Server versão 7.0 Books Online no tópico "Reversões em armazenados procedimentos e disparadores", ou 6.5 manuais online do SQL Server sob o tópico "Transação de disparadores e reversão" para obter mais detalhes.

Mais Informações

O SQL Server replicação faz usar de processamento em lotes de transações para viagens de ida e volta pela rede, reduzindo, assim, aprimorando o desempenho. Se disparadores que podem resultar em ROLLBACK são adicionados no assinante, lotes de transações serão canceladas. Isso não é uma condição de erro e o agente de distribuição não falha quando isso ocorre. Como um lote pode conter comandos de várias transações ou parte de uma transação grande no Editor, ele pode resultar em comprometer a integridade transacional. As seções a seguintes fornecem detalhes em cada um dos cenários anteriores.

Várias transações aplicadas em um único lote

Considere o caso em que várias transações no editor são aplicadas como uma única transação no assinante. Isso pode resultar em um lote consistindo em comandos de mais de um trabalho. Em tais casos, quando um comando ROLLBACK TRANSACTION é encontrado em um disparador em qualquer instrução no lote, a transação inteira é revertida. Isso pode resultar em outras transações que não fazem parte da transação ofensivo Obtendo revertida devido para processamento em lotes. Porque o lote todo for cancelado, outras transações no seguinte lote o comando que causou o ROLLBACK não são executadas uma. Isso pode ser percebido como ausentes registros ou transações no assinante. Isso é ilustrado pelo seguinte exemplo:
   At the Publisher, transactions T1, T2 and T3 were committed.
   Logreader inserted these three transactions into the Distribution
      database.
   Distribution batches these three jobs into a single batch and
      assuming the command in T2 caused a ROLLBACK, the transaction 
      that began the batch would be rolled back causing T1 to be rolled
      back. Since the ROLLBACK command results in the rest of the batch
      being cancelled, T3 is also lost.
   Subscriber is out of sync with the Publisher.
				

Transações única aplicada em vários lotes no assinante

Por outro lado, um lote deve conter apenas uma parte da transação se ele tiver um grande número de comandos. Se for encontrado um ROLLBACK TRANSACTION , este lote será cancelada e a transação é revertida. Observe que o agente de distribuição usa transações implícitas e, portanto, a próxima instrução inicia uma nova transação. Os comandos remanescentes no trabalho de obter executados no próximo lote como uma parte desta transação e podem confirmar posteriormente. Esse comportamento pode resultar em uma transação parcial sendo confirmada no assinante, assim quebra integridade transacional. Isso é explicado no exemplo a seguir:
   At the Publisher, a single transaction T1 consisting of 20 commands was
      committed. Since this is a single transaction, all 20 commands
      should be committed in total at the Subscriber, to preserve
      transactional integrity.
   Logreader inserted this transaction and inserts into the Distribution
      database the 20 commands for this transaction.
   Distribution processes this transaction and assuming 10 commands fit
      into a single batch, sends the first 10 commands. Assuming the 5th
      command in this transaction caused a ROLLBACK, the transaction 
      that began the batch would be rolled back causing commands 1 thru 5
      to be rolled back. Since the ROLLBACK command results in the rest of
      the batch being cancelled, commands 6-10 are also lost. When the 
      Distribution agent continues, it sends commands 11-20 in the next
      batch and since the autocommit option is OFF, this begins a new 
      transaction and continues to completion, causing commands 11-20 to
      be committed, resulting in partial transaction to be committed at
      the subscriber.
   Subscriber is out of sync with the Publisher.
				
Continua o processo de distribuição com os comandos restantes se não houver nenhum erro retornado pelo servidor. Como o comando ROLLBACK não é uma condição de erro, a menos que o disparador explicitamente gerará um erro usando uma instrução RAISERROR , a tarefa de distribuição prosseguirá com os trabalhos restantes no banco de dados de distribuição. Se um RAISERROR for encontrado, a tarefa de distribuição falha com erro alto relevo. Se você tiver que usar uma instrução ROLLBACK em disparadores no assinante, ele deve ser seguido por uma instrução RAISERROR com o nível de gravidade adequado para a tarefa de distribuição para falhar. Além disso, após RAISERROR , você deve adicionar um RETURN para garantir que o SQL Server não processa outras instruções no disparador. Para obter ajuda sobre o uso de RAISERROR , consulte os manuais online do SQL Server sob o tópico "RAISERROR."

Observe que isso não é um problema com a replicação. É a manipulação de um comando ROLLBACK dentro de um disparador que afeta o processo de replicação.

Microsoft recomenda que você não use um ROLLBACK TRANSACTION em disparadores no assinante. Em vez disso, use procedimentos armazenados personalizados para aplicar regras de negócios adicionais no assinante. Procedimentos armazenados personalizados pode manipular uma lógica mais complexa e não aplicar a transação, em vez de implantá-la novamente.

Propriedades

ID do artigo: 240025 - Última revisão: quarta-feira, 26 de novembro de 2003 - Revisão: 3.1
A informação contida neste artigo aplica-se a:
  • Microsoft SQL Server 6.0 Standard Edition
  • Microsoft SQL Server 6.5 Standard Edition
  • Microsoft SQL Server 7.0 Standard Edition
  • Microsoft SQL Server 2000 Standard Edition
Palavras-chave: 
kbmt kbinfo KB240025 KbMtpt
Tradução automática
IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine Translation ou MT), não tendo sido portanto traduzido ou revisto por pessoas. A Microsoft possui artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais, com o objetivo de oferecer em português a totalidade dos artigos existentes na base de dados de suporte. No entanto, a tradução automática não é sempre perfeita, podendo conter erros de vocabulário, sintaxe ou gramática. A Microsoft não é responsável por incoerências, erros ou prejuízos ocorridos em decorrência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza atualizações freqüentes ao software de tradução automática (MT). Obrigado.
Clique aqui para ver a versão em Inglês deste artigo: 240025

Submeter comentários

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com