sql server - replicacion - Error de "error de fila no encontrado" de replicación SQL

sql server replication tables

Question

Tengo una replicación transaccional ejecutándose entre dos bases de datos. Me temo que se han desviado un poco, pero no sé qué registros se ven afectados. Si lo supiera, podría arreglarlo manualmente en el lado del suscriptor.

SQL Server me está dando este mensaje:

La fila no se encontró en el Suscriptor al aplicar el comando replicado. (Fuente: MSSQLServer, número de error: 20598)

He mirado alrededor para tratar de averiguar qué tabla, o incluso mejor, qué registro está causando el problema, pero no puedo encontrar esa información en ningún lado.

La información más detallada que he encontrado hasta ahora es:

Número de secuencia de transacción: 0x0003BB0E000001DF000600000000, ID de comando: 1

¿Pero cómo encuentro la tabla y la fila de eso? ¿Algunas ideas?

Answer 1

Cambiar el perfil a "Continuar con los errores de coherencia de datos" no siempre funcionará. Obviamente, reduce o anula un error, pero no obtendrá todos los datos correctos. Saltará las filas por las cuales ocurre un error y, por lo tanto, no obtendrá datos precisos.

Answer 2

Si su base de datos no es prohibitivamente grande, detendría la replicación, volver a realizar una instantánea y luego reiniciar la replicación. Este artículo de Technet describe los pasos.

Si se desincroniza debido a un usuario que accidentalmente cambia los datos en la réplica, establecería los permisos necesarios para evitar esto.

Vale la pena leer este artículo de replicación .

Answer 3

Responderé a mi propia pregunta con una solución alternativa que terminé usando.

Lamentablemente, no pude averiguar qué tabla estaba causando el problema a través de la interfaz de replicación de SQL Server (o el registro de eventos para el caso). Simplemente no dijo.

Entonces, lo siguiente que pensé fue, "¿Qué pasaría si pudiera hacer que la replicación continúe aunque haya un error?" Y he aquí, hay un camino. De hecho, es fácil. Hay un perfil especial del Agente de distribución llamado "Continuar con los errores de coherencia de los datos". Si habilita eso, estos tipos de errores serán registrados y transmitidos por. Una vez realizada la aplicación de las transacciones y potencialmente registrando los errores (solo encontré dos), puede volver atrás y utilizar RedGate SQL Data Compare (o alguna otra herramienta) para comparar sus dos bases de datos, realizar correcciones al suscriptor y luego iniciar la replicación ejecutándose de nuevo.

Tenga en cuenta que, para que esto funcione, su base de datos de publicaciones deberá estar "en silencio" durante la parte del proceso en la que difiere y repara la base de datos de suscriptores. Afortunadamente, tuve ese lujo en este caso.

Answer 4

por supuesto, si comprueba el error cuando falla la replicación, también le indica qué registro tiene la culpa y puede extraer esos datos del sistema central e insertarlos en el suscriptor.

Esto es mejor que omitir errores, ya que con la comparación de datos SQL bloqueará la tabla para la comparación y si tiene millones de filas, puede llevar mucho tiempo ejecutarla.

Tris

Answer 5

Utilice esta consulta para descubrir el artículo que está fuera de sincronización:

USE [distribution]

select * from dbo . MSarticles 
where article_id IN ( SELECT Article_id from MSrepl_commands 
where xact_seqno = 0x0003BB0E000001DF000600000000)

Answer 6

Esto le da la tabla que el error está en contra

use distribution
go

select * from dbo.MSarticles
where article_id in (
    select article_id from MSrepl_commands
    where xact_seqno = 0x0003BB0E000001DF000600000000)

Y esto le dará el comando (y la clave primaria (es decir, la fila) contra la que se ejecutó el comando)

exec sp_browsereplcmds 
@xact_seqno_start = ''0x0003BB0E000001DF000600000000'', 
@xact_seqno_end = ''0x0003BB0E000001DF000600000000''

Answer 7

las siguientes verificaciones resuelven mi problema

• compruebe que todos los trabajos de replicación de SQL Agents funcionen bien y, si no los inicie.
  • en mi caso fue detenido debido a una sesión asesinada ocurrida unas horas antes por algunos DBA debido a un problema de bloqueo
• después de muy poco tiempo, todos los datos en suscripción se actualizaron y ningún otro error en el monitor de replicación
• en mi caso, todas las consultas anteriores no respondieron nada

Answer 8

Por lo general, este error se produce cuando no existe un registro particular en el suscriptor y se ejecuta un comando de actualización o eliminación para el mismo registro en el servidor primario y que también se ha replicado en el suscriptor.

Como este registro no existe en el suscriptor, la replicación arroja un error "Fila no encontrada"

Solución de este error para hacer que la replicación vuelva al estado normal de ejecución:

Podemos verificar con la siguiente consulta, si la solicitud en el editor fue de actualización o declaración de eliminación:

USE [distribution]

SELECT *
FROM   msrepl_commands 
WHERE  publisher_database_id = 1
       AND command_id = 1
       AND xact_seqno = 0x00099979000038D6000100000000

Podemos obtener información artical id de la consulta anterior, que se puede pasar al siguiente proceso:

EXEC Sp_browsereplcmds
  @article_id = 813,
  @command_id = 1,
  @xact_seqno_start = ''0x00099979000038D60001'',
  @xact_seqno_end = ''0x00099979000038D60001'',
  @publisher_database_id = 1

La consulta anterior brindará información acerca de si fue una declaración de actualización o una declaración de eliminación.

1. En caso de declaración de eliminación

Ese registro se puede eliminar directamente de los objetos msrepl_commands para que la replicación no vuelva a intentar intentos para el registro

DELETE FROM msrepl_commands
WHERE  publisher_database_id = 1
       AND command_id =1
       AND xact_seqno = 0x00099979000038D6000100000000 

2. En caso de declaración de actualización:

Debe insertar ese registro de forma manual desde la base de datos del editor al PP del suscriptor: