Los datos no se están entregando a los suscriptores
Si tiene la impresión de que los suscriptores no están recibiendo los datos, hay dos motivos principales:
Los datos no se están aplicando debido a los filtros, a un problema con un agente o a otro error de replicación.
Los datos se han eliminado en el suscriptor después de haberse aplicado.
Explicación
Existen una serie de motivos posibles por los que los datos no se entregan a los suscriptores:
La tabla está filtrada y no hay ningún cambio para enviar a un suscriptor determinado.
Uno o más agentes no se están ejecutando o están produciendo un error.
Se ha inicializado una suscripción transaccional sin una instantánea y se han producido cambios en el publicador desde que se creó la publicación.
La replicación de la ejecución del procedimiento almacenado de una publicación transaccional produce resultados diferentes en el suscriptor.
El procedimiento almacenado INSERT utilizado por un artículo transaccional incluye una condición que no se ha cumplido.
Los datos han sido eliminados por un usuario, un script de replicación u otra aplicación.
Los datos han sido eliminados por un desencadenador, o un desencadenador incluye una instrucción ROLLBACK.
Acción del usuario
Antes de diagnosticar el motivo por el que los datos no se entregan a los suscriptores, se recomienda que utilice la validación o la utilidad tablediff para comprobar que faltan filas:
Si se pueden ejecutar el Agente de distribución o el Agente de mezcla, determine si faltan datos ejecutando la validación de la suma de comprobación binaria. También puede utilizar la validación de número de filas, aunque este método no revela las diferencias en el contenido de los datos. Para obtener más información, vea Validar los datos replicados.
Si no se pueden ejecutar el Agente de distribución o el Agente de mezcla, determine si faltan datos ejecutando la utilidad tablediff. Para obtener información acerca de cómo usar esta utilidad en tablas de replicación, vea Cómo comparar tablas replicadas para buscar diferencias (programación de la replicación).
Buscar la causa de la pérdida de datos
Las siguientes acciones sirven para investigar las causas enumeradas en la sección "Explicación":
La tabla está filtrada y no hay ningún cambio que enviar a un suscriptor determinado.
Es posible que las filas que faltan en el suscriptor no se replicaran por no cumplir los criterios de filtrado de la publicación. Todos los tipos de replicación son compatibles con los filtros estáticos, y la replicación de mezcla también admite filtros con parámetros y filtros de combinación. Para obtener más información, vea Filtrar datos publicados. Si hay uno o más artículos de la publicación filtrados, lleve a cabo los siguientes procedimientos y compruebe el valor de la cláusula de filtro:
Filtro estático en las publicaciones de instantáneas y transaccionales: la columna filter_clause que devuelve sp_helparticle (Transact-SQL).
Filtro estático o con parámetros en las publicaciones de mezcla: la columna subset_filterclause que devuelve sp_helpmergearticle (Transact-SQL).
Filtro de combinación en las publicaciones de mezcla: la columna join_filterclause que devuelve sp_helpmergefilter (Transact-SQL).
Utilice la cláusula de filtro para determinar si alguna de las filas que falta cumple los criterios de filtrado. Por ejemplo, puede ejecutar la cláusula de filtro en la tabla del publicador y determinar si los datos devueltos coinciden con los datos en el suscriptor.
Uno o más agentes no se están ejecutando o están produciendo un error:
Si está inicializando una suscripción, asegúrese de que el Agente de instantáneas de la publicación haya finalizado antes de intentar aplicar la instantánea con el Agente de distribución o el Agente de mezcla. Si intenta aplicar la instantánea antes de que haya finalizado, se produce el siguiente error: "La instantánea inicial de la publicación '%1' todavía no está disponible".
En la replicación transaccional, asegúrese de que se están ejecutando el Agente de distribución o el Agente de registro del LOG. En la replicación de mezcla, asegúrese de que se está ejecutando el Agente de mezcla. Para obtener información acerca de estos agentes, vea Cómo iniciar y detener un agente de replicación (SQL Server Management Studio) y Conceptos de los ejecutables del Agente de replicación.
Si un agente se detiene a causa de un error, observe los detalles del error para determinar cuál es la causa subyacente. Para obtener información sobre el modo de ver los detalles del error del Agente de instantáneas y del Agente de registro del LOG, vea Cómo ver información y realizar tareas para los agentes asociados con una publicación (Monitor de replicación). Para obtener información sobre el Agente de distribución y el Agente de mezcla, vea Cómo ver información y realizar tareas para los agentes asociados a una suscripción (Monitor de replicación). Si el error se sigue produciendo, incremente el registro del agente y especifique un archivo de salida para el registro. Dependiendo del contexto del error, esto puede proporcionar los pasos que conducen al error o a mensajes de error adicionales. Para obtener más información, vea Agentes de replicación (solución de problemas).
Entre los errores comunes que hacen que los datos no se puedan entregar se incluyen problemas de permisos e infracciones de restricciones. Para obtener más información sobre los problemas de permisos, vea Problemas de seguridad impiden que los datos se repliquen. Las infracciones de restricciones impiden que las filas se inserten en el suscriptor.
En la replicación transaccional, las infracciones de restricciones se tratan como errores. De manera predeterminada, si están presentes hacen que el Agente de distribución detenga la sincronización (para obtener información sobre el modo de omitir estos errores, vea Omitir errores en la replicación transaccional). En la replicación de mezcla, las infracciones de restricciones se tratan como conflictos, pero no detienen la sincronización que realiza el Agente de mezcla. En ambos tipos de replicación, las infracciones de restricciones pueden conducir a la no convergencia de una inserción, actualización o eliminación que se haya realizado correctamente en un nodo y no se produzca en otro.
Cuando se publica una tabla, las opciones de esquema predeterminadas especifican que las restricciones de clave externa y las restricciones CHECK se deben crear en la base de datos de suscripciones con la opción NOT FOR REPLICATION establecida. Si su aplicación requiere el establecimiento de otros valores para las restricciones, cambie las opciones de esquema. Para obtener más información, vea Cómo especificar opciones de esquema (SQL Server Management Studio) y Cómo especificar opciones de esquema (programación de la replicación con Transact-SQL).
Se ha inicializado una suscripción transaccional sin una instantánea y se han producido cambios en el publicador desde que se creó la publicación:
Si habilita una publicación para que se inicialice desde una copia de seguridad, los cambios de las tablas publicadas se controlan en el registro de la base de datos de publicaciones en cuanto se crea la publicación. Cuando se inicializa una publicación, los cambios pendientes se entregan al suscriptor en el momento en que están disponibles en la base de datos de distribución.
A diferencia de lo que ocurre al inicializar desde una copia de seguridad, si inicializa una suscripción utilizando la opción replication support only, usted o la aplicación deben asegurarse de que los datos y el esquema están correctamente sincronizados en el momento de agregar la suscripción. Por ejemplo, si se produce actividad en el publicador entre el momento en que se copian los datos y el esquema en el suscriptor y el momento en que se agrega la suscripción, es posible que los cambios que resulten de dicha actividad no se repliquen en el suscriptor.
Para obtener más información, vea Inicializar una suscripción transaccional sin una instantánea.
La replicación de la ejecución del procedimiento almacenado de una publicación transaccional produce resultados diferentes en el suscriptor.
Si replica la ejecución de un procedimiento almacenado, la definición del procedimiento se replica en el suscriptor cuando se inicializa la suscripción; cuando el procedimiento se ejecuta en el publicador, la replicación ejecuta el procedimiento correspondiente en el suscriptor. Para obtener más información, vea Publicar la ejecución de procedimientos almacenados en la replicación transaccional.
Si el procedimiento almacenado realiza una acción diferente en el suscriptor o actúa en otros datos diferentes a los del publicador, se puede producir un error de convergencia. Considere la posibilidad de utilizar un procedimiento que realice un cálculo y, después, inserte datos basados en dicho cálculo. Si se aplica un filtro en el suscriptor de modo que el cálculo en el suscriptor se base en datos diferentes, puede que se inserte un resultado diferente en el suscriptor o que no se inserte ningún resultado.
El procedimiento almacenado INSERT utilizado por un artículo transaccional incluye una condición que no se ha cumplido.
De manera predeterminada, la replicación transaccional utiliza un conjunto de procedimientos almacenados para propagar los cambios a los suscriptores. También puede personalizar estos procedimientos para que incluyan la lógica de negocios que requiera su aplicación. Para obtener más información, vea Especificar cómo se propagan los cambios para los artículos transaccionales. Si el procedimiento almacenado INSERT incluye una condición en su lógica que no se ha cumplido, la inserción no se produce. Considere la posibilidad de utilizar un procedimiento que esté personalizado para comprobar un valor determinado de la tabla (tabla A) en el suscriptor antes de permitir una inserción en otra tabla (tabla B). Si el valor no está disponible en la tabla A debido a un error o porque los datos no se han replicado todavía en esta tabla, la fila esperada faltará en la tabla B.
Los datos han sido eliminados por un usuario, un script de replicación u otra aplicación:
Si desea permitir a los usuarios eliminar datos en el suscriptor, utilice la replicación de mezcla, la replicación transaccional con opciones de suscripción actualizable o la replicación transaccional de punto a punto. Las eliminaciones se propagan al publicador, de modo que los datos en el publicador y en el suscriptor finalmente convergen. Para obtener más información, vea Información general sobre la replicación de mezcla y Tipos de publicaciones para la replicación transaccional.
Si desea impedir que los usuarios eliminen datos en el suscriptor, cree un desencadenador por cada tabla que contenga la palabra ROLLBACK y utilice la opción NOT FOR REPLICATION (que impide que un desencadenador se active cuando un agente de replicación realiza una operación). Por ejemplo:
USE AdventureWorks GO CREATE TRIGGER prevent_user_dml ON Person.Address FOR INSERT, UPDATE, DELETE NOT FOR REPLICATION AS ROLLBACK
Para obtener más información, vea CREATE TRIGGER (Transact-SQL) y Controlar restricciones, identidades y desencadenadores con NOT FOR REPLICATION.
La replicación le permite ejecutar scripts antes y después de que se aplique la instantánea y durante la sincronización. Los parámetros @pre_snapshot_script y @post_snapshot_script de sp_addpublication y sp_addmergepublication permiten especificar scripts para que se ejecuten antes y después de que se aplique la instantánea. Para obtener más información, vea Ejecutar scripts antes y después de aplicar la instantánea. El procedimiento almacenado sp_addscriptexec le permite ejecutar un script durante el proceso de sincronización. Para obtener más información, vea Cómo ejecutar scripts durante la sincronización (programación de la replicación con Transact-SQL).
Estos script se suelen utilizar en tareas administrativas, por ejemplo para agregar inicios de sesión en el suscriptor. Si los scripts se utilizan para eliminar datos en el suscriptor que se deben tratar como de sólo lectura, el administrador debe asegurarse de que no se produce ninguna divergencia.
Los datos han sido eliminados por un desencadenador, o un desencadenador incluye una instrucción ROLLBACK.
Es necesario administrar correctamente los desencadenadores en el suscriptor con el fin de que no causen problemas de divergencia o de otro tipo:
Los desencadenadores sólo deben causar cambios en los datos en el suscriptor si utiliza la replicación de mezcla, la replicación transaccional con opciones de suscripción actualizable o la replicación transaccional de punto a punto. Para obtener más información, vea Información general sobre la replicación de mezcla y Tipos de publicaciones para la replicación transaccional.
En muchos casos, los desencadenadores deben utilizar la opción NOT FOR REPLICATION. Si un desencadenador incluye una instrucción ROLLBACK y no utiliza la opción NOT FOR REPLICATION, es posible que no se apliquen las filas que se replicaron en el suscriptor.
En la replicación transaccional, existen consideraciones adicionales en lo que se refiere a la configuración de XACT_ABORT y al uso de las instrucciones COMMIT y ROLLBACK en un desencadenador. Para obtener más información, vea la sección sobre los desencadenadores en el tema Consideraciones acerca de la replicación transaccional.