Transactions dans les tables d’entrepôt dans Microsoft Fabric
S’applique à :✅ point de terminaison d’analytique SQL et Warehouse dans Microsoft Fabric
À l’instar de leur comportement dans SQL Server, les transactions vous permettent de contrôler la validation ou la restauration des requêtes de lecture et d’écriture.
Vous pouvez modifier les données stockées dans des tables d’un entrepôt à l’aide de transactions pour regrouper les modifications.
- Par exemple, vous pouvez valider des insertions dans plusieurs tables, ou aucune des tables si une erreur se produit. Si vous modifiez les détails d’un bon de commande qui affecte trois tables, vous pouvez regrouper ces modifications en une seule transaction. Cela signifie que lorsque ces tables sont interrogées, elles ont toutes les modifications ou aucune d’elles ne le fait. Les transactions sont une pratique courante lorsque vous devez vous assurer que vos données sont cohérentes entre plusieurs tables.
Fonctionnalités transactionnelles
Les mêmes fonctionnalités transactionnelles sont prises en charge dans le point de terminaison d’analytique SQL dans Microsoft Fabric, mais pour les requêtes en lecture seule.
Les transactions peuvent également être utilisées pour les instructions SELECT séquentielles afin de s’assurer que les tables impliquées ont toutes des données du même point dans le temps. Par exemple, si une table contient de nouvelles lignes ajoutées par une autre transaction, les nouvelles lignes n’affectent pas les requêtes SELECT à l’intérieur d’une transaction ouverte.
Important
Seul le niveau d’isolation instantané est pris en charge dans Microsoft Fabric. Si vous utilisez T-SQL pour modifier votre niveau d’isolation, la modification est ignorée au moment de l’exécution de la requête et instantané isolation est appliquée.
Prise en charge des transactions de requête inter-bases de données
Warehouse dans Microsoft Fabric prend en charge les transactions qui s’étendent sur les bases de données qui se trouvent dans le même espace de travail, y compris la lecture à partir du point de terminaison d’analytique SQL du Lakehouse. Chaque Lakehouse a un point de terminaison d’analytique SQL en lecture seule. Chaque espace de travail peut avoir plusieurs lakehouses.
Prise en charge DDL dans les transactions
Entrepôt dans Microsoft Fabric prend en charge le langage DDL tel que CREATE TABLE à l’intérieur des transactions définies par l’utilisateur.
Verrous pour différents types d’instructions
Ce tableau fournit une liste des verrous utilisés pour différents types de transactions, tous les verrous se trouvent au niveau de la table :
| Type d’instruction. | Verrouillage pris |
|---|---|
| SELECT | Schema-Stability (Sch-S) |
| INSERT | Intent Exclusive (IX) |
| DELETE | Intent Exclusive (IX) |
| UPDATE | Intent Exclusive (IX) |
| COPY INTO | Intent Exclusive (IX) |
| DDL | Schema-Modification (Sch-M) |
Ces verrous empêchent les conflits tels que la modification du schéma d’une table pendant la mise à jour des lignes dans une transaction.
Vous pouvez interroger les verrous actuellement détenus avec la vue de gestion dynamique (DMV) sys.dm_tran_locks.
Les conflits de deux transactions simultanées ou plus qui mettent à jour une ou plusieurs lignes d’une table sont évalués à la fin de la transaction. La première transaction à valider se termine correctement et les autres transactions sont restaurées avec une erreur retournée. Ces conflits sont évalués au niveau de la table et non au niveau du fichier parquet individuel.
Les instructions INSERT créent toujours de nouveaux fichiers parquet, ce qui signifie moins de conflits avec d’autres transactions, à l’exception de DDL, car le schéma de la table peut être modifié.
Journalisation des transactions
La journalisation des transactions dans Entrepôt dans Microsoft Fabric se fait au niveau du fichier parquet, car les fichiers parquet sont immuables (ils ne peuvent pas être modifiés). Une restauration entraîne un pointage vers les fichiers parquet précédents. Les avantages de cette modification sont que la journalisation des transactions et les restaurations sont plus rapides.
Limites
- Les transactions distribuées ne sont pas prises en charge.
- Les points d’enregistrement ne sont pas pris en charge.
- Les transactions nommées ne sont pas prises en charge.
- Les transactions marquées ne sont pas prises en charge.
- ALTER TABLE n'est pas pris en charge dans une transaction explicite.
- À l’heure actuelle, les fonctionnalités T-SQL sont limitées dans l’entrepôt. Pour obtenir la liste des commandes T-SQL qui ne sont actuellement pas disponibles, consultez Surface d’exposition TSQL.
- Si une transaction comporte une insertion de données dans une table vide et émet un SELECT avant la restauration, les statistiques générées automatiquement peuvent toujours refléter les données non validées, ce qui entraîne des statistiques inexactes. Des statistiques inexactes peuvent entraîner des plans de requête et des temps d’exécution non optimisés. Si vous restaurez une transaction avec des SELECT après un INSERT volumineux, mettez à jour les statistiques pour les colonnes mentionnées dans votre SELECT.