Partager via

Mise en miroir de la base de données Azure SQL

La mise en miroir dans Fabric offre une expérience facile pour éviter les ETL (Extract Transform Load) complexes et intégrer votre domaine Azure SQL Database existant avec le reste de vos données dans Microsoft Fabric. Vous pouvez répliquer en continu vos Azure SQL Databases existantes directement dans OneLake de Fabric. Dans Fabric, vous pouvez débloquer de puissants scénarios de business intelligence, d'intelligence artificielle, d'ingénierie des données, de Science des données et de partage des données.

Pour obtenir un didacticiel sur la configuration de votre Azure SQL Database pour la mise en miroir dans Fabric, consultez Didacticiel : configurer des bases de données Microsoft Fabric mise en miroir depuis Azure SQL Database.

Pour en savoir plus et regarder des démonstrations de mise en miroir d’Azure SQL Database dans Fabric, regardez l’épisode Exposé de données suivant.

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 à partir de plusieurs fournisseurs. Au lieu de cela, vous pouvez profiter d'un produit hautement intégré, complet et simple d'utilisation, conçu pour simplifier vos besoins en matière d'analyse et pour favoriser l'ouverture et la collaboration entre Microsoft, la base de données Azure SQL et les milliers de solutions technologiques. capables de 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 dans Entrepôt de données Fabric distinct de l’Entrepôt et du point de terminaison de l’analytique SQL.

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

La mise en miroir crée trois éléments dans votre espace de travail Fabric :

  • Élément de la base de données 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’analytique. Cela permet des scénarios en aval comme l'ingénierie des données, la science des données, et plus encore.
  • Un Serveur d'analyse SQL
  • Un modèle sémantique par défaut

Chaque base de données Azure SQL mise en miroir dispose d'un point de terminaison d’analytique SQL généré automatiquement qui offre une expérience analytique riche en plus des Tables Delta créées par le processus de mise en miroir. Les utilisateurs ont accès à des commandes T-SQL familières susceptibles de définir et interroger des objets de données, mais qui ne manipulent pas les données à partir du point de terminaison d’analytique 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 dans vos tables Delta Lake à partir de la base de données Azure SQL.
  • Créez des requêtes et des vues sans code et explorez les données visuellement sans écrire une ligne de code.
  • Développez des vues SQL, des fonctions de table (TVF) en ligne, et des procédures stockées pour encapsuler vos sémantiques et logiques métiers dans le T-SQL.
  • Gérer les autorisations sur les objets.
  • Interrogez des données dans d’autres entrepôts et Lakehouses dans le même espace de travail.

Outre l’éditeur de requête SQL, il existe un vaste écosystème d’outils capables d’interroger le point de terminaison d’analytique SQL, notamment SQL Server Management Studio (SSMS), l’extension mssql avec Visual Studio Code, et même GitHub Copilot.

Mise en miroir d’Azure SQL Database derrière le pare-feu (préversion)

Si votre base de données Azure SQL n’est pas accessible publiquement et n’autorise pas les services Azure à y se connecter, vous pouvez configurer la passerelle de données de réseau virtuel 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 Tutoriel : Configurer des bases de données mises en miroir Microsoft Fabric à partir d’Azure SQL Database.

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

  • Les transactions actives continuent de conserver la troncation du journal des transactions jusqu’à ce que la transaction soit validée et que la base de données Azure SQL mise en miroir la rattrape, ou que la transaction soit abandonnée. Les transactions de longue durée peuvent avoir pour effet de remplir le 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 soit pas saturé. Pour plus d’informations, consultez Le journal des transactions augmente en raison de transactions longues et CDC.
  • Chaque charge de travail utilisateur varie. Lors de la capture instantanée initiale, l'utilisation des ressources de la base de données source peut être plus importante, tant au niveau de l'UC que des 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. En savoir plus sur la manière de surveiller les ressources de votre base de données Azure SQL.

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

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

Tarification

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é fabric.

Étape suivante

Didacticiel : configurer les bases de données mises en miroir de Microsoft Fabric depuis Azure SQL Database

Contenu connexe