Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
En este artículo se describe que las instrucciones Update se pueden replicar como pares DELETE/INSERT.
Versión del producto original: SQL Server
Número de KB original: 238254
Resumen
Si se actualiza cualquier columna que forme parte de una restricción única, SQL Server implementa la actualización como una "actualización diferida", lo que significa como un par de DELETE/INSERT operaciones. Esta "actualización diferida" hace que la replicación envíe un par de DELETE/INSERT instrucciones a los suscriptores. También hay otras situaciones que pueden provocar una actualización diferida. Por lo tanto, cualquier lógica de negocios que implemente en UPDATE los desencadenadores o procedimientos almacenados personalizados en el suscriptor también debe incluirse en los DELETE/INSERT desencadenadores o procedimientos almacenados personalizados.
Más información
El comportamiento predeterminado en la replicación transaccional es usar los INSERTprocedimientos almacenados personalizados , UPDATEy DELETE para aplicar cambios en los suscriptores.
INSERT Las instrucciones realizadas en el publicador se aplican a los suscriptores a través de una INSERT llamada a procedimiento almacenado. De forma similar, una DELETE instrucción se aplica a través de una DELETE llamada a procedimiento almacenado.
Sin embargo, cuando una UPDATE instrucción se ejecuta como una "actualización diferida", el agente del lector de registros coloca un par de DELETE/INSERT llamadas a procedimientos almacenados en la base de datos de distribución que se aplicará a los suscriptores en lugar de a una llamada de procedimiento almacenado de actualización. Por ejemplo, supongamos que tiene una tabla de publicación, denominada TABLE1, con estas tres columnas:
- col1 int
- col2 int
- col3 varchar(30)
La única restricción única en TABLE1 se define a col1 través de una restricción de clave principal. Supongamos que tiene un registro (1,1,"Dallas").
Al ejecutar este código:
UPDATE TABLE1 set col1 = 3 where col3 = 'Dallas'
SQL Server implementa la UPDATE instrucción como un par deINSERTDELETE/instrucciones, ya que va a actualizar col1, que tiene definido un índice único. Por lo tanto, el lector de registros coloca un par de llamadas en la base de datos de DELETE/INSERT distribución. Esto puede afectar a cualquier lógica de negocios que esté presente en los desencadenadores o procedimientos almacenados personalizados en el suscriptor. Debe incorporar la lógica de negocios adicional en DELETE y INSERT desencadenadores o procedimientos almacenados para controlar esta situación.
Si prefiere replicar actualizaciones de una sola fila como UPDATE instrucciones en lugar de pares o INSERT , puede habilitar la marca de DELETE seguimiento 8207.
Además, si usa un filtro horizontal en la publicación y si la fila actualizada no cumple una condición de filtro, solo se envía una DELETE llamada de procedimiento a los suscriptores. Si la fila actualizada anteriormente no cumple la condición de filtro, pero cumple la condición después de la actualización, solo se envía la INSERT llamada al procedimiento a través del proceso de replicación.
En el ejemplo anterior, supongamos que también tiene un filtro horizontal definido en TABLE1: where col3 = 'Dallas'. Si ejecuta este código:
UPDATE table1 set col3 = 'New York' where col1 = 3
El agente de registro del log solo coloca una DELETE llamada a procedimiento almacenado que se aplicará a los suscriptores, ya que la fila actualizada no cumple los criterios de filtro horizontal.
Ahora, si ejecuta este código:
UPDATE table1 set col3 = 'Dallas' where col1 = 3
El lector de registros genera solo la INSERT llamada al procedimiento almacenado, ya que la fila no cumplan previamente la condición de filtro.
Aunque se realizó una UPDATE operación en el publicador, solo se aplican los comandos adecuados en el suscriptor.