Partager via

Mise en miroir d’Azure SQL Managed Instance (Préversion)

  • Article

La mise en miroir dans Fabric offre une expérience facile pour éviter les ETL (Extract Transform Load) complexes et intégrer votre infrastructure Azure SQL Managed Instance existante au reste de vos données dans Microsoft Fabric. Vous pouvez répliquer en continu vos bases de données Azure SQL Managed Instance 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 Managed Instance pour la mise en miroir dans Fabric, consultez Tutoriel : Configurer des bases de données en miroir Microsoft Fabric à partir d'Azure SQL Managed Instance (Préversion).

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, Azure SQL Managed Instance et les milliers de solutions technologiques. capables de lire le format de table Delta Lake open source.

Quelles sont les expériences d'analyse prédéfinies ?

Les bases de données en miroir sont un élément de l’instance Fabric Data Warehouse distinct de l’Entrepôt et du point de terminaison d’analytique SQL.

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

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

Chaque base de données Azure SQL Managed Instance en miroir dispose d’un point de terminaison d’analytique SQL généré automatiquement qui offre une expérience analytique enrichie 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 d’Azure SQL Managed Instance.
  • 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 TVF (Table-valued Functions) inclus 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 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), Azure Data Studio et même GitHub Copilot.

Configuration requise pour le réseau

Pendant la préversion actuelle, la mise en miroir Fabric pour Azure SQL Managed Instance exige que vous utilisiez le point de terminaison public et configuriez votre instance gérée SQL VNet pour autoriser le trafic à partir et à destination des services Azure. Vous pouvez utiliser des balises de service Power BI ou Azure Cloud pour étendre cette configuration :

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 l’instance Azure SQL Managed Instance en miroir soit à jour, 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 base de données source doit être monitoré afin que le journal des transactions ne se remplisse pas. 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. Découvrez plus d’informations sur la façon de monitorer les ressources de votre instance Azure SQL Managed Instance.
  • 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. Le même phénomène peut se produire en cas d’erreur temporaire, entraînant l'interruption de 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.

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

L’instance Azure SQL Managed Instance source peut être une instance gérée SQL unique ou une instance gérée SQL appartenant à un pool d’instances.

Étape suivante

Tutoriel : configurer des bases de données en miroir Microsoft Fabric à partir d'Azure SQL Managed Instance (Préversion)

Contenu connexe