Configurer le reseed automatique pour les bases de données en miroir de Fabric à partir de SQL Server

Cet article traite de la réécriture automatique pour la mise en miroir d’une base de données à partir d’une instance SQL Server.

Dans certaines situations, des retards dans la mise en miroir vers Microsoft Fabric peuvent entraîner une utilisation accrue des fichiers journaux de transactions. Cette augmentation se produit parce que le journal des transactions ne peut pas être tronqué tant que les modifications validées n’ont pas été répliquées dans la base de données miroir. Une fois que la taille du journal de transaction atteint sa limite maximale définie, les écritures dans la base de données échouent. Pour protéger les bases de données opérationnelles contre les échecs d’écriture pour les transactions OLTP critiques, vous pouvez configurer un mécanisme autoreseed qui permet au journal des transactions d’être tronqué et réinitialise la mise en miroir de bases de données sur Fabric.

Un reseed arrête le flux de transactions vers Fabric depuis la base de données miroir et réinitialise le miroir à l’état actuel. Ce processus consiste à générer un nouvel instantané initial des tables configurées pour le miroir, puis à répliquer ce snapshot dans Fabric. Après l’instantané, les modifications incrémentielles sont répliquées.

Lors du reseed, l'élément de base de données miroir dans Fabric est disponible mais ne reçoit pas de modifications incrémentales tant que le reseed n'est pas terminé. La colonne reseed_state de sys.sp_help_change_feed_settings indique l’état de réamorçage.

La fonction d’autoreseed est désactivée par défaut dans SQL Server 2025. Pour l’activer, voir Activer l’auto-reseed. Dans Azure SQL Database et Azure SQL Managed Instance, cette fonctionnalité est activée, et vous ne pouvez ni la gérer ni la désactiver.

Dans la mise en miroir de Fabric, le journal des transactions de la base de données SQL source est surveillé. Un autoreseed ne se déclenche que lorsque les trois conditions suivantes sont vraies :

  • Le journal des transactions est rempli à plus de @autoreseedthreshold %, par exemple 70. Sur SQL Server, configurez cette valeur lorsque vous activez la fonctionnalité, en utilisant sys.sp_change_feed_configure_parameters.
  • Le motif de réutilisation du journal des transactions est REPLICATION.
  • Étant donné que l’attente de réutilisation du REPLICATION journal peut être déclenchée pour d’autres fonctionnalités telles que la réplication transactionnelle ou la capture de données modifiées, la réplication automatique se produit uniquement lorsque sys.databases.is_data_lake_replication_enabled = 1. Cette valeur est configurée par la mise en miroir de Fabric.

Diagnose

Pour identifier si le miroir Fabric empêche la troncature logarithmique pour une base de données miroir, vérifiez la log_reuse_wait_desc colonne dans la sys.databases vue catalogue système pour déterminer si la raison est REPLICATION. Pour plus d’informations sur les types d’attente de réutilisation du journal, consultez Facteurs retardant la troncation du journal des transactions. Par exemple:

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

Si la requête affiche REPLICATION le type d’attente de réutilisation du journal, cela signifie qu’en raison de la mise en miroir Fabric, le journal des transactions ne peut pas purger les transactions validées et continue de se remplir.

Utilisez le script T-SQL suivant pour vérifier l’espace total du journal, ainsi que l’utilisation actuelle du journal et l’espace 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];

Activer la mise à jour automatique

Si le taux d’utilisation du journal des transactions renvoyé par le script T-SQL précédent est proche d’être saturé (par exemple, supérieur à 70 %), envisagez d’activer le réensemencement automatique de la base de données en miroir à l’aide de la procédure stockée système sys.sp_change_feed_configure_parameters. Par exemple, pour activer le comportement de réensemencement automatique :

USE <Mirrored database name>
GO
EXECUTE sys.sp_change_feed_configure_parameters 
  @autoreseed = 1
, @autoreseedthreshold = 70;

Pour plus d’informations, consultez sys.sp_change_feed_configure_parameters.

Dans la base de données source, le processus de reseed doit libérer l’espace journal des transactions maintenu par le miroir. Si la raison du blocage est toujours REPLICATION due au miroir, publiez un manuel CHECKPOINT sur la base de données SQL Server source pour forcer la libération de l’espace journal. Pour plus d’informations, consultez CHECKPOINT (Transact-SQL).

Réamorçage manuel

Nous vous recommandons de tester le reseed manuel pour une base de données spécifique en utilisant la procédure stockée suivante afin de comprendre l’impact avant d’activer le reseed automatique.

USE <Mirrored database name>
GO
EXECUTE sp_change_feed_reseed_db_init @is_init_needed = 1;

Pour plus d’informations, consultez sys.sp_change_feed_reseed_db_init.

Vérifiez si un réamorçage a été déclenché

  • La colonne reseed_state de la procédure stockée système sys.sp_help_change_feed_settings dans la base de données SQL source affiche l’état actuel du réamorçage.

    • 0 = Normal.
    • 1 = La base de données a démarré le processus de réinitialisation dans Fabric. État transitionnaire.
      • 2= La base de données est en train de se réinitialiser vers Fabric et attend le redémarrage de la réplication. État transitionnaire. Lorsque la réplication est établie, l’état de re-seed devient 0.

    Pour plus d’informations, consultez sys.sp_help_change_feed_settings.

  • Toutes les tables activées pour le miroir dans la base de données ont une valeur de 7 pour la state colonne dans sys.sp_help_change_feed_table.

    Pour plus d’informations, consultez sys.sp_help_change_feed_table.

Contenu connexe

  • Last updated on