Database Hub in Microsoft Fabric: Datenbank-Observability über Azure, Fabric und On-Premises

Database Hub in Microsoft Fabric soll Datenbankteams eine einheitliche Sicht auf ihre Datenbanklandschaft geben: Welche Ressourcen existieren, wo bestehen Probleme, welche Optimierungen sind möglich und welche Teams müssen handeln? Das klingt nach umfassender Observability für Azure, Fabric und On-Premises. Der entscheidende Vorbehalt lautet jedoch: Database Hub befindet sich weiterhin in Preview. Unterstützung und Monitoring unterscheiden sich je Datenbankdienst, Region und Berechtigung. Vor allem Fabric Data Warehouse wird derzeit nicht abgedeckt.

Für Unternehmen ist Database Hub deshalb heute vor allem eine Chance für ein besseres Inventory-, Triage- und Governance-Betriebsmodell. Es ersetzt nicht automatisch das Monitoring der einzelnen Datenbank-Engines oder eine vollständige Observability-Plattform. Wer den Pilot korrekt eingrenzt, kann dennoch fragmentierte operative Informationen zu einem gemeinsamen Entscheidungsbild zusammenführen.

Was ist der Database Hub in Microsoft Fabric?

Database Hub ist eine übergreifende Oberfläche im Fabric-Portal, die unterstützte Datenbankressourcen aus unterschiedlichen Microsoft-Umgebungen zusammenführt. Die Datenbanken bleiben an ihren ursprünglichen Orten: etwa Azure SQL Database, einer Arc-verwalteten SQL-Server-Instanz oder SQL database in Fabric. Der Hub aggregiert verfügbare Ressourceninformationen, Statushinweise, Performance-Sichten und Handlungsempfehlungen.

Das ist eine wichtige Architekturabgrenzung. Database Hub ist kein weiteres Data Warehouse und kein universeller Datensynchronisationsdienst. Es macht nicht automatisch alle Datenbanken zu Fabric-Datenbanken, verschiebt keine produktiven Daten und erteilt keine neuen Zugriffsrechte. Der dargestellte Bestand hängt von bereits vorhandenen Identitäten, Rollen und unterstützten Diensten ab.

Preview-Status und Lizenzierung richtig verstehen

Microsoft beschreibt Database Hub ausdrücklich als Preview. Für den Zugang kann laut Microsoft eine Fabric Free-Lizenz genügen; eine eigene Fabric-Capacity oder gesonderte Database-Hub-Lizenz ist für den Einstieg nicht erforderlich. Das gilt nicht automatisch für die darunterliegenden Datenbankdienste, deren Betrieb weiterhin eigene Kosten, Abonnements oder Kapazitäten verursachen kann.

Vorschaufeatures können in verschiedenen Tenants und Regionen unterschiedlich verfügbar sein. Insbesondere sollten vor dem Rollout die Voraussetzungen für Preview-Enrolment, My Workspace, Azure Resource Provider und Performance-Monitoring geprüft werden. Eine im Portal angezeigte Ressourcenliste ist kein Beweis dafür, dass alle Funktionen für alle Datenbanken gleichermaßen laufen.

Welche Datenbankdienste werden unterstützt?

Microsoft nennt im aktuellen Preview unter anderem Azure SQL Database, Azure SQL Elastic Pools, Azure SQL Managed Instance, SQL database in Microsoft Fabric, SQL Server mit Azure Arc, SQL Server auf Azure Virtual Machines, Azure Database for PostgreSQL Flexible Server und Azure Cosmos DB. Damit deckt der Hub mehrere relevante Verwaltungsdomänen ab: Cloud-Datenbanken, Arc-integrierte On-Premises-Systeme und Teile der Fabric-Datenbankwelt.

Die Liste ist allerdings kein Funktionsversprechen pro Engine. Welche Issues, Suggestions, Performance-Signale und Aktionen verfügbar sind, hängt von Datenbanktyp, Region, Konfiguration und Zugriffsrechten ab. Vor allem dürfen Azure Cosmos DB und Cosmos DB in Fabric nicht verwechselt werden; der Hub unterstützt nicht automatisch beide Varianten.

Explizite Lücken: Fabric Warehouse und weitere Workloads

Aktuell nicht unterstützt werden Fabric Data Warehouse, gespiegelte Datenbanken in Fabric und Cosmos DB in Fabric. Gerade die Warehouse-Lücke ist für Fabric-zentrierte Unternehmen entscheidend. Ein Team, das SQL Warehouse-Performance, laufende Queries, Kapazitätsverbrauch oder Warehouse-Sicherheit überwachen will, braucht dafür weiterhin workload-spezifische Werkzeuge.

Database Hub darf daher nicht als alleinige Grundlage einer Fabric-weiten Betriebsüberwachung eingeführt werden. Sinnvoll ist eine Coverage-Matrix, in der jeder Dienst und jedes relevante Signal als unterstützt, teilweise unterstützt oder nicht unterstützt dokumentiert wird. Das verhindert blinde Flecken in Betriebsreports und Eskalationen.

Vom Overview zur Estate-Sicht

Die Overview-Seite liefert ein aggregiertes Lagebild: vorhandene Probleme, potenzielle Optimierungen und Hinweise auf Ressourcen, die besondere Aufmerksamkeit benötigen. Die Estate-Sicht dient dazu, den betroffenen Bestand zu durchsuchen, nach Kriterien zu filtern und einzelne Ressourcen genauer zu untersuchen. Sie eignet sich insbesondere für Plattform- und Datenbankteams, die bisher zwischen mehreren Portalen wechseln mussten.

Für die tägliche Arbeit zählt nicht die Anzahl der bunten Kacheln, sondern der Kontext der Findings. Eine Ressource kann mehrere Hinweise besitzen, die unterschiedliche Ursachen haben. Ein einheitlicher Triage-Prozess muss daher Schweregrad, betroffene Geschäftsprozesse, verantwortliche Teams und bereits bekannte Wartungsarbeiten zusammenbringen.

Issues und Suggestions sind zwei verschiedene Handlungsarten

Issues stehen für Bedingungen, die zeitnah untersucht oder behoben werden sollten – etwa Sicherheitsrisiken oder konkrete Betriebsprobleme. Suggestions liefern Möglichkeiten, Sicherheit, Leistung, Ressourcennutzung oder Kosten über längere Zeit zu verbessern. Wer beide Kategorien in eine einzige Maßnahmenliste ohne Priorisierung mischt, verliert die Dringlichkeit.

Ein wirkungsvoller Prozess behandelt kritische Security-Hinweise zunächst unabhängig vom möglichen Effizienzgewinn. Vorschläge zur Optimierung werden anschließend anhand von Auswirkung, Aufwand und Risiko priorisiert. Die redaktionelle beziehungsweise organisatorische Kennzeichnung „Issue“ ist keine automatische Change-Freigabe; jede Handlung benötigt ihre eigene technische und fachliche Bewertung.

Performance beobachten – aber engine-spezifisch

Der integrierte Performance-Bereich soll Trends und relevante Zustandsänderungen sichtbar machen. Je nach Engine stehen unterschiedliche Messwerte, Voraussetzungen und Detailansichten zur Verfügung. Das macht den Hub nützlich als Einstieg in die Fehlersuche, jedoch nicht zu einem universellen Ersatz für Extended Events, Azure Monitor, Query Store, SQL-spezifische Werkzeuge oder bestehende Incident-Plattformen.

Microsoft nennt für Azure SQL Database eine zusätzliche Konfiguration zur Erhebung der Performance-Daten. Diese kann über die Benutzeroberfläche oder mit bereitgestellten T-SQL-Schritten aktiviert werden. Für bestimmte Ressourcen müssen zudem die nötigen Azure-Ressourcenanbieter registriert sein. Ein leeres Dashboard ist deshalb nicht automatisch gleichbedeutend mit einem gesunden System; zunächst muss die Datenabdeckung geprüft werden.

Observability-Prozess: Inventory, Signal, Triage, Aktion

Eine robuste Betriebsstrecke beginnt mit der Erfassung des berechtigten Datenbankbestands. Anschließend werden verfügbare Findings klassifiziert, mit technischen Metriken angereichert und an einen klar benannten Owner übergeben. Dieser entscheidet über Untersuchung, Eskalation und gegebenenfalls Änderung. Die Ergebnisse einschließlich Evidenz, Ticket und Abschlussbewertung werden dokumentiert.

Damit der Prozess funktioniert, sollte jede Datenbank eine verantwortliche Einheit, eine Kritikalität, eine Umgebung und einen dokumentierten Ansprechpartner besitzen. Der Database Hub kann dann Hinweise bündeln, während bestehende Monitoring- und Ticketing-Systeme den operativen Ablauf absichern. Ein Dashboard ist hilfreich, aber noch kein Operating Model.

Berechtigungen und Zugriff über Entra ID

Database Hub verwendet vorhandene Microsoft-Entra- und Plattformberechtigungen, beispielsweise Azure RBAC sowie Fabric-Rollen. Die Sicht auf einen Datenbankbestand ist deshalb von der angemeldeten Identität abhängig. Das ist grundsätzlich richtig, führt aber in großen Organisationen zu einer praktischen Herausforderung: Eine individuelle Ansicht ist nicht automatisch ein vollständiges Inventar aller geschäftskritischen Datenbanken.

Ein Betriebsmodell sollte definieren, welche Dienstkonten oder Benutzer welche Ressourcen sehen dürfen, wie Lücken erkannt und wie Berechtigungen regelmäßig überprüft werden. Gespeicherte oder geteilte Ansichten ersetzen keine Zugriffsrechte. Besonders sensible Findings – beispielsweise zu Sicherheitskonfigurationen – sollten nur dem zuständigen Personenkreis verfügbar sein.

Database Hub Agent Skills: Untersuchungsunterstützung statt Autonomie

Microsoft beschreibt vorgefertigte Agent Skills, die die Arbeit mit Database-Hub-Signalen unterstützen. Ein solcher Skill kann den Kontext eines Problems strukturieren, relevante Informationen erläutern und mögliche nächste Untersuchungsfragen formulieren. Das kann für weniger routinierte Teams sehr wertvoll sein und wiederkehrende Triage-Schritte beschleunigen.

Skills vergeben jedoch weder zusätzliche Datenbankrechte noch ersetzen sie die Prüfung möglicher Maßnahmen. Ein Agent kann aus einem Finding eine plausible Änderung empfehlen, ohne alle betrieblichen Abhängigkeiten zu kennen. Jede Remediation sollte deshalb mit technischer Evidenz, verantwortlichem Owner, Risikoabschätzung und einem Freigabeschritt verbunden sein. Eine automatische Reparatur ohne nachvollziehbare Entscheidungsgrundlage wäre gerade in Preview ein zu großes Risiko.

Gespeicherte Ansichten und Zusammenarbeit

In einer größeren Datenbanklandschaft brauchen Plattform- und Anwendungsteams unterschiedliche Perspektiven. Eine zentrale Datenbankgruppe interessiert sich für kritische Incidents über alle zugänglichen Systeme, während ein Produktteam seine eigenen Datenbanken im Blick behalten will. Gefilterte, gespeicherte und teilbare Ansichten können diese Rollen unterstützen, sofern der Dienst sie für die jeweiligen Ressourcen bereitstellt.

Wichtig ist die Trennung zwischen Ansicht und Autorisierung. Eine weitergegebene Ansicht erteilt nicht selbst Zugriff auf Datenbanken. Für verbindliche Betriebsreports sollten zusätzlich Zeitpunkt, Filterdefinition, Datenabdeckung und eventuelle Preview-Einschränkungen dokumentiert werden. Nur so lassen sich Verlauf und Vollständigkeit später bewerten.

Regionale Grenzen und zusätzliche Voraussetzungen

Die aktuelle Microsoft-Dokumentation weist darauf hin, dass Database Hub im Preview bei Fabric-Kapazitäten in North Europe und West Europe Einschränkungen besitzt. Unter Umständen öffnet die Overview-Seite, während weitere Funktionen Fehler zeigen. Der konkrete Workaround und die Zulässigkeit anderer Regionen müssen unter Datenschutz- und Betriebsaspekten bewertet werden. Eine unbegründete Verlagerung produktiver Ressourcen wäre keine angemessene Standardlösung.

Besonders bei europäischen Unternehmen ist deshalb vor einem Pilot zu klären, welche Fabric-Kapazität die Hub-Oberfläche hostet und welche Datenbankressourcen nur remote betrachtet werden. Das regionale Verhalten der Oberfläche und die physische Region der Datenbank sind zwei verschiedene Sachverhalte.

Praxispilot: fünf überprüfbare Schritte

1. Ressourceninventar abgleichen: Den sichtbaren Estate-Bestand mit dem autoritativen Asset-Inventar vergleichen. 2. Coverage erfassen: Für jeden Dienst die tatsächlich vorhandenen Signale und Voraussetzungen dokumentieren. 3. Findings triagieren: Issues und Suggestions mit eigener Kritikalität und Verantwortlichem verknüpfen. 4. Performance ergänzen: Engine-spezifische Werkzeuge für fehlende Signale beibehalten. 5. Review durchführen: Qualität der Hinweise, Zeitersparnis, False Positives und betriebliche Risiken bewerten.

Als Erfolgskriterium bietet sich nicht „alle Datenbanken in einer Ansicht“ an, weil die Preview diese Vollständigkeit gerade nicht garantiert. Aussagekräftiger sind die Zeit bis zur Erkennung eines relevanten Problems, die Quote korrekt zugeordneter Owner und die Zahl nachvollziehbar abgeschlossener Fälle.

Database Hub, Fabric Monitoring und Governance richtig kombinieren

Ein tragfähiges Zielbild trennt drei Ebenen: Database Hub für übergreifendes Estate-Management und unterstützte Findings; native Workload-Monitoring-Werkzeuge für technische Tiefe; Governance und Incident Management für Zuständigkeiten, Freigaben und Evidenz. Diese Kombination ist robuster als der Versuch, ein einzelnes Preview-Dashboard zur zentralen Wahrheit zu erklären.

Gerade Fabric Data Warehouse, SQL-spezifische Performance-Fragen und Kapazitätsauslastung benötigen weiterhin eigene Sichten. Wer darüber hinaus AI-Agenten für Untersuchungen nutzen will, sollte zunächst lesende Anwendungsfälle definieren und Ergebnisse durch Fachexperten validieren.

---

Fazit

Database Hub ist ein relevanter Schritt in Richtung zentraler Datenbank-Observability, aber sein aktueller Preview-Umfang ist begrenzt. Der Mehrwert liegt heute in transparenterem Bestand, besserer Triage und klareren Verantwortlichkeiten, nicht in einer angeblich lückenlosen Fabric-weiten Überwachung.

---

Nächster Schritt

Für einen seriösen Database-Hub-Pilot sollten unterstützte Services, vorhandene Monitoringsysteme, Governance-Anforderungen und Betriebsrollen gemeinsam geprüft werden. Der Data Strategy Check eignet sich als Einstieg. Der Beitrag Fabric Data Agent API & SDK vertieft, wie Agenten in einen kontrollierten Datenplattformbetrieb eingebettet werden können.