• Artigo

Assinaturas atualizáveis para replicação de transação

ObservaçãoObservação

Esse recurso será removido em uma versão futura do Microsoft SQL Server. Evite usar esse recurso em desenvolvimentos novos e planeje modificar os aplicativos que atualmente o utilizam.

Replicação de transação oferece suporte para atualizações em Assinantes por meio de assinaturas atualizáveis e replicação ponto a ponto. Os dois tipos de assinaturas atualizáveis são os seguintes:

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

  • A atualização em fila do Publicador e Assinante não precisa estar conectada para atualizar dados no Assinante. As atualizações podem ser feitas enquanto o Assinante ou o Publicador estiverem offline.

Quando os dados são atualizados em um Assinante, eles são primeiro propagados para o Publicador e, então, para outros Assinantes. Se a atualização imediata for usada, as alterações são propagadas imediatamente usando-se o protocolo de confirmação de duas fases. Se a atualização enfileirada for usada, as alterações são armazenadas em uma fila; as transações enfileiradas são entã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, podendo ocorrer conflitos ao se aplicar as atualizações. Conflitos são detectados e resolvidos de acordo com uma política de resolução de conflito estabelecida quando a publicação é criada.

Se você criar uma publicação transacional com assinaturas atualizáveis no Assistente para Nova Publicação, tanto a atualização imediata quanto a enfileirada são habilitadas. Se você criar uma publicação com procedimentos armazenados, é possível habilitar uma ou ambas as opções. Ao criar uma assinatura para a publicação, você especifica o modo de atualização a ser usado. É possível então alternar entre modos de atualização se necessário. Para obter mais informações, consulte a seguinte seção "Alternando entre modos de atualização".

Para habilitar assinaturas atualizáveis para publicações transacionais

Para criar assinaturas atualizáveis para publicações transacionais

Alternando entre modos de atualização

Ao usar assinaturas atualizáveis você pode especificar que uma assinatura use um modo de atualização e, então, passe para o outro se o aplicativo assim o exigir. Por exemplo, é possível especificar que uma assinatura use atualização imediata, mas alterne para atualização enfileirada se uma falha do sistema resultar na perda de conectividade de rede.

ObservaçãoObservação

Replicação não alterna automaticamente entre modos de atualização. Você deve definir o modo de atualização por SQL Server Management Studio ou seu aplicativo deve chamar sp_setreplfailovermode (Transact-SQL) para alternar entre modos.

Se você alternar de atualização imediata para atualização enfileirada, não é possível alternar de volta para atualização imediata até que o Assinante ou Publicador esteja conectado e o Queue Reader Agent tenha aplicado todas as mensagens pendentes na fila para o Publicador.

Para alternar entre modos de atualização

Para alternar entre modos de atualização, deve-se habilitar a publicação e a assinatura para ambos os modos de atualização e, então, alternar entre eles, se necessário.

Considerações para o uso de assinaturas atualizáveis

Considerações gerais

  • Assinaturas atualizáveis têm suporte para Assinantes que estejam executando Microsoft SQL Server 2000 SP3 e versões posteriores.

  • Depois que uma publicação é habilitada para assinaturas de atualização ou assinaturas de atualização enfileiradas, a opção não pode ser desabilitada para a publicação (embota assinaturas não precisem usá-la). Para desabilitar a opção, a publicação deve ser excluída e uma nova deve ser criada.

  • Dados de republicação não oferecem suporte.

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

  • Para efetuar alterações de esquema em uma tabela em uma publicação que ofereça suporte a assinaturas de atualização, toda a atividade na tabela deve ser interrompida no Publicador e Assinantes, e alterações de dados pendentes devem ser propagadas a todos os nós antes de fazer qualquer alteração de esquema. Isso assegura que transações pendentes não entrem em conflito com a alteração de esquema pendente. Depois que as alterações de esquema tenham se propagado para todos os nós, a atividade pode ser retomada nas tabelas publicadas. Para obter mais informações, consulte Como confirmar uma topologia de replicação (Programação Transact-SQL de replicação).

  • Se você planeja alternar entre modos de atualização, o Queue Reader Agent deve ser executado pelo menos uma vez depois de a assinatura ser inicializada (por padrão, o Queue Reader Agent é executado de forma contínua).

  • Se o banco de dados do Assinante for particionado horizontalmente e houver linhas na partição que existam no Assinante, mas não no Publicador, o Assinante não pode atualizar as linhas preexistentes. A tentativa de atualizar essas linhas retorna um erro. As linhas devem ser excluídas da tabela e, então, adicionadas ao Publicador.

Atualizações no Assinante

  • Atualizações no Assinante são propagadas para o Publicador mesmo se uma assinatura tiver expirado ou estiver inativa. Assegure-se de que qualquer dessas assinaturas seja cancelada ou reinicializada.

  • Se as colunas TIMESTAMP ou IDENTITY forem usadas e replicadas como seus tipos de dados básicos, valores nessas colunas não devem ser atualizados no Assinante.

  • Assinantes não podem atualizar ou inserir valores text, ntext ou image uma vez que não é possível ler das tabelas inseridas ou excluídas dentro dos gatilhos de replicação de rastreamento de alteração. Da mesma forma, Assinantes não podem atualizar ou inserir valores text ou image usando WRITETEXT ou UPDATETEXT, porque os dados são substituídos pelo Publicador. Em vez disso, é possível particionar as colunas text e image em uma tabela separada e modificar as duas tabelas na transação.

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

  • Atualizações para chaves exclusivas (incluindo chaves primárias) que geram duplicatas (por exemplo, uma atualização da forma UPDATE <coluna> SET <coluna> =<coluna>+1 não são permitidas e serão rejeitadas devido a uma violação de exclusividade. Isso ocorre por que atualizações configuradas feitas no Assinante são propagadas por replicação como instruções UPDATE individuais para cada linha afetada.

  • Se o banco de dados do Assinante for particionado horizontalmente e houver linhas na partição que existam no Assinante, mas não no Publicador, o Assinante não pode atualizar as linhas preexistentes. 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 exige gatilhos no Assinante, os gatilhos devem ser definidos com a opção NOT FOR REPLICATION no Publicador e no Assinante. Para obter mais informações sobre essa opção, consulte Controlando restrições, identidades e gatilhos com NOT FOR REPLICATION. Isso assegura que gatilhos sejam acionados apenas para a alteração de dados original, mas não quando aquela alteração é reproduzida.

  • Verifique se o gatilho definido pelo usuário não é acionado quando o gatilho de replicação atualiza a tabela. Isso é feito usando-se 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ções imediatas, alterações no Assinante são propagadas para o Publicador e aplicadas usando-se o MS DTC (Coordenador de Transações Distribuídas da Microsoft). Certifique-se de que o MS DTC está instalado e configurado no Publicador e no Assinante. Para obter mais informações, consulte a documentação do Windows.

  • Os gatilhos usados por assinaturas de atualização imediatas exigem uma conexão com o Publicador para replicar alterações. Para obter mais informações sobre a segurança dessa conexão, consulte Considerações de segurança para a atualização de assinaturas.

  • Se a publicação permitir assinaturas de atualização imediata e um artigo na publicação tiver um filtro de coluna, não é possível filtrar colunas não anuláveis sem padrões.

Atualização enfileirada

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

  • Atualizações feitas para colunas de chave primária não são recomendadas quando se usa atualização enfileirada, uma vez que a chave primária é usada como um localizador de registro para todas as consultas. Quando a política de resolução de conflito é definida como Assinante Vence, atualizações para chaves primárias devem ser feitas com cuidado. Se atualizações para a chave primária são feitas tanto no Publicador quanto no Assinante, o resultado será duas linhas com chaves primárias diferentes.

  • Para colunas de tipo de dados SQL_VARIANT: quando os dados são inseridos ou atualizados no Assinante, eles são mapeados da seguinte forma pelo Queue Reader Agent ao serem copiados do Assinante para a fila:

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

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

Detecção de conflito e resolução

  • Para a política de conflito Assinante Vence: resolução de conflito não oferece suporte para atualizações para colunas de chave primária.

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

    • Se conflitos não são esperados e os dados são bem particionados (Assinantes não atualizam as mesmas linhas), é possível usar restrições de chave estrangeira no Publicador e Assinante.

    • Se conflitos são esperados: não se deve usar restrições de chave estrangeira no Publicador ou Assinante se usar resolução de conflito "Assinante vence"; não se deve usar restrições de chave estrangeira no Assinante se você usar resolução de conflito "Publicador vence".