Partager via

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

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

Pour résoudre les problèmes, voir :

Disponibilité des fonctionnalités

Vous pouvez configurer Azure SQL Managed Instance pour la mise en miroir si elle est déployée dans n’importe quelle région Azure, à l’exception de ces régions actuellement : USA Est 2 ; USA Ouest 2 ; USA Centre ; USA Ouest.

La disponibilité des fonctionnalités dépend également des régions Fabric. Pour obtenir la liste complète de la prise en charge des régions Fabric, consultez les régions Fabric qui prennent en charge la mise en miroir.

Limitations au niveau de la base de données

  • La mise en miroir sur Azure SQL Managed Instance est disponible uniquement pour les instances dont la stratégie de mise à jour est définie sur Always up to date. Sql Server 2022 version de SQL Managed Instance ne prend pas en charge la mise en miroir.

  • La configuration de la géorécupération d’urgence n’est pas prise en charge par la mise en miroir.

  • La mise en miroir de structure pour Azure SQL Managed Instance est prise en charge uniquement sur une base de données primaire accessible en écriture .

  • Une base de données Azure SQL Managed Instance ne peut pas être mise en miroir si la base de données a activé la capture de données modifiées (CDC), la réplication transactionnelle ou 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. Le reste des tableaux en bas de la liste alphabétique ne sont pas mis 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.

  • La fonctionnalité de copie/déplacement de base de données n’est pas prise en charge sur les bases de données mises en miroir. Si vous déplacez ou copiez une base de données avec mise en miroir activée, la copie signale un état d’erreur de mise en miroir.

  • Si votre base de données d’instance managée SQL est configurée pour utiliser la fonctionnalité Azure SQL Managed Instance Link, le réplica lisible n’est pas pris en charge pour être une source pour la mise en miroir Fabric.

  • Si votre base de données est configurée pour la mise en miroir, puis renommée, la fonctionnalité de mise en miroir du moniteur cesse de fonctionner. Le changement de nom de la base de données au nom qu’elle avait lors de la configuration de la mise en miroir résout le problème.

  • Une base de données Azure SQL Managed Instance 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 de la base de données source dans Fabric OneLake.
  • Pour configurer la mise en miroir pour Azure SQL Managed Instance, le principal utilisé pour se connecter à l’instance managée SQL source doit disposer des autorisations CONTROL ou db_owner . Il est recommandé d’accorder uniquement cette valeur uniquement sur la base de données mise en miroir. Ne le faites pas au niveau du serveur entier.

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

  • 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é.
  • L’identité managée affectée par le système (SAMI) d’Azure SQL Managed Instance doit être activée et doit être l’identité principale.
  • Les autorisations de contributeur du principal du service Azure SQL Managed Instance ne doivent pas être supprimées de l’élément de base de données en miroir Fabric.
  • L’identité managée affectée par l’utilisateur (UAMI) n’est pas prise en charge.
  • La mise en miroir entre les locataires Microsoft Entra n’est pas prise en charge lorsqu’une instance managée 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 Managed Instance ne sont pas mises en miroir sur 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é.
    • 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 Objet binaire volumineux (LOB) de taille > 1 Mo, les données de colonne sont tronquées à la taille de 1 Mo dans Fabric OneLake. Configurez l’option de configuration de serveur de taille de texte maximale pour autoriser plus de 65 536 octets si vous souhaitez autoriser les insertions volumineuses.

  • Les tables sources qui ont l’une des fonctionnalités suivantes en cours d’utilisation 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 au niveau du tableau (DDL) suivantes ne sont pas autorisées sur les tables sources lorsqu’elles sont activées pour la mise en miroir SQL Managed Instance vers Microsoft Fabric.

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

  • Lorsqu’il existe une modification DDL, un instantané de données complet est redémarré pour la table modifiée et les données de table entières sont réinsérées dans Fabric OneLake.

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

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

  • Les vues et les vues matérialisées ne sont pas prises en charge pour la mise en miroir.

  • À compter de mai 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 à mai 2025 n’ont pas pu être mises en miroir. Après mai 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 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 sur Fabric OneLake. Les types de données suivants ne sont pas pris en charge pour la mise en miroir :
    • image
    • texte/ntexte
    • xml
    • json
    • 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.
  • Les opérations DDL (Column Level Data Definition Language) suivantes ne sont pas prises en charge sur les tables sources lorsqu’elles sont activées pour la mise en miroir SQL Managed Instance vers Microsoft Fabric :
    • Modifier la colonne
    • Renommer la colonne (sp_rename)

Limitations des éléments en miroir

  • L’utilisateur doit être membre du rôle Administrateur/Membre de l’espace de travail pour créer la mise en miroir SQL Managed Instance. 
  • 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. 
  • Si la capacité fabric est arrêtée, puis redémarrée, la mise en miroir cesse de fonctionner et doit être redémarrée manuellement. Il n’y aura pas d’avertissements/messages d’erreur indiquant que la mise en miroir a cessé de fonctionner.

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 d’Azure SQL Managed Instance

Contenu connexe

  • Last updated on