Subscrições atualizáveis - Para replicação transacional

Aplica-se a:SQL Server

A replicação transacional suporta atualizações nos Subscritores através de subscrições atualizáveis e replicação peer-to-peer. Seguem-se os dois tipos de subscrições atualizáveis:

• Atualização imediata. O Editor e o Assinante devem estar ligados para atualizar os dados no Assinante.

• Atualização em fila O Publicador e o Subscritor não têm de estar ligados entre si para atualizar os dados no Subscritor. Pode atualizar os dados enquanto o Subscritor ou Publisher estiver offline.

Quando atualiza dados num Assinante, a atualização vai primeiro para o Publisher e depois para outros Assinantes. Se utilizar a atualização imediata, as alterações são aplicadas de imediato utilizando o protocolo de confirmação em duas fases. Se usares atualização em fila, as alterações vão para uma fila. As transações em fila vão para o Publisher de forma assíncrona quando a conectividade de rede está disponível. Como as atualizações vão para o Publisher de forma assíncrona, os mesmos dados podem ser atualizados pelo Publisher ou por outro Subscritor e podem ocorrer conflitos ao aplicar as atualizações. O sistema deteta e resolve conflitos de acordo com uma política de resolução de conflitos que define ao criar a publicação.

Se criar uma publicação transacional com subscrições atualizáveis no Assistente de Novas Publicações, tanto a atualização imediata como a atualização em fila estão ativadas. Se criar uma publicação com procedimentos armazenados, pode ativar uma ou ambas as opções. Quando cria uma subscrição da publicação, especifica qual o modo de atualização a utilizar. Depois podes alternar entre modos de atualização, se necessário. Para mais informações, consulte a secção seguinte "Alternância entre Modos de Atualização".

Para permitir subscrições atualizáveis para publicações transacionais, consulte Permitir Atualização de Subscrições para Publicações Transacionais.

Para criar subscrições atualizáveis para publicações transacionais, veja Criar uma Subscrição Atualizável para uma Publicação Transacional (Management Studio).

Alternar entre modos de atualização

Quando usa subscrições atualizáveis, pode especificar um modo de atualização para uma subscrição e mudar para o outro modo se a aplicação assim o exigir. Por exemplo, pode especificar que uma subscrição use atualização imediata, mas mude para atualização em fila se uma falha do sistema resultar na perda da conectividade de rede.

Se mudar de atualização imediata para atualização em fila, não pode voltar à atualização imediata até que o Subscritor e o Publisher estejam ligados e o Agente Leitor de Fila aplique todas as mensagens pendentes na fila ao Publisher.

Para alternar entre modos de atualização

Para alternar entre modos de atualização, ative a publicação e a subscrição para ambos os modos de atualização, e depois alterne entre eles se necessário. Para obter mais informações, consulte
Alterne entre modos de atualização para uma subscrição transacional atualizável.

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

• Depois de ativar uma publicação para subscrições atualizáveis ou subscrições atualizáveis em fila, não pode desativar essa opção para essa publicação (embora as subscrições não tenham de a utilizar). Para desativar a opção, apague a publicação e crie uma nova.

• A republicação de dados não é suportada.

• A replicação adiciona a coluna msrepl_tran_version às tabelas publicadas para efeitos de acompanhamento. Por causa desta coluna extra, inclua uma lista de colunas em todas as INSERT declarações.

• Para efetuar alterações ao esquema de uma tabela numa publicação que suporta a atualização das subscrições, interrompa toda a atividade na tabela no Publicador e nos Subscritores, e propague as alterações de dados pendentes para todos os nós antes de efetuar quaisquer alterações ao esquema. Este processo garante que as transações pendentes não entram em conflito com a alteração pendente do esquema. Após as alterações de esquema se propagarem para todos os nós, a atividade pode ser retomada nas tabelas publicadas. Para obter mais informações, consulte desativar uma topologia de replicação (replicação Transact-SQL programação).

• Para alternar entre modos de atualização, o Agente Leitor de Fila deve ser executado pelo menos uma vez após a inicialização da subscrição (por defeito, o Agente Leitor de Fila corre continuamente).

• Se a base de dados do Assinante estiver particionada horizontalmente e houver linhas na partição que existem no Assinante mas não no Publisher, o Assinante não pode atualizar as linhas pré-existentes. Tentar atualizar estas linhas devolve um erro. Apaga as linhas da tabela e depois adiciona-as no Publisher.

• A replicação transacional com subscritores atualizáveis em fila pode apresentar desempenho lento quando são usados índices filtrados únicos. Se ocorrer um conflito num artigo que tenha índices filtrados únicos, a resolução de conflitos resulta em eliminações e inserções adicionais no assinante para as linhas que não são abrangidas pelo índice filtrado único.

Atualizações no Subscritor

• As atualizações no Assinante propagam-se para o Publisher mesmo que a subscrição esteja expirada ou inativa. Certifique-se de que cancela ou reinicializa qualquer uma dessas subscrições.

• Se usar colunas TIMESTAMP ou IDENTITY e as replicar como tipos de dados de base, não atualize os valores nessas colunas no Assinante.

• Os subscritores não podem atualizar ou inserir texto, ntext ou valores de imagem porque os gatilhos de rastreamento de alterações de replicação não conseguem ler das tabelas inseridas ou eliminadas. De forma semelhante, os Subscritores não podem atualizar ou inserir valores de texto ou imagem usando WRITETEXT ou UPDATETEXT porque o Publisher sobrescrive os dados. Em vez disso, poderia particionar as colunas de texto e imagem numa tabela separada e modificar ambas as tabelas dentro de uma transação.

  Para atualizar objetos de grande dimensão no Assinante, utilize os tipos de dados varchar(max), nvarchar(max) e varbinary(max) em vez dos tipos de dados text, ntext e image, respetivamente.

• Atualizações a chaves únicas (incluindo chaves primárias) que geram duplicados, como uma atualização do formulário UPDATE <column> SET <column> =<column>+1, não são permitidas e são rejeitadas devido a uma violação de unicidade. As atualizações de conjunto feitas no Assinante propagam-se por replicação como instruções individuais UPDATE para cada linha afetada.

• Se a base de dados do Assinante estiver particionada horizontalmente e a partição contiver linhas que existem no Assinante mas não no Publisher, o Assinante não pode atualizar as linhas pré-existentes. Tentar atualizar estas linhas devolve um erro. Apague e volte a inserir essas linhas.

Gatilhos definidos pelo utilizador

• Se a aplicação exigir gatilhos no Assinante, defina os gatilhos com a opção NOT FOR REPLICATION no Publicador e no Assinante. Esta opção assegura que os acionadores são ativados apenas para a alteração original dos dados, mas não quando a replicação propaga essa alteração.

  Certifique-se de que o gatilho definido pelo utilizador não é acionado quando o gatilho de replicação atualiza a tabela. Chame o procedimento sp_check_for_sync_trigger no corpo do gatilho definido pelo utilizador. Para mais informações, veja sp_check_for_sync_trigger (Transact-SQL).

Atualização Imediata

• Para subscrições de atualização imediata, as alterações efetuadas no Assinante propagam-se para o Publicador e são aplicadas através do Coordenador de Transações Distribuídas da Microsoft (MS DTC). Certifique-se de que o MS DTC está instalado e configurado no Publicador e no Subscritor. Para obter mais informações, consulte a documentação do Windows.

• Os gatilhos que as subscrições de atualização imediata usam requerem uma ligação ao Publisher para replicar as alterações.

• Se a publicação permitir subscrições de atualização imediata e um artigo na publicação tiver um filtro de colunas, não é possível excluir da filtragem colunas não anuláveis sem valores predefinidos.

Atualização em fila

• Não pode publicar tabelas incluídas numa publicação de fusão como parte de uma publicação transacional que permita subscrições atualizadas em fila.

• Não atualize as colunas da chave primária ao usar a atualização em fila de espera, porque a chave primária funciona como identificador do registo para todas as consultas. Quando a política de resolução de conflitos está definida para Vitórias dos Assinantes, tenha cautela ao atualizar as chaves primárias. Se tanto o Publisher como o Assinante atualizarem a chave primária, o resultado são duas linhas com chaves primárias diferentes.

• Para colunas do tipo de dados SQL_VARIANT: quando os dados são inseridos ou atualizados no Assinante, o Agente Leitor de Fila faz o respetivo mapeamento da seguinte forma ao copiar dados do Assinante para a fila:

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

  • BINARY e VARBINARY correspondem a dados VARBINARY .

Deteção e resolução de conflitos

• Para a política de conflitos «O Subscritor vence»: a resolução de conflitos não suporta atualizações em colunas de chave primária.

• A replicação não resolve conflitos devido a falhas de restrições de chave estrangeira:

  • Se não esperares conflitos e os dados estiverem bem particionados (os Assinantes não atualizam as mesmas linhas), usa restrições de chave externa no Publicador e nos Assinantes.

  • Se esperar conflitos, não utilize restrições de chave estrangeira no Publicador ou no Subscritor se usar a resolução de conflitos "o subscritor prevalece". Não utilize restrições de chave estrangeira no Subscritor se utilizar a resolução de conflitos "Publisher wins".

Conteúdo relacionado

• Peer-to-Peer - Replicação Transacional
• Replicação transacional
• Publicar Dados e Objetos de Base de Dados
• Subscreva Publicações