Partager via

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

  • Article

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

Pour dépanner la mise en miroir configurée automatiquement pour une base de données Fabric SQL, consultez Dépannage de la mise en miroir d’une base de données Fabric SQL (préversion).

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

Cause Result Résolution recommandée
Capacité Fabric suspendue/supprimée La mise en miroir s’arrête 1. Reprenez ou affectez une capacité à partir du Portail Azure
2. Accédez à l’élément de base de données miroir Fabric. Dans la barre d’outils, sélectionnez Arrêter la réplication.
3. Démarrez la réplication en sélectionnant la Base de données miroir pour l’élément miroir dans le portail Fabric.
Capacité Fabric reprise La mise en miroir ne reprend pas 1. Accédez à l’élément de base de données miroir Fabric. Dans la barre d’outils, sélectionnez Arrêter la réplication.
2. Démarrez la réplication en sélectionnant la Base de données miroir pour l’élément miroir dans le portail Fabric.
Espace de travail supprimé La mise en miroir s’arrête automatiquement Si la mise en miroir est toujours active sur la base de données Azure SQL, exécutez la procédure stockée suivante sur votre base de données Azure SQL : exec sp_change_feed_disable_db;.
La capacité d’essai de Fabric a expiré La mise en miroir s’arrête automatiquement Consultez La capacité d’essai de Fabric arrive à expiration.
Capacité Fabric dépassée La mise en miroir sera mise en pause Attendez que l’état de surcharge soit terminé ou mettez à jour votre capacité. Pour en savoir plus, consultez la page Les actions que vous pouvez effectuer pour surmonter les situations de surcharge. La mise en miroir continuera une fois la capacité récupérée.
Toute autre erreur de ressource La mise en miroir sera désactivée Pour vous assurer que vos ressources de calcul ne sont pas affectées et réduire l’impact sur Azure SQL Database, la mise en miroir est désactivée sur toutes les erreurs de ressources persistantes.

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 de 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’existe 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 SAMI correct dispose d’autorisations.

    1. Dans le portail Fabric, sélectionnez l'option ellipses « ... » 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 du serveur logique Azure SQL s’affiche avec les autorisations lecture et écriture.
    4. Vérifiez que l’AppId qui s’affiche correspond à l’ID du SAMI de votre serveur logique Azure SQL Database.

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

Identité managée

L'identité gérée affectée par le système (SAMI) de votre serveur logique Azure SQL doit être activée et doit être l'identité principale. Pour plus d'informations, consultez Créer un serveur Azure SQL Database avec une identité gérée attribuée à l'utilisateur.

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 Database vers Fabric OneLake échoue.

Le SAMI doit être l’identité principale. Vérifiez que le SAMI est l’identité principale avec les éléments suivants : 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 ce problème :

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

Autorisations SPN

Ne supprimez pas les autorisations du contributeur du nom de principal du service (SPN) de la base de données Azure SQL sur l'élément de base mise en miroir Fabric.

Si vous supprimez accidentellement l’autorisation SPN, la mise en miroir d’Azure SQL Database ne fonctionnera pas comme prévu. Aucune nouvelle donnée ne peut être mise en miroir depuis la base de données source.

Si vous supprimez les autorisations SPN d'Azure SQL Database ou si les autorisations ne sont pas configurées correctement, procédez comme suit.

  1. Ajoutez le SPN en tant qu'utilisateur en sélectionnant l'option ... sur l'élément de la base de données mise en miroir.
  2. Sélectionnez l’option Gérer les autorisations.
  3. Entrez le nom du serveur logique de la base de données Azure SQL. Fournissez des autorisations de lecture et d’écriture.

Contenu connexe