Agrupar alterações em linhas relacionadas com registros lógicos
Aplica-se a: 
SQL Server
Observação
Esse recurso será removido em uma versão futura do SQL Server. Evite usar esse recurso em desenvolvimentos novos e planeje modificar os aplicativos que atualmente o utilizam.
Por padrão, os dados de processos de replicação de mesclagem são alterados em uma base de linha por linha. Em muitas circunstâncias isto é apropriado, mas para alguns aplicativos, é essencial que as linhas relacionadas sejam processadas como uma unidade. O recurso de registro lógico de replicação de mesclagem permite que você defina uma relação entre linhas relacionadas em diferentes tabelas para que as linhas sejam processadas como uma unidade.
Observação
O recurso de registros lógicos pode ser usado só ou junto com filtros de junção. Para obter mais informações sobre filtros de junção, consulte Join Filters. Para usar registros lógicos, o nível de compatibilidade da publicação deve ser pelo menos 90RTM.
Considere estas três tabelas relacionadas:
A tabela Customers é a tabela pai nesta relação e tem uma coluna de chave primária CustID. A tabela Orders tem uma coluna de chave primária OrderID, com uma restrição de chave estrangeira na coluna CustID que faz referência à coluna CustID na tabela Customers . De forma semelhante, a tabela OrderItems tem uma coluna de chave primária OrderItemID, com uma restrição de chave estrangeira na coluna OrderID que faz referência à coluna OrderID na tabela Orders .
Neste exemplo, um registro lógico consiste de todas as linhas na tabela Orders que são relacionadas a um valor CustID único e todas as linhas na tabela OrderItems são relacionadas a aquelas linhas na tabela Orders . Este diagrama exibe todas as linhas nas três tabelas que estão no registro lógico para Customer2:
Definir uma relação de registro lógico entre artigos, consulte Definir uma relação de registro lógico entre artigos da tabela de mesclagem.
Benefícios de registros lógicos
O recurso de registros lógicos tem dois benefícios primários:
Aplicação de alterações de dados como uma unidade.
A detecção e resolução de conflitos simultaneamente em várias linhas de várias tabelas.
A aplicação de alterações como uma unidade
Se o processamento de mesclagem for interrompido, como no caso de uma conexão descartada, o conjunto parcialmente completado de alterações replicadas relacionadas será revertido se forem usados registros lógicos. Por exemplo, considere o caso onde um Assinante adiciona um novo pedido com OrderID = 6 e duas novas linhas na tabela OrderItems com OrderItemID = 10 e OrderItemID = 11 para OrderID = 6.
Se o processo de replicação for interrompido depois da linha Pedidos , para OrderID = 6 está concluído, mas, antes que os OrderItems 10 e 11 sejam concluídos e os registros lógicos não sejam usados, o valor de OrderTotal para OrderID = 6 não será consistente com a soma dos valores OrderAmount das linhas OrderItems . Se forem usados registros lógicos, a linha Orders para OrderID = 6 não será confirmada até que as alterações OrderItems sejam replicadas.
Em um cenário diferente, se forem usados registros lógicos e alguém estiver consultando tabelas quando o processo de mesclagem estiver aplicando alterações, o usuário não verá alterações replicadas parcialmente até que todas elas sejam concluídas. Por exemplo, se o processo de replicação tiver carregado a linha de Pedidos para OrderID = 6, mas um usuário consultar as tabelas antes que o processo de replicação tenha replicado as linhas de OrderItems , o valor de OrderTotal não será o mesmo da soma dos valores de OrderAmount . Se forem usados registros lógicos, a linha de Pedidos não será visível ate que as linhas de OrderItems sejam concluídas e a transação seja confirmada como uma unidade.
A aplicação de manipulação de conflito para mais do que uma tabela
Considere o caso e quem dois Assinantes têm os dados acima definidos:
Um usuário no primeiro Assinante altera o OrderAmount do OrderItemID 5 de 100 para 150 e o OrderTotal do OrderID 3 de 200 para 250.
Um usuário no segundo Assinante altera o OrderAmount do OrderItemID 6 de 25 para 125 e o OrderTotal do OrderID 3 de 200 para 300.
Se essas alterações forem replicadas sem usar registros lógicos, os valores diferentes de OrderTotal resultarão em um conflito e apenas um deles será replicado. Mas as alterações não conflitantes na tabela OrderItems serão replicadas sem conflito, deixando os valores finais OrderTotal em um estado inconsistente em relação às linhas OrderItems . Se forem usados registros lógicos neste cenário, a alteração de OrderItems associada com a alteração perdida da tabela Orders será revertida e o valor final de OrderTotal será um resumo preciso das linhas de OrderItems .
Para mais informações sobre as opções relacionadas à detecção e à resolução de conflitos com registros lógicos, consulte Detectando e resolvendo conflitos em registros lógicos.
Considerações para usar registros lógicos
Lembre-se das seguintes considerações ao usar registros lógicos:
Considerações gerais
É recomendável que você mantenha o número de tabelas em um registro lógico o mais baixo possível; cinco tabelas ou menos é o recomendável.
Registros lógicos não podem fazer referência a colunas com quaisquer dos tipos de dados seguintes:
varchar(max) e nvarchar(max)
varbinary(max)
text e ntext
imagem
XML
UDT
Não podem ser definidas relações de chave estrangeira em tabelas publicadas com a opção CASCADE. Para obter mais informações, consulte CREATE TABLE (Transact-SQL) e ALTER TABLE (Transact-SQL).
Você não pode atualizar qualquer coluna que é usada na cláusula de relação lógica.
A resolução de conflitos personalizada com manipuladores de lógica de negócios ou resolvedores personalizados não tem suporte para artigos que não são incluídos em um registro lógico.
Se registros lógicos forem usados em uma publicação que inclui filtros com parâmetros, você deverá inicializar cada Assinante com um instantâneo de sua partição. Se você inicializar um Assinante com outro método, o Merge Agent falhará. Para obter mais informações, consulte Snapshots for Merge Publications with Parameterized Filters.
Não são exibidos conflitos que envolvem registros lógicos no Visualizador de Conflitos. Para exibir informações sobre esses conflitos, use procedimentos armazenados de replicação. Para obter mais informações, consulte Exibir informações sobre conflitos em publicações de mesclagem (Programação Transact-SQL de replicação).
Configurações de Publicação
A publicação deve ter um nível de compatibilidade de 90RTM ou maior. Para mais informações, consulte a seção "Nível de Compatibilidade para publicações” em Compatibilidade com a replicação.
A publicação deve usar modo de instantâneo nativo. Este é o padrão a menos que você esteja replicando para SQL Server Compact, que não oferece suporte a registros lógicos.
A publicação não pode permitir sincronização da Web. Para obter mais informações sobre a sincronização da Web, consulte Web Synchronization for Merge Replication.
Para usar registros lógicos em uma publicação filtrada:
Também devem ser usadas partições pré-computadas. Os requisitos de partições pré-computadas também se aplicam a registros lógicos. Para obter mais informações, consulte Optimize Parameterized Filter Performance with Precomputed Partitions (Otimizar o desempenho do filtro parametrizado com partições pré-computadas).
Você não pode usar filtros com parâmetros que não se sobrepõem. Para obter mais informações, consulte a seção "Configurando opções de partição" em Filtros de linha com parâmetros.
Se a publicação usar filtros de junções, a propriedade juntar chave exclusiva deverá ser definida como verdadeiro para todos os filtros de junção que são envolvidos em relações de registro lógico. Para obter mais informações, consulte Join Filters.
Relações entre tabelas
Tabelas relacionadas por registros lógicos devem ter uma relação chave primária-chave estrangeira.
A opção NOT FOR REPLICATION não pode ser definida para restrições de chave estrangeira.
Tabelas filho podem ter só uma tabela pai.
Por exemplo, um banco de dados que rastreia classes e estudantes poderá ter um design semelhante a:
Você não pode usar um registro lógico para representar as três tabelas nessa relação, porque as linhas em ClassMembers não são associadas com uma linha de chave primária única. As tabelas Classes e ClassMembers poderiam ainda formar um registro lógico, como poderiam as tabelas ClassMembers e Students, mas não todas as três.
A publicação não pode conter relações de filtro de junção circulares.
Usando o exemplo com as tabelas Customers, Orderse OrderItems, você não poderia usar registros lógicos se a tabela Orders também tivesse uma restrição de chave estrangeira que fez referência à tabela OrderItems .
Implicações de desempenho de registros lógicos
O recurso de registro lógico vem com um custo de desempenho. Se não forem usados registros lógicos, o agente de replicação poderá processar todas as alterações para um determinado artigo ao mesmo tempo, e como as alterações são aplicadas no modo linha por linha, os requisitos de bloqueio e log de transação, necessários para aplicar as alterações, serão mínimos.
Se registros lógicos forem usados, o Merge Agent deverá processar as alterações para cada registro lógico inteiro, de forma conjunta. Isto tem um efeito no tempo necessário para o Merge Agent replicar as linhas. Adicionalmente, como o agente abre uma transação separada para cada registro lógico, os requisitos de bloqueio podem aumentar.