Consideraciones acerca de la réplica transaccional

  • Artículo

Actualizado: 14 de abril de 2006

Existen diversas consideraciones respecto a la réplica 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 réplica 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 réplica 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 réplica 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 pone los archivos de instantáneas inmediatamente a disposición de los suscriptores (que es la opción predeterminada): las transacciones se almacenan hasta que se han replicado a todos los suscriptores o hasta que se alcanza el período de retención (de los dos procesos, el que sea más breve).
  • Si crea una publicación transaccional y pone los archivos de instantáneas inmediatamente a disposición de los suscriptores: las transacciones se almacenan hasta que se han replicado a todos los suscriptores o hasta que el Agente de instantáneas crea una nueva instantánea (de los dos procesos, el que sea más largo). 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 réplica 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-SQL ALTER 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 réplica 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 réplica transaccional.
  • Se recomienda no incluir transacciones explícitas en desencadenadores en el suscriptor. La réplica 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 réplica transaccional es compatible con la publicación de LOB y realiza actualizaciones parciales en columnas LOB: si se actualiza una columna LOB, sólo se replica el fragmento de datos cambiado, en lugar de todos los datos de la columna.

Si una tabla publicada incluye LOB, considere la posibilidad de utilizar los siguientes parámetros del Agente de distribución: -UseOledbStreaming, -OledbStreamThreshold y -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 réplica. 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 réplica 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 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 acerca de cómo instalar esta base de datos, vea Descargar las bases de datos de ejemplo Northwind y pubs.

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.

Vea también

Conceptos

Compatibilidad con versiones anteriores de réplica
Información general de la réplica transaccional
Usar varias versiones de SQL Server en una topología de réplica

Otros recursos

Consideraciones para la implementación de la réplica
Replication Distribution Agent

Ayuda e información

Obtener ayuda sobre SQL Server 2005