Résoudre les problèmes liés aux bases de données mises en miroir Fabric à partir d’Azure SQL Database

Cet article décrit les étapes de résolution des problèmes liés à la mise en miroir d’Azure SQL Database.

Pour résoudre les problèmes de mise en miroir automatiquement configurée pour la base de données Fabric SQL, consultez Résoudre les problèmes de mise en miroir à partir de la base de données Fabric SQL.

Modifications de la capacité de Fabric ou de l’espace de travail

Les modifications apportées à la capacité ou à l’espace de travail Fabric peuvent affecter la mise en miroir. Pour plus d’informations, examinez les effets de la mise en miroir de modifications apportées à la capacité de Fabric.

Résolution des problèmes liés à Azure SQL Database

Pour obtenir des scénarios de résolution des problèmes supplémentaires, consultez Résoudre les problèmes liés aux bases de données mises en miroir Fabric - Microsoft Fabric.

Requêtes T-SQL pour la résolution des problèmes

Si vous rencontrez des problèmes de mise en miroir, effectuez les vérifications suivantes au niveau de la base de données à l’aide des vues de gestion dynamique (DMV) et des procédures stockées pour valider la configuration.

1. Exécutez la requête suivante pour vérifier si les modifications sont correctement transmises :

   SELECT * FROM sys.dm_change_feed_log_scan_sessions;
   

2. Si le DMV sys.dm_change_feed_log_scan_sessions n’affiche aucune progression lors du traitement des modifications incrémentielles, exécutez la requête T-SQL suivante pour vérifier s’il y a des problèmes signalés :

   SELECT * FROM sys.dm_change_feed_errors;
   

3. S’il n’y a aucun problème signalé, exécutez la procédure stockée suivante pour passer en revue la configuration actuelle de la base de données Azure SQL mise en miroir. Confirmez qu'il a bien été activé.

   EXEC sp_help_change_feed;
   

   Les colonnes clés à rechercher ici sont les table_name et state. Toute valeur autre que 4 indique un problème potentiel.

4. Si la réplication ne fonctionne toujours pas, vérifiez que l’objet d’identité managée approprié dispose d’autorisations.

   1. Dans le portail Fabric, sélectionnez l’option « ... » Option de sélection sur l’élément de base de données mis en miroir.
   2. Sélectionnez l’option Gérer les autorisations .
   3. Vérifiez que le nom de l’identité managée s’affiche avec les autorisations de lecture et d'écriture.
   4. Vérifiez que AppId qui s’affiche correspond à l’ID de l’identité managée de votre serveur logique Azure SQL Database.

5. Contactez le support si un dépannage est nécessaire.

Identité managée

L’identité managée affectée par le système (SAMI) ou l’identité managée affectée par l’utilisateur (UAMI) du serveur logique Azure SQL doit être activée, et l’une d’elles doit être l’identité principale.

Vérifiez l’identité principale correcte à l’aide de la requête Transact-SQL suivante :

SELECT * FROM sys.dm_server_managed_identities;

Pour plus d’informations, consultez Créer un serveur Azure SQL Database.

Autorisations pour les identités managées

L’identité managée affectée par le système (SAMI) et l’identité managée affectée par l’utilisateur (UAMI) pour le serveur logique Azure SQL doivent disposer d’autorisations de lecture et d’écriture sur l’élément de base de données mis en miroir dans Microsoft Fabric.

Lorsque vous créez la base de données mise en miroir à partir du portail Fabric, l’autorisation est accordée automatiquement. Si vous rencontrez une erreur Unable to grant required permission to the source server. User does not have permission to reshare lors de l’installation, vérifiez que vous disposez d’un rôle membre ou administrateur dans l’espace de travail avec un privilège suffisant. Lorsque vous utilisez l’API ou CI/CD pour créer la base de données mise en miroir, veillez à accorder l’autorisation explicitement.

Ne supprimez pas les autorisations de lecture et d’écriture SAMI et/ou UAMI sur les éléments de base de données en miroir Fabric. Si vous supprimez accidentellement les autorisations, la mise en miroir d’Azure SQL Database ne fonctionne pas comme prévu. Aucune nouvelle donnée ne peut être mise en miroir à partir de la base de données source.

Si vous supprimez les autorisations SAMI et/ou UAMI Azure SQL Database, ou si les autorisations ne sont pas configurées correctement, reportez-vous aux étapes décrites dans la section du didacticiel pour la configurer.

Erreurs des autorisations obsolètes avec les connexions Microsoft Entra

Avant d’utiliser l’authentification Microsoft Entra ID, passez en revue les limitations dans les principaux serveurs de Microsoft Entra.

Les utilisateurs de base de données créés à l’aide de connexions Microsoft Entra peuvent rencontrer des retards lors de l’octroi de rôles et d’autorisations. Cela peut entraîner une erreur telle que la suivante dans le portail Fabric :

"The database cannot be mirrored to Fabric due to below error: Unable to retrieve SQL Server managed identities. A database operation failed with the following error: 'VIEW SERVER SECURITY STATE permission was denied on object 'server', database 'master'. The user does not have permission to perform this action.' VIEW SERVER SECURITY STATE permission was denied on object 'server', database 'master'. The user does not have permission to perform this action. SqlErrorNumber=300,Class=14,State=1, Activity ID: ..."

Pendant la préversion actuelle, les commandes suivantes doivent être utilisées pour résoudre ces problèmes.

• Supprimez l’utilisateur de la base de données utilisateur.
• Exécutez DBCC FREESYSTEMCACHE('TokenAndPermUserStore') pour effacer les caches de sécurité sur la base de données.
• Exécutez DBCC FLUSHAUTHCACHE pour effacer le cache de contexte d’authentification fédéré.
• Dans la base de données utilisateur, recréez l’utilisateur en fonction de la connexion.

Utilisation du journal des transactions

L’utilisation du journal des transactions pour une base de données activée pour la mise en miroir peut continuer à croître constamment 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. Pour éviter cela, la mise en miroir déclenche la réinition automatique de l’ensemble de la base de données lorsque l’espace journal utilisé dépasse un seuil d’espace journal configuré total. Pour diagnostiquer cela et en savoir plus sur le réensemencement automatique, consultez Réensemencement automatique pour les bases de données Fabric mises en miroir provenant d’Azure SQL Database.

La réexédation a démarré automatiquement

La réplication de la base de données à partir d'Azure SQL Database peut, dans certaines conditions, être réinitialisée automatiquement au niveau de la table individuelle ou pour l’ensemble de la base de données. Pour en savoir plus, réimplantation automatique pour les bases de données "Fabric" mises en miroir depuis Azure SQL Database.

Contenu connexe

• Limitations de Microsoft Fabric Data Warehouse
• FAQ sur la mise en miroir d’Azure SQL Database dans Microsoft Fabric