Partager via

Réensemencement automatique pour les bases de données mises en miroir dans Fabric à partir d'Azure SQL Database

Cet article traite de la réécriture automatique pour la mise en miroir d’une base de données dans Azure SQL Database.

Une utilisation accrue du fichier journal des transactions peut résulter d’un retard de la mise en miroir vers Fabric dans certaines conditions. 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, la mise en miroir dans Azure SQL Database et Azure SQL Managed Instance utilise la fonctionnalité autoreseed qui permet au journal des transactions d’être tronqué et réinitialise la mise en miroir de bases de données vers 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. Un réécriture 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.

Dans Azure SQL Database et Azure SQL Managed Instance, le reseed peut se produire au niveau de la base de données ou au niveau de la table.

  • Réamorçage au niveau de la base de données : La mise en miroir continue des données est arrêtée pour toutes les tables de la base de données activées pour cette fonction, le journal des transactions est tronqué, puis la mise en miroir est réinitialisée pour la base de données en republier l’instantané initial de toutes les tables activées. Ensuite, les modifications incrémentielles reprendnt la réplication continue.

  • Reseed au niveau de la table : La mise en miroir continue des données est arrêtée uniquement pour les tables qui nécessitent un resemis. La mise en miroir est réinitialisée pour ces tables affectées en republiaint l’instantané initial. Ensuite, les modifications incrémentielles reprendnt la réplication continue.

Causes de la réécriture automatique au niveau de la base de données

Une réinitialisation au niveau de la base de données protège la disponibilité des écritures de la base de données en garantissant que le journal des transactions ne dépasse pas la taille maximale. La taille maximale du journal des transactions est basée sur l’objectif de niveau de service de base de données d’Azure SQL Database ou d’Azure SQL Managed Instance. L’utilisation du journal des transactions pour une base de données activée pour la mise en miroir de Fabric peut continuer à croître et à empêcher la troncation du journal. Une fois que la taille du journal des transactions atteint la limite maximale définie, les écritures dans la base de données échouent.

  • La troncation du journal empêchée en raison de la mise en miroir peut se produire pour plusieurs raisons :

    • La latence de la mise en miroir des données entre la source et la base de données miroir empêche les transactions en attente de réplication d’être supprimées du journal des transactions.
    • Les transactions répliquées de longue durée en attente de réplication ne peuvent pas être tronquées, ce qui maintient l'espace du journal de transaction.
    • Les erreurs d'écriture persistantes de la zone d'atterrissage dans OneLake peuvent empêcher la réplication.

      • Ce scénario peut être dû à des autorisations insuffisantes. La mise en miroir vers Fabric utilise l’identité managée affectée par le système (SAMI) ou l’identité managée affectée par l’utilisateur (UAMI) pour écrire dans la zone d’atterrissage de One Lake. S’il n’est pas configuré correctement, la réplication des transactions peut échouer à plusieurs reprises.

        Note

        La prise en charge de l’identité managée affectée par l’utilisateur (UAMI) est actuellement en préversion.

  • Si la capacité du fabric est suspendue et reprise, l’état de la base de données mise en miroir reste suspendu. Par conséquent, les modifications apportées dans la source ne sont pas répliquées sur OneLake. Pour reprendre la mise en miroir, accédez à la base de données mise en miroir dans le portail Fabric, sélectionnez Reprendre la réplication. La mise en miroir continue de l’endroit où elle a été suspendue.

    Si la capacité du Fabric reste suspendue pendant une longue période, la mise en miroir peut ne pas reprendre à partir de son point d’arrêt et redémarrer le transfert de données depuis le début. Cela est dû au fait que la suspension de la mise en miroir pendant une longue période peut entraîner une augmentation de l'utilisation du journal des transactions de la base de données source et empêcher la troncation du journal. Lorsque la mise en miroir est réactivée, si l’espace de fichier journal des transactions utilisé est proche de la saturation, une nouvelle synchronisation de la base de données sera lancée pour libérer l’espace du journal retenu.

Causes de la réécriture automatique au niveau de la table

Lorsque des modifications de schéma se produisent sur les tables sources activées pour la mise en miroir, le schéma de ces tables mises en miroir dans Fabric ne correspond plus à la source. Cela peut se produire en raison des instructions de langage de définition de données (DDL) T-SQL ALTER TABLE sur la source :

  • Ajouter/supprimer/modifier/renommer une colonne
  • Tronquer/renommer une table
  • Ajouter une clé primaire non cluster

Reseed est déclenché uniquement pour les tables affectées.

Diagnostiquer

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. Pour plus d’informations sur la résolution des problèmes d’utilisation des journaux dans Azure SQL Database, consultez Résoudre les erreurs de journal des transactions avec Azure SQL Database.

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];

Pendant le réamorçage

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.

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.
  • 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.

Vérifier si un réécriture au niveau de la base de données a été déclenché

Si l'intégralité de la base de données est réinitialisée, recherchez les conditions suivantes.

  • 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.

Vérifiez si un réensemencement au niveau de la table a été déclenché

  • Pour toute table réensemencée, recherchez une valeur 7 dans la colonne state de sys.sp_help_change_feed_table.

    Pour plus d’informations, consultez sys.sp_help_change_feed_table.

Contenu connexe

  • Last updated on