Partager via


Limitations dans les bases de données mises en miroir Microsoft Fabric à partir d’Azure SQL Database

Les limitations actuelles des bases de données mises en miroir 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 Azure SQL Database est prise en charge uniquement sur une base de données primaire accessible en écriture.

  • Azure SQL Database ne peut pas être mis en miroir si la base de données a activé la capture de données modifié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 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 Azure SQL Database nécessitent la propriété /p:DoNotAlterReplicatedObjects=False de publication pour activer 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.

  • Azure SQL Database ne peut pas être mis en miroir si la durabilité des transactions retardées 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 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é

  • L’identité managée affectée par le système (SAMI) ou l’identité managée affectée par l’utilisateur (UAMI) du serveur logique Azure SQL doit être activée et doit être l’identité principale.

    Note

    La prise en charge de l’identité managée affectée par l’utilisateur (UAMI) est actuellement en préversion.

  • Les autorisations de contributeur du principal du service Azure SQL Database 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 base de données Azure SQL et l’espace de travail Fabric se trouvent dans des locataires distincts. 

  • Les étiquettes Microsoft Purview Information Protection/sensibilité définies dans Azure SQL Database ne sont pas en cascade et mises en miroir vers 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).

  • 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é.
    • 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 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.
  • À compter d’avril 2025, une table peut être mise en miroir même si elle n’a pas de clé primaire.

    • Les tables sans clés primaires antérieures à avril 2025 n’ont pas pu être mises en miroir. Après avril 2025, les tables existantes sans clés primaires ne seront pas automatiquement ajoutées à la mise en miroir, même si vous aviez sélectionné automatiquement la mise en miroir des tables ultérieures.
      • Pour démarrer la mise en miroir de tables sans clés primaires lorsque vous avez sélectionné automatiquement les tables futures de mise en miroir :
        1. Arrêtez la réplication et démarrez la réplication, qui réexécise toutes les tables et détecte les nouvelles tables éligibles à la mise en miroir. Il s’agit de l’étape recommandée.

        2. Pour contourner ce problème, créez une table dans la base de données source. Cela déclenche un inventaire des tables pour la base de données source et détecte les tables qui n’ont pas été mises en miroir précédemment, y compris celles sans clés primaires. Par exemple, le script suivant crée une table nommée test_20250401, puis la supprime une fois la test_20250401 table mise en miroir. Ce script suppose qu’une table nommée dbo.test_20250401 n’existe pas déjà.

          --This script assumes that a table named dbo.test_20250401 does not already exist.
          CREATE TABLE dbo.test (ID int not null);
          

          Une fois qu’elle s’affiche dans la liste des tables mises en miroir, vous devez également voir les tables sans clés primaires. Vous pouvez ensuite supprimer la test table :

          DROP TABLE dbo.test_20250401;
          
      • Pour démarrer la mise en miroir de tables sans clés primaires lorsque vous n’avez pas sélectionné automatiquement les tables ultérieures, ajoutez les tables à la liste des tables sélectionnées dans les paramètres de 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 dans Fabric OneLake. Les types de données suivants ne sont pas pris en charge pour la mise en miroir :
    • image
    • texte/ntexte
    • xml
    • rowversion/horodatage
    • sql_variant
    • Types définis par l’utilisateur (UDT)
    • geometry
    • geography
  • 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