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.

  • Filtro estático para instantâneo e publicações transacionais: a coluna filter_clause retornada por sp_helparticle (Transact-SQL).

  • Filtro estático ou filtro com parâmetros para publicações de mesclagem: a coluna subset_filterclause retornada por sp_helpmergearticle (Transact-SQL).

  • Filtro de junção para publicações de mesclagem: a coluna join_filterclause retornada por sp_helpmergefilter (Transact-SQL).

  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:

  • Se estiver inicializando uma assinatura, verifique se o Snapshot Agent da publicação foi concluído antes de tentar aplicar o instantâneo com o Distribution Agente ou com o Merge Agent. Se tentar aplicar o instantâneo antes de estar concluído, o seguinte erro ocorrerá: "O instantâneo inicial da publicação '%1' ainda não está disponível".

  • Para a replicação transacional, verifique se o Distribution Agent e o Log Reader Agent estão sendo executados; para a replicação de mesclagem, verifique se o Merge Agent está executando. Para obter mais informações sobre como iniciar esses agentes, consulte Como iniciar e parar um Replication Agent (SQL Server Management Studio) e Conceitos dos executáveis do Replication Agent.

  • Se um agente parar por causa de um erro, exiba os detalhes de erro para o agente para determinar qual é a causa subjacente. Para obter informações sobre como exibir detalhes de erro para o Snapshot Agent e o Log Reader Agent, consulte Como exibir informações e executar tarefas para os agentes associados com uma publicação (Replication Monitor). Para obter informações sobre o Distribution Agent e o Merge Agent, consulte Como exibir informações e executar tarefas para os agentes associados a uma assinatura (Replication Monitor). Se o erro continuar ocorrendo, aumente o log do agente e especifique um arquivo de saída para o log. Dependendo do contexto do erro, poderá fornecer as etapas que levaram ao erro e/ou mensagem de erro adicionais. Para obter mais informações, consulte Agentes de replicação (Solucionando problemas).

    Erros comuns, que fazem com que os dados não sejam distribuídos, incluem problemas de permissões e violações de restrição. Para obter mais informações sobre problemas de permissões, consulte Problemas de segurança estão impedindo os dados de serem replicados. Violações de restrição impedem as linhas de serem inseridas no Assinante.

    Para a replicação transacional, as violações de restrição são tratadas como erros; por padrão podem fazer com que o Distribution Agent interrompa a sincronização, caso sejam encontradas (para obter mais informações sobre como ignorar esses erros, consulte Ignorando erros na replicação transacional). Para a replicação de mesclagem, as violações de restrição são tratadas como conflitos; seu log é executado, mas não fazem o Merge Agent parar a sincronização. Para ambos os 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ó e não obteve 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 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).

• 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 assinatura é 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 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.

  • 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

Solucionando problemas (Replicação)