Partilhar via


Os dados não estão sendo distribuídos aos Assinantes

Se aparentemente os dados não estiverem sendo distribuídos aos Assinantes, há duas razões principais:

  • Os dados não estão sendo aplicados devido a filtragem, um problema com o agente ou outro erro de replicação.

  • Os dados estão sendo excluídos no Assinante, depois de aplicados.

Explicação

Há vários razões possíveis para os dados não serem distribuídos aos Assinantes:

  • A tabela é filtrada e não há nenhuma alteração para distribuir para um determinado Assinante.

  • Um ou mais agentes não estão executando ou estão com um erro.

  • Uma assinatura transacional foi inicializada sem um instantâneo, e ocorreram mudanças no Publicador desde que a publicação foi criada.

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

  • O procedimento armazenado INSERT usado por um artigo transacional inclui uma condição que não é atendida.

  • Os dados são excluídos por um usuário, um script de replicação ou outro aplicativo.

  • Os dados são excluídos por um gatilho ou um gatilho inclui uma instrução ROLLBACK.

Ação do usuário

Antes de tentar diagnosticar por que os dados não estão sendo distribuídas aos Assinantes, recomendamos que use a validação ou o utilitário tablediff para verificar quais as linhas que estão faltando:

  • Se o Distribution Agent ou Merge Agent puderem executar, 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 esse método não revela as diferenças no conteúdo dos dados. Para obter mais informações, consulte Validando os dados replicados.

  • Se o Distribution Agent ou o Merge Agent não conseguem executar, determine se há dados faltando, executando o utilitário tablediff. Para obter informações sobre como usar esse utilitário em tabelas replicadas, consulte Como comparar tabelas replicadas para descobrir diferenças (Programação de Replicação).

Descobrindo a causa de dados perdidos

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

  • A tabela é filtrada e não há nenhuma alteração para distribuir para um determinado Assinante.

    É possível que as linhas que faltam no Assinante não tenham sido replicadas, pois não atendem aos critérios de filtragem da publicação. Todos os tipos de replicação oferecem suporte a filtros estáticos e a replicação de mesclagem também dá suporte a filtros com parâmetros e filtros de junção. Para obter mais informações, consulte Filtrando dados publicados. Se um ou mais artigos da publicação forem filtrados, execute os seguintes procedimentos e verifique o valor cláusula de filtro.

    Use a cláusula de filtro para determinar se alguma linha perdida atende aos critérios de filtragem. Por exemplo, você poderá executar a cláusula de filtro na tabela do Publicador e determinar se os dados retornados correspondem aos dados do Assinante.

  • Um ou mais agentes não estão executando ou estão com um erro:

  • Uma assinatura transacional foi inicializada sem um instantâneo e ocorreram mudanças no Publicador desde que a publicação foi criada:

    • Se você habilitar uma publicação para inicializar a partir de um backup, as mudanças em tabelas publicadas são rastreadas no log do banco de dados de publicação, assim que a publicação é criada. Quando a subscrição é inicializada, as mudanças pendentes são distribuídas ao Assinante, desde que estejam disponíveis no banco de dados de distribuição.

    • Diferentemente da inicialização a partir de um backup, se você inicializar a assinatura usando a opção suporte para a replicação somente, é preciso que você ou o aplicativo verifique se os dados e o esquema estão sincronizados corretamente, na hora que você adicionar a assinatura. Por exemplo, se houver atividade no Publicador, durante o tempo em que os dados e o esquema são copiados no Assinante e a Assinatura é adicionada, as alterações resultantes dessa atividade poderão não ser replicadas no Assinante.

    Para obter mais informações, consulte Inicializando uma assinatura transacional sem um instantâneo.

  • A replicação de execução do procedimento armazenado de 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 daquelas do Publicador. Considere um procedimento que executa um cálculo e então insere dados baseados neste cálculo. Se o Assinante é filtrado, de modo que o cálculo no Assinante seja baseado em dados diferentes, o resultado inserido no Assinante poderá ser diferente ou poderá não ocorrer a inserção.

  • O procedimento armazenado INSERT usado por um artigo transacional inclui uma condição que não é atendida.

    Por padrão, replicação transacional usa um conjunto de procedimentos armazenados para distribuir as alterações aos Assinantes. Você também pode personalizar esses procedimentos para incluir a lógica corporativa necessária ao seu aplicativo. Para obter mais informações, consulte Especificando como as alterações são propagadas para Artigos Transacionais. Se o procedimento armazenado INSERT usado por um artigo transacional inclui uma condição, em usa lógica, que não é atendida, a inserção não ocorrerá. Considere um procedimento que é personalizado para verificar um determinado valor de tabela em uma tabela (tabela A) no Assinante, antes de permitir uma inserção em outra tabela (tabela B). Se o valor não está disponível na tabela A, por causa de um erro ou de dados que não foram replicados ainda nessa tabela, a linha esperada não existe na Tabela B.

  • Os dados estão sendo excluídos por um usuário, um script de replicação ou outro aplicativo:

    • Se desejar permitir que os usuários excluam os dados em um Assinante, use a replicação de mesclagem, a replicação transacional com assinaturas atualizáveis ou a replicação transacional ponto a ponto. As exclusões são propagadas ao Publicador, assim os dados no Publicador e Assinante acabarão convergentes. 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 contém a palavra ROLLBACK e usa a opção NOT FOR REPLICATION (que impede que o gatilho seja acionado quando o Replication Agent estiver executando uma operação). Por exemplo:

      USE AdventureWorks2008R2;
      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.

    • A replicação permite que se executem scripts antes e depois da aplicação do instantâneo e durante a sincronização. 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, normalmente, para tarefas administrativas, como adição de logons no Assinante. Se os scripts forem usados para excluir os dados em um Assinante, isso deve ser tratado como somente leitura, o administrador deve assegurar que não haja não convergência.

  • Os dados são excluídos por um gatilhos ou um gatilhos inclui uma instrução ROLLBACK.

    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 deveriam usar a opção NOT FOR REPLICATION. Se um gatilho inclui uma instrução ROLLBACK e o gatilho não usa a opção NOT FOR REPLICATION, as linhas que foram replicadas em um Assinante podem não ser 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.

Consulte também

Conceitos