Mise en miroir de bases de données SQL Fabric dans Microsoft Fabric (préversion)
La mise en miroir de bases de données est une fonctionnalité de Microsoft Fabric pour répliquer en continu les données de votre base de données opérationnelle dans Fabric OneLake. Grâce à la mise en miroir automatique de vos données dans Fabric, vous pouvez effectuer des recherches et des analyses combinées à d’autres données. Fabriquez un guichet unique pour vos besoins d’analyse avec un effort d’intégration de données minimal dans une solution tout-en-un.
Vue d’ensemble de la mise en miroir pour la base de données SQL dans Fabric
La base de données SQL dans Microsoft Fabric, qui utilise le même moteur de base de données SQL que Microsoft SQL Server et qui est similaire à Azure SQL Database, hérite de la plupart des fonctionnalités de mise en miroir Fabric de la base de données Azure SQL. Pour plus d’informations, consultez Mise en miroir de la base de données Azure SQL vers Fabric, mais cette page se concentre sur la mise en miroir des données de la base de données SQL dans Fabric et les différences de la mise en miroir de la base de données Azure SQL.
Lorsque vous créez une base de données SQL dans Microsoft Fabric, trois artefacts sont approvisionnés dans votre espace de travail Fabric :
- la base de données SQL elle-même
- le point de terminaison d’analytique SQL
- le modèle sémantique par défaut
Pour faciliter les scénarios d’analytique, la base de données SQL dans Fabric met automatiquement en miroir ses données dans Fabric OneLake, dans le même espace de travail que celui où réside la base de données. La mise en miroir commence lors de la création de votre base de données SQL dans Fabric sans aucune action utilisateur requise. Il n’existe aucun paramètre pour configurer la mise en miroir : toutes les tables prises en charge et leurs colonnes prises en charge sont mises en miroir dès qu’elles sont créées.
- La base de données SQL dans Fabric stocke ses données dans des fichiers .mdf, comme la base de données Azure SQL.
- Les données mises en miroir sont stockées sous forme de fichiers Parquet delta dans OneLake.
- Le point de terminaison d’analyse SQL pointe vers ces fichiers. Vous pouvez donc interroger les données mises en miroir sans que les performances de la charge de travail principale ne soient affectées par les requêtes d’analyse.
- Les données accessibles via le point de terminaison d’analyse SQL sont en lecture seule, ce qui protège la source de données opérationnelles contre les écritures ou les suppressions accidentelles.
Vous pouvez créer des vues dans votre point de terminaison d’analyse SQL pour mettre en forme la présentation des données afin de mieux répondre à vos requêtes d’analyse. Vous pouvez également rejoindre pour connecter des tables mises en miroir ou d’autres tables dans différents entrepôts ou lakehouses dans l’espace de travail. De même, avec les autorisations appropriées, les données mises en miroir dans OneLake suivent des modèles d’accès aux données d’autres données Fabric telles que des notebooks, des raccourcis, etc.
Différences entre la mise en miroir d’une base de données SQL dans Fabric et la mise en miroir d’une base de données Azure SQL Database
Pour l’essentiel, la mise en miroir d’une base de données Azure SQL Database et la mise en miroir d’une base de données SQL dans Fabric restent identiques.
| Fonction | Azure SQL Database | Base de données SQL dans Fabric |
|---|---|---|
| Configuration de la mise en miroir | L’utilisateur s’occupe de l’authentification, de la connectivité réseau et de la configuration manuelle de la mise en miroir. | La mise en miroir est automatique lors de la création. |
| Authentification lors de la configuration | La mise en miroir nécessite une connexion avec l’autorisation de base de données CONTROL. | L’authentification se fait avec des identités managées Fabric. |
| Contrôle de mise en miroir | Contrôle total par l’utilisateur | La mise en miroir est toujours activée et ne peut pas être désactivée. |
| Choix des tables à mettre en miroir | Contrôle total par l’utilisateur | Toutes les tables prises en charge sont mises en miroir sans possibilité d’ignorer des tables. |
| Limite de restauration dans le temps | PITR crée une base de données et la mise en miroir doit être reconfigurée manuellement. | PITR crée une base de données dans Fabric. La mise en miroir continue démarre automatiquement avec une capture instantanée. |
| Procédures stockées pour le contrôle et la surveillance | Autorisé | Uniquement autorisées pour la surveillance, et non pour la configuration |
| Capacité Fabric mise en pause/reprise/suppression/suppression de l’espace de travail | Intervention manuelle pour supprimer ou reprendre la mise en miroir | Automatique. Fabric suspend/reprend/supprime la mise en miroir et les données. |
| Supprimer une table | Si l’option « mettre automatiquement en miroir toutes les données » est sélectionnée, le réplica Fabric de la table est supprimé. Si les tables sont choisies manuellement, la table ne sera pas supprimée de Fabric et la table source manquante affiche une erreur sur la page de surveillance de la mise en miroir. |
Supprime les données de la table mise en miroir de Fabric OneLake. |
Effets de la mise en miroir sur les transactions et les charges de travail
Le moteur de réplication se caractérise par les comportements suivants :
- La base de données SQL dans Fabric est un produit serverless qui s’interrompt automatiquement après une période d’inactivité utilisateur. L’activité de mise en miroir n’empêche pas l’interruption de la base de données. Si la base de données s’interrompt, toute activité de mise en miroir en attente est également suspendue. La mise en miroir reprend là où elle s'était arrêtée dès la réactivation de la base de données.
- Les transactions actives conservent la troncature du journal des transactions jusqu'à ce que la transaction soit validée. Les transactions de longue durée peuvent occasionner une utilisation de la capacité du journal des transactions plus marquée que d’habitude.
- Chaque charge de travail utilisateur varie. Les opérations de mise à jour/suppression des tables peuvent entraîner une génération de journaux accrue.
- Le moteur réplicateur surveille chaque table pour les modifications indépendamment. S’il n’existe aucune mise à jour dans une table source, le moteur de réplicateur commence à se retirer avec une durée exponentiellement croissante pour cette table, jusqu’à une heure. La même chose peut se produire en cas d’erreur temporaire, ce qui empêche l’actualisation des données. Le moteur de réplicateur reprend automatiquement l’interrogation régulière après la détection des données mises à jour.
- Si vous souhaitez en savoir plus, veuillez consulter Limitations et comportements pour la mise en miroir de bases de données SQL Fabric (préversion).
Authentification et autorisation pour la base de données SQL dans Fabric
Connectez-vous à la copie répliquée des données de votre base de données SQL dans OneLake via le point de terminaison d’analytique SQL de la base de données SQL. Vous pouvez l’interroger en tant que copie dynamique et en lecture seule de vos données. Pour plus d’informations sur l’authentification, l’autorisation et la connectivité à la base de données SQL dans Fabric, consultez :
- Authentification dans une base de données SQL dans Microsoft Fabric
- Autorisation dans une base de données SQL dans Microsoft Fabric
- Liaisons privées dans Microsoft Fabric
- Se connecter à Base de données SQL dans Microsoft Fabric