Partager via


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

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

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 Managed Instance

La cause Résultat Résolution recommandée
Espace de travail supprimé La mise en miroir s’arrête automatiquement et désactive le flux de modification dans Azure SQL Managed Instance Si la mise en miroir est toujours active sur Azure SQL Managed Instance, exécutez la procédure stockée suivante pour chaque base de données affectée sur votre instance managée Azure SQL : exec sp_change_feed_disable_db;
Erreurs persistantes La mise en miroir est désactivée pour la base de données affectée Pour vous assurer que vos ressources de calcul ne sont pas affectées et pour protéger votre base de données source dans Azure SQL Managed Instance, la mise en miroir est désactivée sur toutes les erreurs persistantes. Passez en revue sys.dm_change_feed_errors et résolvez les erreurs sous-jacentes avant de réactiver la base de données pour la mise en miroir.
« Les utilisateurs peuvent accéder aux données stockées dans OneLake avec des applications externes à Fabric » désactivé « Réplicateur - Les tables ne peuvent pas atteindre l’état de réplication » Activez le paramètre Locataire Les utilisateurs peuvent accéder aux données stockées dans OneLake avec des applications externes à 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. Si aucun problème n’est signalé, exécutez la procédure stockée suivante pour passer en revue la configuration actuelle de l’instance managée 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. (Les tables ne doivent pas s’asseoir trop longtemps dans les états autres que 4)

  4. Si la réplication ne fonctionne toujours pas, vérifiez que l’objet SAMI correct dispose d’autorisations (voir autorisations SAMI).

    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 d’Azure SQL Managed Instance s’affiche avec des autorisations en lecture et écriture.
    4. Vérifiez que AppId qui s’affiche correspond à l’ID du SAMI de votre instance managée Azure SQL.
  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) d’Azure SQL Managed Instance doit être activée et doit être l’identité principale.

Après l’activation, si l’état du paramètre SAMI est désactivé ou activé initialement, puis désactivé, puis activé à nouveau, la mise en miroir d’Azure SQL Managed Instance vers Fabric OneLake échoue. SAMI après la réactivation n’est pas la même identité qu’avant la désactivation. Par conséquent, vous devez accorder aux nouvelles autorisations SAMI pour accéder à l’espace de travail Fabric.

Le SAMI doit être l’identité principale. Vérifiez que SAMI est l’identité principale avec le code SQL suivant : SELECT * FROM sys.dm_server_managed_identities;

L’identité managée affectée par l’utilisateur (UAMI) n’est pas prise en charge. Si vous ajoutez un UAMI, il devient l’identité principale, en remplaçant le SAMI comme principal. Cela entraîne l’échec de la réplication. Pour résoudre les problèmes suivants :

  • Supprimez toutes les UAMIs. Vérifiez que le SAMI est activé.

Autorisations SAMI

L’identité managée affectée par le système (SAMI) d’Azure SQL Managed Instance doit disposer d’autorisations en lecture-é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 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 sur l’élément de base de données en miroir Fabric. Si vous supprimez accidentellement les autorisations, la mise en miroir d’Azure SQL Managed Instance ne fonctionnera 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 ou autorisations SAMI Azure SQL Managed Instance ne sont pas configurées correctement, procédez comme suit.

  1. Ajoutez le SAMI en tant qu’utilisateur en sélectionnant l’option ... de sélection sur l’élément d’instance managée mise en miroir.
  2. Sélectionnez l’option Gérer les autorisations .
  3. Entrez le point de terminaison public Azure SQL Managed Instance. Fournissez des autorisations de lecture et d’écriture .

Utilisation des journaux de système

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 mises en miroir Fabric à partir d’Azure SQL Managed Instance.

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

La fonctionnalité Miroir de tissu d’Azure SQL Managed Instance peut être automatiquement réensemencée dans certaines conditions, au niveau de la table individuelle ou pour l’ensemble de la base de données. Pour en savoir plus, réamorçage automatique des bases de données mises en miroir de Fabric à partir d'Azure SQL Managed Instance.