Partager via

Limitations dans les bases de données mises en miroir Microsoft Fabric à partir de SQL Server

Les limitations actuelles dans les bases de données mises en miroir Microsoft Fabric à partir de SQL Server sont répertoriées dans cette page. Cette page est susceptible d’être modifiée.

Pour résoudre les problèmes, voir :

Limitations de la plateforme

  • La mise en miroir de structure pour SQL Server 2025 n’est actuellement pas prise 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.

Limitations au niveau de la base de données

  • La mise en miroir Fabric pour SQL Server n'est prise en charge que sur une base de données principale d'un groupe de disponibilité.

    • La mise en miroir de structure n’est actuellement pas prise en charge sur une instance de cluster de basculement.

  • La base de données SQL Server ne peut pas être mise en miroir si la base de données a déjà été configurée pour Azure Synapse Link pour SQL ou si la base de données est déjà mise en miroir dans un autre espace de travail Fabric.

    • Une base de données dans une instance SQL Server 2025 ne peut pas être mise en miroir si la capture de données modifiées (CDC) est activée sur la base de données source.

  • Le nombre maximal de tables pouvant être mises en miroir dans Fabric est de 500 tables. Aucune table au-dessus de la limite de 500 ne peut actuellement être répliquée.

    • Si vous sélectionnez Mettre en miroir toutes les données lors de la configuration de la mise en miroir, les tables à mettre en miroir sont les 500 premières tables lorsque toutes les tables sont triées par ordre alphabétique en fonction du nom du schéma, puis du nom de la table. Les tables restantes au bas de la liste alphabétique ne sont pas mises en miroir.
    • Si vous désélectionnez mettre en miroir toutes les données et sélectionnez des tables individuelles, vous ne pouvez pas sélectionner plus de 500 tables.

  • .dacpac les déploiements vers SQL Server nécessitent la propriété /p:DoNotAlterReplicatedObjects=False de publication pour permettre les modifications apportées à toutes les tables mises en miroir. Pour plus d’informations sur les paramètres de publication disponibles pour les déploiements .dacpac, consultez la documentation de publication SqlPackage.

  • La mise en miroir de structure à partir de SQL Server 2025 n’est pas prise en charge lorsque les fonctionnalités suivantes sont activées :

  • Une base de données SQL Server ne peut pas être mise en miroir si la durabilité différée des transactions est activée pour la base de données.

Autorisations dans la base de données source

  • La sécurité au niveau des lignes est prise en charge, mais les autorisations ne sont actuellement pas propagées aux données répliquées dans Fabric OneLake.
  • Les autorisations au niveau de l’objet, par exemple l’octroi d’autorisations à certaines colonnes, ne sont actuellement pas propagées aux données répliquées dans Fabric OneLake.
  • Les paramètres de masquage des données dynamiques ne sont actuellement pas propagés aux données répliquées dans Fabric OneLake.
  • Pour configurer la mise en miroir pour SQL Server, le principal utilisé pour se connecter au serveur SQL Server source doit recevoir l’autorisation ALTER ANY EXTERNAL MIRROR, qui est incluse dans l’autorisation de niveau supérieur, comme l’autorisation CONTROL ou le rôle db_owner .

Sécurité des réseaux et de la connectivité

  • Les autorisations de contributeur pour le nom de principal du service SQL Server ne doivent pas être supprimées de l'élément de base de données en miroir Fabric.
  • La mise en miroir entre les locataires Microsoft Entra n’est pas prise en charge lorsqu’une instance SQL Server et l’espace de travail Fabric se trouvent dans des locataires distincts. 
  • Les étiquettes Microsoft Purview Information Protection/étiquettes de sensibilité définies dans SQL Server ne sont pas propagées et reflétées dans Fabric OneLake.

Niveau de table

  • Les tables avec clé primaire ou un index cluster (lorsqu’une clé primaire n’existe pas) sur des types non pris en charge ne peuvent pas être mises en miroir : colonnes calculées, types définis par l’utilisateur, géométrie, géographie, ID de hiérarchie, variante SQL, timestamp, datetime2(7), datetimeoffset(7) ou time(7).

  • Lors de la mise en miroir de SQL Server 2016 à l’aide de SQL Server 2022, une table ne peut pas être mise en miroir si elle n’a pas de clé primaire.

  • Delta Lake ne prend en charge que six chiffres de précision.

    • Les colonnes de type SQL datetime2, avec une précision de sept chiffres fractionnaires pour les secondes, n’ont pas de type de données équivalent offrant la même précision dans les fichiers Delta de Fabric OneLake. Si des colonnes de ce type sont mises en miroir, une perte de précision se produit, et le septième chiffre décimal de la seconde est supprimé.
    • Le type de données datetimeoffset(7) n’a pas de type de données équivalent offrant la même précision dans les fichiers Delta dans Fabric OneLake. Une perte de précision (perte du fuseau horaire et du septième chiffre décimal des secondes) se produit si des colonnes de ce type sont en miroir.

  • Les index columnstore en cluster ne sont actuellement pas pris en charge.

  • Si une ou plusieurs colonnes de la table sont de type Grand objet binaire (LOB) avec une taille > 1 Mo, les données de la colonne sont tronquées à la taille de 1 Mo dans Fabric OneLake.

  • Les tables sources pour lesquelles l'une des caractéristiques suivantes est utilisée ne peuvent pas être mises en miroir.

    • Tables d’historique temporel et tables d’historique du registre
    • Toujours Chiffré
    • Tables en mémoire
    • Graph
    • Tables externes

  • Les opérations de langage de définition de données (DDL) de niveau table suivantes ne sont pas autorisées sur les tables sources de base de données SQL lorsqu’elles sont activées pour la mise en miroir.

    • Basculer/fractionner/fusionner une partition
    • Modifier la clé primaire

  • Lorsqu’il existe une modification DDL, une instantané de données complète est redémarrée pour la table modifiée et les données sont réexédées.

  • Actuellement, une table ne peut pas être mise en miroir si elle a le type de données json ou vector .

    • Actuellement, vous ne pouvez pas modifier une colonne vers le type de données vector ou json lorsqu’une table est mise en miroir.

Au niveau des colonnes

  • La mise en miroir de structure à partir de SQL Server ne réplique pas les types de données suivants :
    • CLR
    • vector
    • json
    • geometry
    • geography
    • hierarchyid
    • sql_variant
    • horodatage/rowversion
    • xml
    • Types définis par l’utilisateur (UDT)
    • image
    • texte/ntexte
  • Si la table source contient des colonnes calculées, ces colonnes ne peuvent pas être mises en miroir sur la Fabric OneLake. 
  • La mise en miroir prend en charge la réplication de colonnes contenant des espaces ou des caractères spéciaux dans des noms (tels que ,;{}()\n\t=). Pour les tables sous réplication avant que cette fonctionnalité soit activée, vous devez mettre à jour les paramètres de base de données mis en miroir ou redémarrer la mise en miroir pour inclure ces colonnes. En savoir plus sur la Prise en charge du mappage de colonnes Delta.

Limitations de l’entrepôt

  • La hiérarchie de schéma source est répliquée dans la base de données mise en miroir. Pour les bases de données mises en miroir créées avant l’activation de cette fonctionnalité, le schéma source est aplatit et le nom du schéma est encodé dans le nom de la table. Si vous souhaitez réorganiser des tables avec des schémas, recréez votre base de données mise en miroir. En savoir plus sur la hiérarchie de schémas source de réplication.

Limitations des éléments en miroir

  • L’utilisateur doit être membre du rôle Administration/membre de l’espace de travail pour créer la mise en miroir de bases de données SQL. 
  • L’arrêt de la mise en miroir désactive complètement la mise en miroir. 
  • Le démarrage de la mise en miroir réalimente toutes les tables, ce qui revient à repartir de zéro. 

Limitations du point de terminaison analytique SQL

Régions prises en charge

La mise en miroir de bases de données et la mise en miroir ouverte sont disponibles dans toutes les régions Microsoft Fabric. Pour plus d'informations, voir Disponibilité des régions Fabric.

Étape suivante

Tutoriel : Configurer des bases de données mises en miroir Microsoft Fabric à partir de SQL Server

Contenu connexe

  • Last updated on