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

Cet article décrit les scénarios courants, les résolutions et les solutions de contournement pour les bases de données mises en miroir Microsoft Fabric. Pour chaque source de données, passez également en revue la résolution des problèmes, les questions fréquentes (FAQ) et les limitations spécifiques.

Area	Reference
Résolution des problèmes	Mise en miroir pour Azure Cosmos DB, Azure Database pour PostgreSQL, Azure SQL Database, Azure SQL Managed Instance, Snowflake, SQL Server, Base de données SQL Fabric
Limites	Mise en miroir pour Azure Cosmos DB, Azure Database pour PostgreSQL, Azure Databricks, Azure SQL Database, Azure SQL Managed Instance, Snowflake, Google BigQuery, Oracle, SAP, SQL Server, Fabric SQL Database
Questions fréquentes (FAQ)	Mise en miroir pour Azure Cosmos DB, Azure Database pour PostgreSQL, Azure Databricks, Azure SQL Database, Azure SQL Managed Instance, Google BigQuery, SQL Server, Fabric SQL Database

Modifications apportées à la capacité fabric

Scénario	Descriptif
Capacité de l’infrastructure suspendue	La mise en miroir est arrêtée et vous ne pouvez pas répertorier ou accéder à l’élément de base de données mis en miroir. Reprendre ou réaffecter la capacité à votre espace de travail.
Capacité de l’infrastructure reprise	Lorsque la capacité est reprise à partir d’un état suspendu, l’état de la base de données mise en miroir apparaît comme 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. Notez que la capacité reste suspendue pendant une longue période, la mise en miroir peut ne pas reprendre à partir de son point d’arrêt et réinsérer les données à partir du 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. Pour réduire l’impact sur la base de données, si l’espace du journal utilisé est proche d’être plein, lorsque la mise en miroir est reprise, une réinitialisation de la base de données sera lancée pour libérer l’espace du journal retenu.
Mise à l’échelle de la capacité de l'	La mise en miroir continue. Si vous réduisez la capacité, n’oubliez pas que le stockage OneLake pour les données mises en miroir est libre jusqu’à une limite en fonction de la taille de la capacité, ce qui entraîne un scale-down de la capacité peut entraîner des frais de stockage supplémentaires. En savoir plus sur le coût de la mise en miroir.
Capacité de l’infrastructure limitée	Attendez que l’état de surcharge soit terminé ou mettez à jour votre capacité. La mise en miroir continuera une fois la capacité restaurée. En savoir plus sur les actions que vous pouvez effectuer pour récupérer à partir de situations de surcharge.
La capacité d’évaluation de l’infrastructure a expiré	La mise en miroir est arrêtée. Pour conserver votre base de données mise en miroir, achetez la capacité Fabric. En savoir plus sur la capacité d’évaluation de Fabric expire.

Les données ne semblent pas être réplicables

Si vous observez un délai dans l’apparence des données mises en miroir, vérifiez ce qui suit :

• État de la mise en miroir : Dans la page de surveillance du portail Fabric de la base de données mise en miroir, vérifiez l’état de la base de données mise en miroir et des tables spécifiques, ainsi que la colonne « Dernière exécution » qui indique la dernière fois que Fabric actualise la table mise en miroir à partir de la source. Vide signifie que la table n’est pas encore mise en miroir.

  Si vous activez la surveillance de l’espace de travail, vous pouvez également vérifier la latence d’exécution de la mise en miroir en interrogeant la ReplicatorBatchLatency valeur des journaux d’opération de base de données en miroir.

  Pour les types sources tels qu’Azure SQL Database, Azure SQL Managed Instance et Azure Database pour PostgreSQL, suivez les instructions spécifiques pour vérifier également la configuration et l’état de la base de données source.

• Données dans OneLake : La mise en miroir réplique en continu vos données dans OneLake au format de table Delta Lake. Pour vérifier si les données atterrissent correctement dans OneLake, vous pouvez créer un raccourci à partir des tables mises en miroir dans un Lakehouse, puis créer des notebooks avec des requêtes Spark pour interroger les données. En savoir plus sur Explorer avec les blocs-notes.

• Données dans le point de terminaison d’analytique SQL : Vous pouvez interroger des données mises en miroir via le point de terminaison d’analyse SQL de la base de données mise en miroir ou un Lakehouse avec un raccourci vers les données mises en miroir. Lorsque vous voyez un délai, validez l’état de mise en miroir et les données dans OneLake, comme mentionné ci-dessus. Si les données s’affichent dans OneLake, mais pas dans le point de terminaison d’analytique SQL, elles peuvent être provoquées par un retard dans la synchronisation des métadonnées dans le point de terminaison d’analyse SQL.

  Vous pouvez forcer manuellement une actualisation de l’analyse automatique des métadonnées. Dans la page du point de terminaison d’analyse SQL, sélectionnez le bouton Actualiser , comme illustré dans l’image suivante. Attendez un certain temps, puis interrogez à nouveau les données pour vérifier.

  

Arrêter la réplication

Lorsque vous sélectionnez Arrêter la réplication, les fichiers OneLake restent tels quel, mais la réplication incrémentielle s’arrête. Vous pouvez redémarrer la réplication à tout moment en sélectionnant Démarrer la réplication. Vous souhaiterez peut-être arrêter/démarrer la réplication lors de la réinitialisation de l’état de la réplication, après les modifications apportées à la base de données source ou en tant qu’outil de résolution des problèmes.

Répliquer la hiérarchie de schéma source

Lorsque vous miroirz des données provenant de différents types de bases de données sources, votre hiérarchie de schéma source est conservée dans la base de données mise en miroir. Elle garantit que vos données restent organisées de manière cohérente entre différents services, ce qui vous permet de l’utiliser à l’aide de la même logique dans le point de terminaison d’analyse SQL, les notebooks Spark, les modèles sémantiques et d’autres références aux données.

Pour les bases de données mises en miroir créées avant l’activation de cette fonctionnalité, vous voyez que le schéma source est aplatit dans la base de données mise en miroir et que le nom du schéma est encodé dans le nom de la table. Si vous souhaitez réorganiser des tables avec des schémas, recréez votre base de données mise en miroir.

Si vous utilisez l’API pour créer/mettre à jour une base de données mise en miroir, définissez la valeur de la propriété defaultSchema, qui indique s’il faut répliquer la hiérarchie de schéma à partir de la base de données source. Reportez-vous aux exemples de définition dans l’API REST publique de mise en miroir microsoft Fabric.

Prise en charge du mappage de colonnes delta

La mise en miroir prend en charge la réplication de colonnes contenant des espaces ou des caractères spéciaux dans des noms (par exemple,;{}()\n\t=) de vos bases de données sources vers les bases de données mises en miroir. En arrière-plan, la mise en miroir écrit des données dans OneLake avec le mappage de colonnes Delta activé.

Pour les tables déjà en cours de réplication avant cette fonctionnalité activée, pour inclure des colonnes avec un caractère spécial dans des noms, vous devez mettre à jour les paramètres de base de données mis en miroir en supprimant et en lisant ces tables, ou arrêter et redémarrer la base de données mise en miroir.

Prendre possession d’une base de données mise en miroir

Actuellement, la base de données mise en miroir ne prend pas en charge le changement de propriété. Si une base de données mise en miroir cesse de fonctionner, car le propriétaire de l’élément a quitté l’organisation ou qu’il n’est plus valide, vous devez recréer la base de données mise en miroir.

Régions prises en charge

La mise en miroir de bases de données et la mise en miroir ouverte sont disponibles dans toutes les régions Microsoft Fabric. Pour plus d'informations, voir Disponibilité des régions Fabric.

Troubleshoot

Cette section contient des étapes générales de résolution des problèmes de mise en miroir.

Je ne peux pas me connecter à une base de données source

1. Vérifiez que les détails de votre connexion sont corrects, le nom du serveur, le nom de la base de données, le nom d’utilisateur et le mot de passe.
2. Vérifiez que le serveur ne se trouve pas derrière un pare-feu ou un réseau virtuel privé. Ouvrez les ports de pare-feu appropriés.
   • Certaines sources mises en miroir prennent en charge la passerelle de données de réseau virtuel ou les passerelles de données locales, consultez la documentation de la source pour obtenir la prise en charge de cette fonctionnalité.

Aucune vue n’est répliquée

Actuellement, les vues ne sont pas prises en charge. Seules la réplication de tables régulières est prise en charge.

Aucune table n’est répliquée

1. Vérifiez l’état de surveillance pour vérifier l’état des tables. Pour plus d’informations, consultez Surveiller la réplication de base de données mise en miroir Fabric.
2. Sélectionnez le bouton Configurer la réplication . Vérifiez si les tables sont présentes dans la liste des tables ou si des alertes sur chaque détail de table sont présentes.

Les colonnes sont manquantes dans la table de destination

1. Sélectionnez le bouton Configurer la réplication .
2. Sélectionnez l’icône Alerte en regard du détail du tableau si aucune colonne n’est répliquée.

Certaines données de ma colonne semblent tronquées

Le point de terminaison d’analytique SQL prend en charge varchar(max) jusqu’à 16 Mo.

• La limite de 16 Mo s’applique aux tables créées après le 18 novembre 2025 dans les bases de données mises en miroir, mais chaque type d’élément mis en miroir peut avoir une limite différente et inférieure. Par exemple, SQL Server mis en miroir prend en charge jusqu’à 1 Mo et Cosmos DB prend en charge jusqu’à 2 Mo. Consultez le tableau suivant.
• Les tables existantes créées avant le 18 novembre 2025 prennent uniquement en charge varchar(8000) et doivent être recréées pour adopter un nouveau type de données et prendre en charge les données supérieures à 8 Ko.

Élément de plateforme en miroir	limite varchar(max)
Sql Server mis en miroir, Azure SQL Database, Azure SQL Managed Instance	1 Mo
Base de données SQL dans Fabric	1 Mo
Mise en miroir d’Azure Cosmos DB	2 Mo
Cosmos DB dans Fabric	2 Mo

La table/le schéma mis en miroir n’est pas supprimé lorsqu’il est supprimé dans la base de données source

Niveau de table :

• Lorsque vous choisissez de mettre en miroir une liste de tables sélectives et que la table source est supprimée, la table mise en miroir reste et vous voyez l’erreur « La table source n’existe pas » dans l’analyse. Si vous ne souhaitez plus répliquer cette table, mettez à jour la configuration de votre base de données mise en miroir et supprimez-la, la table mise en miroir sera supprimée.
• Lorsque vous choisissez de mettre en miroir toutes les données et que la table source est supprimée, la table mise en miroir est également supprimée.

Niveau de schéma : lorsque le schéma est supprimé dans la base de données source, vous voyez toujours le schéma dans le point de terminaison SQL Analytics comme schéma vide.

Je ne peux pas modifier la base de données source

La modification de la base de données source n’est pas prise en charge. Créez une base de données mise en miroir.

Limite les messages d’erreur

Ces messages d’erreur courants ont des explications et des atténuations :

Message d'erreur	Raison	Atténuation
« Le nombre de tables peut dépasser la limite, il peut y avoir des tables manquantes. »	Il existe un maximum de 500 tables.	Dans la base de données source, supprimez ou filtrez des tables. Si la nouvelle table est la 500e table, aucune atténuation n’est requise.
« La réplication est limitée et devrait continuer au niveau AAAA-MM-DDTHH :MM :ss. »	Il existe un maximum de 1 To de données modifiées capturées par base de données mise en miroir par jour.	Attendez la fin de la limitation.

Contenu connexe

• Qu’est-ce que la mise en miroir dans Fabric ?
• Surveiller la réplication mise en miroir de la base de données Fabric