Partager via


Mise en miroir Azure SQL Database

Mirroring dans Fabric facilite l'expérience pour éviter les opérations ETL complexes (Extraction, Transformation et Chargement) et intégrer votre patrimoine d'Azure SQL Database existant avec l'ensemble de vos autres données dans Microsoft Fabric. Vous pouvez répliquer en continu vos bases de données Azure SQL existantes directement dans OneLake de Fabric. Dans Fabric, vous pouvez déverrouiller des scénarios puissants d'informatique décisionnelle, d'intelligence artificielle, d'ingénierie des données, de science des données et de partage de données.

Pour obtenir un didacticiel sur la configuration de votre Azure SQL Database pour la mise en miroir dans Fabric, consultez Tutorial : Configurer Microsoft Fabric bases de données mises en miroir à partir de Azure SQL Database.

Pour en savoir plus et regarder des démonstrations de mise en miroir Azure SQL Database dans Fabric, regardez les Data Exposed episode suivants.

Pourquoi utiliser la mise en miroir dans Fabric ?

Avec la mise en miroir dans Fabric, vous n’avez pas besoin de regrouper différents services de plusieurs fournisseurs. Au lieu de cela, vous pouvez profiter d’un produit hautement intégré, de bout en bout et facile à utiliser qui est conçu pour simplifier vos besoins d’analyse, et conçu pour l’ouverture et la collaboration entre Microsoft, Azure SQL Database et les 1000 solutions technologiques qui peuvent lire le format de table Delta Lake open source.

Quelles expériences d’analytique sont intégrées ?

Les bases de données mises en miroir sont un élément de l’entreposage de données Fabric distinct de l’entrepôt et du point de terminaison d’analytique SQL.

Schéma du miroir de la base de données Fabric pour Azure SQL Database.

La création d’une base de données de mise en miroir crée ces éléments dans votre espace de travail Fabric :

  • Élément de base de données SQL mis en miroir. La mise en miroir gère la réplication des données dans OneLake et la conversion en Parquet, dans un format prêt pour l'analyse. Cela permet des scénarios en aval tels que l’ingénierie des données, la science des données et bien plus encore.
  • Un Serveur d'analyse SQL

Chaque Azure SQL Database mise en miroir a un point de terminaison d’analytique SQL généré automatiquement qui offre une expérience analytique enrichie sur les tables Delta créées par le processus de mise en miroir. Les utilisateurs ont accès aux commandes T-SQL familières qui peuvent définir et interroger des objets de données, mais qui ne manipulent pas les données à partir du point de terminaison d’analyse SQL, car il s’agit d’une copie en lecture seule. Vous pouvez effectuer les actions suivantes dans le point de terminaison d’analytique SQL :

  • Explorez les tables qui référencent les données de vos tables Delta Lake à partir de Azure SQL Database.
  • Créez des requêtes et des vues sans code et explorez les données de façon visuelle sans écrire une seule ligne de code.
  • Développez des vues SQL, des fonctions table-values en ligne (TVF) et des procédures stockées pour encapsuler votre sémantique et votre logique métier dans T-SQL.
  • Gérer les autorisations sur les objets.
  • Interroger des données dans des entrepôts et des Lakehouses différents dans le même espace de travail.

En plus de l'éditeur de requête SQL, Il existe un vaste écosystème d'outils qui peut interroger le point de terminaison d'analyse SQL, notamment SQL Server Management Studio (SSMS), l'extension MSSQL pour Visual Studio Code et même GitHub Copilot.

Mise en miroir de la base de données SQL Azure derrière un pare-feu

Si votre Azure SQL Database n'est pas accessible publiquement et ne permet pas aux services Azure de s'y connecter, vous pouvez configurer la passerelle de données réseau virtuelle ou la passerelle de données locale pour mettre en miroir les données. La passerelle de données facilite les connexions sécurisées à vos bases de données sources via un point de terminaison privé ou à partir d’un réseau privé approuvé. Pour plus d’informations, consultez Tutorial : Configurer Microsoft Fabric bases de données mises en miroir à partir de Azure SQL Database.

Transactions actives, charges de travail et comportements du moteur de réplication

  • Les transactions actives continuent d'empêcher la troncation du journal des transactions jusqu'à ce que la transaction soit validée et que la base de données Azure SQL en miroir rattrape son retard, ou que la transaction soit abandonnée. Les transactions de longue durée peuvent entraîner le remplissage du journal des transactions plus que d’habitude. Le journal des transactions de la base de données source doit être surveillé afin que le journal des transactions ne se remplisse pas. Pour plus d’informations, consultez le journal des transactions augmente en raison de transactions de longue durée et de CDC (capture de données changeantes).
  • Chaque charge de travail utilisateur varie. Lors de l’instantané initial, il peut y avoir davantage d’utilisation des ressources sur la base de données source, pour le processeur et les IOPS (opérations d’entrée/sortie par seconde, pour lire les pages). Les opérations de mise à jour/suppression des tables peuvent entraîner une génération de journaux accrue. Découvrez comment surveiller les ressources de votre base de données Azure SQL.

Prise en charge des modèles de palier et d’achat

La source Azure SQL Database peut être une base de données unique ou une base de données dans un pool élastique.

Pricing

Le calcul Fabric utilisé pour répliquer vos données dans Fabric OneLake est gratuit. Le stockage dans OneLake est gratuit en fonction de la taille de capacité. Pour plus d’informations, consultez Coût de la mise en miroir et tarification oneLake pour la mise en miroir. L’utilisation du calcul pour l’interrogation de données via SQL, Power BI ou Spark est toujours facturée en fonction de la capacité de l’infrastructure.

Étape suivante