Instruções UPDATE podem ser replicadas como DELETE/INSERT pares

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

Sumário

Se qualquer coluna que faz parte de uma restrição exclusiva é atualizada, SQL Server implementa a atualização como uma "adiada atualização", que significa como um par de DELETE / INSERT operações. Este "Atualização adiada" faz com que a duplicação para enviar um par de DELETE / INSERT instruções para os assinantes. Também há outras situações que podem causar uma atualização adiada. Portanto, qualquer lógica de negócios que você implementar em sua UPDATE disparadores ou procedimentos armazenados personalizados no assinante também deve ser incluída no DELETE / INSERT disparadores ou procedimentos armazenados personalizados.

Mais Informações

O comportamento padrão na replicação transacional é usar INSERT , UPDATE e DELETE procedimentos armazenados personalizados para aplicar alterações nos assinantes.

instruções INSERT feitas no editor são aplicadas a assinantes através de uma chamada de procedimento INSERT armazenado. Da mesma forma, uma instrução DELETE é aplicada por meio de uma chamada de procedimento DELETE armazenados.

No entanto, quando uma instrução UPDATE é executada como uma "adiada atualização", os locais de agente logreader um par de DELETE / procedimento INSERT armazenado chama no banco de dados distribuição para ser aplicado aos assinantes em vez de uma atualização armazenadas chamada de procedimento. Por exemplo, suponha que você tenha uma tabela de publicação, chamada Table1, com essas três colunas:
  • Col1 int
  • Col2 int
  • Col3 varchar(30).
A restrição exclusiva somente em Table1 é definida em col1 através de uma restrição de chave primária. Pressupõem que você tenha um registro (1,1, ' Dallas').

Quando você executar esse código:
UPDATE TABLE1 set col1 = 3 where col2 = 'Dallas'
				
a instrução UPDATE é implementada pelo SQL Server como um par de DELETE / INSERT instruções desde que você estão atualizando col1, que tem um índice exclusivo definido. Portanto, o logreader coloca um par de DELETE / INSERT chama no banco de dados de distribuição. Isso pode afetar qualquer lógica comercial que está presente no disparadores ou procedimentos armazenados personalizados no assinante. Você deve incorporar a lógica de negócios adicionais em DELETE e INSERT disparadores ou procedimentos armazenados para lidar com essa situação.

Se você preferir usar lógica única e desejar que todos os seus comandos UPDATE replicados como DELETE / INSERT pares, você pode ativar um sinalizador de rastreamento conforme descrito neste artigo:
160181INF: Sinalizador de rastreamento para duplicar UPDATE como DELETE/INSERT par
Além disso, se você usar um filtro horizontal em sua publicação e se a linha atualizada não atender a uma condição de filtro, somente uma DELETE chamada de procedimento é enviada para os assinantes. Se a linha atualizada anteriormente não atendeu a condição de filtro, mas atende à condição após a atualização, apenas a INSERT chamada de procedimento será enviada através do processo de replicação.

No exemplo anterior, pressupõem que você também tenha um filtro horizontal definido em Table1: onde col2 = 'Dallas'. Se você executar este código:
UPDATE table1 set col2 = 'New York' where col1 = 3
				
os locais de somente agente logreader um DELETE armazenados chamada de procedimento a ser aplicado aos assinantes desde que a linha atualizada não atende aos critérios de filtro horizontal.

Agora, se você executar esse código:
UPDATE table1 set col2 = 'Dallas' where col1 = 3
				
o logreader gera somente INSERT armazenado chamada de procedimento, pois a linha não atendeu anteriormente a condição de filtro.

Embora uma operação UPDATE foi executada no Editor, somente os comandos apropriados são aplicados no assinante.

Referências

Para o SQL Server 2000 Service Pack 1 ou posterior, consulte o seguinte artigo na Base de dados de Conhecimento da Microsoft:
302341INF: Novo sinalizador de rastreamento para ativar a atualização de singleton para replicação transacional

Propriedades

ID do artigo: 238254 - Última revisão: segunda-feira, 12 de maio de 2008 - Revisão: 6.2
A informação contida neste artigo aplica-se a:
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 7.0 Standard Edition
  • Microsoft SQL Server 2005 Workgroup Edition
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
Palavras-chave: 
kbmt kbinfo KB238254 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: 238254

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