Partager via

Mise en miroir Azure SQL Managed Instance

Mirroring dans Fabric offre une expérience simple pour éviter les opérations ETL complexes (Extraction, Transformation, Chargement) et intégrer votre environnement Azure SQL Managed Instance existant avec le reste de vos données dans l'environnement de Microsoft Fabric. Vous pouvez répliquer en continu vos bases de données SQL Managed Instance 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 Managed Instance pour la mise en miroir dans Fabric, consultez Tutorial : Configurer Microsoft Fabric bases de données mises en miroir à partir de Azure SQL Managed Instance.

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 Managed Instance 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 du Fabric Data Warehouse distinct du point de terminaison Warehouse et SQL Analytics.

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

La création d’une instance managée SQL mise en miroir crée ces éléments dans votre espace de travail Fabric :

  • Élément de base de données 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 instance managée Azure SQL mise en miroir possède un point de terminaison 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 Managed Instance.
  • 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 d'une Azure SQL Managed Instance derrière un pare-feu

Si votre Azure SQL Managed Instance n’est pas accessible publiquement, créez une passerelle de données de réseau virtuel ou passerelle de données locale pour mettre en miroir les données. Vérifiez que le réseau du serveur de passerelle ou de Azure Virtual Network peut se connecter au Azure SQL Managed Instance via a point de terminaison privé.

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

  • Les transactions actives continuent de contenir la troncature du journal des transactions jusqu'à ce que la transaction soit validée et que l'instance Azure SQL Managed mise en miroir ne soit synchronisée, 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é pour éviter qu'il 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 instance gérée Azure SQL.

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

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

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

Tutorial : Configurez Microsoft Fabric bases de données mises en miroir à partir de Azure SQL Managed Instance

Contenu connexe

  • Last updated on