Assinaturas atualizáveis para replicação transacional

Aplica-se a: SQL Server 2008 (e posterior)

No SQL Server 2014, a replicação transacional oferece suporte a atualizações nos Assinantes por meio de assinaturas atualizáveis e replicação entre pares. Veja a seguir os dois tipos de assinaturas atualizáveis:

• Atualização imediata. O Publicador e o Assinante precisam estar conectados entre si para atualizar dados no Assinante.

• A atualização em fila permite que o Publicador e o Assinante não precisem estar conectados ao mesmo tempo para atualizar dados no Assinante. As atualizações podem ser feitas enquanto o Assinante ou o Publicador está offline.

Quando os dados são atualizados em um Assinante, eles são propagados primeiro para o Publicador e propagados para outros Assinantes. Se a atualização imediata for usada, as alterações serão propagadas imediatamente usando o protocolo de confirmação de duas fases. Se a atualização enfileirada for usada, as alterações serão armazenadas em uma fila; as transações enfileiradas são aplicadas de forma assíncrona no Publicador sempre que a conectividade de rede estiver disponível. Como as atualizações são propagadas de forma assíncrona para o Publicador, os mesmos dados podem ter sido atualizados pelo Publicador ou por outro Assinante e conflitos podem ocorrer ao aplicar as atualizações. Os conflitos são detectados e resolvidos de acordo com uma política de resolução de conflitos definida ao criar a publicação.

Se você criar uma publicação transacional com assinaturas atualizáveis no Assistente para Nova Publicação, a atualização imediata e a atualização na fila serão habilitadas. Se você criar uma publicação com procedimentos armazenados, poderá habilitar uma ou ambas as opções. Ao criar uma assinatura para a publicação, especifique qual modo de atualização usar. Em seguida, você pode alternar entre os modos de atualização, se necessário. Para obter mais informações, consulte a seção a seguir "Alternar entre modos de atualização".

Para habilitar assinaturas atualizáveis para publicações transacionais, habilite a atualização de assinaturas para publicações transacionais

Para criar assinaturas atualizáveis para publicações transacionais, consulte Criar uma assinatura atualizável para uma publicação transacional

Alternar entre os modos de atualização

Ao usar assinaturas atualizáveis, você pode especificar que uma assinatura deve usar um modo de atualização e, em seguida, alternar para o outro se o aplicativo exigir. Por exemplo, você pode especificar que uma assinatura deve usar a atualização imediata, mas alternar para a atualização na fila se uma falha do sistema resultar na perda de conectividade de rede.

Se você alternar da atualização imediata para a atualização na fila, não poderá alternar de volta para a atualização imediata até que o Assinante e o Publicador estejam conectados e o Queue Reader Agent tenha aplicado todas as mensagens pendentes na fila ao Publicador.

Para alternar entre os modos de atualização

Para alternar entre os modos de atualização, você deve habilitar a publicação e a assinatura para ambos os modos de atualização e alternar entre eles, se necessário. Para obter mais informações, consulte
Alternar entre os modos de atualização para uma assinatura transacional atualizável.

Considerações sobre como usar assinaturas atualizáveis

• Depois que uma publicação é habilitada para atualizar assinaturas ou assinaturas de atualização em fila, a opção não pode ser desativada para a publicação (embora as assinaturas não precisem utilizá-la). Para desabilitar a opção, a publicação deve ser excluída e uma nova criada.

• Não há suporte para a republicação de dados.

• A replicação adiciona a coluna msrepl_tran_version às tabelas publicadas para fins de rastreamento. Devido a essa coluna adicional, todas as INSERT instruções devem incluir uma lista de colunas.

• Para fazer alterações de esquema em uma tabela em uma publicação que dê suporte à atualização de assinaturas, todas as atividades na tabela devem ser interrompidas no Publicador e nos Assinantes e as alterações de dados pendentes devem ser propagadas para todos os nós antes de fazer alterações de esquema. Isso garante que as transações pendentes não entrem em conflito com a alteração de esquema pendente. Depois que as alterações de esquema forem propagadas para todos os nós, as operações poderão ser retomadas nas tabelas publicadas. Para obter mais informações, confira Como confirmar uma topologia de replicação (Programação Transact-SQL de replicação).

• Se você planeja alternar entre os modos de atualização, o Queue Reader Agent deverá ser executado pelo menos uma vez depois que a assinatura tiver sido inicializada (por padrão, o Queue Reader Agent será executado continuamente).

• Se o banco de dados do Assinante for particionado horizontalmente e houver linhas na partição que existem no Assinante, mas não no Publicador, o Assinante não poderá atualizar as linhas pré-existentes. A tentativa de atualizar essas linhas retorna um erro. As linhas devem ser excluídas da tabela e adicionadas ao Publicador.

Atualizações em Subscritor

• As atualizações no Assinante são propagadas para o Publicador mesmo que uma assinatura tenha expirado ou esteja inativa. Verifique se essas assinaturas foram descartadas ou reinicializadas.

• Se colunas TIMESTAMP ou IDENTITY forem usadas e forem replicadas como seus tipos de dados base, os valores nessas colunas não devem ser atualizados pelo Assinante.

• Os assinantes não podem atualizar ou inserir os valores text, ntext ou image, porque não é possível ler das tabelas de inserção ou exclusão dentro dos gatilhos de controle de alterações de replicação. Da mesma forma, os Assinantes não podem atualizar ou inserir text ou image valores usando WRITETEXT ou UPDATETEXT porque os dados são substituídos pelo Publicador. Em vez disso, você pode particionar as colunas text e image em uma tabela separada e modificar as duas tabelas dentro de uma transação.

  Para atualizar objetos grandes em um Assinante, use os tipos de dados varchar(max), nvarchar(max) e varbinary(max) em vez dos tipos de dados text, ntext e image, respectivamente.

• As atualizações para chaves exclusivas (incluindo chaves primárias) que geram duplicatas (por exemplo, uma atualização do formulário UPDATE <column> SET <column> =<column>+1 não são permitidas e serão rejeitadas devido a uma violação de exclusividade. Isso ocorre porque as atualizações definidas feitas no Assinante são propagadas pela replicação como instruções individuais UPDATE para cada linha afetada.

• Se o banco de dados do Assinante for particionado horizontalmente e houver linhas na partição que existem no Assinante, mas não no Publicador, o Assinante não poderá atualizar as linhas pré-existentes. A tentativa de atualizar essas linhas retorna um erro. As linhas devem ser excluídas da tabela e inseridas novamente.

Gatilhos definidos pelo usuário

• Se o aplicativo requer gatilhos no Assinante, os gatilhos deverão ser definidos com a opção NOT FOR REPLICATION no Publicador e no Assinante. Isso garante que os gatilhos sejam disparados apenas para a alteração de dados original e não quando essa alteração for replicada.

  Verifique se o gatilho definido pelo usuário não é acionado quando o gatilho de replicação atualiza a tabela. Isso é feito chamando o procedimento sp_check_for_sync_trigger no corpo do gatilho definido pelo usuário. Para obter mais informações, consulte sp_check_for_sync_trigger (Transact-SQL).

Atualização imediata

• Para assinaturas de atualização imediata, as alterações no Assinante são propagadas para o Publicador e aplicadas usando o Ms DTC (Coordenador de Transações Distribuídas da Microsoft). Verifique se o MS DTC está instalado e configurado no Publicador e assinante. Para obter mais informações, consulte a documentação do Windows.

• Os gatilhos usados pela atualização imediata de assinaturas exigem uma conexão com o Publicador para replicar as alterações.

• Se a publicação permitir assinaturas de atualização imediata e um artigo na publicação tiver um filtro de coluna, você não poderá filtrar as colunas não anuláveis sem os valores padrão.

Atualização em fila

• Tabelas incluídas em uma publicação de mesclagem também não podem ser publicadas como parte de uma publicação transacional que permite assinaturas de atualização na fila.

• Atualizações feitas em colunas de chave primária não são recomendadas ao usar atualização em fila, pois a chave primária é utilizada como registro localizador para todas as consultas. Quando a política de resolução de conflitos está configurada como "Prioridade do Assinante", é preciso ter cuidado ao atualizar as chaves primárias. Se as atualizações para a chave primária forem feitas no Publicador e no Assinante, o resultado será duas linhas com chaves primárias diferentes.

• Para colunas de dados do tipo SQL_VARIANT: quando os dados são inseridos ou atualizados no Assinante, eles são mapeados da seguinte maneira pelo Agente Leitor de Fila quando são copiados do Assinante para a fila:

  • BIGINT, DECIMAL, NUMERIC, e MONEYSMALLMONEY são mapeados para NUMERIC.

  • BINARY e VARBINARY são mapeados para VARBINARY dados.

Detecção e resolução de conflitos

• Para a política de conflitos Assinante Wins: não há suporte para resolução de conflitos nas atualizações nas colunas de chave primária.

• Conflitos devido a falhas de restrição de chave estrangeira não são resolvidos pela replicação:

  • Se conflitos não forem esperados e os dados estiverem bem particionados (os Assinantes não atualizarão as mesmas linhas), você poderá usar restrições de chave estrangeira no Publicador e assinantes.

  • Se forem esperados conflitos: você não deverá usar restrições de chave estrangeira no Publicador ou assinante se usar a resolução de conflitos "Assinante vence"; você não deve usar restrições de chave estrangeira no Assinante se usar a resolução de conflitos "Publisher wins".

Consulte Também

Replicação transacional entre pares
Replicação transacional
Publicar dados e objetos de banco de dados
Assinar publicações