Compartir a través de

Resiembra automática para las bases de datos reflejadas de Fabric desde Azure SQL Database

En este artículo se describe la reconfiguración automática para reflejar una base de datos en Azure SQL Database.

En determinadas condiciones si hay un retraso en la creación de reflejo en Fabric, puede producirse un aumento del uso de archivos de registro de transacciones. El registro de transacciones no se puede truncar hasta que se repliquen los cambios confirmados en la base de datos reflejada. Una vez que el tamaño del registro de transacciones alcanza su límite máximo definido, se producirá un error en las escrituras en la base de datos.

Para proteger las bases de datos operativas frente a errores de escritura en transacciones OLTP críticas, el reflejo en Azure SQL Database y la Instancia Administrada de Azure SQL utiliza la funcionalidad de autoreseed que permite truncar el registro de transacciones y reinicializar el espejado de la base de datos en Fabric.

Un resemado detiene el flujo de transacciones a Microsoft Fabric desde la base de datos reflejada y reinicializa la creación de reflejo en el estado actual. Un resembrado implica generar una nueva instantánea inicial de las tablas configuradas para la replicación y replicarla a Microsoft Fabric. Después de la instantánea, se replican los cambios incrementales.

En Azure SQL Database y en Azure SQL Managed Instance, la operación de reseed puede realizarse a nivel de base de datos o a nivel de tabla.

  • Nivel de base de datos vuelto a sesear: La creación de reflejo continua de datos se detiene para todas las tablas de la base de datos que están habilitadas para la creación de reflejo, el registro de transacciones se trunca y la creación de reflejo se reinicializa para la base de datos publicando la instantánea inicial de todas las tablas habilitadas para la creación de reflejo. A continuación, los cambios incrementales reanudan la replicación de forma continua.

  • Restablecimiento a nivel de tabla: La replicación continua de datos se detiene solo para las tablas que requieren restablecimiento. La replicación se reinicia para las tablas afectadas mediante la republicación de la instantánea inicial. A continuación, los cambios incrementales reanudan la replicación de forma continua.

Causas de la reasignación automática a nivel de base de datos

Una reinicialización a nivel de base de datos protege la disponibilidad de escritura de la base de datos al asegurar que el log de transacciones no crezca hasta su tamaño máximo. El tamaño máximo del registro de transacciones se basa en el objetivo de nivel de servicio de base de datos de Azure SQL Database o Instancia administrada de Azure SQL. El uso del registro de transacciones para una base de datos habilitada para el reflejo de Fabric puede seguir creciendo y retrasar la truncación del registro. Una vez que el tamaño del registro de transacciones alcanza el límite máximo definido, se producirá un error en las escrituras en la base de datos.

  • Se ha evitado el truncamiento del registro debido a la creación de reflejos por varias razones:

    • La latencia en la replicación de datos del origen a la base de datos espejo impide que las transacciones pendientes de replicación sean eliminadas del registro de transacciones.
    • Las transacciones replicadas de larga duración pendientes de replicación no se pueden truncar, y ocupan espacio en el log de transacciones.
    • Los errores persistentes al escribir en la zona de destino de OneLake pueden impedir la replicación.

      • Este escenario puede deberse a permisos insuficientes. La creación de reflejo en Fabric usa identidad administrada asignada por el sistema (SAMI) o identidad administrada asignada por el usuario (UAMI) para escribir en la zona de aterrizaje en One Lake. Si esto no está configurado correctamente, la replicación de transacciones puede producir un error repetidamente.

        Nota:

        La compatibilidad con la identidad administrada asignada por el usuario (UAMI) está actualmente en versión preliminar.

  • Si la capacidad de Fabric se pausa y luego se reanuda, el estado de la base de datos reflejada permanece en pausa. Como resultado, los cambios realizados en el origen no se replican en OneLake. Para reanudar la creación de reflejo, vaya a la base de datos reflejada en el portal de Fabric, seleccione Reanudar replicación. La creación de reflejo continúa desde donde se ha pausado.

    Si la capacidad de Fabric permanece en pausa durante mucho tiempo, es posible que la creación de reflejo no se reanude desde su punto de detención y volverá a crear datos desde el principio. Esto se debe a que pausar la replicación durante mucho tiempo puede hacer que el uso del registro de transacciones de la base de datos de origen aumente e impida el truncamiento del registro. Cuando se reanuda el reinicio de la replicación, si el espacio del archivo de registro de transacciones usado está cerca de lleno, se iniciará un reseed de la base de datos para liberar el espacio de registro ocupado.

Causas del resembrado automático a nivel de tabla

Cuando se producen cambios de esquema en las tablas de origen habilitadas para la creación de reflejo, el esquema de esas tablas reflejadas en Fabric ya no coincide con el origen. Esto puede ocurrir debido a las siguientes ALTER TABLE instrucciones T-SQL del lenguaje de definición de datos (DDL) en el origen:

  • Agregar, quitar, modificar o cambiar nombre de columna
  • Truncar o cambiar el nombre de la tabla
  • Adición de una clave principal no agrupada

La reinicialización solo se activa para las tablas afectadas.

Diagnóstico

Para identificar si la creación de reflejo de Fabric impide el truncamiento del registro de una base de datos reflejada, compruebe la log_reuse_wait_desc columna de la vista de catálogo del sys.databases sistema para ver si el motivo es REPLICATION. Para obtener más información sobre los tipos de espera de reutilización del registro, consulte Factores que retrasan el truncamiento del registro de transacciones. Por ejemplo:

SELECT [name], log_reuse_wait_desc 
FROM sys.databases 
WHERE is_data_lake_replication_enabled = 1;

Si la consulta muestra REPLICATION el tipo de espera de reutilización del registro, debido a la creación de reflejo de Fabric, el registro de transacciones no puede vaciar las transacciones confirmadas y seguirá rellenando. Para obtener más solución de problemas de uso de registros en Azure SQL Database, consulte Solución de errores de registro de transacciones con Azure SQL Database.

Use el siguiente script de T-SQL para comprobar el espacio total del registro y el uso actual del registro y el espacio disponible:


USE <Mirrored database name>
GO 
--initialize variables
DECLARE @total_log_size bigint = 0; 
DECLARE @used_log_size bigint = 0;
DECLARE @size int;
DECLARE @max_size int;
DECLARE @growth int;

--retrieve total log space based on number of log files and growth settings for the database
DECLARE sdf CURSOR
FOR
SELECT SIZE*1.0*8192/1024/1024 AS [size in MB],
            max_size*1.0*8192/1024/1024 AS [max size in MB],
            growth
FROM sys.database_files
WHERE TYPE = 1 
OPEN sdf 
FETCH NEXT FROM sdf INTO @size,
                @max_size,
                @growth 
WHILE @@FETCH_STATUS = 0 
BEGIN
SELECT @total_log_size = @total_log_size + 
CASE @growth
        WHEN 0 THEN @size
        ELSE @max_size
END 
FETCH NEXT FROM sdf INTO @size,
              @max_size,
              @growth 
END 
CLOSE sdf;
DEALLOCATE sdf;

--current log space usage
SELECT @used_log_size = used_log_space_in_bytes*1.0/1024/1024
FROM sys.dm_db_log_space_usage;

-- log space used in percent
SELECT @used_log_size AS [used log space in MB],
       @total_log_size AS [total log space in MB],
       @used_log_size/@total_log_size AS [used log space in percentage];

Durante la resiembra

Durante la actualización, el elemento de base de datos reflejado en Microsoft Fabric está disponible, pero no recibirá cambios incrementales hasta que se complete la reseada. La reseed_state columna de sys.sp_help_change_feed_settings indica el estado de la seseada.

En La creación de reflejo del tejido, se supervisa el registro de transacciones de base de datos SQL de origen. Un autoreed solo se desencadenará cuando se cumplan las tres condiciones siguientes:

  • El registro de transacciones es más de @autoreseedthreshold un porcentaje completo, por ejemplo, 70.
  • El motivo de reutilización del registro es REPLICATION.
  • Dado que la espera de reutilización del REPLICATION registro se puede generar para otras características, como la replicación transaccional o CDC, solo se produce automáticamente cuando sys.databases.is_data_lake_replication_enabled = 1. Este valor lo configura Fabric Mirroring.

Verifique si se ha desencadenado un resembrado a nivel de base de datos

Si se vuelve a crear toda la base de datos, busque las condiciones siguientes.

  • La columna reseed_state en el procedimiento almacenado del sistema sys.sp_help_change_feed_settings de la base de datos SQL de origen indica su estado actual de reseeding.

    • 0 = Normal.
    • 1 = La base de datos ha iniciado el proceso de reinicialización en Fabric. Estado transitionary.
    • 2 = La base de datos se reinicializa en Fabric y espera a que se reinicie la replicación. Estado transitionary. Cuando se establece la replicación, el estado de la seseada se mueve a 0.

    Para obtener más información, consulte sys.sp_help_change_feed_settings.

  • Todas las tablas habilitadas para la creación de reflejo en la base de datos tendrán un valor de 7 para la state columna de sys.sp_help_change_feed_table.

    Para obtener más información, consulte sys.sp_help_change_feed_table.

Compruebe si se ha activado un resembrado a nivel de tabla.

  • Para cualquier tabla que se va a volver a usar, busque un valor de 7 para la state columna en sys.sp_help_change_feed_table.

    Para obtener más información, consulte sys.sp_help_change_feed_table.

Contenido relacionado

  • Last updated on