Sqlserver
 sql >> Base de Dados >  >> RDS >> Sqlserver

Internos de replicação transacional do SQL Server


A Replicação Transacional do SQL Server é uma das técnicas de replicação mais comuns usadas para compartilhar, copiar ou distribuir dados para vários destinos. Neste artigo, discutiremos a Replicação, vários Tipos de Replicação e prestaremos atenção especial ao trabalho de Replicação Transacional.

O que é replicação transacional SQL?


Replicação é a tecnologia do SQL Server para copiar ou distribuir dados de um banco de dados para outro, mantendo a consistência dos dados.

A replicação pode ser usada para transferir dados de um banco de dados para outro
  • na mesma instância ou em outra instância no mesmo servidor;
  • ou entre servidores em um único local ou em vários locais.

Primeiro, devemos passar pela Arquitetura de Replicação e entender as terminologias de Replicação.

Arquitetura e terminologias de replicação do SQL Server

  • O editor é a instância do Source Database que publica as alterações de dados que podem ser distribuídas para outro banco de dados. Dados de um único editor pode ser enviado para um Assinante Único ou vários assinantes .
  • Assinante é a Instância do Banco de Dados de Destino onde distribuímos as alterações de dados capturadas do Banco de Dados do Publicador. O Assinante pode ser uma Instância do Publicador ou outra instância no Servidor Publicador/outro Servidor no mesmo local/local distante. Antes que as alterações de dados sejam distribuídas para a instância do Banco de Dados do Assinante, esses dados são armazenados no Distribuidor .
  • O Distribuidor é um banco de dados que armazena logs de alterações capturados dos bancos de dados do Publisher. Quando um Servidor é habilitado como Distribuidor, ele criará um Banco de Dados do sistema denominado banco de dados de distribuição .

Pela localização dos bancos de dados de distribuição, eles podem ser classificados como distribuidores locais ou remotos.

Distribuidor Local é um banco de dados de distribuição que reside na instância do banco de dados do Publicador.
Distribuidor Remoto é um banco de dados de distribuição que reside na instância do banco de dados do Assinante ou em qualquer outra instância do SQL Server além da instância do banco de dados do Publicador.

O fator decisivo é onde colocar o banco de dados Distribution na instância do Publicador (outra instância). depende dos recursos do servidor disponíveis para lidar com a carga de distribuição de dados.

De acordo com a forma como os dados serão enviados do banco de dados Distribution para a instância do Assinante, eles podem ser classificados em Push ou Puxar assinaturas .

Enviar assinatura significa que o banco de dados Distribution assume a responsabilidade de enviar os dados para a instância do banco de dados do Assinante.
Puxar assinatura significa que a instância do banco de dados do Assinante assume a responsabilidade de extrair os dados disponíveis do banco de dados de Distribuição e aplicá-los ao banco de dados do Assinante.
  • Artigos são a unidade fundamental da Replicação. Indica quaisquer alterações de dados neste objeto de banco de dados ou artigo que serão replicadas do Publicador para o Assinante. O artigo pode ser uma tabela, exibição, exibição indexada, procedimento armazenado ou função definida pelo usuário.
  • Publicações são uma coleção de um ou mais artigos do banco de dados no Publisher.
  • Assinatura define qual Publicação será recebida. Além disso, determina a partir de qual publicação e em qual agendamento os dados são replicados. A assinatura pode ser Push ou Pull (da publicação à assinatura).
  • Agentes de replicação são programas independentes responsáveis ​​por rastrear alterações e distribuir dados entre o Publicador para o Distribuidor e o Assinante. Todos os Agentes de Replicação são executados como Trabalhos no SQL Server Agent. Assim, ele pode ser administrado via SSMS em SQL Server Agent Jobs ou Replication Monitor. Os seguintes tipos de agentes de replicação estão disponíveis:
  • Agente de instantâneo – Usado por quase todos os tipos de Replicação. O Snapshot Agent é executado a partir do Servidor que contém o banco de dados de distribuição. Prepara o Esquema e os dados iniciais de todos os Artigos incluídos em uma Publicação em uma Editora. Além disso, ele cria os arquivos de instantâneos em uma pasta de instantâneos e registra os detalhes da sincronização no banco de dados de distribuição.
  • Agente do leitor de registros – Usado pela Replicação Transacional. O objetivo é ler as alterações de dados de artigos habilitados para replicação dos logs de transações do banco de dados do editor e armazenados no banco de dados de distribuição. o Log Reader Agent é executado a partir do Distributor Server.
  • Agente de distribuição – Usado por replicação transacional e de instantâneo. Ele aplica os arquivos de Snapshot iniciais e transações pendentes incrementais ou disponíveis do banco de dados de Distribuição para o banco de dados do Assinante. O Distribution Agent é executado a partir do servidor do distribuidor para assinaturas push e do servidor do assinante para assinaturas pull.
  • Agente de mesclagem – Usado apenas pela Replicação de Mesclagem. Ele aplica os arquivos de instantâneo iniciais e a reconciliação de alterações diferenciais ou incrementais no Publicador ou Assinante. O Merge Agent é executado no servidor do distribuidor para replicação push e no servidor do assinante para assinaturas pull.
  • Agente de leitor de fila – O Queue Reader Agent é usado pela Replicação Transacional com a opção de atualização enfileirada. Ele move as alterações do Assinante para o Publicador. O Queue Reader Agent é executado a partir do Distributor Server.
  • Trabalhos de manutenção de replicação – Conforme explicado anteriormente, todos os Replication Agents são programas autônomos configurados durante a configuração da Replicação. Eles são executados como trabalhos em Trabalhos do SQL Server Agent. Poucos trabalhos significativos a serem observados são Limpeza de distribuição:Distribuição, Limpeza do histórico do agente:Distribuição e Limpeza de assinatura expirada.

Tipos de replicação no SQL Server


Agora que conhecemos a terminologia, vamos mergulhar nos tipos de Replicação.
  1. Replicação Transacional . Como o nome sugere, cada transação ou alteração de dados dentro do escopo transacional no Publicador será enviada ao Assinante quase em tempo real com pequenos atrasos, dependendo da largura de banda da rede e dos recursos do servidor. A Replicação Transacional usa o Log Reader Agent para ler as alterações de dados dos logs transacionais do banco de dados do Publicador. Ele também usa o Distribution Agent para aplicar as alterações ao Assinante. Ocasionalmente, ele pode usar o Snapshot Agent para obter os dados iniciais do Snapshot de todos os artigos replicados. A Publicação de Replicação Transacional pode se enquadrar nas categorias abaixo:
    • Replicação transacional padrão – O Assinante é um banco de dados somente leitura da perspectiva da Replicação Transacional. Quaisquer alterações realizadas por qualquer pessoa no banco de dados do Assinante não serão rastreadas e atualizadas no Banco de Dados do Publicador. A Replicação Transacional Padrão é frequentemente chamada de Replicação Transacional.
    • Replicação transacional com assinaturas atualizáveis é um aprimoramento da replicação transacional padrão que rastreia as alterações de dados que ocorrem nas assinaturas. Sempre que as alterações de dados forem iniciadas em uma assinatura atualizável, elas serão propagadas primeiro para o editor e depois para outros assinantes.
    • Replicação ponto a ponto é um aprimoramento da replicação transacional padrão. Ele propaga alterações transacionalmente consistentes quase em tempo real em várias instâncias de servidor.
    • Replicação bidirecional é um aprimoramento da replicação transacional padrão que permite que dois servidores (limitado a apenas 2 servidores e, portanto, denominados bidirecional) troquem as alterações de dados entre si com qualquer servidor atuando como editor (para enviar alterações para outro servidor) ou como assinante (para receber alterações de outro servidor).
  2. Mesclar replicação – Suporta a captura de alterações de dados que ocorrem no Publicador e no Assinante e as distribui para o outro Servidor. A replicação de mesclagem requer o ROWGUID coluna nos Artigos da Tabela envolvidos na Replicação de Mesclagem. Ele usa acionadores para capturar as alterações de dados no editor e no assinante. Além disso, ele entrega as alterações entre os Servidores quando o Publicador e o Assinante estão conectados à rede. A replicação de mesclagem usa o Merge Agent para replicar as alterações de dados entre o editor e o assinante.
  3. Replicação de instantâneo – Como o nome indica, a replicação de instantâneo não depende de logs transacionais ou gatilhos para capturar as alterações. Ele tira um instantâneo dos artigos envolvidos na Publicação e o aplica ao Assinante com os registros disponíveis no momento do instantâneo. A Replicação de Snapshot usa o Snapshot Agent para tirar um snapshot do Publicador e usa o Distribution Agent para aplicar esses registros ao Assinante.

Replicação transacional do SQL Server


A Replicação Transacional é normalmente preferida em cenários em que o banco de dados OLTP Publisher tem atividades pesadas de Data INSERT/UPDATE e/ou DELETE.

Como a instância do servidor Publicador tem um grande DISK IO acontecendo, a geração de relatórios pode causar bloqueios graves. Também pode afetar o desempenho do servidor. Portanto, outro Servidor com dados quase em tempo real é bom para descarregar os requisitos de Relatório.

Um dos requisitos fundamentais para a Replicação Transacional é que as tabelas replicadas tenham uma Chave Primária disponível.

Podemos resumir como funciona a Replicação Transacional. Dê uma olhada no diagrama de Arquitetura de Replicação Transacional abaixo retirado da documentação oficial da Microsoft.

A Publicação é criada no banco de dados do Publicador que compreende a lista de Artigos para replicação no banco de dados do Assinante.

A Replicação Transacional normalmente será inicializada do Publicador para o Distribuidor por meio do Snapshot Agent ou Backups Completos. O Snapshot Agent é suportado por meio do Assistente de configuração de replicação. O backup completo é suportado por meio de instruções TSQL para inicializar a replicação transacional.

O Log Reader Agent verifica o log transacional do banco de dados do Publisher em busca de artigos rastreados. Em seguida, ele copia as alterações de dados do log transacional para o banco de dados de distribuição.

O banco de dados de Distribuição pode estar no Publicador ou no Assinante; também pode ser ou outra instância independente do SQL Server.

Observe também as seguintes coisas:
  • O Log Reader Agent é executado continuamente a partir do Distributor Server para procurar novos comandos marcados para replicação. No entanto, se você não deseja executar continuamente e deseja executar em uma programação, podemos alterar o trabalho SQL do Log Reader Agent que será criado.
  • O Log Reader Agent coleta todos os registros marcados para replicação do log transacional em lotes e os envia para o banco de dados de distribuição.
  • O Log Reader Agent coleta apenas transações confirmadas do banco de dados de log transacional do editor. Portanto, qualquer consulta de longa duração no banco de dados do Publicador pode afetar diretamente a Replicação, pois ela aguarda a conclusão da transação ativa.

O Distribution Agent pega todos os novos comandos não distribuídos do banco de dados de Distribuição e os aplica ao banco de dados de Assinatura por meio do Mecanismo Push ou Pull. Como mencionado anteriormente, se o Distribuidor de Assinatura Push se apropriar para aplicar as alterações do banco de dados de Distribuição ao Assinante, enquanto no banco de dados de Assinatura Pull, o banco de dados do Assinante assume a propriedade de buscar as alterações do banco de dados de Distribuição para o Assinante.

Assim que os registros forem distribuídos com sucesso do banco de dados de Distribuição para Assinante, eles serão marcados como Distribuídos e marcados para exclusão do banco de dados de Distribuição. Um dos trabalhos de manutenção de replicação de chave denominado Distribution Clean Up:trabalho de distribuição é executado uma vez a cada 10 minutos para excluir os registros distribuídos do banco de dados de distribuição para manter o tamanho do banco de dados de distribuição sob controle.

Com a explicação detalhada dos conceitos de Replicação e Replicação Transacional, podemos colocá-la em prática configurando a Replicação para AdventureWorks banco de dados e verificando a replicação para cada componente discutido teoricamente.

Configurando a replicação transacional passo a passo (via SSMS GUI)


A configuração da replicação transacional envolve 3 etapas principais:
  1. Configurando o banco de dados de distribuição
  2. Criação de publicação
  3. Criação de assinatura

Antes de tentar configurar a Replicação, certifique-se de que os Componentes de Replicação estejam instalados como parte da instalação do SQL Server ou use a mídia do SQL Server para instalar os Componentes de Replicação, pois eles são necessários para a tarefa.

No SSMS, conecte-se à Instância de banco de dados do editor e clique com o botão direito do mouse em Replicação :

A distribuição não está configurada agora. Assim, temos a opção Configure Distribution. Podemos configurar o banco de dados de distribuição usando o assistente para configurar distribuição ou por meio do assistente de criação de publicação.

Para configurar o banco de dados de distribuição e publicação, siga as etapas abaixo:

Expandir Replicação e clique com o botão direito do mouse em Nova publicação .

Assistente de nova publicação lançará. Clique em Avançar para ver o Distribuidor opções de configuração.

Por padrão, ele escolhe o servidor Publicador para manter o banco de dados de distribuição. Se você deseja usar um banco de dados de distribuição remoto, escolha a segunda opção. Clique em Avançar .

A próxima opção é configurar a Pasta de instantâneo . Altere-o para a pasta necessária. Caso contrário, ele será criado no caminho da pasta de instalação do SQL Server por padrão. Clique em Avançar .

Selecione o Banco de dados de publicação (aqui está AdventureWorks ) e clique em Avançar .

Escolha o Tipo de publicação Replicação Transacional . Clique em Avançar .

Escolha Artigos para esta publicação. Para fins de teste, selecione todas as Tabelas e Visualizações :

Antes de clicar em Próximo , expanda as tabelas mais uma vez para verificar alguns problemas.

Algumas tabelas são marcadas por ícones vermelhos. Quando clicamos nessas tabelas, vemos o aviso indicando que uma tabela não pode ser replicada porque não possui uma Chave Primária, um dos requisitos cruciais para a Replicação Transacional. Mais tarde entraremos em mais detalhes. Agora, clique em Avançar .

Uma página com Problemas de artigos relacionadas às dependências serão exibidas. Clique em Avançar .

A próxima opção é Filtrar linhas da tabela – já que estamos testando a replicação básica, podemos ignorá-la. Clique em Avançar .

Configurar o Snapshot Agent – ignore e clique em Avançar .

Agente Configurações – clique em Configurações de segurança para configurar a conta para executar o agente Snapshot e o Log Reader Agent nele.

Em seguida, altere o Processo do agente de instantâneo para ser executado na conta de serviço do SQL Server Agent.

Defina o Agente do leitor de log para Conectar-se ao editor> personificando a conta do processo . Clique em OK .

A segurança do agente será atualizada.

Assim, configuramos o Distribuidor e todos os elementos da Publicação como Artigos , Agente de instantâneo , Agente do leitor de registros e Títulos do Agente . Estamos quase completando a criação da Publicação via Wizard.

Se você precisar estudar mais sobre os scripts TSQL usados ​​para criar a publicação, podemos verificar o Gerar um arquivo de script para criar a publicação opção. Caso contrário, clique em Avançar .

Como escolhi salvar o arquivo, o assistente me permite definir o Caminho do arquivo de script e nome . Forneça esses detalhes e clique em Avançar .

O assistente finalmente pede o Nome da publicação , chamei-o de AdventureWorks_pub com o nome do banco de dados e palavras-chave para indicá-lo como uma publicação para facilitar a identificação.

Verifique todos os dados fornecidos no Resumo página e clique em Concluir .

O Assistente exibirá o progresso em Criando publicação . Quando estiver concluído, veremos a confirmação. Clique em Fechar .

Para verificar a criação bem-sucedida do Distribuidor (banco de dados de distribuição), expanda os bancos de dados do sistema:

Para verificar a criação bem-sucedida de Publicação , expanda Publicação local :

configuramos o banco de dados de distribuição e criamos o banco de dados de publicação no banco de dados AdventureWorks com sucesso. Agora podemos prosseguir com a Assinatura criação

Clique com o botão direito do mouse na nova Publicação acabamos de criar e selecionar Novas assinaturas :

O Assistente de Novas Assinaturas vai aparecer. Para iniciar o processo, clique em Próximo .

A Publicação página pede para garantir que tanto a Publicação e Editor bancos de dados são selecionados. Clique em Avançar .

Defina o Agente de distribuição para Pressionar ou Puxar Inscrição. Vamos usar o Servidor do Editor como o Assinante, e esse tipo não terá nenhum impacto. Portanto, deixamos o padrão Push Inscrição. Clique em Avançar .

Selecione os Assinantes (base de dados). Estou selecionando AdventureWorks_REPL restaurado a partir do mesmo backup do banco de dados AdventureWorks. Clique em Avançar .

Defina a Segurança do agente :

Como vou fazer tudo em um único servidor, estou usando a conta de serviço do agente .

A próxima janela apresenta a Segurança do Agente de Distribuição valores já configurados. Clique em Avançar .

Programação de sincronização – deixe-o para o padrão. Clique em Avançar .

Inicializar assinaturas – deixe-o com os valores padrão. Clique em Avançar .

Depois de fornecer todos os detalhes necessários, você poderá concluir o processo de criação da Assinatura. Verifique o Gerar arquivo de script… opção para estudar os scripts mais tarde e clique em Próximo .

Forneça o caminho para salvar os arquivos, clique em Próximo .

Dê uma olhada no resumo e verifique todos os valores configurados. Depois de verificado, clique em Concluir .

A Criação da Assinatura está concluída. Clique em Fechar .

Agora podemos ver a Assinatura exibido em nossa Publicação .

Configurar o Snapshot Agent


Nosso próximo passo é trabalhar no Snapshot Agente para enviar os dados iniciais do Editor para Assinante .

Antes de entrar nele, precisamos observar o Replication Monitor . Essa ferramenta crítica está disponível no SSMS para exibir o status de replicação em vários níveis, nível de servidor, nível de banco de dados do editor, nível de assinatura e nível de agentes de replicação.

Clique com o botão direito do mouse em Replicação /Publicação local /Assinatura local /Publicação ou a Assinatura criamos para lançar o Replication Monitor como mostrado abaixo:

No Monitor de replicação , expanda Servidor do Editor (RRJ)> Publicação ([AdventureWorks]:AdventureWorks_pub) para exibir os detalhes da assinatura. Clique com o botão direito do mouse em Assinatura e selecione Ver detalhes .

Como podemos ver, as informações sobre o Instantâneo inicial para nossa publicação AdventureWorks_pub ainda não está disponível. Precisaremos executar o trabalho do agente Snapshot para enviar os dados iniciais ao banco de dados do Assinante .

Mantenha esta janela aberta para ver o progresso do Snapshot após iniciar o trabalho do Snapshot Agent .

Clique com o botão direito do mouse em Publicação > Visualizar o status do agente de instantâneo :

O agente nunca foi executado mensagem informa que nunca executamos o Snapshot Agent. Clique em Iniciar .

Enquanto o Snapshot Agent está em execução, você pode observar o progresso:

Quando todos os instantâneos forem criados, ele produzirá a mensagem de confirmação:

Podemos ver os arquivos Snapshot criados recentemente na pasta Snapshot para a qual fornecemos o caminho anteriormente.

Depois que todos os instantâneos forem aplicados pelo Agente de distribuição para o banco de dados de assinantes , ele exibirá o status abaixo no Replication Monitor aberto janela:

Parabéns! Configuramos com sucesso a Replicação Transacional usando o Snapshot Agent.

Observação :Se tivermos um grande banco de dados do editor, a criação de um instantâneo pode levar muito tempo. Portanto, é recomendável usar o backup completo do banco de dados do Publisher em vez de executar o Snapshot Agent – ​​abordaremos esse problema em artigos subsequentes.

Verificando os componentes de replicação


Todos os componentes de replicação podem ser verificados por consultas GUI do SSMS e TSQL. Discutiremos isso em outros artigos e aqui explicaremos rapidamente como visualizar as propriedades dos componentes abaixo.

Editor


No SSMS, clique com o botão direito do mouse em Replicação > Propriedades do editor > Bancos de dados de publicação :

Para ver detalhes sobre o Editor , execute as consultas abaixo no banco de dados de distribuição.
USE distribution
GO
exec sp_helpdistpublisher
GO
select * from MSpublisher_databases
GO

Assinante


As informações do assinante podem ser obtidas com a consulta abaixo no SSMS.
USE distribution
GO
exec sp_helpsubscriberinfo
GO
select * from MSsubscriber_info

Distribuidor


No SSMS, clique com o botão direito do mouse em Replicação > Distribuidor Propriedades :

Clique em Editores para exibir a lista de todos os Publicadores que usam esse banco de dados de Distribuição.

No SSMS, podemos executar a consulta abaixo para obter os mesmos detalhes.
USE distribution
GO
exec sp_helpdistributor
GO
exec sp_helpdistributiondb
GO	

Artigos


Clique com o botão direito do mouse em Publicação > Propriedades de publicação > Artigos . Você verá a lista de todos os artigos disponíveis. As propriedades de artigos individuais podem ser modificadas clicando em Propriedades do artigo também.
USE AdventureWorks
GO
-- To View all articles available under a Publication
exec sp_helparticle @publication = 'Adventureworks_pub'
GO
-- To View all article columns for a particular article available under a Publication
exec sp_helparticlecolumns @publication = 'Adventureworks_pub', @article = 'Address'
GO
USE distribution
GO
SELECT * from MSArticles

Publicação


Clique com o botão direito do mouse em Publicação > Propriedades :

No SSMS, podemos executar a consulta abaixo para visualizar as Propriedades da publicação :
USE AdventureWorks
GO
exec sp_helppublication
GO
USE distribution
GO
SELECT * FROM MSPublications

Assinatura


Clique com o botão direito do mouse em Assinatura > Propriedades da assinatura :

No SSMS, podemos executar o script abaixo para obter as informações da assinatura:
USE AdventureWorks
GO
exec sp_helpsubscription
GO
USE distribution
GO
SELECT * FROM MSsubscriptions
GO

Agentes de replicação


Em Trabalhos do SQL Server Agent , podemos encontrar os Trabalhos específicos criado para todos os agentes de replicação:

No SSMS, podemos executar a consulta para descobrir qual trabalho é o trabalho do agente de leitor de log necessário , Trabalho de agente de instantâneo e Trabalhos de agente de distribuição . Além disso, podemos ver o trabalho de limpeza do agente de distribuição e vários outros trabalhos relacionados à Replicação criados enquanto definimos Publicação e Assinaturas internamente.

Como o Log Reader Agent funciona


O Agente do leitor de registros lê todos os dados confirmados dos logs transacionais do banco de dados do Publicador e os envia por push para o banco de dados do Distribuidor. Embora a Microsoft não forneça uma maneira oficial de ler logs transacionais, existem poucas funções não documentadas, como fn_dblog() e fn_dump_dblog() que pode ler os dados dos Arquivos de Log. No entanto, essas funções não são documentadas e não são cobertas pelo suporte da Microsoft. Assim, não vamos explorá-los mais.

Como o Distribution Agent entrega as alterações de dados ao banco de dados do assinante


Depois que os dados são gravados no banco de dados Distribution, podemos ler como esses dados são armazenados nas tabelas de distribuição. Para isso, aplicamos o sp_browsereplcmds procedimento – ele busca os registros nos MSrepl_commands e MSrepl_transactions mesas.

Para fins de aprendizado, vamos pegar uma tabela com 3 colunas chamada Person.ContactType :

A Assinatura criada fará 3 procedimentos para cada artigo que fizer parte da Publicação no banco de dados do Assinante com as convenções de nomenclatura abaixo:
  • dbo.sp_MSins_
  • dbo.sp_MSupd_
  • dbo.sp_MSdel_

Para o artigo da Tabela Person.ContactType, podemos ver os procedimentos abaixo criados no banco de dados do Assinante:
  • dbo.sp_MSins_PersonContactType INSERIR novos registros capturados do banco de dados de logs de transações do editor e então propagados para o banco de dados de distribuição.
  • dbo.sp_MSupd_PersonContactType ATUALIZAÇÃO alterações capturadas do banco de dados de logs de transações do editor e, em seguida, propagadas para o banco de dados de distribuição.
  • dbo.sp_MSdel_PersonContactType EXCLUIR registros capturados do banco de dados de logs de transações do editor e então propagados para o banco de dados de distribuição.

Script do procedimento dbo.sp_MSins_PersonContactType


Como você pode ver, é uma instrução INSERT direta que sai do banco de dados de distribuição:
ALTER procedure [dbo].[sp_MSins_PersonContactType]
    @c1 int,
    @c2 nvarchar(50),
    @c3 datetime
as
begin  
	insert into [Person].[ContactType] (
		[ContactTypeID],
		[Name],
		[ModifiedDate]
	) values (
		@c1,
		@c2,
		@c3	) 
end  
GO

Script of the dbo.sp_MSupd_PersonContactType Procedure


The script relies on the Primary Key values to identify the unique record for updating:
ALTER procedure [dbo].[sp_MSupd_PersonContactType]
		@c1 int = NULL,
		@c2 nvarchar(50) = NULL,
		@c3 datetime = NULL,
		@pkc1 int = NULL,
		@bitmap binary(1)
as
begin  
	declare @primarykey_text nvarchar(100) = ''
update [Person].[ContactType] set
		[Name] = case substring(@bitmap,1,1) & 2 when 2 then @c2 else [Name] end,
		[ModifiedDate] = case substring(@bitmap,1,1) & 4 when 4 then @c3 else [ModifiedDate] end
	where [ContactTypeID] = @pkc1
if @@rowcount = 0
    if @@microsoftversion>0x07320000
		Begin
			if exists (Select * from sys.all_parameters where object_id = OBJECT_ID('sp_MSreplraiserror') and [name] = '@param3')
			Begin
				
				set @primarykey_text = @primarykey_text + '[ContactTypeID] = ' + convert(nvarchar(100),@pkc1,1)
				exec sp_MSreplraiserror @errorid=20598, @param1=N'[Person].[ContactType]', @[email protected]_text, @param3=13233 
			End
			Else
				exec sp_MSreplraiserror @errorid=20598
		End
end 
GO

Script of the dbo.sp_MSdel_PersonContactType Procedure


This script relies on the Primary Key values to identify a unique record for deleting records from the Subscriber :
ALTER procedure [dbo].[sp_MSdel_PersonContactType]
		@pkc1 int
as
begin  
	declare @primarykey_text nvarchar(100) = ''
	delete [Person].[ContactType] 
	where [ContactTypeID] = @pkc1
if @@rowcount = 0
    if @@microsoftversion>0x07320000
		Begin
			if exists (Select * from sys.all_parameters where object_id = OBJECT_ID('sp_MSreplraiserror') and [name] = '@param3')
			Begin
				
				set @primarykey_text = @primarykey_text + '[ContactTypeID] = ' + convert(nvarchar(100),@pkc1,1)
				exec sp_MSreplraiserror @errorid=20598, @param1=N'[Person].[ContactType]', @[email protected]_text, @param3=13234 
			End
			Else
				exec sp_MSreplraiserror @errorid=20598
		End
end  
GO

This clearly explains why Transactional Replication enforces the Primary Key as a key requirement for tables to be added as part of Replication .

Now, let’s see the Transactional Replication in action. Let’s change some data in the Publisher database. For simplicity, I’ll take the same Person.ContactType tabela.

Executing the SELECT statement on the table yields 20 records:

Next, I INSERTed a sample record into the Person.ContactType tabela:

And, I UPDATE the newly inserted record:

DELETE the newly inserted record from the table:

We need to verify these transactions in Replication using sp_browsereplcmds

Changes from Person.ContactType were captured from the Transactional Logs of Publisher Database (AdventureWorks ) and sent to the Distribution database in the same order. Later, it was propagated to the Subscriber Database (AdventureWorks_REPL ).

Conclusão


Thanks for reading this long power-packed article! We have gone through a variety of topics, such as:
  • Replication Architecture and Terminologies
  • SQL Server Replication Types
  • SQL Server Transactional Replication in Detail
  • SQL Server Transactional Replication Configuration (Default approach)
  • SQL Server Transactional Replication Verification
  • SQL Server Transactional Replication in action

I hope that you’ve found lots of helpful information in this article. In subsequent parts, we’ll explore troubleshooting various issues that are frequently encountered in Replication, and learn how to handle them more efficiently.