Compartir a través de

  • Artículo

Agrupar cambios en filas relacionadas con registros lógicos

[!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.

De manera predeterminada, la replicación de mezcla procesa los cambios de datos fila por fila. Esto es apropiado en muchos casos, pero para algunas aplicaciones, es fundamental que las filas relacionadas se procesen como una unidad. La característica de registros lógicos de la replicación de mezcla permite definir una relación entre filas relacionadas de diferentes tablas, para que las filas se procesen como una unidad.

[!NOTA]

La característica de registros lógicos se puede utilizar sola o con los filtros de combinación. Para obtener más información acerca de los filtros de combinación, vea Filtros de combinación. Para utilizar los registros lógicos, el nivel de compatibilidad de la publicación debe ser de al menos 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 replicación.

Considere estas tres tablas relacionadas:

Tres registros lógicos de tabla, sólo con los nombres de columna

La tabla Customers es la tabla primaria en esta relación y tiene una columna de clave principal, CustID. La tabla Orders tiene una columna de clave principal, OrderID, con una restricción de clave externa en la columna CustID que hace referencia a la columna CustID de la tabla Customers. De la misma forma, la tabla OrderItems tiene una columna de clave principal, OrderItemID, con una restricción de clave externa en la columna OrderID que hace referencia a la columna OrderID de la tabla Orders.

En este ejemplo, un registro lógico está formado por todas las filas de la tabla Orders relacionadas con un solo valor CustID y todas las filas de la tabla OrderItems relacionadas con esas filas en la tabla Orders. En este diagrama se muestran todas las filas de las tres tablas que se incluyen en el registro lógico para Customer2:

Tres registros lógicos de tabla con valores

Para definir una relación lógica entre artículos

Ventajas de los registros lógicos

La característica de registros lógicos tiene dos ventajas principales:

  • Los cambios de datos se aplican como una unidad.

  • Los conflictos se detectan y resuelven simultáneamente en varias filas de varias tablas.

Aplicación de cambios como una unidad

Si se utilizan registros lógicos y se interrumpe el proceso de mezcla, como ocurre en el caso de que se termine la conexión, se revierte el conjunto de cambios relacionados replicados parcialmente. Por ejemplo, considere el caso en el que un suscriptor agrega un nuevo pedido con OrderID = 6 y dos filas nuevas a la tabla OrderItems con OrderItemID = 10 y OrderItemID = 11 para OrderID = 6.

Tres registros lógicos de tabla con valores

Si no se utilizan registros lógicos y el proceso de replicación se interrumpe después de finalizar la fila Orders para OrderID = 6 pero antes de finalizar OrderItems 10 y 11, el valor de OrderTotal para OrderID = 6 no será coherente con la suma de los valores OrderAmount de las filas OrderItems. Si se utilizan registros lógicos, la fila Orders para OrderID = 6 no se confirma hasta que se repliquen los cambios de OrderItems relacionados.

En un escenario distinto, si se utilizan registros lógicos y alguien está consultando las tablas cuando el proceso de mezcla está aplicando cambios, el usuario no verá los cambios parcialmente replicados hasta que finalicen. Por ejemplo, el proceso de réplica ha cargado la fila Orders para OrderID = 6, pero un usuario consulta las tablas antes de que el proceso de replicación haya replicado las filas OrderItems. En este caso, el valor OrderTotal no será igual a la suma de los valores OrderAmount. Si se utilizan registros lógicos, la fila Orders no estará visible hasta que finalicen las filas OrderItems y la transacción se confirme como una unidad.

Aplicación del control de conflictos a más de una tabla

Considere el caso en el que dos suscriptores tienen el conjunto de datos anterior:

  • Un usuario del primer suscriptor cambia OrderAmount de OrderItemID 5 de 100 a 150 y OrderTotal de OrderID 3 de 200 a 250.

  • Un usuario del segundo suscriptor cambia OrderAmount de OrderItemID 6 de 25 a 125 y OrderTotal de OrderID 3 de 200 a 300.

Si estos cambios se replican sin utilizar registros lógicos, los diferentes valores de OrderTotal producirán un conflicto y sólo se replicará uno de ellos. Sin embargo, los cambios que no tengan conflictos en la tabla OrderItems se replicarán sin conflictos, lo que dejará los valores finales de OrderTotal en un estado incoherente respecto a las filas OrderItems. Si se utilizan registros lógicos en este escenario, también se revertirá el cambio de OrderItems asociado a la tabla Orders perdedora y el valor final de OrderTotal será un resumen exacto de las filas OrderItems.

Para obtener más información acerca de las opciones relacionadas con la detección y resolución de conflictos con registros lógicos, vea Detectar y resolver conflictos en registros lógicos.

Consideraciones para el uso de registros lógicos

Tenga en cuenta las consideraciones siguientes al utilizar registros lógicos:

Consideraciones generales

  • Se recomienda mantener el menor número de tablas posible en un registro lógico; se recomienda utilizar cinco tablas o menos.

  • Los registros lógicos no pueden hacer referencia a columnas con ninguno de los siguientes tipos de datos:

    • varchar(max) y nvarchar(max)

    • varbinary(max)

    • text y ntext

    • image

    • XML

    • UDT

  • Las relaciones de clave externa en las tablas publicadas no se pueden definir con la opción CASCADE. Para obtener más información, vea CREATE TABLE (Transact-SQL) y ALTER TABLE (Transact-SQL).

  • No puede actualizar columnas que se utilicen en una cláusula de relación lógica.

  • No se admite la resolución de conflictos personalizada con controladores de lógica de negocios o resoluciones personalizadas para los artículos incluidos en un registro lógico.

  • Si se utilizan registros lógicos en una publicación que incluye filtros con parámetros, debe inicializar cada suscripción con una instantánea para su partición. Si inicializa un suscriptor con otro método, se producirá un error en el Agente de mezcla. Para obtener más información, vea Instantáneas para publicaciones de mezcla con filtros con parámetros.

  • Los conflictos relativos a registros lógicos no se muestran en el Visor de conflictos. Para ver información acerca de esos conflictos, use los procedimientos almacenados de replicación. Para obtener más información, vea Cómo ver información de conflictos para publicaciones de mezcla (programación de la replicación con Transact-SQL).

Configuración de publicaciones

  • La publicación debe tener un nivel de compatibilidad igual o superior a 90RTM. Para obtener más información, vea la sección sobre el nivel de compatibilidad para las publicaciones en el tema Compatibilidad con versiones anteriores de replicación.

  • La publicación debe utilizar un modo de instantánea nativo. Ésta es la opción predeterminada, a menos que esté replicando en SQL Server Compact 3.5 SP1, que no admite registros lógicos.

  • La publicación no permite la sincronización Web. Para obtener más información acerca de la sincronización Web, vea Sincronización Web para la replicación de mezcla.

  • Para utilizar registros lógicos en una publicación filtrada:

  • Si la publicación utiliza filtros de combinación, debe establecer la propiedad join unique key en true para todos los filtros de combinación involucrados en relaciones de registros lógicos. Para obtener más información, vea Filtros de combinación.

Relaciones entre tablas

  • Las tablas relacionadas a través de registros lógicos deben tener una relación clave principal-clave externa.

  • No se puede establecer la opción NOT FOR REPLICATION para restricciones de clave externa. Para obtener más información acerca de esta opción, vea Controlar restricciones, identidades y desencadenadores con NOT FOR REPLICATION.

  • Las tablas secundarias sólo pueden tener una tabla primaria.

    Por ejemplo. una base de datos que realice un seguimiento de las clases y los estudiantes puede tener un diseño similar al siguiente:

    Tabla secundaria con más de una tabla primaria

    No puede utilizar un registro lógico para representar las tres tablas en esta relación, ya que las filas de ClassMembers no están asociadas con una sola fila de clave principal. Las tablas Classes y ClassMembers pueden formar un registro lógico, al igual que las tablas ClassMembers y Students, pero no las tres juntas.

  • La publicación no puede contener relaciones circulares de filtros de combinación.

    Siguiendo el ejemplo de las tablas Customers, Orders y OrderItems, no puede utilizar registros lógicos si la tabla Orders también tiene una restricción de clave externa que hace referencia a la tabla OrderItems.

Consecuencias de los registros lógicos en el rendimiento

La característica de registros lógicos tiene un costo en rendimiento. Si no se utilizan registros lógicos, el agente de replicación puede procesar todos los cambios para un artículo determinado a la vez, y como los cambios se aplican fila por fila, los requisitos de bloqueo y registro de transacciones necesarios para aplicar los cambios son mínimos.

Si se utilizan registros lógicos, el Agente de mezcla debe procesar juntos los cambios de todo el registro lógico. Esto afecta al tiempo que tarda el Agente de mezcla en replicar las filas. Además, como el agente abre una transacción distinta para cada registro lógico, los requisitos de bloqueo pueden aumentar.