Langsame SQL-Abfragen, schwankende Laufzeiten und steigende Capacity-Last wirken auf den ersten Blick wie dasselbe Problem. In Microsoft Fabric haben diese Symptome aber unterschiedliche Ursachen – und benötigen unterschiedliche Monitoring-Werkzeuge. Wer Live-Abfragen, Query-Historie und Kapazitätsverbrauch sauber trennt, kann Engpässe gezielter beheben, statt vorschnell die F-SKU zu erhöhen.
Was gehört zum Microsoft Fabric Data Warehouse Monitoring?
Fabric Data Warehouse Monitoring ist kein einzelnes Dashboard, sondern die Kombination mehrerer Diagnoseebenen. Für aktive Requests eignen sich dynamische Verwaltungsansichten (DMVs). Query Insights liefert historische Ausführungen und Abfragemuster. Der Data Warehouse Monitor zeigt einen Teil davon als Portaloberfläche. Die Capacity Metrics App bewertet die geteilte Fabric-Kapazität. Workspace Monitoring ergänzt eine workspaceweite Sicht auf abgeschlossene verteilte SQL-Ausführungen. Ein KI-gestützter Operations-Skill kann diese Daten interpretieren, ersetzt aber weder die zugrunde liegende Telemetrie noch die menschliche Entscheidung.
Entscheidend sind drei Fragen: Was ist gerade aktiv? Was hat sich gegenüber früher verändert? Und betrifft das Problem die SQL-Ausführung oder die gemeinsam genutzte Kapazität?
Monitoring nach drei Fragen aufbauen – nicht nach verfügbaren Dashboards
Bevor ein Team weitere Dashboards baut, sollte es den Vorfall eindeutig beschreiben: Welcher Geschäftsprozess ist betroffen, seit wann und an welchem Warehouse? Eine einzelne langsame Query im SQL-Editor ist etwas anderes als ein verspäteter nächtlicher Ladejob oder eine gleichzeitige Verschlechterung vieler Berichte. Notiere daher Workspace und Item, betroffenes Zeitfenster mit Zeitzone, aufrufende Anwendung, Abfragezustand und erwartete Laufzeit. Diese kleine Vorarbeit vermeidet viele falsche Vergleiche.
Für den ersten Drilldown empfiehlt sich eine feste Reihenfolge: Eine aktuell laufende Query zuerst in den DMVs untersuchen; eine bereits abgeschlossene Abfrage über Query Insights beziehungsweise den Data Warehouse Monitor auflösen; bei mehreren betroffenen Warehouses Workspace Monitoring hinzuziehen. Erst danach die Capacity Metrics App öffnen, um zu prüfen, ob die Plattformlast den Vorfall plausibel erklärt. So bleiben SQL-Ausführung und Kapazität zwei getrennte Diagnoseebenen.
Beide Ebenen liefern unterschiedliche Identifikatoren. distributed_statement_id hilft bei der Verbindung zwischen WarehouseExecutions und Query Insights, während eine Operation-ID aus der Capacity Metrics App nicht einfach dieselbe Abfrage identifiziert. Für den Kapazitätsabgleich sind daher Workspace/Item und ein überlappendes Zeitfenster maßgeblich.
Data Warehouse Monitor: Ein schneller Einstieg ohne T-SQL
Der Data Warehouse Monitor bündelt im Fabric-Portal laufende und historische T-SQL-Abfragen sowie Ansichten für häufig und lange laufende Query-Muster. In der Query-Historie lassen sich unter anderem Zeitfenster, Status, Absender und Ausführungsquellen eingrenzen. Über den Query Hash können ähnliche Ausführungen verglichen werden.
Wichtig für die Einführung: Der Monitor befindet sich in der Preview. Außerdem ist für den Zugriff die Workspace-Rolle Admin erforderlich. Mitglieder mit den Rollen Member, Contributor oder Viewer dürfen diese Ansicht derzeit nicht öffnen. Historische Abfragen können bis zu 15 Minuten verzögert erscheinen; die aktuelle Filteransicht ist auf die obersten 10.000 Zeilen begrenzt. Damit ist die Oberfläche nützlich für die schnelle Untersuchung, aber weder lückenloses Echtzeit-Event-Streaming noch ein Ersatz für eine eigene Langzeitüberwachung.
Vom Monitor-Treffer zur reproduzierbaren Untersuchung
Im Incident ist der Monitor besonders praktisch, wenn niemand zunächst eine SQL-Diagnoseabfrage schreiben möchte. Wähle das konkrete Warehouse, grenze das Zeitfenster auf den gemeldeten Fehler ein und unterscheide laufende von historischen Requests. Für wiederkehrende Auffälligkeiten sollte nicht nur der längste einzelne Lauf betrachtet werden: Entscheidend ist, ob mehrere Ausführungen desselben Query-Musters schlechter werden. Der Query Hash ist dafür ein geeigneter Einstieg.
Dokumentiere beim auffälligen Lauf die verfügbaren Identifikatoren, Status und Zeitangaben und wechsle für detaillierte Scan-/CPU-Werte in Query Insights. Dass der Monitor nur die obersten 10.000 Zeilen der jeweils gefilterten Sicht zeigt und historische Einträge verzögert ankommen können, ist ein Grund für engere Filter, nicht für die Annahme, eine fehlende Query habe nicht stattgefunden.
Query Insights: Historie und wiederkehrende Engpässe erkennen
Wenn ein Bericht nur an manchen Tagen langsam wird, ist eine aktuelle Session-Abfrage zu wenig. Query Insights liefert Ausführungsdaten für die vergangenen 30 Tage, darunter abgeschlossene, fehlgeschlagene und abgebrochene SQL-Requests. Die historischen Views stehen im Schema queryinsights des Warehouses oder SQL Analytics Endpoints. Systemgenerierte Queries sind nicht Bestandteil dieser Historie.
Besonders interessant sind queryinsights.exec_requests_history für einzelne Läufe, queryinsights.long_running_queries und queryinsights.frequently_run_queries für wiederkehrende Muster sowie queryinsights.sql_pool_insights für SQL-Pool-Druck und Konfigurationsereignisse. Über den query_hash können Abfragen mit ähnlicher Struktur zusammengeführt werden. Hohe Gesamtlaufzeit und hohe CPU-Zeit sind unterschiedliche Signale: Die eine kann auch durch Warten, die andere durch tatsächlichen Rechenaufwand geprägt sein.
Eine erste, rein lesende Auswertung für die letzten 24 Stunden kann so aussehen:
SELECT TOP (20)
submit_time,
distributed_statement_id,
query_hash,
total_elapsed_time_ms,
allocated_cpu_time_ms,
result_cache_hit,
command
FROM queryinsights.exec_requests_history
WHERE submit_time >= DATEADD(HOUR, -24, GETUTCDATE())
ORDER BY total_elapsed_time_ms DESC;Beispielstatus: nicht in einer Fabric-Laufzeit ausgeführt. Die Spalten erlauben, langsame Requests zu identifizieren und anschließend CPU-Zeit, Cache-Verhalten und SQL-Text zu beurteilen. Query Insights setzt ausreichende Warehouse-/Workspace-Rechte voraus; für den vollständigen Query-Text nennt Microsoft Admin, Member und Contributor. Ergebnisse können ebenfalls bis zu 15 Minuten nachlaufen.
Wiederkehrende Query-Muster vergleichen: Nicht nur den langsamsten Lauf suchen
Ein einzelner Ausreißer ist für eine Optimierungsentscheidung oft ungeeignet. Sinnvoller ist eine Zusammenfassung über mehrere Ausführungen mit gleichem query_hash. Das folgende lesende Beispiel gruppiert erfolgreiche Requests aus sieben Tagen und zeigt Anzahl, durchschnittliche Laufzeit sowie die längste Ausführung. So fallen sowohl seltene Extremfälle als auch regelmäßig langsame Muster auf; bei Bedarf ergänzt man einen Vergleich der CPU- und Scanwerte.
Die Query-Historie enthält nur einen begrenzten Rückblick und ist keine vollständige Anwendungstelemetrie. Außerdem kann sich ein Query Hash bei strukturellen SQL-Änderungen verändern. Für einen fairen Vorher-/Nachher-Vergleich sollten deshalb Parameterbereich, Datenumfang, Query-Text, Ausführungszeit und der Cache-Kontext mit protokolliert werden.
SELECT TOP (20)
query_hash,
COUNT(*) AS anzahl_ausfuehrungen,
AVG(CAST(total_elapsed_time_ms AS BIGINT)) AS durchschnitt_ms,
MAX(total_elapsed_time_ms) AS laengster_lauf_ms
FROM queryinsights.exec_requests_history
WHERE submit_time >= DATEADD(DAY, -7, GETUTCDATE())
AND status = 'Succeeded'
AND query_hash IS NOT NULL
GROUP BY query_hash
HAVING COUNT(*) >= 3
ORDER BY laengster_lauf_ms DESC;SQL-Beispiel: nicht in einer Fabric-Instanz ausgeführt.
Cold Start, Cache und Statistiken von echter Regression unterscheiden
In Fabric kann die erste Ausführung einer Abfrage deutlich länger dauern als spätere Läufe. Beim Cold Start werden Daten aus OneLake gelesen, Knoten vorbereitet oder erforderliche Statistiken erzeugt. Vergleicht man nur diesen ersten Lauf mit einer späteren Cache-Ausführung, entsteht leicht der falsche Eindruck einer Optimierung. Query Insights liefert mit data_scanned_remote_storage_mb, data_scanned_memory_mb und data_scanned_disk_mb Hinweise auf das tatsächlich gelesene Datenvolumen.
Eine Verschlechterung nach einer größeren Datenladung kann aber auch an Statistikstand, Datenverteilung, verändertem Join-Verhalten oder umfangreicherem Scan liegen. Prüfe deshalb nicht allein CPU und Gesamtdauer, sondern auch die gescannte Datenmenge und – bei geeigneten Rechten – den Ausführungsplan. Für die Optimierung sind passende Datentypen in Join-Bedingungen, aktuelle Statistiken und ein bewusster Umgang mit aufwendigen Sortierungen wichtig. Kapazitätserhöhung ist keine allgemeine Ersatzmaßnahme für fehlerhafte Abfragepläne.
DMVs: Wenn eine Query jetzt gerade hängt
Für aktive Requests sind Dynamic Management Views der bessere Startpunkt. sys.dm_exec_requests zeigt laufende Anfragen, sys.dm_exec_sessions aktive Sessions und sys.dm_exec_connections Verbindungen. Diese Sicht ist besonders wertvoll, wenn eine Abfrage auf Ressourcen wartet oder Sperren vermutet werden.
SELECT
request_id,
session_id,
status,
start_time,
total_elapsed_time
FROM sys.dm_exec_requests
WHERE status = 'running'
ORDER BY total_elapsed_time DESC;SQL-Beispiel: nicht in einer Fabric-Instanz ausgeführt. Der Abfragekontext und die Rechte sind entscheidend: Workspace-Admins sehen die Requests verschiedener Nutzer. Member, Contributor und Viewer sehen in sys.dm_exec_requests und sys.dm_exec_sessions grundsätzlich nur ihre eigenen Sessions und Requests; sys.dm_exec_connections ist Admins vorbehalten.
Bei echten Blockaden sollte zuerst geprüft werden, ob eine andere Transaktion einen Lock hält. In Fabric Warehouse gibt es Sperren auf Tabellenebene bei DML-Operationen. Das Beenden einer Session mit KILL kann offene Transaktionen zurückrollen und ist ausschließlich Admins vorbehalten. Ein lang laufender Request ist deshalb noch keine ausreichende Begründung, ihn abzubrechen.
Blocking mit einem konkreten Beleg prüfen
Wenn eine Query scheinbar hängt, sollte zuerst geklärt werden, ob sie arbeitet oder auf eine andere Transaktion wartet. In Fabric Warehouse können DML-Operationen Tabellen sperren. Mit einer einfachen Abfrage auf sys.dm_exec_requests lassen sich Requests mit einer blockierenden Session erkennen. Ein positiver Treffer ist ein wesentlich stärkeres Indiz als „die Query läuft seit 20 Minuten“. Anschließend kann der zuständige Administrator über Session- und Lock-Daten den Eigentümer und die offene Transaktion bestimmen.
Ein sinnvoller Ablauf lautet: erst den wartenden Request und die blockierende Session identifizieren, danach die betroffene Transaktion mit ihrem Owner abgleichen, schließlich COMMIT/ROLLBACK durch den zuständigen Prozess oder ein abgestimmtes Betriebsfenster erwägen. Das administrative KILL ist kein Standard-Tuning-Schritt: Es beendet die Session und rollt unbestätigte Änderungen zurück. Die folgende Abfrage zeigt relevante Felder für die Blocking-Diagnose.
SELECT
session_id,
status,
blocking_session_id,
wait_type,
total_elapsed_time,
open_transaction_count
FROM sys.dm_exec_requests
WHERE blocking_session_id <> 0;SQL-Beispiel: rein lesend, nicht in der Zielumgebung ausgeführt; erforderliche Berechtigungen beachten.
Workspace Monitoring: Mehrere Warehouses vergleichen
Betreibt ein Team mehrere Warehouses oder SQL Analytics Endpoints innerhalb eines Workspaces, beginnt die Suche nach der Ursache häufig eine Ebene höher. Workspace Monitoring (Preview) schreibt abgeschlossene, durch Nutzer initiierte verteilte SQL-Ausführungen in die KQL-Tabelle WarehouseExecutions. Darüber lassen sich beispielsweise Query-Anzahl, Fehlerrate oder Laufzeitverteilungen je Item auswerten.
Die Abdeckung ist wichtig: Laufende Queries, reine SQL-Frontend-Abfragen und systemgenerierte Requests fehlen. Die Funktion wird von einem Workspace-Admin aktiviert; zum Abfragen der Monitoring-Daten ist mindestens die Contributor-Rolle vorgesehen. Workspace Monitoring ist außerdem workspacebezogen, nicht automatisch ein mandantenweites Warehouse-Monitoring. Für das Monitoring-Eventhouse und die KQL-Datenbank können zusätzliche Verbrauchskosten entstehen.
Ein praktischer Drilldown ist möglich: WarehouseExecutions.OperationId entspricht bei diesen Events der distributed_statement_id aus Query Insights. Damit lässt sich ein auffälliger KQL-Eintrag im betroffenen Warehouse weiter untersuchen. Das ist nicht dieselbe ID wie eine Operation-ID in der Capacity Metrics App.
Aus Workspace Monitoring einen sinnvollen Alarm ableiten
Eine workspaceweite Sicht wird erst dann betrieblich wertvoll, wenn daraus nachvollziehbare Prioritäten entstehen. Anstatt jede fehlgeschlagene Query sofort zu melden, kann eine KQL-Abfrage die Fehlerrate pro Item in einem festen Zeitfenster bilden. Das folgende Beispiel betrachtet 15 Minuten und filtert nur Items mit mindestens zehn ausgeführten Queries und mindestens 20 Prozent Fehlern. Das sind bewusst Beispielschwellen; produktive Werte müssen an kritische Workloads und das normale Datenvolumen angepasst werden.
Der eigentliche Alarm gehört erst nach einer Baseline in ein Real-Time-Dashboard oder Activator. Ein einzelner Fehler bei geringem Volumen muss nicht sofort einen Alarm auslösen; ein ausgefallener täglicher Geschäftsprozess kann dagegen bereits mit einem einzigen Fehlschlag kritisch sein. Ebenso wichtig: Workspace Monitoring enthält keine laufenden Requests. Eine fehlende Ausführung darf deshalb nicht als „Query erfolgreich“ interpretiert werden.
WarehouseExecutions
| where Timestamp > ago(15m)
| summarize
QueryCount = count(),
FailedQueries = countif(Status == "Failed")
by ItemId, ItemKind
| extend FailureRatePercent =
round(100.0 * FailedQueries / QueryCount, 2)
| where QueryCount >= 10 and FailureRatePercent >= 20KQL-Beispiel: kein Alert in einer Fabric-Umgebung angelegt oder getestet.
Capacity Metrics App: Auslastung ist nicht gleich SQL-Performance
Die Microsoft Fabric Capacity Metrics App betrachtet den gemeinsamen Compute-Pool. Sie beantwortet Fragen nach CU-Verbrauch, Lastspitzen und Throttling, während Query Insights die SQL-Ausführung betrachtet. Im Capacity-Kontext sind neben Warehouse-Queries auch andere Fabric-Workloads relevant. Der Bericht bietet unter anderem Compute-Ansichten und eine Untersuchung einzelner Zeitpunkte.
Query-CPU in Millisekunden ist nicht dasselbe wie verbrauchte Capacity Units. Es gibt keine seriöse Eins-zu-eins-Umrechnung zwischen beiden Kennzahlen. Ein zeitgleich hoher SQL-CPU-Wert und hoher CU-Verbrauch begründet zunächst eine Korrelation, nicht automatisch eine gesicherte Ursache. Deshalb sollte die Diagnose Query Insights, eventuelle SQL-Pool-Drucksignale und die Capacity Metrics App im selben Zeitfenster berücksichtigen – und erst dann über Query-Tuning, Workload-Verteilung oder eine andere Kapazitätsgröße entscheiden.
Wer die finanziellen Folgen einer Kapazitätsentscheidung bewerten möchte, sollte dabei nicht nur auf Compute schauen. Unser Beitrag zu den Kosten von Microsoft Fabric trennt Kapazität, Lizenzen, Speicher und zusätzlichen Workload-Verbrauch.
Kapazitätsprobleme belastbar nachweisen – und Alternativen abwägen
Eine hohe Kapazitätsauslastung allein erklärt noch nicht, warum gerade eine bestimmte Warehouse-Query langsam wurde. Prüfe im betroffenen Zeitfenster die CU-Auslastung, gegebenenfalls tatsächlich aufgetretenes Throttling und die betroffenen Workloads. Die Timepoint-Ansichten der Capacity Metrics App helfen, Beiträge aus interaktiven und Hintergrundoperationen zu unterscheiden. Auch andere Fabric-Items können dieselbe Kapazität beanspruchen; ein hoher Gesamtverbrauch ist daher nicht automatisch dem Warehouse zuzurechnen.
Für die Ursachenentscheidung sind drei Fälle hilfreich: (1) Hohe Query-Dauer bei unauffälliger Capacity: SQL-Plan, Scanmenge, Cache, Datenwachstum und Blocking untersuchen. (2) Gleichzeitige Capacity-Überlast mit dokumentiertem Throttling: verursachende Workloads und Ausführungsfenster ermitteln; gegebenenfalls die Last verteilen. (3) Hohe Capacity ohne eindeutigen Zusammenhang: keine pauschale Aussage zur Ursache treffen; zunächst gezielter messen. Erst wenn ein wiederholbarer Lastengpass vorliegt, ist ein geplanter Skalierungstest eine fundierte Option.
Die Kostenentscheidung gehört zum Ergebnis des Tests: Hat eine größere SKU bei vergleichbarer Last die Laufzeit oder Fehlerrate tatsächlich verbessert? Falls nicht, sollten Optimierungen an SQL, Datenmodell und Jobplanung Vorrang haben. Capacity Metrics App und Timepoint-Analyse liefern dafür ergänzende Messdaten.
KI-gestützte Diagnose: Was der Warehouse Operations Skill leistet
Zusätzlich gibt es einen Data Warehouse Operations Skill (sqldw-cli) innerhalb von Skills for Fabric. Er befindet sich in der Preview und arbeitet aus kompatiblen AI-Coding-Werkzeugen mit bestehenden Berechtigungen und lesenden Diagnosen. Er kann etwa fehlerhafte Queries einordnen, ressourcenintensive Muster untersuchen oder Kapazitätsspitzen mit Query Insights korrelieren. Voraussetzung sind eine passende Installation, eine angebundene Fabric-SQL-Endpoint-Schnittstelle sowie die benötigten Rollen.
Das ist kein selbstständiger Operations Agent mit Schreibrechten und auch nicht identisch mit dem Operations Agent für Data-Factory-Pipelines. Letzterer behandelt das Monitoring und die Reaktion auf Pipeline-Ereignisse, wie wir im Beitrag zu Operations Agents für Fabric Pipelines erläutern. Für Warehouse-Queries liefert sqldw-cli eine zusätzliche Diagnosehilfe; er ersetzt weder kontrollierte Abfragen noch die Überprüfung von Empfehlungen.
AI-Unterstützung ist nur so gut wie die mitgelieferten Messdaten
Der Vorteil eines Operations-Skills liegt nicht darin, SQL-Warnungen automatisch „wegzuoptimieren“, sondern in einer schnelleren strukturierten Auswertung. Ein sinnvoller Auftrag nennt Workspace, Warehouse, UTC-Zeitfenster und konkrete Symptome: „Untersuche fehlgeschlagene Requests der letzten 24 Stunden und vergleiche Query-CPU, Laufzeit, Scanmenge und Capacity-Last; markiere fehlende Daten ausdrücklich.“ Ein vertrauenswürdiges Ergebnis trennt Beobachtung, Hypothese, ausgeschlossene Ursachen und Empfehlung.
Änderungen an SQL, Ressourcen oder Daten folgen erst nach einem überprüften Plan und einer eigenen Berechtigungsprüfung. Ein Warehouse-Operations-Skill kann lesende Diagnosen unterstützen. Eine zeitliche Überschneidung zwischen SQL und Capacity allein beweist jedoch noch keine Kausalität. Für einen ersten Pilot reicht deshalb ein begrenztes, nachvollziehbares Diagnosebriefing statt eines autonom handelnden Agents.
Praxisfall: Ein täglich laufender SQL-Job wird plötzlich langsam
Ein fiktives Beispiel zeigt den Diagnoseweg: Ein SQL-Job benötigte bisher ungefähr sechs Minuten und läuft nun rund eine halbe Stunde. Die naheliegende Reaktion wäre, die Fabric-Kapazität hochzuskalieren. Dafür fehlen aber zunächst Belege.
- Historie sichern: In Query Insights wird anhand von Zeitfenster, SQL-Text und Query Hash geprüft, ob wirklich dieselbe Abfrage betroffen ist. Der Vergleich von CPU-Zeit, Laufzeit und Scan-Metriken trennt Rechenlast von Wartezeiten und verändertem Datenzugriff.
- Aktuellen Zustand prüfen: Falls die Abfrage noch läuft, zeigen DMVs, ob sie aktiv arbeitet, wartet oder durch eine andere Session blockiert wird. Offene Transaktionen werden nicht vorschnell beendet.
- Workload-Kontext ergänzen:
sql_pool_insightsund Capacity Metrics zeigen, ob gleichzeitig SQL-Pool-Druck, andere Workloads oder Capacity-Throttling auftreten. Zeitliche Überschneidungen werden als Hypothesen behandelt, nicht als Ursachenbeweise. - Gezielt handeln und nachmessen: Je nach Befund kommen Query-Optimierung, Behebung von Blocking, Änderung der Ausführungszeit, Ressourcenverteilung oder ein Capacity-Test infrage. Danach wird mit demselben Query-Muster und vergleichbarer Last erneut gemessen.
Die wichtigste Regel lautet: Zuerst den Engpass nachweisen, dann Kapazität oder Code ändern. Gerade bei automatisierten Data-Warehouse-Prozessen ist Monitoring nur ein Teil eines verlässlichen Betriebsmodells. Wie stark Fachlogik, Verantwortlichkeiten und Automatisierung zusammenhängen, vertieft unser Beitrag zur Data Warehouse Automatisierung.
Ein Incident-Protokoll macht aus Einzelmessungen belastbare Entscheidungen
Für das fiktive Beispiel mit dem von sechs auf dreißig Minuten angewachsenen Job sollte ein kleines Protokoll angelegt werden. Mindestens erforderlich sind Start-/Endzeit in UTC, Workspace/Item, Query Hash oder Statement-ID, Laufzeit, CPU-Zeit, Scanvolumen, Cache-Hinweis, Fehlermeldung, SQL-Pool-Signal, Capacity-Befund und getestete Maßnahme. Ohne diese Felder lässt sich eine spätere Verbesserung kaum reproduzieren; mehrere unterschiedliche Abfragen können in der Incident-Diskussion sonst versehentlich vermischt werden.
Eine gute Vorher-/Nachher-Messung nutzt vergleichbare Datenmengen, Parameter und Zeitfenster. Beispielsweise darf ein verbesserter Lauf mit warmem Cache nicht ohne Kennzeichnung gegen den ersten Cold-Start-Lauf gestellt werden. Nach einer Korrektur werden neben der Ausführungsdauer auch Fehlerquote, CPU/Scan-Verhalten und Capacity-Kontext erneut geprüft. Die Entscheidung lautet dann nicht bloß „Job ist schneller“, sondern „Welche Hypothese wurde durch welche Messung bestätigt oder verworfen?“
Für wiederkehrende Muster sollten Unternehmen außerdem den betroffenen Fachprozess nennen: Eine um fünf Minuten verspätete interne Ad-hoc-Analyse kann tolerierbar sein; ein blockierter täglicher Rechnungslauf benötigt möglicherweise eine andere Eskalationsstufe. Die technische Metrik wird so mit einem tatsächlichen Geschäftsrisiko verbunden.
Welche Mindeststandards gehören in den Betrieb?
Ein robustes Monitoring benötigt mehr als technische Ansichten. Vor dem Produktiveinsatz sollten Teams festhalten, welche Abfragen geschäftskritisch sind, welche Laufzeiten toleriert werden, wer Monitoring-Daten und SQL-Texte sehen darf und wer über operative Eingriffe entscheidet.
Für wiederkehrende Reviews bieten sich vier Signale an: Fehlerquote, Laufzeitverteilung, CPU-/Scan-Trends und Capacity-Last im gleichen Zeitfenster. Bei personenbezogenen Query-Texten sowie Login- und Ausführungsinformationen müssen Berechtigungen und Aufbewahrung besonders bewusst gewählt werden. Preview-Funktionen gehören zudem in einen expliziten Änderungs- und Updateprozess.
Kleines Betriebsmodell: Zuständigkeiten, Rhythmus und messbare Ziele
Ein produktives Monitoring benötigt keine große neue Plattform, sondern verbindliche Verantwortlichkeiten. Warehouse-Owner bewerten Query- und Datenmodellprobleme, Capacity-Owner prüfen plattformweite Last und Throttling, und Fachverantwortliche definieren, welche Verzögerungen geschäftskritisch sind. Für jeden Alarm sollte klar sein, wer ihn erhält, wer nur lesend untersucht und wer Änderungen oder ein Rollback genehmigen darf.
Als pragmatischer Start reicht ein kleines Set: tägliche Sichtung fehlgeschlagener und besonders langer Geschäftsabfragen; wöchentlicher Vergleich stabiler Query-Hashes, Scanmengen und Capacity-Spitzen; monatliche Bewertung von Kapazitätsbedarf, Preview-Funktionsänderungen und Zugriffen auf SQL-Telemetrie. Für geschäftskritische Muster können eigene Schwellwerte und ein klarer Eskalationsweg ergänzt werden. Entscheidend ist weniger Alarmrauschen, mehr nachvollziehbare Maßnahmen.
Die Aufbewahrungsdauer begrenzt die Langzeitanalyse: Query Insights und das standardmäßige Workspace Monitoring bieten einen begrenzten historischen Blick. Wer Quartalstrends, SLA-Berichte oder längerfristige Kapazitätsentscheidungen benötigt, plant eine autorisierte und datenschutzkonforme Aggregation der nötigen Kennzahlen. Rohdaten wie Login-Namen oder vollständige SQL-Texte sollten dabei nur so lange und so breit zugänglich sein, wie die Aufgabe es verlangt.
Fazit: Monitoring beginnt mit der richtigen Frage
Microsoft Fabric stellt mehrere leistungsfähige Diagnosewege für Warehouses bereit. DMVs beantworten Live-Fragen, Query Insights erklärt historische Query-Muster, Monitor erleichtert den Portalzugang, Workspace Monitoring liefert eine workspaceweite Ereignissicht und die Capacity Metrics App ordnet die Plattformlast ein. Ein AI-Skill kann die Analyse ergänzen, aber keine fehlenden Berechtigungen oder Belege ersetzen.
Nicht die größte Zahl an Dashboards verbessert den Betrieb, sondern eine nachvollziehbare Verbindung von Symptom, Quelle, Hypothese und überprüfter Maßnahme. Wer diese Trennung etabliert, kann Query-Tuning und Kapazitätsplanung begründet priorisieren.
Nächste Schritte: Fabric-Warehouse-Betrieb gezielt stabilisieren
Wenn Warehouse-Queries regelmäßig bremsen, lohnt sich ein kleiner, nachvollziehbarer Monitoring-Pilot: zwei bis drei wiederkehrende Abfragemuster, definierte Zeitfenster, ein gemeinsamer Blick auf Query Insights und Capacity Metrics sowie konkrete Maßnahmen mit Vorher-/Nachher-Messung. Bei weitergehenden Architektur- und Betriebsfragen kann der Microsoft Fabric Kick Start helfen, einen passenden Pilot und ein belastbares Vorgehen aufzusetzen.
