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.
Si tiene uno o varios procedimientos almacenados que se ejecutan en el publicador y afectan a las tablas publicadas, considere la posibilidad de incluir esos procedimientos almacenados en la publicación como artículos de ejecución de procedimientos almacenados. La definición del procedimiento (la instrucción CREATE PROCEDURE) 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. Esto puede proporcionar un rendimiento significativamente mejor para los casos en los que se realizan operaciones por lotes grandes, ya que solo se replica la ejecución del procedimiento, pasando la necesidad de replicar los cambios individuales de cada fila. Por ejemplo, supongamos que crea el siguiente procedimiento almacenado en la base de datos de publicación:
CREATE PROC give_raise AS
UPDATE EMPLOYEES SET salary = salary * 1.10
Este procedimiento da a cada uno de los 10.000 empleados de su empresa un aumento de pago del 10 %. Al ejecutar este procedimiento almacenado en el publicador, actualiza el salario de cada empleado. Sin la replicación de la ejecución del procedimiento almacenado, la actualización se enviaría a los suscriptores como una transacción de varios pasos grande:
BEGIN TRAN
UPDATE EMPLOYEES SET salary = salary * 1.10 WHERE PK = 'emp 1'
UPDATE EMPLOYEES SET salary = salary * 1.10 WHERE PK = 'emp 2'
Y esto se repite para 10 000 actualizaciones.
Con la replicación de la ejecución del procedimiento almacenado, la replicación envía solo el comando para ejecutar el procedimiento almacenado en el suscriptor, en lugar de escribir todas las actualizaciones en la base de datos de distribución y, a continuación, enviarlos a través de la red al suscriptor:
EXEC give_raise
Importante
La replicación de procedimientos almacenados no es adecuada para todas las aplicaciones. Si un artículo se filtra horizontalmente, de modo que haya diferentes conjuntos de filas en el publicador que en el suscriptor, la ejecución del mismo procedimiento almacenado en ambos devuelve resultados diferentes. Del mismo modo, si una actualización se basa en una subconsulta de otra tabla no replicada, la ejecución del mismo procedimiento almacenado en el publicador y el suscriptor devuelve resultados diferentes.
Para publicar la ejecución de un procedimiento almacenado
SQL Server Management Studio: publicar la ejecución de un procedimiento almacenado en una publicación transaccional (SQL Server Management Studio)
Programación de Transact-SQL de replicación: ejecute sp_addarticle (Transact-SQL) y especifique un valor de "serializable proc exec" (recomendado) o "proc exec" para el parámetro @type. Para obtener más información sobre cómo definir artículos, vea Definir un artículo.
Modificación del procedimiento en el suscriptor
De forma predeterminada, la definición del procedimiento almacenado en el publicador se propaga a cada suscriptor. Sin embargo, también puede modificar el procedimiento almacenado en el Subscriber. Esto resulta útil si desea que se ejecute una lógica diferente en el publicador y el suscriptor. Por ejemplo, considere sp_big_delete, un procedimiento almacenado en el publicador que tiene dos funciones: elimina 1000 000 filas de la tabla replicada big_table1 y actualiza la tabla no replicada big_table2. Para reducir la demanda de recursos de red, debería propagar la eliminación de 1 millón de filas como un procedimiento almacenado publicando sp_big_delete. En el suscriptor, puede modificar sp_big_delete para eliminar solo los 1 millón de filas y no realizar la actualización posterior a big_table2.
Nota:
De forma predeterminada, los cambios realizados mediante ALTER PROCEDURE en el publicador se propagan al suscriptor. Para evitar esto, deshabilite la propagación de los cambios de esquema antes de ejecutar ALTER PROCEDURE. Para obtener información sobre los cambios de esquema, vea Realizar cambios de esquema en bases de datos de publicación.
Tipos de artículos de ejecución de procedimientos almacenados
Hay dos maneras diferentes de publicar la ejecución de un procedimiento almacenado: artículo de ejecución de procedimientos serializables y artículo de ejecución de procedimientos.
Se recomienda la opción serializable porque replica la ejecución del procedimiento solo si el procedimiento se ejecuta dentro del contexto de una transacción serializable. Si el procedimiento almacenado se ejecuta desde fuera de una transacción serializable, los cambios en los datos de las tablas publicadas se replican como una serie de instrucciones DML. Este comportamiento contribuye a hacer que los datos en el suscriptor sean coherentes con los datos del publicador. Esto es especialmente útil para las operaciones por lotes, como las operaciones de limpieza grandes.
Con la opción de ejecución del procedimiento, es posible que la ejecución se pueda replicar en todos los suscriptores, independientemente de si las instrucciones individuales del procedimiento almacenado se realizaron correctamente. Además, dado que los cambios realizados en los datos por el procedimiento almacenado pueden producirse en varias transacciones, es posible que los datos de los suscriptores no sean coherentes con los datos del publicador. Para abordar estos problemas, es necesario que los suscriptores sean de solo lectura y que utilice un nivel de aislamiento superior al de lectura no confirmada. Si usa read uncommitted, los cambios realizados en los datos de las tablas publicadas se replican como una serie de instrucciones DML.
En el ejemplo siguiente se muestra por qué se recomienda configurar la replicación de procedimientos como artículos de procedimientos serializables.
BEGIN TRANSACTION T1
SELECT @var = max(col1) FROM tableA
UPDATE tableA SET col2 = <value>
WHERE col1 = @var
BEGIN TRANSACTION T2
INSERT tableA VALUES <values>
COMMIT TRANSACTION T2
En el ejemplo anterior, se supone que la instrucción SELECT en la transacción T1 se produce antes de INSERTAR en la transacción T2.
Si el procedimiento no se ejecuta dentro de una transacción serializable (con el nivel de aislamiento establecido en SERIALIZABLE), la transacción T2 podrá insertar una nueva fila dentro del intervalo de la instrucción SELECT en T1 y se confirmará antes de T1. Esto también significa que se aplicará al suscriptor antes de T1. Cuando se aplica T1 en el suscriptor, el SELECT puede devolver un valor diferente al del publicador y puede resultar en un resultado diferente del UPDATE.
Si el procedimiento se ejecuta dentro de una transacción serializable, la transacción T2 no podrá insertar dentro del intervalo cubierto por la instrucción SELECT en T2. Se bloqueará hasta que T1 se comprometa a garantizar los mismos resultados en el suscriptor.
Los bloqueos se mantendrán durante más tiempo cuando ejecute el procedimiento dentro de una transacción serializable y pueden dar lugar a una reducción en la concurrencia.
Configuración de XACT_ABORT
Al replicar la ejecución del procedimiento almacenado, la configuración de la sesión que ejecuta el procedimiento almacenado debe especificar XACT_ABORT ON. Si XACT_ABORT se establece en OFF y se produce un error durante la ejecución del procedimiento en el publicador, se producirá el mismo error en el suscriptor, lo que provocará un error en el Agente de distribución. Especificar XACT_ABORT ON garantiza que los errores detectados durante la ejecución en el Editor hacen que se revierta toda la ejecución, evitando el fallo del Agente de Distribución. Para obtener más información sobre cómo establecer XACT_ABORT, vea SET XACT_ABORT (Transact-SQL).
Si necesita una configuración de XACT_ABORT OFF, especifique el parámetro -SkipErrors para el Agente de distribución. Esto permite al agente seguir aplicando los cambios en el suscriptor incluso si se produce un error.