Optimizar el rendimiento de la réplica de mezcla con seguimiento condicional de eliminaciones

En la réplica de mezcla, puede especificar que los desencadenadores de réplica y las tablas del sistema no realicen el seguimiento de las eliminaciones de uno o varios artículos. Si se especifica esta opción para un artículo, no se realiza el seguimiento ni la réplica de las eliminaciones del publicador ni de ningún suscriptor. Esta opción está disponible para admitir una serie de escenarios de aplicación y para proporcionar una optimización del rendimiento para los casos en los que la réplica 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, y las eliminaciones no se replican ni aplican en el suscriptor.

[!NOTA] Para utilizar artículos de sólo descarga, el nivel de compatibilidad de la publicación debe ser como mínimo de 90RTM. Para obtener más información, vea la sección sobre el nivel de compatibilidad para las publicaciones de mezcla en el tema Usar varias versiones de SQL Server en una topología de réplica.

La opción se puede especificar al crear una publicación, o bien se puede activar o desactivar si la aplicación requiere que algunas eliminaciones se repliquen y otras no, como las eliminaciones por lotes. En los siguientes ejemplos se ilustra de qué maneras se puede utilizar esta opción en una aplicación:

• Normalmente, una aplicación para personal de ventas móvil tiene tablas como SalesOrderHeader, SalesOrderDetail y Product. Los pedidos se pasan al suscriptor y después se replican en el publicador, que suele proporcionar los datos a un sistema de cumplimentación de pedidos. Muchos trabajadores móviles utilizan dispositivos de mano que tienen un almacenamiento limitado: una vez recibido el pedido en el publicador, dicho pedido puede eliminarse del suscriptor. La eliminación no se propaga al publicador porque el pedido sigue activo en el sistema.
  En esta situación, no se realiza el seguimiento de las eliminaciones para las tablas SalesOrderHeader y SalesOrderDetail. Se realiza el seguimiento de las eliminaciones para la tabla Product, ya que si se elimina un producto en el publicador, la eliminación debe enviarse al suscriptor para que la lista de productos se mantenga actualizada.
• Una aplicación puede almacenar datos históricos en una tabla como TransactionHistory, de la que periódicamente se purgan los registros cuya antigüedad es superior a un año. La tabla se puede filtrar para que los suscriptores reciban sólo los datos de las transacciones del mes en curso. Las eliminaciones mensuales de lotes en el publicador que purgan datos antiguos no son relevantes para los suscriptores, pero aun así se realiza un seguimiento de las mismas y se enumeran de forma predeterminada.
  En esta situación, antes de que tenga lugar el procesamiento por lotes, la actividad podría detenerse en el sistema y la aplicación podría deshabilitar el seguimiento de las eliminaciones. Una vez completado el procesamiento, el seguimiento podría volver a habilitarse.

Importante:
Si siguen llevándose a cabo otras actividades en el publicador, deberá asegurarse de que no se producen eliminaciones que se deban propagar a los suscriptores mientras el seguimiento de eliminaciones está deshabilitado.

Para especificar que no se realice el seguimiento de las eliminaciones

• Programación de la réplica con Transact-SQL: How to: Specify that Deletes Should Not Be Tracked (Replication Transact-SQL Programming)

Vea también

Conceptos

Opciones de artículos para réplica de mezcla
Optimizar el rendimiento de la réplica de mezcla con artículos de sólo descarga

Ayuda e información

Obtener ayuda sobre SQL Server 2005