Répliquer une instance gérée SQL d'Azure

La mise en miroir dans Fabric offre une expérience simple pour éviter les opérations ETL complexes (Extraire la charge de transformation) et intégrer votre patrimoine Azure SQL Managed Instance existant avec le reste de vos données dans Microsoft Fabric. Vous pouvez répliquer en continu vos bases de données SQL Managed Instance existantes directement dans OneLake de Fabric. À l’intérieur de Fabric, vous pouvez déverrouiller des scénarios de décisionnel puissants, 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 instance managée Azure SQL pour la mise en miroir dans Fabric, consultez tutoriel : Configurer des bases de données mises en miroir Microsoft Fabric à partir d’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 de l’entrepôt de données Fabric distinct du point de terminaison d’analytique SQL et de l’entrepôt.

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 en OneLake et la conversion en Parquet, dans un format prêt pour l’analytique. 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 point de terminaison d’analytique SQL

Chaque instance managée Azure SQL 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 des données dans vos tables Delta Lake à partir d’Azure SQL Managed Instance.
• Créez aucune requête et vues de code et explorez les données visuellement sans écrire de ligne de code.
• Développez des vues SQL, des fichiers TVF inline (Fonctions table) 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.

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, y compris SQL Server Management Studio (SSMS),l’extension mssql pour Visual Studio Code et même GitHub Copilot.

Mise en miroir d’Azure SQL Managed Instance derrière le pare-feu

Si votre instance managée Azure SQL n’est pas accessible publiquement, créez une passerelle de données de réseau virtuel ou unepasserelle de données locale pour mettre en miroir les données. Assurez-vous que le réseau du serveur de passerelle ou de réseau virtuel Azure peut se connecter à Azure SQL Managed Instance via un point de terminaison privé.

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

• Les transactions actives continuent de contenir la troncation du journal des transactions jusqu’à ce que les validations de transaction et l’instance managée Azure SQL mise en miroir rattrapent, ou que la transaction abandonne. Les transactions de longue durée peuvent entraîner le remplissage du journal des transactions plus que d’habitude. Le journal des transactions de base de données source doit être surveillé afin que le journal des transactions ne soit pas rempli. Pour plus d’informations, consultez Le journal des transactions augmente en raison de transactions de longue durée et de capture de données modifiées.
• 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. Apprenez-en davantage sur la surveillance des ressources de votre instance managée Azure SQL.

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

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

• Tous les niveaux de service du modèle d’achat vCore sont pris en charge.

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

Étape suivante

Contenu connexe

• Guide pratique pour sécuriser les bases de données mises en miroir Microsoft Fabric à partir d’Azure SQL Managed Instance
• Limites dans les bases de données en miroir de Microsoft Fabric dans Azure SQL Managed Instance
• Surveiller la réplication de base de données Managed Instance mise en miroir fabric
• Résoudre les problèmes liés aux bases de données mises en miroir Fabric à partir d’Azure SQL Managed Instance