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

Este artigo descreve que as instruções de atualização podem ser replicadas como pares DELETE/INSERT.

Versão original do produto: SQL Server
Número de KB original: 238254

Resumo

Se qualquer coluna que faz parte de uma restrição exclusiva for atualizada, SQL Server implementará a atualização como uma "atualização adiada", o que significa como um par de DELETE/INSERT operações. Essa "atualização adiada" faz com que a replicação envie um par de DELETE/INSERT instruções aos assinantes. Há também outras situações que podem causar uma atualização adiada. Portanto, qualquer lógica de negócios que você implementar em seus UPDATE gatilhos ou procedimentos armazenados personalizados no Assinante também deve ser incluída nos DELETE/INSERT gatilhos ou procedimentos armazenados personalizados.

Mais informações

O comportamento padrão na replicação transacional é usar INSERTe UPDATEDELETE procedimentos armazenados personalizados para aplicar alterações nos assinantes.

INSERT as instruções feitas no Publisher são aplicadas aos assinantes por meio de uma INSERT chamada de procedimento armazenada. Da mesma forma, uma DELETE instrução é aplicada por meio de uma DELETE chamada de procedimento armazenado.

No entanto, quando uma instrução UPDATE é executada como uma "atualização adiada", o agente logreader coloca um par de chamadas de procedimento armazenadas no banco de DELETE/INSERT dados de distribuição a serem aplicadas aos Assinantes em vez de uma chamada de procedimento armazenado de atualização. Por exemplo, suponha que você tenha uma tabela de publicação chamada TABLE1, com estas três colunas:

• col1 int
• col2 int
• col3 varchar(30)

A única restrição exclusiva em TABLE1 é definida por col1 meio de uma restrição de chave primária. Suponha que você tenha um recorde (1,1,'Dallas').

Ao executar este código:

UPDATE TABLE1 set col1 = 3 where col3 = 'Dallas'

A UPDATE instrução é implementada por SQL Server como um par deINSERTDELETE/instruções desde que você está atualizando col1, que tem um índice exclusivo definido. Assim, o logreader coloca um par de chamadas no banco de dados de DELETE/INSERT distribuição. Isso pode afetar qualquer lógica de negócios presente nos gatilhos ou nos procedimentos armazenados personalizados no Assinante. Você deve incorporar a lógica comercial adicional e DELETEINSERT dispara ou procedimentos armazenados para lidar com essa situação.

Se preferir usar a lógica única e desejar que todos os comandos UPDATE sejam replicados como DELETE/INSERT pares, você poderá habilitar um sinalizador de rastreamento.

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, apenas uma DELETE chamada de procedimento será enviada aos assinantes. Se a linha atualizada anteriormente não atendesse à condição de filtro, mas atendesse à condição após a atualização, somente a chamada de INSERT procedimento será enviada por meio do processo de replicação.

No exemplo anterior, suponha que você também tenha um filtro horizontal definido em TABLE1: where col3 = 'Dallas'. Se você executar este código:

UPDATE table1 set col3 = 'New York' where col1 = 3

o agente logreader só coloca uma DELETE chamada de procedimento armazenado a ser aplicada aos assinantes, uma vez que a linha atualizada não atende aos critérios de filtro horizontal.

Agora, se você executar este código:

UPDATE table1 set col3 = 'Dallas' where col1 = 3

o logreader gera apenas a chamada de INSERT procedimento armazenado, já que a linha não cumpriu anteriormente a condição de filtro.

Embora uma UPDATE operação tenha sido executada no Publisher, apenas os comandos apropriados são aplicados no Assinante.