Compartir a través de

Reasignación automática para las bases de datos replicadas de Fabric desde Azure SQL Managed Instance

En este artículo se describe la reutilización automática para la creación de reflejo de una base de datos en Azure SQL Managed Instance.

En determinadas condiciones, si hay un retraso en la replicación a Fabric, puede resultar en 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 e Instancia administrada de Azure SQL utiliza la funcionalidad de autosembrado que permite truncar el registro de transacciones y reinicializar el reflejo 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. Una nueva inicialización implica generar una nueva instantánea inicial de las tablas configuradas para la replicación y replicarlas hacia Microsoft Fabric. Después de la instantánea, se replican los cambios incrementales.

En Azure SQL Database y Azure SQL Managed Instance, se puede restablecer el valor de inicio a nivel de base de datos o tabla.

  • Reseed a nivel de base de datos: El reflejo continuo de datos se detiene para todas las tablas de la base de datos que están habilitadas para el reflejo, el log de transacciones se trunca y el reflejo se reinicializa para la base de datos volviendo a publicar la instantánea inicial de todas las tablas habilitadas para el reflejo. A continuación, los cambios incrementales continúan replicándose de forma continua.

  • Se ha vuelto a cambiar el nivel de tabla: La creación de reflejo continua de los datos solo se detiene para las tablas que requieren volver a usarse. El reflejo se reinicializa para las tablas afectadas mediante la republicación de la instantánea inicial. A continuación, los cambios incrementales continúan replicándose de forma continua.

Causas de la reesiembra automática a nivel de base de datos

Una reseada en el nivel de base de datos protege la disponibilidad de escritura de la base de datos asegurándose de que el registro de transacciones no crece hasta el 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 mirroring 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 al reflejo por diversas razones.

    • La latencia en el reflejo de datos desde el origen a la base de datos reflejada impide que se trunquen del registro de transacciones las transacciones pendientes de replicación.
    • No se pueden truncar las transacciones replicadas de larga duración que están esperando ser replicadas y mantienen espacio en el registro 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 está en pausa y 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 reflejo, si el espacio del archivo de registro de transacciones usado está casi lleno, se iniciará una reinicialización de la base de datos para liberar el espacio de registro ocupado.

Causas de la reseada automática de 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 reseada solo se desencadena 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 reseada

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.

Compruebe si se ha desencadenado una nueva seseada de nivel de base de datos

Si se está restableciendo toda la base de datos, considere las siguientes condiciones.

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

    • 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 desencadenado un reinicio 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