Inicio > Base de datos > Usando sp_repldone para marcar todas las transacciones pendientes como si hubieran sido replicadas

Usando sp_repldone para marcar todas las transacciones pendientes como si hubieran sido replicadas

domingo, 17 de noviembre de 2024 Dejar un comentario Ir a comentarios

Pensé que podría ser útil si público un ejemplo usando sp_repldone para marcar todas las transacciones pendientes como «replicadas». Hemos utilizado este comando para «saltar» un comando DELETE en lotes que fue ejecutado por error en el publicador. Esto impidió que el DELETE sea empujado a la base de datos de distribución y luego hacia los suscriptores. Ahora nos podría haber permitido el LOG Reader para recoger las filas entonces tienen que saltar el Agente de distribución, pero el DELETE fue de más de 100 millones de filas. Encontramos más fácil saltar ellos en el LOG Reader.


Para recuperar los datos que puede restaurar el publicador o volver a cargar los registros borrados desde la tabla del suscriptor. Para una base de datos de 10 TB, cargar los registros de una tabla era mucho más rápido que una completa restauración.

Este comando se encuentra en los SQL Server Books Online (de todas las versiones). El estado del BOL de la publicación debe ser inicializado. Se trata de una recomendación para asegurar que el publicador y el suscriptor tengan los mismos datos. Sin embargo, como veremos, esto no siempre es necesario.

  • Crear una publicación de réplica transaccional a efectos de demostración, editar las propiedades de los trabajos del LogReader y de Distribucion en el Agente del Sql y remueve –Continuos.
  • Utiliza el Monitor de replicación, haz clic en la tarea del Agente Log Reader, a continuación, en Propiedades.

  • En la ventana Propiedades seleccione Steps (Pasos), luego «Run Agent», y a continuación, el botón Modificar.

  • En el comando: eliminar-continua situado en el extremo de la línea de comandos.

--1st update transaction 
  update [SalesLT].[Customer]
  set FirstName = 'Tran1'
  where CustomerID = 1
 
--Start LogReader for 1 transactions (-continuous option was removed)
--Start Distributor
--Verify 'Tran1' was replicated to subscriber   
  SELECT top 1 CustomerID, FirstName
  FROM AdventureWorks_Peer_B.[SalesLT].[Customer]
 
--2nd update transaction 
  update [SalesLT].[Customer]
  set FirstName = 'Tran2'
  where CustomerID = 1
 
--Show transactions pending in the Transaction Log 
  sp_replshowcmds
 
       xact_seqno = 0x00000180000000ED0004
       {CALL [dbo].[sp_MSupd_SalesLTCustomer] (,,,N'Tran2',,,,,,,,,,,,1,0x0800)}
 
--The DBCC OPENTRAN command be used to show if there are pending transactions.
--Notice the “Oldest non-distributed LSN” is the BEGIN Tran LSN for the same UPDATE
  DBCC OPENTRAN
 
  Replicated Transaction Information:
        Oldest distributed LSN     : (384:235:4)
        Oldest non-distributed LSN : (384:237:1) >>>>>0x00000180 000000ED 0001
       
 
--The FN_DBLOG function can display the log contents from the
--     Begin Tran (DBCC OPENTRAN)    00000180:000000ed:0001
--   to the
--     Commit Tran(sp_replshowcmds)  00000180:000000ed:0004
  select  [Current LSN],[Operation],[Transaction ID], Left([Description],20)
  from::fn_dblog('0x00000180:000000ED:0001','0x00000180:000000ED:0004')
Current LSN             Operation                      Transaction ID 
----------------------- ------------------------------ -------------- --------------------
00000180:000000ed:0001  LOP_BEGIN_XACT                 0000:0001d5c2  UPDATE;0x01050000000
00000180:000000ed:0002  LOP_DELETE_ROWS                0000:0001d5c2  REPLICATE
00000180:000000ed:0003  LOP_INSERT_ROWS                0000:0001d5c2  REPLICATE
00000180:000000ed:0004  LOP_COMMIT_XACT                0000:0001d5c2  REPLICATE

 
--Mark all transactions as having been replicated.
  EXEC sp_repldone @xactid = NULL, @xact_segno = NULL, @numtrans = 0, @time = 0, @reset = 1
 
 
--Re-run sp_replshowcmds, no pending transactions.
  sp_replshowcmds
 
--DBCC OPENTRAN 
  DBCC OPENTRAN
No active open transactions.
--Flush Transaction Log article cache
  sp_replflush
 
--3rd update transaction
  update [SalesLT].[Customer]
  set FirstName = 'Tran3'
  where CustomerID = 1
 
 
--Start LogReader
--Start Distributor
--Verify 'Tran3' was replicated to subscriber   
  SELECT top 1 CustomerID, FirstName
  FROM AdventureWorks_Peer_A.[SalesLT].[Customer]
 
  SELECT top 1 CustomerID, FirstName
  FROM AdventureWorks_Peer_B.[SalesLT].[Customer]
 
       CustomerID  FirstName
       ----------- ------------------------------
       1           Tran3

Nota que Tran3 se replica correctamente al suscriptor. Entonces ¿Cuál es el problema? Bueno, si hubiera habido otra transacción pendiente de la cual no sabía nada, también se han marcado como replicada y que no se ha recogido por el LOG Reader. Esto resultara con el publicador y el suscriptor fuera de sincronización. Para corregir, que hay utilizar la utilidad TableDiff.exe incluida con SQL Server para encontrar las diferencias fila/columna, o inicializar el suscriptor

Los Hands on demos son una gran manera de aprender de replicación antes de que surjan problemas. Pruebe usted mismo esta demostración rápida. Entonces si se pueden insertar dos operaciones, pero sólo marca la primera operacion como replicada mantenimiento la segunda como activa para ser recogida por el LOG Reader.

También puede ver el video de demostración en YouTube.

Comparte y diviertete:
  • Print
  • Digg
  • StumbleUpon
  • del.icio.us
  • Facebook
  • Yahoo! Buzz
  • Twitter
  • Google Bookmarks
  • BarraPunto
  • Bitacoras.com
  • BlinkList
  • Blogosphere
  • Live
  • Meneame
  • MSN Reporter
  • MySpace
  • RSS
  • Suggest to Techmeme via Twitter
  • Technorati
  • LinkedIn
  • email
  • FriendFeed
  • PDF
  • Reddit
  • Wikio IT
  • Add to favorites
  • blogmarks
Top Footer