Os dados do Publicador e do Assinante não correspondem

Os dados no Publicador e no Assinante são considerados não convergentes (ou seja, os dados não correspondem) se:

• O número de linhas no Assinante for diferente do número de linhas no Publicador e a publicação não for filtrada. Se a publicação for filtrada, talvez o número de linhas seja diferente.

• Os dados em uma ou mais linhas forem diferentes em conteúdo no Publicador e no Assinante.

Explicação

Os dados no Publicador e no Assinante podem ser não convergentes por várias razões:

• Os dados são atualizados em um Assinante que deveria ser tratado como somente leitura. O banco de dados de assinatura deve ser tratado como somente leitura a menos que você esteja usando a replicação de mesclagem, replicação transacional com assinaturas atualizáveis ou replicação transacional ponto a ponto.

• São usados gatilhos no Assinante. Os gatilhos podem alterar dados no Assinante e também impedem que os dados sejam atualizados se o gatilho emitir um ROLLBACK.

• Os scripts são executados por replicação no Assinante, mas não no Publicador.

• A replicação de execução de procedimento armazenado para uma publicação transacional produz resultados diferentes no Assinante.

• As violações de restrição ou outros problemas impedem que as linhas sejam inseridas, atualizadas ou excluídas no Assinante.

Ação do usuário

As seguintes ações descrevem como determinar se os dados são não convergentes e como fazer para que eles convirjam:

1. Determine se os dados são não convergentes utilizando a validação ou o utilitário tablediff:

   • Se o Distribution Agent ou Merge Agent puderem ser executados, determine se estão faltando dados executando a validação de soma de verificação binária. Você também pode usar a validação de número de linhas, mas este método não revela as diferenças em conteúdo nos dados. Para obter mais informações, consulte Validando os dados replicados.

   • Se o Distribution Agent ou Merge Agent não puderem ser executados, determine se os dados são não convergentes executando o utilitário tablediff. Para obter informações sobre como usar este utilitário em tabelas replicadas, consulte Como comparar tabelas replicadas para descobrir diferenças (Programação de Replicação).

2. Se os dados não estiverem convergentes, você poderá usar o utilitário tablediff para gerar um script Transact-SQL para fazer com que os dados convirjam. Para obter mais informações, consulte Utilitário tablediff.

Endereçando a causa da não-convergência

As ações abaixo tratam das causas listadas na seção de "Explicação":

• Os dados são atualizados no Assinante fora da replicação:

  • Se você quer autorizar os usuários a inserir, atualizar e excluir dados no Assinante, use replicação de mesclagem, replicação transacional com assinaturas atualizáveis ou replicação transacional ponto a ponto. Para obter mais informações, consulte Visão geral da replicação de mesclagem. e Tipos de publicação para Replicação Transacional.

  • Se você deseja impedir que os usuários insiram, atualizem e excluam dados no Assinante, crie um gatilho para cada tabela que contenha a palavra ROLLBACK e usa a opção NOT FOR REPLICATION (que impede que o gatilho seja acionado quando o Replication Agent executa uma operação). Por exemplo:

    USE AdventureWorks
    GO
    CREATE TRIGGER prevent_user_dml
    ON Person.Address
    FOR INSERT, UPDATE, DELETE
    NOT FOR REPLICATION
    AS
    ROLLBACK
    

    Para obter mais informações, consulte CREATE TRIGGER (Transact-SQL) e Controlando restrições, identidades e gatilhos com NOT FOR REPLICATION.

• São usados gatilhos no Assinante. Os gatilhos no Assinante devem ser gerenciados corretamente de forma que não causem não-convergência ou outros problemas:

  • Os gatilhos só devem alterar os dados em um Assinante se for usada a replicação de mesclagem, a replicação transacional com assinaturas atualizáveis ou a replicação transacional ponto a ponto. Para obter mais informações, consulte Visão geral da replicação de mesclagem. e Tipos de publicação para Replicação Transacional.

  • Em muitos casos, os gatilhos devem usar a opção NOT FOR REPLICATION. Considere um gatilho que insere dados em uma tabela de rastreamento: quando o usuário insere originalmente a linha, é apropriado que o gatilho seja acionado e insira uma linha na tabela de rastreamento, mas o gatilho não deverá ser acionado quando os dados forem replicados para o Assinante, porque isto resultará em uma linha desnecessária inserida na tabela de rastreamento.

    Se um gatilho incluir uma instrução ROLLBACK e o gatilho não usar a opção NOT FOR REPLICATION, as linhas que foram replicadas em um Assinante talvez não sejam aplicadas.

  • Para a replicação transacional, existem outras considerações com relação à configuração XACT_ABORT e o uso das instruções COMMIT e ROLLBACK em um gatilho. Para obter mais informações, consulte a seção "Gatilhos" em Considerações sobre replicação transacional.

• Os scripts são executados por replicação no Assinante, mas não no Publicador.

  Os parâmetros @pre_snapshot_script e @post_snapshot_script de sp_addpublication e sp_addmergepublication permitem que você especifique scripts a serem executados antes e depois da aplicação do instantâneo. Para obter mais informações, consulte Executando scripts antes ou depois que o instantâneo é aplicado. O procedimento armazenado sp_addscriptexec permite executar um script durante o processo de sincronização. Para obter mais informações, consulte Como executar scripts durante a sincronização (Programação Transact-SQL de replicação).

  Esses scripts são usados tipicamente para tarefas administrativas, como adição de logons no Assinante. Se os scripts forem usados para atualizar dados em um Assinante que deve ser tratado como somente leitura, o administrador deve assegurar que não resultem não-convergências.

• A replicação de execução de procedimento armazenado para uma publicação transacional produz resultados diferentes no Assinante.

  Se você replicar a execução de um procedimento armazenado, a definição do procedimento será replicada para o Assinante quando a assinatura for inicializada; quando o procedimento armazenado for executado no Publicador, a replicação executará o procedimento correspondente no Assinante. Para obter mais informações, consulte Publicando execução de procedimento armazenado em replicação de transação.

  Poderá ocorrer uma não-convergência se o procedimento armazenado executar uma ação diferente no Assinante ou agir sobre dados diferentes daqueles do Publicador. Considere um procedimento que realiza um cálculo e então insere dados baseados neste cálculo. Se o Assinante for filtrado de forma que o cálculo no Assinante baseie-se em dados diferentes, o resultado inserido no Assinante poderá ser diferente ou poderá não ocorrer inserção.

• As violações de restrição ou outros assuntos impedem que as linhas sejam inseridas, atualizadas ou excluídas no Assinante.

  Para replicação transacional, as violações de restrição são tratadas como erros; por padrão, elas fazem com que o Distribution Agent pare a sincronização se não forem encontradas (para obter mais informações sobre como ignorar esses erros, consulte Ignorando erros na replicação transacional). Para replicação de mesclagem, as violações de restrição são tratadas como conflitos; elas são registradas, mas não fazem o Merge Agent parar a sincronização. Para os dois tipos de replicação, as violações de restrição podem acarretar não-convergência se uma inserção, atualização ou exclusão obteve êxito em um nó, mas não em outro.

  Quando uma tabela é publicada, as opções de esquema padrão especificam que as restrições de chave estrangeira e de verificação deverão ser criadas no banco de dados de assinatura com a opção NOT FOR REPLICATION definida. Se o seu aplicativo requer configurações diferentes para restrições, altere as opções de esquema. Para obter mais informações, consulte Como especificar opções de esquema (SQL Server Management Studio) e Como especificar opções de esquema (Programação Transact-SQL de replicação).

Consulte também

Conceitos

Solucionando problemas (Replicação)