Compartir a través de

Optimizar el rendimiento de la replicación de fusión con seguimiento condicional de eliminaciones

Nota:

Esta característica se quitará en una versión futura de Microsoft SQL Server. Evite utilizar esta característica en nuevos trabajos de desarrollo y tenga previsto modificar las aplicaciones que actualmente la utilizan.

Con la replicación de mezcla, puede especificar que no se debe realizar un seguimiento de las eliminaciones de uno o varios artículos mediante desencadenadores de replicación y tablas del sistema. Si especifica esta opción para un artículo, no se realiza un seguimiento de las eliminaciones ni se replican desde el publicador ni desde ningún suscriptor. Esta opción está disponible para admitir una serie de escenarios de aplicación y proporcionar una optimización del rendimiento para los casos en los que la replicación de eliminaciones no es necesaria o deseable. El rendimiento se mejora de tres maneras: los metadatos de las eliminaciones no se almacenan; las eliminaciones no se enumeran durante la sincronización; las eliminaciones no se replican ni se aplican en el Suscriptor.

Nota:

Para usar artículos de solo descarga, el nivel de compatibilidad de la publicación debe ser al menos 90RTM.

La opción se puede especificar cuando se crea una publicación o se puede activar y desactivar si una aplicación requiere que se repliquen algunas eliminaciones y que otras no se repliquen, como eliminaciones por lotes. En los ejemplos siguientes se muestran formas en las que se puede usar esta opción en una aplicación:

  • Una aplicación para una fuerza de ventas móvil normalmente tiene tablas como SalesOrderHeader, SalesOrderDetail y Product. Los pedidos se ingresan en el suscriptor y, a continuación, se replican en el publicador, que a menudo suministra datos a un sistema de cumplimiento de pedidos. Muchos trabajadores móviles usan dispositivos portátiles que tienen almacenamiento limitado: después de recibir el pedido en el publicador, se puede eliminar en el suscriptor. La eliminación no se propaga al publicador, ya que el orden sigue activo en el sistema.

    En este escenario, no se realizaría un seguimiento de las eliminaciones de las tablas SalesOrderHeader y SalesOrderDetail . Se realizaría un seguimiento de las eliminaciones de la tabla Product , ya que si se elimina un producto en el publicador, la eliminación se debe enviar al suscriptor para mantener actualizada la lista de productos.

  • Una aplicación podría almacenar datos históricos en una tabla como TransactionHistory, que se purga periódicamente de registros anteriores a un año. La tabla se podría filtrar de forma que los suscriptores solo reciban datos sobre transacciones en el mes actual. Las eliminaciones mensuales por lotes realizadas en el publicador que eliminan los datos más antiguos no son relevantes para los suscriptores, pero aún se rastrearían y enumerarían por defecto.

    En este escenario, antes de que se produjera el procesamiento por lotes, se podría detener la actividad en el sistema y la aplicación podría deshabilitar el seguimiento de eliminaciones. Una vez finalizado el procesamiento, el seguimiento podría volver a habilitarse.

Importante

Si otra actividad continúa en el publicador, debe asegurarse de que las eliminaciones que deban ser propagadas a los suscriptores no ocurran mientras el seguimiento de eliminaciones esté deshabilitado.

Para especificar que no se debe realizar un seguimiento de las eliminaciones

Véase también

Opciones de artículo para la replicación de combinación
Optimización del rendimiento de la replicación de mezcla con artículos de Download-Only

  • Last updated on