Compartir a través de

  • Artículo

Consideraciones acerca de la replicación transaccional

Existen diversas consideraciones respecto a la replicación transaccional:

  • Espacio para el registro de transacciones.

  • Espacio en disco para la base de datos de distribución.

  • Claves principales para cada tabla publicada.

  • Desencadenadores.

  • Tipos de datos Objetos grandes (LOB).

  • Suscripciones actualizables (si se utilizan). Para obtener más información acerca de las consideraciones de las suscripciones actualizables, vea Suscripciones actualizables para replicación transaccional.

Espacio para el registro de transacciones

Asegúrese de que el registro de transacciones tenga asignado espacio suficiente para cada base de datos que vaya a publicarse en la replicación transaccional. El registro de transacciones de una base de datos publicada puede necesitar más espacio que el registro de una base de datos idéntica sin publicar, porque los registros no se truncan hasta que mueven a la base de datos de distribución.

Si la base de datos de distribución no está disponible o el Agente de registro del LOG no está en ejecución, el registro de transacciones de una base de datos de publicaciones sigue creciendo. El registro no se puede truncar más allá de la transacción publicada más antigua que no se ha entregado a la base de datos de distribución. Se recomienda configurar el crecimiento automático del archivo de registro de transacciones para que el registro pueda adaptarse a estas circunstancias. Para obtener más información, vea CREATE DATABASE (Transact-SQL) y ALTER DATABASE (Transact-SQL).

Se recomienda que establezca la opción sync with backup en la base de datos de distribución, que retrasa el truncamiento del registro en la base de datos de publicaciones hasta que se haya hecho la copia de seguridad de las transacciones correspondientes en la base de datos de distribución. Esto puede producir un registro de transacciones mayor en la base de datos de publicaciones. Para obtener más información acerca de esta opción, vea Estrategias para hacer copias de seguridad y restaurar la replicación de instantáneas o transaccional.

Espacio en disco para la base de datos de distribución

Asegúrese de que tiene espacio en disco suficiente para almacenar las transacciones replicadas en la base de datos de distribución:

  • Si no hace que los archivos de instantánea estén disponibles inmediatamente para los suscriptores (que es el valor predeterminado), las transacciones se almacenan hasta que se hayan replicado para todos los suscriptores o hasta que se haya alcanzado el período de retención, lo que resulte más breve.

  • Si crea una publicación transaccional y hace que los archivos de instantánea estén disponibles para los suscriptores inmediatamente, las transacciones se almacenan hasta que se hayan replicado a todos los Suscriptores o hasta que se ejecute el Agente de instantáneas y cree una nueva instantánea, lo que tarde más tiempo. Si el tiempo que transcurre entre las ejecuciones del Agente de instantáneas es superior al período máximo de retención de la distribución para la publicación, que tiene un valor predeterminado de 72 horas, las transacciones más antiguas que el período de retención se quitan de la base de datos de distribución. Para obtener más información, vea Desactivación y caducidad de las suscripciones.

Aunque poner la instantánea inmediatamente a disposición de los suscriptores aumenta la velocidad con la que los suscriptores nuevos tienen acceso a la publicación, la opción puede producir un aumento del almacenamiento en disco para la base de datos de distribución. También significa que se genera una nueva instantánea cada vez que se ejecuta el Agente de instantáneas. Si no se utiliza la opción, sólo se genera una nueva instantánea si existe una nueva suscripción.

Claves principales para cada tabla publicada

Todas las tablas publicadas en la replicación transaccional deben contener una clave principal declarada. Las tablas existentes se pueden preparar para publicación agregando una clave principal con la instrucción Transact-SQLALTER TABLE (Transact-SQL).

Desencadenadores

Tenga en cuenta los siguientes problemas al utilizar desencadenadores en una base de datos de suscripciones:

  • De forma predeterminada, los desencadenadores se ejecutan con XACT_ABORT establecido en ON. Si una instrucción en un desencadenador produce un error mientras el Agente de distribución aplica cambios en el suscriptor, todo el lote de cambios tendrá errores, en vez de la instrucción individual. En la replicación transaccional, puede utilizar el parámetro -SkipErrors del Agente de distribución para omitir las instrucciones que provocan errores. Si se utiliza -SkipErrors con XACT_ABORT ON, se omite todo el lote de cambios si una instrucción produce un error. A menos que necesite establecer XACT_ABORT en ON en los desencadenadores, se recomienda que lo establezca en OFF si utiliza el parámetro -SkipErrors. Para establecer la opción en OFF, especifique SET XACT_ABORT OFF en la definición del desencadenador. Para obtener más información sobre XACT_ABORT, vea SET XACT_ABORT (Transact-SQL). Para obtener más información acerca del parámetro -SkipErrors, vea Omitir errores en la replicación transaccional.

  • Se recomienda no incluir transacciones explícitas en desencadenadores en el suscriptor. La replicación transaccional utiliza el proceso por lotes de transacciones para reducir los ciclos de ida y vuelta en la red, lo que mejora el rendimiento. Si se agregan en el suscriptor desencadenadores que incluyen instrucciones ROLLBACK, se pueden cancelar los lotes de transacciones y puede producirse el error de servidor 266 (El recuento de transacciones después de EXECUTE indica que falta una instrucción COMMIT o ROLLBACK TRANSACTION. Recuento anterior = %ld, recuento actual = %ld.). Un lote puede contener comandos de varias transacciones o formar parte de una gran transacción en el publicador, por lo que revertir transacciones puede comprometer la integridad transaccional.

    Si no incluye transacciones explícitas, asegúrese de que todas las transacciones COMMIT en un desencadenador tienen las correspondientes instrucciones BEGIN TRANSACTION. Una instrucción COMMIT sin una instrucción BEGIN TRANSACTION correspondiente provoca la aplicación no transaccional de cambios de filas en el suscriptor. Además, puede producirse un error posterior si el Agente de distribución encuentra el error de servidor 266 e intenta revertir una transacción o lote de comandos para poder aplicarlos de nuevo. Cuando el agente intenta aplicar comandos que ya se han aplicado, se producen errores de clave duplicada.

Para obtener más información sobre los desencadenadores, vea Controlar restricciones, identidades y desencadenadores con NOT FOR REPLICATION.

Tipos de datos Objetos grandes (LOB)

La replicación transaccional admite la publicación de LOB y realiza actualizaciones parciales en columnas de LOB: si una columna LOB está actualizada, sólo se replica el fragmento de los datos cambiados, en lugar de todos los datos de la columna.

Si una tabla publicada incluye cualquier LOB, piense en usar los siguientes parámetros del Agente de distribución: - UseOledbStreaming, - OledbStreamThresholdy - PacketSize. La forma más directa de establecer estos parámetros es utilizar el perfil del Agente de distribución denominado Perfil de distribución para secuencias OLEDB. Para obtener más información, vea Perfiles del Agente de replicación. Además de en este perfil predefinido, el parámetro se puede especificar en el perfil del agente que se crea o modifica, o en la línea de comandos. Para obtener más información, vea:

Tipos de datos text, ntext e image

El proceso de replicar tipos de datos text, ntext e image en una publicación transaccional está sujeto a una serie de consideraciones. Se recomienda utilizar los tipos de datos varchar(max), nvarchar(max) y varbinary(max) en vez de los tipos de datos text, ntext e image, respectivamente.

Si utiliza text, ntext o image, tenga en cuenta los siguientes aspectos:

  • Las instrucciones WRITETEXT y UPDATETEXT deben agruparse en transacciones explícitas.

  • Las operaciones de texto registradas se pueden replicar mediante WRITETEXT y UPDATETEXT con la opción WITH LOG en tablas publicadas. La opción WITH LOG es necesaria porque la replicación transaccional realiza el seguimiento de cambios en el registro de transacciones.

  • Las operaciones UPDATETEXT sólo se pueden utilizar si todos los suscriptores ejecutan SQL Server. Las operaciones WRITETEXT se replican como instrucciones UPDATE, por lo que también se pueden utilizar con suscriptores que no sean de SQL Server.

  • Un parámetro configurable, max text repl size, controla el tamaño máximo (en bytes) de los datos text, ntext, varchar(max), nvarchar(max) e image que se pueden replicar. Esto permite admitir los controladores ODBC y proveedores OLE DB, instancias de SQL Server Database Engine (Motor de base de datos de SQL Server) que no puedan controlar valores grandes de estos tipos de datos y distribuidores que tengan restricciones en recursos del sistema (memoria virtual).Cuando se publica una columna con alguno de estos tipos de datos y se ejecuta una operación INSERT, UPDATE, WRITETEXT o UPDATETEXT que sobrepasa el límite configurado, la operación produce un error.

    El uso del procedimiento almacenado del sistema sp_configure (Transact-SQL) establece el parámetro max text repl size.

  • Cuando se publican columnas text, ntext e image, el puntero de texto debe recuperarse dentro de la misma transacción que la operación UPDATETEXT o WRITETEXT (y con repetibilidad de lectura). Por ejemplo, no recupere el puntero de texto en una transacción para utilizarlo a continuación en otra. Puede haberse movido y ya no ser válido.

    Además, cuando se ha obtenido el puntero de texto, no debe realizar otras operaciones que puedan alterar la ubicación del texto al que hace referencia el puntero de texto (como actualizar la clave principal) antes de ejecutar la instrucción UPDATETEXT o WRITETEXT.

    La siguiente es la forma recomendada de utilizar las operaciones UPDATETEXT y WRITETEXT con datos que se vayan a replicar:

    1. Inicie la transacción.

    2. Obtenga el puntero de texto con la función TEXTPTR() con el nivel de aislamiento REPEATABLE READ.

    3. Utilice el puntero de texto en la operación UPDATETEXT o WRITETEXT.

    4. Confirme la transacción.

      Nota

      Si no obtiene el puntero de texto en la misma transacción, se permitirán las modificaciones en el publicador, pero los cambios no se publicarán en los suscriptores.

    Por ejemplo:

    SET TRANSACTION ISOLATION LEVEL REPEATABLE READ
BEGIN TRAN
DECLARE @mytextptr varbinary(16)
SELECT @mytextptr = textptr(Notes)
FROM Employees 
WHERE EmployeeID = '7'
IF @mytextptr IS NOT NULL 
BEGIN
UPDATETEXT Employees.Notes @mytextptr 0 NULL 'Terrific job this review period.'
-- Dummy update to fire trigger that will update metadata and ensure the update gets propagated to other Subscribers.
UPDATE Employees 
-- Set value equal to itself.
SET Notes = Notes
WHERE EmployeeID = '7' 
END
COMMIT TRAN 
SET TRANSACTION ISOLATION LEVEL READ COMMITTED

Nota

Este ejemplo se basa en la base de datos Northwind, que no se instala de forma predeterminada. Para obtener información sobre cómo instalar esta base de datos, vea bases de datos de ejemplo Northwind y pubs en el Centro de descarga de Microsoft.

Una consideración que se debe tener en cuenta al asignar el tamaño de las bases de datos de suscriptor es que el puntero de texto de las columnas text, ntext e image replicadas debe inicializarse en las tablas del suscriptor, incluso cuando no se hayan inicializado en el publicador. Por consiguiente, cada columna text, ntext e image agregada a la tabla del suscriptor por la tarea de distribución consume por lo menos 43 bytes de almacenamiento en la base de datos, incluso si está vacía.