Partager via


Mise en miroir de SQL Server

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 SQL Server existant avec le reste de vos données dans Microsoft Fabric. Vous pouvez répliquer en continu vos bases de données SQL Server 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, consultez Tutoriel : Configurer des bases de données mises en miroir Microsoft Fabric à partir de SQL Server.

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, SQL Server 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 du point de terminaison d’analytique SQL et de l’entrepôt.

Diagramme de la mise en miroir de bases de données Fabric pour SQL Server.

La 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 base de données SQL Server 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 de SQL Server.
  • 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 avec Visual Studio Code, et même GitHub Copilot.

Environnements pris en charge

  • SQL Server 2016 - 2022

    • SQL Server sur Windows prend en charge la mise en miroir Fabric dans les éditions Standard, Entreprise et Développeur.
    • SQL Server 2017 sur Linux prend en charge le Fabric Mirroring à partir de CU18.
    • SQL Server 2019 et SQL Server 2022 sur Linux prennent en charge Fabric Mirroring.
    • Les instances SQL Server hébergées sur site, SQL Server sur une machine virtuelle Azure, SQL Server sur des clouds non-Azure prennent en charge la mise en miroir de Fabric.
  • SQL Server 2025

    • La mise en miroir de structure pour SQL Server 2025 est prise en charge pour les instances locales, actuellement non prises en charge pour les instances SQL Server 2025 s’exécutant dans une machine virtuelle Azure.
    • La mise en miroir de structure pour SQL Server 2025 n’est actuellement pas prise en charge dans SQL Server sur Linux.
    • La mise en miroir de structure pour SQL Server 2025 nécessite une connexion à Azure Arc, notamment l’extension Azure pour SQL Server. Pour plus d’informations, consultez tutoriel : Configurer la mise en miroir Microsoft Fabric à partir de SQL Server.

Mise en miroir de SQL Server derrière le pare-feu

Configurez une passerelle de données locale ou une passerelle de données de réseau virtuel 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é. Découvrez-en plus dans le didacticiel SQL Server mis en miroir et comment sécuriser les bases de données mises en miroir Microsoft Fabric à partir de SQL Server.

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 le serveur SQL Server mis 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 pour votre serveur SQL Server.

Mise en miroir de structure et groupes de disponibilité Always On

La mise en miroir de structure pour SQL Server a les comportements suivants lorsqu’il est configuré pour un groupe de disponibilité Always On :

  • En cas de basculement :
  • Si vous supprimez un nœud secondaire du groupe de disponibilité :
    • Les bases de données qui faisaient partie du groupe de disponibilité dans le nœud secondaire passent à l’état RESTORING.
    • Lorsque la base de données est récupérée en exécutant l’instruction RESTORE DATABASE WITH RECOVERY et revient en ligne, la mise en miroir est désactivée.
  • Si le groupe de disponibilité est supprimé (DROP AVAILABILITY GROUP) :
    • Si la mise en miroir est activée sur l’ancien réplica principal, la mise en miroir cesse de fonctionner, car la chaîne de connexion de l’écouteur utilisée par Fabric pour se connecter à SQL Server n’est plus valide. Rétablissez la mise en miroir en supprimant et en réactivant la base de données sur Fabric et l’instance SQL Server.
    • Pour les bases de données qui passent à l’état RESTORING, lorsque ces bases de données sont récupérées par l’instruction en cours d’exécution RESTORE DATABASE WITH RECOVERY , la mise en miroir est désactivée.
  • Ajoutez un nouveau nœud à un groupe de disponibilité existant :

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