Configurer le réeed automatique pour les bases de données mises en miroir 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.

Il existe certaines situations où les retards de mise en miroir vers Fabric peuvent entraîner une utilisation accrue du fichier journal des transactions. Cela est dû au fait que le journal des transactions ne peut pas être tronqué tant qu’une fois les modifications validées répliquées dans la base de données mise en miroir. Une fois que la taille du journal des transactions atteint sa limite définie maximale, 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.

Une réinitialisation arrête le flux de transactions vers Microsoft Fabric à partir de la base de données mise en miroir et réinitialise la mise en miroir à l’état actuel. Cela implique la génération d’un nouvel instantané initial des tables configurées pour la mise en miroir et la réplication de celle-ci dans Microsoft Fabric. Après l’instantané, les modifications incrémentielles sont répliquées.

Pendant la réécriture, l’élément de base de données mis en miroir dans Microsoft Fabric est disponible, mais ne recevra pas de modifications incrémentielles tant que la nouvelle version n’est pas terminée. La reseed_state colonne dans sys.sp_help_change_feed_settings indique l’état reseed.

La fonctionnalité autoreseed est désactivée par défaut dans SQL Server 2025, pour l'activer, voir Enable autoreseed. La fonctionnalité autoreseed est activée et ne peut pas être gérée ou désactivée dans Azure SQL Database et Azure SQL Managed Instance.

Dans la mise en miroir fabric, le journal des transactions de base de données SQL source est surveillé. Une mise à jour automatique se déclenche uniquement lorsque les trois conditions suivantes sont remplies :

Le journal des transactions est plus de @autoreseedthreshold pourcentage complet, par exemple 70. Sur SQL Server, configurez cette valeur lorsque vous activez la fonctionnalité, avec sys.sp_change_feed_configure_parameters.
La raison de réutilisation du journal 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 fabric.

Diagnose

Pour identifier si la mise en miroir fabric empêche la troncation des journaux pour une base de données mise en miroir, vérifiez la log_reuse_wait_desc colonne dans l’affichage sys.databases catalogue système pour voir si la raison est REPLICATION. Pour plus d’informations sur les types d’attente de réutilisation des journaux, consultez Facteurs qui retardent 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 des journaux, en raison de la mise en miroir du journal des transactions, le journal des transactions ne peut pas vider les transactions validées et continuera à se remplir.

Utilisez le script T-SQL suivant pour vérifier l’espace journal total, ainsi que l’utilisation actuelle des journaux 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 l’utilisation du journal retournée par le script T-SQL précédent est proche d’être complète (par exemple, supérieure à 70%), envisagez d’activer la base de données mise en miroir pour le réeeding automatique à l’aide de la sys.sp_change_feed_configure_parameters procédure stockée système. Par exemple, pour activer le comportement autoreseed :

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 réécrit doit libérer l’espace du journal des transactions conservé par la mise en miroir. Émettez un manuel CHECKPOINT sur la base de données SQL Server source pour forcer la libération de l’espace journal si la raison de la conservation est toujours REPLICATION due à la mise en miroir. Pour plus d’informations, consultez CHECKPOINT (Transact-SQL).

Réexéché manuellement

En guise de meilleure pratique, vous pouvez tester la réécriture manuelle d’une base de données spécifique à l’aide de la procédure stockée suivante pour comprendre l’impact avant d’activer la fonctionnalité de réécriture 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éeed a été déclenché

La colonne reseed_state dans la procédure système stockée sys.sp_help_change_feed_settings sur la base de données SQL source indique son état actuel de réimplantation.
- 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 réinitialisée sur Fabric et attend le redémarrage de la réplication. État transitionnaire. Lorsque la réplication est établie, l’état reseed passe à 0.
Pour plus d’informations, consultez sys.sp_help_change_feed_settings.
Toutes les tables activées pour la réplication dans la base de données présenteront une valeur de 7 pour la colonne state dans sys.sp_help_change_feed_table.

Pour plus d’informations, consultez sys.sp_help_change_feed_table.

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2025-11-19