Otimize o desempenho da replicação de fusão com rastreamento condicional de eliminação

Aplica-se a: SQL Server

Note

Esse recurso será removido em uma versão futura do SQL Server. Evite usar esse recurso em novos trabalhos de desenvolvimento e planeje modificar aplicativos que atualmente usam esse recurso.

Ao usar a replicação por fusão, pode especificar que os gatilhos de replicação e as tabelas do sistema não registem eliminações de um ou mais artigos. Se selecionares esta opção para um artigo, as eliminações não são rastreadas nem replicadas pelo Publisher ou por quaisquer Subscritores. Esta opção suporta vários cenários de aplicação e oferece uma otimização de desempenho para casos em que replicar eliminações não é necessário ou desejável. O desempenho é melhorado de três formas: o sistema não armazena metadados para eliminações; não enumera as eliminações durante a sincronização; e não replica as eliminações para, nem as aplica, ao Assinante.

Note

Para usar artigos apenas para download, o nível de compatibilidade da publicação deve ser pelo menos 90RTM.

A opção pode ser especificada quando uma publicação é criada ou pode ser ativada ou desativada se uma aplicação exigir que algumas eliminações sejam replicadas e outras não, como eliminações em lote. Os exemplos seguintes ilustram formas como esta opção pode ser usada numa aplicação:

  • Uma aplicação para uma força de vendas móvel normalmente tem tabelas como SalesOrderHeader, SalesOrderDetail e Product. Os pedidos são registados no Assinante e depois replicados para o Publicador, que frequentemente fornece dados a um sistema de processamento de pedidos. Muitos trabalhadores em mobilidade utilizam dispositivos portáteis com capacidade de armazenamento limitada: depois de o pedido ser recebido pelo Publicador, pode ser eliminado no Subscritor. A exclusão não é propagada para o Publisher, porque a encomenda ainda está ativa no sistema.

    Neste cenário, as eliminações não seriam registadas nas tabelas SalesOrderHeader e SalesOrderDetail . As eliminações seriam registadas na tabela de Produtos, porque se um produto for eliminado no Publisher, a eliminação deve ser enviada ao Assinante para manter a lista de produtos atualizada.

  • Uma aplicação poderia armazenar dados históricos numa tabela como o TransactionHistory, que é periodicamente eliminado de registos com mais de um ano. A tabela poderia ser filtrada de modo a que os Assinantes só recebam dados das transações no mês corrente. As eliminações em lote mensais no Publisher, que removem dados mais antigos, não são relevantes para os Subscritores, mas seriam, ainda assim, registadas e enumeradas por predefinição.

    Neste cenário, antes de ocorrer o processamento em lote, a atividade podia ser interrompida no sistema e a aplicação podia desativar o rastreio das eliminações. Depois de concluído o processamento, o rastreamento pode voltar a ser ativado.

Importante

Se outras atividades continuarem no Publisher, deve garantir que as eliminações que deveriam ser propagadas aos Subscritores não ocorram enquanto o rastreamento de eliminações estiver desativado.

Para especificar que as eliminações não devem ser rastreadas