Como implementar bidireccional replicação transaccional

Este artigo passo a passo descreve como implementar a replicação transaccional bidireccional. Este artigo também descreve os problemas envolvidos na implementação bidireccional replicação transaccional.

Bidireccional replicação transaccional

Replicação transaccional bidireccional, também conhecido como bidireccional replicação transaccional, permite que um servidor para ser um editor e subscritor aos mesmos dados. Uma vez que os servidores que participam na replicação irão replicam que quaisquer alterações aos outros servidores, as alterações não são ser propagadas ao servidor de origem.

Por exemplo, se tiver dois servidores (servidor A e B Server), os servidores são chamados a ser bidireccional replicação transaccional se ambas as condições seguintes forem verdadeiras:

• As alterações efectuadas a tabela T1 no servidor A são replicadas a tabela T1 no servidor B.
• As alterações efectuadas a tabela T1 no servidor B são replicadas para tabela T1 no servidor a.

Por conseguinte, se uma alteração provém do servidor, a alteração é replicada para o servidor B, mas não propagar o servidor B a alteração mesma servidor a. replicação utiliza um mecanismo de detecção de loopback o distribuidor utiliza para determinar se para enviar as alterações efectuadas ao servidor de origem.

Planear a topologia de replicação transaccional bidireccional

Replicação transaccional bidireccional, um dos servidores pode agir como subscritor central e todos os outros servidores subscrever subscritor central. Por conseguinte, quaisquer alterações que têm origem num servidor são replicadas para o subscritor central e, em seguida, o subscritor central, replica por sua vez, as alterações para todos os outros servidores que participam na replicação. No entanto, com a ajuda do mecanismo de detecção de loopback, o distribuidor deixa de alteração de que está a ser propagadas para o servidor de origem.

Por exemplo, três servidores (servidor, servidor B e C Server) participam na replicação transaccional do bidireccional e servidor for o subscritor central, os fabricantes e os subscritores serão mantidos se das seguintes formas:

• Servidor A publica para servidor B e C. Server
• Servidor A subscreve a partir do servidor B e C. Server
• Servidor B publica e subscrevem do servidor apenas a.
• Servidor C publica e subscrevem do servidor apenas a.

Por este motivo, qualquer alteração que tem origem no servidor B é replicada para servidor A e C. Server

Conflitos de bidireccional replicação transaccional

Quando efectuar alterações num servidor que está a participar na replicação, as alterações são replicadas para todos os outros servidores participantes. Durante esta replicação, poderão ocorrer conflitos e replicação poderá falhar. A lista seguinte descreve possíveis conflitos e as formas que pode evitar estes conflitos:

• Se inserir um registo que tenha uma chave para uma tabela dos servidores e outro registo que tenha a mesma chave já existe noutros servidores que participam na replicação, a replicação não propagar as alterações as outros servidores.
  
  acção sugerida Para evitar este problema, certifique-se que utilize chaves diferentes em cada servidor que participa na replicação. Para o fazer, atribuir um intervalo predeterminado de teclas para cada servidor que participa na replicação. Também pode utilizar uma chave composta em cada servidor.
• Quando actualizar um registo que foi eliminado noutro servidor, a instrução UPDATE afecta zero linhas no servidor onde o registo foi eliminado e a replicação falha com erro.
  
  acção sugerida Para evitar este problema, efectue um dos seguintes passos:
  • Remover @@ ROWCOUNT verificar após a instrução UPDATE real no procedimento armazenado personalizada de actualização.
    
    - ou -
  • Utilize o -Skiperrors parâmetro para o agente de distribuição ignorar este erro. Para mais informações sobre como ignorar erros de replicação transaccional, visite o seguinte Web site da Microsoft:
    
    http://msdn2.microsoft.com/en-us/library/aa178842(SQL.80).aspx (http://msdn2.microsoft.com/en-us/library/aa178842(SQL.80).aspx)
    - ou -
  • Procure um registo antes da instrução UPDATE na actualização para o procedimento armazenado. Se nenhum registo existir, ignorar a instrução UPDATE e o registo é eliminado em todos os subscritores.
• Quando actualiza uma coluna de um registo que é actualizada ao mesmo tempo noutro servidor, os dados podem ser diferentes nos dois servidores.
  
  acção sugerida Para evitar este problema, determine se os dados está a ser actualizados simultaneamente noutros servidores e então efectuar qualquer acção necessária. Para fazê-lo, modificar o procedimento armazenado personalizada da actualização e utilizar XCALL sintaxe para chamar a actualização de procedimento armazenado. A sintaxe XCALL fornece os valores para todas as colunas antes o procedimento de actualização é chamado e fornece os valores actualizados na coluna. Pode comparar o valor da coluna contra o valor actual antes do procedimento armazenado de actualização é chamado. Se vir valores diferentes, a coluna a ser actualizada em simultâneo por diferentes servidores. Pode personalizar o procedimento armazenado para seleccionar o valor persistir. Para mais informações sobre como utilizar XCALL, visite o seguinte Web site da Microsoft:
  
  http://msdn2.microsoft.com/en-us/library/Aa237133(SQL.80).aspx (http://msdn2.microsoft.com/en-us/library/Aa237133(SQL.80).aspx)
  Nota Pode especificar a sintaxe XCALL para chamar a actualização correspondente procedimento armazenado ou eliminar o procedimento armazenado utilizando sp_addarticle durante a publicação. Também pode especificar a sintaxe XCALL utilizando o SQL Server Enterprise Manager. Para o fazer, siga estes passos:
  1. No SQL Server Enterprise Manager, localize a publicação que pretende.
  2. Clique com o botão direito do rato a publicação e, em seguida, clique em Propriedades .
  3. Clique no separador artigos , localize o artigo e, em seguida, clique no artigo propriedades botão (...) junto do artigo.
  4. Na caixa de diálogo Propriedades da tabela artigo , clique no separador de comandos .
  5. Na caixa de texto comandos UPDATE substituir com esta chamada de procedimento armazenado , escreva XCALL e, em seguida, clique em OK .
  6. Na caixa de diálogo Propriedades de publicação , clique em OK .
• Quando actualiza diferentes colunas de um registo, actualizações simultâneas de diferentes colunas de um registo, por vezes, poderão conduzir a conflitos.
  
  acção sugerida Para evitar este problema, determine se as colunas diferentes no mesmo registo são actualizadas ao mesmo tempo e então efectuar qualquer acção necessária. Para fazê-lo, modificar o procedimento armazenado personalizada da actualização e, em seguida, utilizar o XCALL sintaxe para chamar a actualização de procedimento armazenado. Uma vez que a sintaxe XCALL fornece os valores antes o procedimento armazenado de actualização é chamado, é possível adicionar uma das seguintes opções ao procedimento de actualização armazenado antes da actualização real é efectuada:
  • Compare os valores actuais de todas as colunas com os respectivos valores antes da actualização de procedimento armazenado é chamado.
  • Adicione uma coluna para representar a versão de linha e para comparar o valor actual pelo respectivo valor antes da actualização de procedimento armazenado é chamada.
  Valores diferentes indicam que diferentes colunas estão a ser actualizadas ao mesmo tempo. Pode então decidir se pretende actualizar a coluna.
• Quando eliminar uma linha que está a ser actualizada por outro servidor ao mesmo tempo, a replicação poderá falhar.
  
  acção sugerida Para determinar se uma linha é actualizada e eliminada ao mesmo tempo, utilize a sintaxe XCALL no procedimento de eliminação armazenado. Compare todas as coluna da linha que está a ser eliminada com os valores antes o procedimento de eliminação armazenado é chamado. Valores diferentes indicam que estas actualizações estão a ser efectuadas ao mesmo tempo. Pode eliminar ou reter a linha actualizada.
  
  Nota Mesmo se não eliminar o registo no subscritor, o registo já não existe no servidor que originou a DELETE instrução.
• Quando elimina uma linha que está a ser eliminada ao mesmo tempo noutro servidor que está a participar na replicação, a replicação falha porque a instrução DELETE não afecta quaisquer linhas em alguns dos subscritores.
  
  acção sugerida Para evitar este problema, efectue um dos seguintes passos:
  • Remover @@ ROWCOUNT verificar depois da instrução DELETE real no procedimento armazenado personalizada de actualização.
    
    - ou -
  • Utilize o -Skiperrors parâmetro com o agente de distribuição para ignorar este erro. Para mais informações sobre como ignorar erros de replicação transaccional, visite o seguinte Web site da Microsoft:
    
    http://msdn2.microsoft.com/en-us/library/aa178842(SQL.80).aspx (http://msdn2.microsoft.com/en-us/library/aa178842(SQL.80).aspx)

Nota Cada implementação poderá necessitar de uma abordagem diferente para resolver estes conflitos, consoante os requisitos empresariais. Estes conflitos fáceis de resolver quando apenas dois servidores envolvidos. Quando mais do que dois servidores envolvido, poderá utilizar procedimentos armazenados para determinar qual o servidor teve as alterações. O procedimento de actualização armazenado que é utilizado para actualizar os registos no servidor C não sabe se a alteração teve origem no servidor ou no servidor B. Ao contrário de replicação de intercalação, replicação transaccional não foi concebida para resolver conflitos. Implementar a replicação transaccional apenas em cenários onde podem ser evitados conflitos em vez de resolvido.

Implementar bidireccional replicação transaccional

Para implementar bidireccional replicação transaccional, todas as seguintes condições têm de ser verdadeiras:

• Os dados são sincronizados entre os servidores de replicação.
• Procedimentos armazenados que são utilizados por replicação estão localizados nas bases de dados todos os participantes.
• A subscrição foi configurada, utilizando @ loopback_detection = 'true' parâmetro.
  
  Nota A opção de Definir @ loopback_detection = 'true' não está actualmente disponível na interface de utilizador. Por este motivo, deve subscrever utilizando o procedimento sp_addsubscription armazenados.

Se efectuar uma cópia de segurança e restauro, lembre-se de que sites diferentes requerem diferentes restrições da chave primária para garantir que os duplicados chaves primárias não são criadas. Lembre-se também de criar todos os constrangimentos com a cláusula NOT FOR REPLICATION.

Pode utilizar o exemplo seguinte para configurar a replicação transaccional bidireccional num computador com o SQL Server 2000.

Nota Instruções de Transact-SQL estão listadas para cada um dos seguintes passos. Execute as instruções de Transact-SQL para executar a tarefa mencionada no passo anterior.

1. Crie um distribuidor, fabricantes e os subscritores num computador com o SQL Server. Para o fazer, siga estes passos:
   1. Criar duas bases de dados:

      use master
      go
      
      create database test1
      go
      
      create database test2
      go
      

   2. Crie duas tabelas com uma coluna IDENTITY com a opção definida NOT FOR REPLICATION:

      use test1
      go
      
      create table two_way_test1 
      (
      	pkcol		INTEGER PRIMARY KEY NOT NULL,
      	intcol		INTEGER IDENTITY(1,1) NOT FOR REPLICATION,
       	charcol		CHAR(100),
      	timestampcol 	TIMESTAMP
      )
      
      use test2
      go
      
      create table two_way_test2 
      (
      	pkcol 		INTEGER PRIMARY KEY NOT NULL,
      	intcol 		INTEGER IDENTITY(1000000000,1) NOT FOR REPLICATION,
       	charcol 	CHAR(100),
       	timestampcol 	TIMESTAMP
      )
      go

   3. Atribuir um intervalo de valores para a coluna de chave primária predeterminado para que os valores em diferentes servidores não estejam na mesma gama. Por exemplo, pode impor 1-1000 como intervalo de chave para a tabela two_way_test1 na base de dados Teste1 e, em seguida, aplicar 1001-2000 como intervalo de chave para two_way_test2 tabela na base de dados Teste2 . Para o fazer, utilize o seguinte código:

      	-- Constraint to enforce a range of values between 1 and 1000 in database test1 
      use test1
      go
      
      alter table 
      	two_way_test1 
      with nocheck 
      add constraint 
      	checkprimcol check NOT FOR REPLICATION 
      	(
      		pkcol BETWEEN 1 and 1000
      	) 
      go 
      
      
      use test2
      go
      
      	-- Constraint to enforce a range of values between 1001 and 2000 in the database test2 
      
      alter table 
      	two_way_test2
      with nocheck 
      add constraint 
      	checkprimcol check NOT FOR REPLICATION 
      	(
      		pkcol BETWEEN 1001 and 2000
      	) 
      go 
      
      

2. Activar o servidor como o distribuidor e crie uma base de dados de distribuição:

   use master
   go
   sp_adddistributor @distributor = '<distributor name>' 
   go
   use master
   go
   sp_adddistributiondb @database='distribution'
   go

3. Permitir todos os os computadores com o SQL Server que participam na replicação como editores:

   use master
   go
   
   exec sp_adddistpublisher 
   	@publisher = '<Your Server Name>', 
   	@distribution_db ='distribution', 
   	@security_mode = 0, 
   	@login = 'sa', 
   	@password = 'sa',
   	@working_directory ='<Location of Directory>'

4. Activar os identificados bases para replicação:

   use master
   go
   
   exec sp_replicationdboption N'test1', N'publish', true
   go
   
   exec sp_replicationdboption N'test2', N'publish', true
   go
   

5. Criar personalizados procedimentos armazenados para INSERT, UPDATE e DELETE operações em todas as bases de dados para aplicar as alterações efectuadas durante a replicação.
   
   Nota Normalmente, quando insere um valor para uma coluna IDENTITY, a opção IDENTITY_INSERT para a tabela tem de ser ACTIVADO. Esta tarefa é conseguida através da opção NOT FOR REPLICATION de agentes de replicação a receber.
   
   Não é possível actualizar os valores na coluna IDENTITY. Por este motivo, quando actualiza os valores durante a replicação, terá de remover os valores antigos e inserir os novos valores. Para criar os procedimentos armazenados personalizados, siga estes passos:
   1. Create the custom stored procedures in the test1 database:

      use test1
      go
      
      -- INSERT Stored Procedure
      
      create procedure sp_ins_two_way_test1	
      	@pkcol int, 
      	@intcol int, 
      	@charcol char(100), 
      	@timestampcol timestamp,
      	@rowidcol uniqueidentifier
      as
      	insert into two_way_test1 
      	(
      		pkcol,
      		intcol,
      		charcol
      	) 
      	values
      	(
      		@pkcol, 
      		@intcol, 
      		@charcol
      	)
      go
      
      --UPDATE Stored Procedure
      
      create procedure sp_upd_two_way_test1	
      	@pkcol int, 
          	@intcol int, 
          	@charcol char(100), 
          	@timestampcol timestamp,
      	@rowidcol uniqueidentifier,
          	@old_pkcol int
      as
      	declare @x int
      	declare @y int
      	declare @z char(100)
       
      	select 
      		@x=pkcol, 
      		@y=intcol, 
      		@z=charcol 
      	from 
      		two_way_test1 
      	where 
      		pkcol = @pkcol
      
      
      
      	delete 
      		two_way_test1 
      	where 
      		pkcol=@pkcol
      
      
      
      	insert into two_way_test1 
      	(
      		pkcol, 
      		intcol, 
      		charcol
      	) 
      	values
      	(
      		case isnull(@pkcol,0) when 0 then @x else @pkcol end,
      		case isnull(@intcol,0) when 0 then @y else @intcol end,
      		case isnull(@charcol,'N') when 'N' then @z else @charcol end
      	)
      go
      
      --  DELETE Stored Procedure
      
      create procedure sp_del_two_way_test1 
      	@old_pkcol int
      as
      	delete 
      		two_way_test1 
      	where 
      		pkcol = @old_pkcol
      go
      
      

   2. Create the custom stored procedures in the test2 database:

      use test2
      go
      
      -- INSERT Stored Procedure
      
      create procedure sp_ins_two_way_test2	
      	@pkcol int, 
      	@intcol int, 
      	@charcol char(100), 
      	@timestampcol timestamp,
      	@rowidcol uniqueidentifier
      as
      	insert into two_way_test2 
      	(
      		pkcol,
      		intcol,
      		charcol
      	) 
      	values
      	(
      		@pkcol, 
      		@intcol, 
      		@charcol
      	)
      go
      
      --UPDATE Stored Procedure
      
      create procedure sp_upd_two_way_test2	
      	@pkcol int, 
          	@intcol int, 
          	@charcol char(100), 
          	@timestampcol timestamp,
      	@rowidcol uniqueidentifier,
          	@old_pkcol int
      as
      	declare @x int
      	declare @y int
      	declare @z char(100)
       
      	select 
      		@x=pkcol, 
      		@y=intcol, 
      		@z=charcol 
      	from 
      		two_way_test2 
      	where 
      		pkcol = @pkcol
      
      
      
      	delete 
      		two_way_test2 
      	where 
      		pkcol=@pkcol
      
      
      
      	insert into two_way_test2 
      	(
      		pkcol, 
      		intcol, 
      		charcol
      	) 
      	values
      	(
      		case isnull(@pkcol,0) when 0 then @x else @pkcol end,
      		case isnull(@intcol,0) when 0 then @y else @intcol end,
      		case isnull(@charcol,'N') when 'N' then @z else @charcol end
      	)
      go
      
      
      --  DELETE Stored Procedure
      
      create procedure sp_del_two_way_test2 
      	@old_pkcol int
      as
      	delete 
      		two_way_test2 
      	where 
      		pkcol = @old_pkcol
      go
      

6. Criar uma publicação transaccional e, em seguida, adicionar artigos à publicação no Teste1 e as bases de dados Teste2 :

   --In the database test1.
   
   use test1
   go
   
   --  Adding the transactional publication.
   exec sp_addpublication 
   	@publication = N'two_way_pub_test1', 
   	@restricted = N'false',
   	@sync_method = N'native', 
   	@repl_freq = N'continuous',
   	@description = N'Transactional publication of database test1.',
   	@status = N'active', 
   	@allow_push = N'true', 
   	@allow_pull = N'true',
   	@allow_anonymous = N'false', 
   	@enabled_for_internet = N'false',
   	@independent_agent = N'false', 
   	@immediate_sync = N'false',
   	@allow_sync_tran = N'true', 
   	@autogen_sync_procs = N'true',
   	@retention = 72
   go
   
   exec sp_addpublication_snapshot 
   	@publication = N'two_way_pub_test1',
   	@frequency_type = 4,
   	@frequency_interval = 1, 
   	@frequency_relative_interval = 0,
   	@frequency_recurrence_factor = 1, 
   	@frequency_subday = 1,
   	@frequency_subday_interval = 0, 
   	@active_start_date = 0,
   	@active_end_date = 0, 
   	@active_start_time_of_day = 233000,
   	@active_end_time_of_day = 0
   go
   
   --  Adding the transactional articles.
   
   exec sp_addarticle 
   	@publication = N'two_way_pub_test1', 
   	@article = N'two_way_test1',
   	@source_owner = N'dbo', 
   	@source_object = N'two_way_test1',
   	@destination_table = N'two_way_test1', 
   	@type = N'logbased',
   	@creation_script = null, 
   	@description = null, 
   	@pre_creation_cmd = N'drop',
           @schema_option = 0x00000000000000F1, 
   	@status = 16,
   	@vertical_partition = N'false', 
   	@ins_cmd = N'CALL sp_ins_two_way_test2',
   	@del_cmd = N'CALL sp_del_two_way_test2',
   	@upd_cmd = N'CALL sp_upd_two_way_test2', 
   	@filter = null,
   	@sync_object = null
   go
   
   --  In the database test2
   use test2
   go
   
   --  Adding the transactional publication.
   
   exec sp_addpublication 
   	@publication = N'two_way_pub_test2', 
   	@restricted = N'false',
   	@sync_method = N'native', 
   	@repl_freq = N'continuous',
   	@description = N'Transactional publication of database test2',
   	@status = N'active', 
   	@allow_push = N'true', 
   	@allow_pull = N'true',
   	@allow_anonymous = N'false', 
   	@enabled_for_internet = N'false',
   	@independent_agent = N'false', 
   	@immediate_sync = N'false',
   	@allow_sync_tran = N'true', 
   	@autogen_sync_procs = N'true',
   	@retention = 72
   go
   
   exec sp_addpublication_snapshot 
   	@publication = N'two_way_pub_test2',
   	@frequency_type = 4,
   	@frequency_interval = 1, 
   	@frequency_relative_interval = 0,
   	@frequency_recurrence_factor = 1, 
   	@frequency_subday = 1,
   	@frequency_subday_interval = 0, 
   	@active_start_date = 0,
   	@active_end_date = 0, 
   	@active_start_time_of_day = 233000,
   	@active_end_time_of_day = 0
   go
   
   --  Adding the transactional articles.
   exec sp_addarticle 
   	@publication = N'two_way_pub_test2', 
   	@article = N'two_way_test2',
   	@source_owner = N'dbo', 
   	@source_object = N'two_way_test2',
   	@destination_table = N'two_way_test2', 
   	@type = N'logbased',
   	@creation_script = null, 
   	@description = null, 
   	@pre_creation_cmd = N'drop',
   	@schema_option = 0x00000000000000F1, 
   	@status = 16,
   	@vertical_partition = N'false', 
   	@ins_cmd = N'CALL sp_ins_two_way_test1',
   	@del_cmd = N'CALL sp_del_two_way_test1',
   	@upd_cmd = N'CALL sp_upd_two_way_test1', 
   	@filter = null,
   	@sync_object = null
   go
   

7. Activar todos os servidores que participam na replicação, os subscritores:

   exec sp_addsubscriber 
   	@subscriber = '<Your Server Name>', 
   	@login = '<login name>', 
   	@password = '<password>'
   go
   
   

8. Identificar das bases de dados como subscritor central. Crie subscrições transaccionais em todas as bases de dados que participam na replicação, para que todas as bases de dados subscrever subscritor central e o subscritor central subscreve as outras bases de dados.
   
   Por exemplo, neste cenário, a base de dados Teste1 é subscritor central. Crie subscrições transaccionais na base de dados Teste2 subscrever a publicação Teste1 e na base de dados Teste1 subscrever a publicação Teste2 .
   
   Nota Crie todas as subscrições com a opção LOOPBACK_DETECTION activada.
   
   Para o fazer, utilize o seguinte código:

   --Adding the transactional subscription in test1.
   
   use test1
   go
   exec sp_addsubscription 
   	@publication = N'two_way_pub_test1', 
   	@article = N'all', 
   	@subscriber = '<Your Server Name>', 
   	@destination_db = N'test2', 
   	@sync_type = N'none', 
   	@status = N'active', 
   	@update_mode = N'sync tran', 
   	@loopback_detection = 'true'
   go
   
   -- Adding the transactional subscription in test2.
   
   use test2
   go
   exec sp_addsubscription 
   	@publication = N'two_way_pub_test2', 
   	@article = N'all', 
   	@subscriber = '<Your Server Name>', 
   	@destination_db = N'test1', 
   	@sync_type = N'none', 
   	@status = N'active', 
   	@update_mode = N'sync tran', 
   	@loopback_detection = 'true'
   go
   

Nota Pode também criar procedimentos armazenados personalizados para todas as publicações utilizando o procedimento armazenado do sistema de sp_scriptpublicationcustomprocs . Para mais informações sobre o procedimento armazenado do sistema de sp_scriptpublicationcustomprocs , consulte o tópico "sp_scriptpublicationcustomprocs" no SQL Server 2000 actualizada Books Online.

Nota Analisador de consultas de SQL devolve apenas 256 caracteres por coluna. Pode alterar esta opção para o máximo valor permitido.

Para obter informações adicionais, clique números de artigo que se seguem para visualizar os artigos na base de dados de conhecimento da Microsoft: Para obter informações adicionais sobre como implementar bidireccional replicação transaccional em SQL Server 7.0, clique números de artigo que se seguem para visualizar os artigos na base de dados de conhecimento da Microsoft: