Partager via

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

  • Article

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

Pour résoudre les problèmes, voir :

Limitations au niveau de la base de données

  • La mise en miroir de structure pour la base de données Azure SQL est prise en charge uniquement sur une base de données primaire accessible en écriture.
  • La base de données Azure SQL ne peut pas être mis en miroir si la base de données a activé la capture des changements de données (CDC), 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.
  • Le nombre maximal de tables pouvant être mise 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 seront déterminées en prenant 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.

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 Azure SQL Database, le principal utilisé pour se connecter à la base de données Azure SQL source doit recevoir l’autorisation ALTER ANY EXTERNAL MIRROR, qui est incluse dans une autorisation de niveau supérieur, comme l’autorisation CONTROL ou le rôle db_owner.

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

  • Le SQL server source doit activer Autoriser l’accès au réseau public et autoriser les services Azure à se connecter.
  • L'identité managée affectée par le système (SAMI) de votre serveur logique Azure SQL doit être activée et doit être l'identité principale.
  • Ne supprimez pas les autorisations du contributeur du nom de principal du service (SPN) de la base de données Azure SQL sur l'élément de base mise en miroir Fabric.
  • La mise en miroir entre locataires Microsoft Entra n'est pas prise en charge lorsqu'une base de données Azure SQL et l'espace de travail Fabric se trouvent dans des locataires distincts. 
  • Protection des données Microsoft Purview/étiquettes de confidentialité définies dans la base de données Azure SQL ne sont pas en cascade et miroir dans Fabric OneLake.

Niveau de table

  • Une table qui n’a pas de clé primaire définie ne peut pas être mise en miroir.
    • Une table utilisant une clé primaire définie comme clé primaire non cluster ne peut pas être mise en miroir.
  • Une table ne peut pas être mise en miroir si la clé primaire est l’un des types de données suivants : sql_variant, timestamp/rowversion.
  • 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. Une perte de précision se produit si des colonnes de ce type sont mises en miroir, le septième chiffre décimal des secondes étant alors supprimé.
    • Une table ne peut pas être en miroir si la clé primaire correspond à l’un des types de données suivants : datetime2(7), datetimeoffset(7), time(7), où 7 présente sept chiffres de précision.
    • 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 mises 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
    • Always Encrypted
    • 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. 
    • Changer/Séparer/Fusionner la 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

  • Si la table source contient des colonnes calculées, ces colonnes ne peuvent pas être mises en miroir sur la Fabric OneLake. 
  • Si la table source contient des colonnes avec l’un de ces types de données, ces colonnes ne peuvent pas être mises en miroir vers Fabric OneLake. Les types de données suivants ne sont pas pris en charge pour la mise en miroir :
    • image
    • text/ntext
    • xml
    • rowversion/horodateur
    • sql_variant
    • Types définis par l’utilisateur (UDT)
    • geometry
    • Geography
  • Les noms de colonnes d’une table SQL ne peuvent pas contenir d’espaces, ni les caractères suivants : , ; { } ( ) \n \t =.

Limitations de l’entrepôt

  • La hiérarchie de schéma source n’est pas répliquée dans la base de données mise en miroir. Au lieu de cela, le schéma source est aplatit et le nom du schéma est encodé dans le nom de la table de base de données mise en miroir. 

Limitations des articles 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 d’analytique SQL

Régions de structure qui prennent en charge la mise en miroir

Voici les régions Fabric qui prennent en charge la mise en miroir pour la base de données Azure SQL :

Asie-Pacifique :

  • Australie Est
  • Australie Sud-Est
  • Inde centrale
  • Asie Est
  • Japon Est
  • Centre de la Corée
  • Asie Sud-Est
  • Inde Sud

Europe

  • Europe Nord
  • Europe Ouest
  • France Centre
  • Allemagne Centre-Ouest
  • Norvège Est
  • Suède Centre
  • Suisse Nord
  • Suisse Ouest
  • Sud du Royaume-Uni
  • Ouest du Royaume-Uni

Amériques :

  • Brésil Sud
  • Centre du Canada
  • Est du Canada
  • USA Centre
  • USA Est
  • USA Est 2
  • Centre-Nord des États-Unis
  • USA Ouest
  • USA Ouest 2

Moyen-Orient et Afrique :

  • Afrique du Sud Nord
  • Émirats arabes unis Nord

Étape suivante

Didacticiel : configurer des bases de données Microsoft Fabric mise en miroir depuis la base de données Azure SQL Database

Contenu connexe