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.
