Le point de départ

Fabric Warehouse expose un sous-ensemble des DMV (Dynamic Management Views) héritées de SQL Server : sys.dm_exec_connections, sys.dm_exec_sessions, sys.dm_exec_requests. Elles répondent à une seule question : qu’est-ce qui tourne maintenant, et qui bloque qui. Quand on vient de SQL Server, le réflexe est de les interroger comme avant. C’est précisément là que les écarts apparaissent, et ils sont rarement documentés de façon frontale.

Cet article couvre le temps réel. L’analyse de l’historique (les vues queryinsights) fait l’objet d’un article séparé.

Règle suivie ici : chaque affirmation est vérifiée en lab avant d’être écrite, et quand un résultat contredit l’intuition SQL Server il est signalé comme tel. Les captures proviennent d’un warehouse de test (lh_dp700_sandbox) chargé avec le jeu de données d’exemple de Fabric, en charge faible et mono-utilisateur : certaines absences observées plus bas sont des artefacts de ce contexte, pas des limites de la plateforme.

Après cette lecture, on saura :

  • répartir un besoin de diagnostic entre les trois DMV et leur hiérarchie ;
  • reconnaître les fonctions SQL Server absentes de Fabric Warehouse et leurs contournements ;
  • éviter les pièges de la colonne command et du libellé « Submitter » ;
  • anticiper le RBAC des DMV et le modèle de concurrence, tous deux différents de SQL Server on-premises.

Prérequis : un Fabric Warehouse accessible, des notions de DMV SQL Server, et l’éditeur SQL du portail Fabric (ou SSMS / Azure Data Studio connecté à l’endpoint T-SQL).

1. DMV ou Query Insights : lequel pour quoi

Repère à poser avant tout le reste : ce sont deux mécanismes complémentaires, pas deux chemins vers la même information.

CritèreDMV (cet article)Query Insights (article dédié)
NatureÉtat courant, en mémoireHistorique persistant
Question type“Qu’est-ce qui tourne maintenant, qui bloque qui ?”“Quelles requêtes ont été lentes cette semaine ?”
PersistanceAucune. L’information disparaît avec la sessionConservée dans les vues queryinsights.* (30 jours)

Chercher un historique dans les DMV, ou un instantané temps réel dans Query Insights, mène à une impasse.

À retenir : DMV pour diagnostiquer l’instant présent, Query Insights pour analyser une tendance.

2. Les trois DMV et leur hiérarchie

Les trois vues s’emboîtent, du réseau vers l’exécution :

DMVNiveauRépond à
sys.dm_exec_connectionsRéseauComment le client s’est connecté (protocole, adresse, authentification)
sys.dm_exec_sessionsSessionQui est connecté, depuis quand, avec quelle application
sys.dm_exec_requestsExécutionCe qui s’exécute à cet instant précis

Une connexion porte une ou plusieurs sessions ; une session peut avoir une requête active à un instant donné. Commençons par sys.dm_exec_sessions seule, filtrée sur les sessions utilisateur :

SELECT session_id, login_name, host_name, program_name, login_time
FROM sys.dm_exec_sessions
WHERE is_user_process = 1;

La même requête, lancée à trois moments du lab, ne renvoie pas le même nombre de lignes :

sys.dm_exec_sessions : une seule session retournée Premier passage : une seule session utilisateur active.

sys.dm_exec_sessions : trois sessions retournées Quelques minutes plus tard : trois sessions, avec des session_id et des login_time différents.

sys.dm_exec_sessions dans l’éditeur du portail : cinq sessions, panneau Explorer visible À un autre moment : cinq sessions. Une DMV est un instantané, elle reflète l’état à la milliseconde près et ne conserve rien. Deux détails à noter : host_name est masqué ici volontairement, et program_name affiche DMS_user pour toutes les sessions, une valeur interne au moteur distribué de Fabric et non le nom de l’outil client. Ne pas s’y fier pour identifier la provenance d’une session.

En joignant les trois vues, on obtient une image complète connexion vers session vers requête :

SELECT
    connections.connection_id,
    sessions.session_id,
    sessions.login_name,
    sessions.login_time,
    requests.command,
    requests.start_time,
    requests.total_elapsed_time
FROM sys.dm_exec_connections AS connections
INNER JOIN sys.dm_exec_sessions AS sessions
    ON connections.session_id = sessions.session_id
INNER JOIN sys.dm_exec_requests AS requests
    ON requests.session_id = sessions.session_id
WHERE requests.status = 'running'
ORDER BY requests.total_elapsed_time DESC;

Résultat de la jointure des trois DMV La jointure fonctionne sans adaptation : le modèle relationnel connexion, session, requête se comporte comme sur SQL Server classique. Attention toutefois : sys.dm_exec_connections est réservé à l’Admin du workspace (voir section 6), donc cette jointure échoue pour un rôle Member, Contributor ou Viewer.

À retenir : la hiérarchie des trois DMV est identique à SQL Server. Ce sont les colonnes, pas la structure, qui réservent des surprises.

3. Ce que SQL Server offre et que Fabric Warehouse retire

sys.dm_exec_sql_text, la fonction qui restitue le texte complet d’une requête à partir d’un sql_handle, n’est pas documentée pour Fabric Warehouse : elle ne figure pas dans le périmètre d’application de la référence T-SQL (contrairement à sys.dm_exec_requests), et le guide de monitoring Fabric ne l’utilise jamais. Le schéma habituel (joindre sys.dm_exec_requests à sys.dm_exec_sql_text pour lire la requête en cours) ne s’applique pas ici.

C’est l’une des raisons d’être de queryinsights : le texte des requêtes se récupère dans l’historique, pas dans les DMV temps réel.

À retenir : pas de texte de requête en temps réel dans Fabric Warehouse. Pour lire le SQL exécuté, on passe par queryinsights.exec_requests_history.

4. La colonne command ne contient pas la requête

Dans sys.dm_exec_requests, la colonne command ne porte pas le texte SQL. Elle porte un type de commande : SELECT, INSERT, CREATE TABLE, etc. Piège classique pour qui s’attend, par habitude, à y lire la requête complète.

Deux observations de lab sur cette même DMV :

  • Un SELECT DISTINCT status FROM sys.dm_exec_requests a renvoyé trois valeurs (background, running, sleeping) sur les six documentées. Les trois autres (rollback, runnable, suspended) étaient simplement absentes faute de contention au moment du test ; suspended en particulier signale un blocage réel.
  • À un instant donné, la vue contenait plus d’une centaine de lignes command = 'TASK MANAGER', toutes au même horodatage. Ce sont des threads de maintenance interne du moteur, probablement liés à un réveil de capacité, pas des requêtes utilisateur. Il faut les filtrer explicitement pour isoler l’activité réelle.

À retenir : command en DMV = catégorie d’instruction. Et il existe un bruit interne (TASK MANAGER) à exclure de toute analyse.

5. “Submitter” : un libellé d’interface, pas une colonne

Le portail (Data Warehouse Monitor) affiche une colonne Submitter. Elle n’existe pas en T-SQL, ni dans les DMV, ni dans queryinsights. “Submitter” est un libellé d’interface ; la colonne réelle à interroger est login_name.

À retenir : avant de chercher une colonne vue dans le portail, vérifier qu’elle porte le même nom côté T-SQL. Souvent non.

6. RBAC des DMV : qui voit quoi

Deux couches de permission distinctes, souvent confondues. L’écran du portail, longtemps appelé « Query Activity », s’appelle désormais Data Warehouse Monitor :

RôleDMV en T-SQLData Warehouse Monitor (portail)
AdminLes trois DMV, toutes les sessions du workspace ; commande KILLAccès complet
Member / Contributorsys.dm_exec_sessions et sys.dm_exec_requests, ses propres requêtes uniquement ; pas de sys.dm_exec_connections, pas de KILLAucun accès, réservé aux Admins
ViewerIdem Member / ContributorAucun accès, réservé aux Admins

Un Contributor peut donc interroger sys.dm_exec_requests en T-SQL pour ses propres requêtes, mais ne peut même pas ouvrir Data Warehouse Monitor dans le portail. Conséquence pratique : sys.dm_exec_connections étant réservé à l’Admin, la jointure des trois DMV de la section 2 ne fonctionne que pour un Admin.

À retenir : l’accès T-SQL aux DMV est plus permissif que Data Warehouse Monitor. Deux modèles séparés.

7. Modèle de concurrence : Snapshot imposé

SET TRANSACTION ISOLATION LEVEL n’a aucun effet dans Fabric Warehouse : l’instruction est acceptée mais ignorée à l’exécution. La raison : le warehouse impose Snapshot Isolation, sans possibilité d’en changer, cohérent avec une plateforme pensée pour l’analytique concurrente plutôt que pour de l’OLTP.

Conséquences concrètes :

  • un lecteur n’est pas bloqué par un écrivain non validé, contrairement au modèle pessimiste de SQL Server on-premises ;
  • le verrouillage s’applique au niveau de la table entière, pas de la ligne.

À retenir : on ne règle pas l’isolation dans Fabric Warehouse, on compose avec Snapshot et un verrouillage table-level.

8. Un faux positif IntelliSense qui fait perdre du temps

Écrire BEGIN TRANSACTION dans l’éditeur SQL du portail déclenche un soulignement rouge (“no viable alternative at input”). L’instinct est de conclure que la syntaxe est invalide. En réalité c’est un faux positif cosmétique : la commande s’exécute normalement (“1 records affected” en lab), et BEGIN TRANSACTION / COMMIT / ROLLBACK sont bien pris en charge.

À retenir : l’éditeur peut se tromper avant le moteur. Tester l’exécution avant de conclure qu’une fonctionnalité manque.

9. Ce qui reste ouvert

Point testé mais pas tranché avec certitude : le comportement de @@TRANCOUNT dans un batch groupé (plusieurs instructions envoyées en une seule exécution). Renvoie-t-il toujours 1 après BEGIN TRANSACTION, ou cela dépend-il de la structure du batch ? À vérifier avec un test dédié avant d’en faire une affirmation.

Récapitulatif anti-pièges

PiègeCe qu’il faut retenir
sys.dm_pdw_exec_requestsSynapse dédié (PDW), pas Fabric
sys.dm_exec_sql_textHors périmètre Fabric Warehouse : passer par queryinsights.exec_requests_history
command (DMV)Type de commande, pas le texte
command = 'TASK MANAGER'Bruit de maintenance interne, à filtrer
program_nameVaut DMS_user, valeur moteur, pas l’outil client
submitterLibellé du portail, en T-SQL c’est login_name
sys.dm_exec_connectionsRéservé à l’Admin ; la jointure des trois DMV échoue pour un non-Admin
KILLRéservé à l’Admin
SET TRANSACTION ISOLATION LEVELAccepté mais ignoré à l’exécution, Snapshot Isolation imposée
Data Warehouse Monitor (portail)Réservé aux Admins, contrairement aux DMV en T-SQL

Pourquoi ça compte au-delà de l’examen

Pour l’examen DP-700 (domaine “Monitor and optimize an analytics solution”), ces nuances séparent une réponse solide d’une intuition approximative héritée de SQL Server.

En production, l’enjeu est plus direct : savoir que sys.dm_exec_sql_text est absent, ou que sys.dm_exec_connections est réservé à l’Admin, évite de bâtir un diagnostic sur une fonctionnalité ou un accès qui n’existe pas pour l’identité qui l’exécutera. Mieux vaut le découvrir avant l’incident.

En résumé

Les trois DMV de Fabric Warehouse gardent la structure de SQL Server, mais :

  • pas de texte de requête en temps réel (sys.dm_exec_sql_text hors périmètre) ;
  • command est un type d’instruction, pas du SQL, et un bruit interne (TASK MANAGER) est à filtrer ;
  • sys.dm_exec_connections et KILL sont réservés à l’Admin ;
  • un seul modèle de concurrence, non négociable : Snapshot Isolation et verrouillage table-level.

Pour l’historique et les agrégats, voir Query Insights dans Fabric Warehouse.

Sources officielles