Partager via

Réécrit automatiquement pour les bases de données mises en miroir Fabric à partir d’Azure SQL Managed Instance

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

Dans certaines conditions, la présence d’un retard dans la mise en miroir vers Fabric peut entraîner une utilisation accrue du fichier journal des transactions. 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 renouvellement peut se produire au niveau de la base de données ou de la table.

  • Réensemencement 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 la mise en miroir, le journal des transactions est tronqué, et 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 pour la mise en miroir. Ensuite, les modifications incrémentielles reprendnt la réplication continue.

  • Reseed au niveau de la table : La réplication continue des données est arrêtée uniquement pour les tables qui nécessitent un resemi. La mise en miroir est réinitialisée pour ces tables affectées en republiant 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 dans 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 le mirroring 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.

  • L'empêchement de la troncation du journal en raison de la mise en miroir peut se produire pour plusieurs raisons :

    • La latence dans la mise en miroir des données de la source vers la base de données mise en 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, occupant ainsi l'espace du journal des transactions.
    • Les erreurs d'écriture persistantes vers la zone d'atterrissage de 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 dans 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 puis reprise, l’état de la base de données 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é de l'infrastructure reste suspendue pendant une longue période, la mise en miroir risque de ne pas reprendre de son point d'arrêt initial et de réensemencer les 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 reprise, si l’espace de fichier journal des transactions utilisé est presque saturé, une resynchronisation de la base de données est initiée pour libérer l'espace 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 suivantes ALTER TABLE sur la source :

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

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 resemis

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 de la procédure système stockée sys.sp_help_change_feed_settings sur la base de données SQL source indique son état de réensemencement actuel.

    • 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 de la base de données 7 qui sont activées pour la mise en miroir auront une valeur de state dans la colonne sys.sp_help_change_feed_table.

    Pour plus d’informations, consultez sys.sp_help_change_feed_table.

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

  • Pour toute table reseeded, recherchez 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.

Contenu connexe

  • Last updated on