Teilen über

Datensammlung und Datasets des Datenbankwatchers (Vorschau)

  • Artikel

Gilt für: Azure SQL-Datenbank Azure SQL Managed Instance

Der Datenbankwatcher erfasst Überwachungsdaten aus SQL-Systemansichten und nimmt sie in Form von Datasets in den Datenspeicher auf. Jedes Dataset wird anhand der Daten aus einer oder mehreren SQL-Systemansichten gebildet. Für jedes Dataset gibt es eine separate Tabelle im Datenspeicher.

Datensammlung

Der Datenbankwatcher erfasst Überwachungsdaten in regelmäßigen Intervallen mithilfe von T-SQL-Abfragen. Die in jeder Ausführung einer Abfrage erfassten Daten werden als Probe bezeichnet. Die Häufigkeit der Probenerfassung je nach Dataset unterschiedlich. So können zum Beispiel Daten, die sich häufig ändern, wie SQL-Leistungsindikatoren, alle 10 Sekunden erfasst werden, während überwiegend statische Daten, wie die Datenbankkonfiguration, vielleicht nur alle fünf Minuten erfasst werden. Weitere Informationen finden Sie unter Datasets.

Der Datenbankwatcher nutzt die Streamingerfassung im Azure Data Explorer und in der Echtzeitanalyse in Microsoft Fabric für eine Überwachung in Quasi-Echtzeit. In der Regel stehen erfasste SQL-Überwachungsdaten für Berichte und Analysen innerhalb von weniger als 10 Sekunden zur Verfügung. Über den Link Erfassungsstatistik können Sie die Datenerfassungslatenz auf den Dashboards des Datenbankwatchers überwachen.

Interaktion zwischen Datenbankwatcher und Anwendungsworkloads

Das Aktivieren des Datenbankwachters hat voraussichtlich keine erkennbaren Auswirkungen auf die Anwendungsworkloads. Häufigere Überwachungsabfragen werden in der Regel innerhalb von weniger als einer Sekunde ausgeführt, während Abfragen, die möglicherweise mehr Zeit erfordern, z. B. zum Zurückgeben großer Datasets, in selteneren Intervallen ausgeführt werden.

Um die Gefahr von Auswirkungen auf Anwendungsworkloads weiter zu verringern, werden alle Abfragen des Datenbankwatchers in Azure SQL-Datenbank ressourcengesteuert als interne Workload behandelt. Im Fall eines Ressourcenkonflikts wird der Ressourcenverbrauch durch die Überwachungsabfragen auf einen kleinen Bruchteil der Gesamtressourcen beschränkt, die für die Datenbank verfügbar sind. Dadurch werden Anwendungsworkloads gegenüber Überwachungsabfragen priorisiert.

Zum Vermeiden von Nebenläufigkeitskonflikten wie Blockierungen und Deadlocks zwischen der Datensammlung und Datenbankworkloads, die in den Azure SQL-Ressourcen ausgeführt werden, nutzen die Überwachungsabfragen kurze Sperrtimeouts und eine niedrige Deadlockpriorität. Im Fall eines Nebenläufigkeitskonflikts haben Anwendungsworkload-Abfragen Vorrang. Je nach Muster der Anwendungsworkloads können dadurch bei manchen DataSets gelegentlich Lücken in den gesammelten Daten entstehen.

Datensammlung in Pools für elastische Datenbanken

Zum Überwachen eines Pool für elastische Datenbanken müssen Sie eine Datenbank im Pool als Ankerdatenbank festlegen. Der Datenbankwatcher verbindet sich mit der Ankerdatenbank. Da der Watcher die VIEW SERVER PERFORMANCE STATE-Berechtigung besitzt, stellen Systemansichten in der Ankerdatenbank Überwachungsdaten für den Pool als Ganzes bereit.

Tipp

Sie können zu jedem Pool für elastische Datenbanken, den Sie überwachen möchten, eine leere Datenbank hinzufügen und als Ankerdatenbank festlegen. Auf diese Weise können Sie andere Datenbanken in den Pool, aus dem Pool oder zwischen Pools verschieben, ohne dass die Überwachung des Pools für elastische Datenbanken unterbrochen wird.

Die aus der Ankerdatenbank erfassten Daten enthalten Metriken auf Poolebene und bestimmte Leistungsmetriken auf Datenbankebene für jede Datenbank im Pool. Dazu gehören z. B. Metriken zur Ressourcenverwendung und Anforderungsrate für jede Datenbank. In manchen Szenarien macht die Überwachung eines Pools für elastische Datenbanken als Ganzes die Überwachung jeder einzelne Datenbank im Pool überflüssig.

Bestimmte Überwachungsdaten wie CPU-, Arbeitsspeicher- und Speicherauslastung auf Poolebene sowie Wartezeitstatistiken werden nur auf der Ebene des Pools für elastische Datenbanken erfasst, da sie nicht einer einzelnen Datenbank in einem Pool zugeordnet werden können. Umgekehrt sind bestimmte andere Daten wie Abfragelaufzeitstatistiken, Datenbankeigenschaften, Tabellen- und Indexmetadaten nur auf Datenbankebene verfügbar.

Wenn Sie einzelne Datenbanken aus einem Pool für elastische Datenbanken als Ziele des Datenbankwatchers hinzufügen, sollten Sie auch den Pool selbst als Ziel hinzufügen. Auf diese Weise erhalten Sie eine vollständigere Ansicht der Leistung von Datenbank und Pool.

Überwachen umfangreicher Pools für elastische Datenbanken

Ein umfangreicher Pool für elastische Datenbanken enthält eine große Anzahl von Datenbanken, hat jedoch eine relativ kleine Computegröße. Mit dieser Konfiguration können Kunden erhebliche Kosteneinsparungen erzielen, indem sie die Zuteilung von Compute-Ressourcen auf ein Minimum beschränken, wenn davon auszugehen ist, dass nur eine kleine Anzahl von Datenbanken im Pool gleichzeitig aktiv ist.

Die Compute-Ressourcen, die in einem umfangreichen Pool für elastische Datenbanken für Abfragen des Datenbankwatchers verfügbar sind, werden weiter begrenzt, um Auswirkungen auf Anwendungsabfragen zu vermeiden. Aus diesem Grund kann der Datenbankwatcher in einem umfangreichen Pool für elastische Datenbanken eventuell nicht für jede Datenbank Überwachungsdaten erfassen.

Tipp

Aktivieren Sie zum Überwachen eines umfangreichen Pools für elastische Datenbanken die Überwachung auf Poolebene, indem Sie den Pool als Ziel hinzufügen.

Es ist nicht zu empfehlen, in einem umfangreichen Pool für elastische Datenbanken, mehr als nur einige wenige einzelne Datenbanken zu überwachen. Es könnte zu Lücken in den erfassten Daten oder größeren Intervalle zwischen Datenproben als erwartet kommen, weil für die Abfragen des Datenbankwachters keine ausreichenden Compute-Ressourcen zur Verfügung stehen.

Datenresidenz

Kund*innen können sich entscheiden, gesammelte SQL Monitoring-Daten in einem von drei Datenspeichertypen zu speichern:

  • Eine Datenbank auf einem Azure Data Explorer-Cluster. Standardmäßig wird für jeden neuen Watcher ein neuer Azure Data Explorer-Cluster erstellt, der sich in derselben Azure-Region wie der Watcher befindet.

    Kund*innen können die genaue Azure-Region in einer Azure-Geografie als Standort ihres Azure Data Explorer-Clusters und der Datenbank auswählen. Weitere Informationen über Datenreplikationsfunktionalitäten in Azure Data Explorer finden Sie unter Übersicht über Business Continuity & Disaster Recovery.

  • Eine Datenbank auf einem kostenlosen Azure Data Explorer-Cluster.

    Kund*innen können die genaue Azure-Geografie, aber nicht die genaue Azure-Region als Standort ihres kostenlosen Azure Data Explorer-Clusters und der Datenbank auswählen. Die Datenreplikation in einer anderen Region oder Geografie wird nicht unterstützt.

  • Eine Datenbank in der Echtzeitanalyse in Microsoft Fabric.

    Kund*innen können den geografischen Standort der Datenbank nicht auswählen.

Um die Datenresidenz für gesammelte SQL Monitoring-Daten vollständig zu steuern, müssen Kund*innen eine Datenbank in einem Azure Data Explorer-Cluster als Datenspeicher auswählen.

Kund*innen können auch die Geografie und Region ihres Azure Data Explorer-Clusters an die Geografie und Region der überwachten Azure SQL-Ressourcen ausrichten. Wenn sich die Azure SQL-Ressourcen in mehreren Regionen befinden, müssen Kund*innen möglicherweise mehrere Watcher und mehrere Azure Data Explorer-Cluster erstellen, um ihre Datenresidenzanforderungen zu erfüllen.

Datasets

Dieser Abschnitt beschreibt die für jeden Zieltyp verfügbaren Datasets, einschließlich Häufigkeit der Erfassung und Tabellennamen im Datenspeicher.

Hinweis

Während der Vorschau könnten Datasets hinzukommen oder wegfallen. Die Eigenschaften von Datasets wie Name, Beschreibung, Häufigkeit der Erfassung und verfügbare Spalten können sich noch ändern.

Datasetname Tabellenname Häufigkeit der Erfassung (hh:mm:ss) Beschreibung
Aktive Sitzungen sqldb_database_active_sessions 00:00:30 Jede Zeile stellt eine Sitzung dar, die eine Anforderung ausführt, ein Blocker ist oder eine offene Transaktion hat.
Sicherungsverlauf sqldb_database_sql_backup_history 00:05:00 Jede Zeile stellt eine erfolgreich abgeschlossene Datenbanksicherung dar.
Verarbeitung von Änderungen sqldb_database_change_processing 00:01:00 Jede Zeile stellt eine Momentaufnahme aggregierter Protokollscanstatistiken für ein Feature zur Verarbeitung von Änderungen wie Change Data Capture oder Änderungsfeed (Azure Synapse Link) dar.
Fehler bei der Verarbeitung von Änderungen sqldb_database_change_processing_errors 00:01:00 Jede Zeile stellt einen Fehler dar, der während der Verarbeitung von Änderungen aufgetreten ist, wenn ein Feature zur Verarbeitung von Änderungen wie Change Data Capture oder Änderungsfeed (Azure Synapse Link) eingesetzt wird.
Konnektivität sqldb_database_connectivity 00:00:30 Jede Zeile stellt einen Verbindungstest (eine Anmeldung und eine Abfrage) für eine Datenbank dar.
Georeplikate sqldb_database_geo_replicas 00:00:30 Jede Zeile stellt ein primäres oder sekundäres Georeplikat dar, einschließlich Metadaten und Statistiken zur Georeplikation.
Index-Metadaten sqldb_database_index_metadata 00:30:00 Jede Zeile stellt eine Indexpartition dar und enthält Indexdefinition, Eigenschaften und Betriebsstatistiken.
Arbeitsspeichernutzung sqldb_database_memory_utilization 00:00:10 Jede Zeile stellt einen Arbeitsspeicherclerk dar und enthält den Speicherverbrauch durch den Clerk in der Instanz der Datenbank-Engine.
Fehlende Indizes sqldb_database_missing_indexes 00:15:00 Jede Zeile stellt einen Index dar, der im Fall seiner Erstellung die Abfrageleistung verbessern könnte.
Ereignisse mit unzureichendem Arbeitsspeicher sqldb_database_oom_events 00:01:00 Jede Zeile stellt ein Ereignis mit unzureichendem Arbeitsspeicher in der Datenbank-Engine dar.
Leistungsindikatoren (allgemein) sqldb_database_performance_counters_common 00:00:10 Jede Zeile stellt einen Leistungsindikator der Instanz der Datenbank-Engine dar. Dieses Dataset enthält häufig verwendete Leistungsindikatoren.
Leistungsindikatoren (detailliert) sqldb_database_performance_counters_detailed 00:01:00 Jede Zeile stellt einen Leistungsindikator der Instanz der Datenbank-Engine dar. Dieses Dataset enthält Leistungsindikatoren, die gegebenenfalls für eine detaillierte Überwachung und Problembehandlung erforderlich sind.
Eigenschaften sqldb_database_properties 00:05:00 Jede Zeile stellt eine Datenbank dar und enthält Datenbankoptionen, Grenzwerte für die Ressourcengovernance und andere Datenbankmetadaten.
Abfrage-Laufzeitstatistiken sqldb_database_query_runtime_stats 00:15:00 Jede Zeile stellt ein Laufzeitintervall des Abfragespeichers dar und enthält Abfrage-Ausführungsstatistiken.
Abfrage-Wartezeitstatistiken sqldb_database_query_wait_stats 00:15:00 Jede Zeile stellt ein Laufzeitintervall des Abfragespeichers dar und enthält Statistiken zu Wartekategorien.
Replikate sqldb_database_replicas 00:00:10 Jede Zeile stellt ein Datenbankreplikat dar, einschließlich Metadaten und Statistiken zur Replikation. Enthält das primäre Replikat und Georeplikate bei Erfassung im primären Replikat und sekundäre Replikate bei Erfassung in einem sekundären Replikat.
Ressourcenverwendung sqldb_database_resource_utilization 00:00:15 Jede Zeile stellt Statistiken zum CPU-, Daten-E/A-, Protokoll-E/A- und sonstigen Ressourcenverbrauch für eine Datenbank in einem Zeitintervall dar.
Sitzungsstatistiken sqldb_database_session_stats 00:01:00 Jede Zeile stellt eine Zusammenfassung der Sitzungsstatistiken für eine Datenbank dar, aggregiert nach nicht-additiven Sitzungsattributen wie Anmeldename, Hostname, Anwendungsname usw.
SOS-Planer sqldb_database_sos_schedulers 00:01:00 Jede Zeile stellt einen SOS-Planer dar und enthält Statistiken für den Planer, den CPU-Knoten und den Arbeitsspeicherknoten.
Speicher-E/A sqldb_database_storage_io 00:00:10 Jede Zeile stellt eine Datenbankdatei dar und enthält kumulative Statistiken zu IOPS, Durchsatz und Wartezeit für die Datei.
Speichernutzung sqldb_database_storage_utilization 00:01:00 Jede Zeile stellt eine Datenbank dar und enthält ihre Speichernutzung, einschließlich tempdb, Abfragespeicher und permanentem Versionsspeicher.
Tabellenmetadaten sqldb_database_table_metadata 00:30:00 Jede Zeile stellt eine Tabelle oder eine indizierte Sicht dar und enthält Metadaten wie Zeilenanzahl, Platzbedarf, Datenkomprimierung, Spalten und Einschränkungen.
Wartestatistiken sqldb_database_wait_stats 00:00:10 Jede Zeile stellt einen Wartetyp dar und enthält kumulative Wartezeitstatistiken der Instanz der Datenbank-Engine. Bei Datenbanken in einem Pool für elastische Datenbanken werden nur datenbankbezogene Wartezeitstatistiken erfasst.

Hinweis

Bei Datenbanken in einem Pool für elastische Datenbanken werden die SQL-Datenbank-Datasets, die Daten auf Poolebene enthalten, nicht erfasst. Dazu gehören die Datasets für Arbeitsspeichernutzung, Ereignisse mit unzureichendem Arbeitsspeicher, Leistungsindikatoren (allgemein) und Leistungsindikatoren (detailliert). Das Dataset für die Wartezeitstatistik wird erfasst, enthält jedoch nur datenbankbezogene Wartezeiten. Dadurch wird vermieden, dass von jeder Datenbank im Pool die gleichen Daten erfasst werden.

Daten auf Poolebene werden in den Datasets für den Pool für elastische SQL-Datenbanken erfasst. Für einen bestimmten Pool für elastische Datenbanken enthalten die Datasets für Leistungsindikatoren (allgemein) und Leistungsindikatoren (detailliert) Metriken auf Poolebene und gewisse Metriken auf Datenbankebene, wie CPU, Daten-E/A, Protokollschreibvorgänge, Anforderungen, Transaktionen usw.

Allgemeine Spalten

Für jeden Zieltyp haben Datasets allgemeine Spalten, wie in den folgenden Tabellen beschrieben.

Spaltenname Beschreibung
subscription_id Die Azure-Abonnement-ID der SQL-Datenbank.
resource_group_name Der Name der Ressourcengruppe der SQL-Datenbank.
resource_id Die Azure-Ressourcen-ID der SQL-Datenbank.
sample_time_utc Die Zeit, zu der die Werte in der Zeile beobachtet wurden, in UTC.
collection_time_utc Die Zeit, zu der die Zeile vom Watcher erfasst wurde, in UTC. Diese Spalte ist in Datasets vorhanden, bei denen die Erfassungszeit von der Probenzeit abweichen kann.
replica_type Eine der folgenden Optionen: Primär, Hochverfügbar sekundär, Georeplikationsweiterleitung, Benannt sekundär.
logical_server_name Der Name des logischen Servers in Azure SQL-Datenbank, der die überwachte Datenbank oder den Pool für elastische Datenbanken enthält.
database_name Der Name der überwachten Datenbank.
database_id Datenbank-ID der überwachten Datenbank, eindeutig innerhalb des logischen Servers.
logical_database_id Ein eindeutiger Datenbankbezeichner, der während der Lebensdauer der Benutzerdatenbank unverändert bleibt. Durch Umbenennen der Datenbank oder Ändern des Serviceobjekts ändert sich dieser Wert nicht.
physical_database_id Ein eindeutiger Datenbankbezeichner für die aktuelle physische Datenbank, die der Benutzerdatenbank entspricht. Durch Ändern des Serviceobjekts der Datenbank ändert sich dieser Wert.
replica_id Ein eindeutiger Bezeichner für ein Hyperscale-Compute-Replikat.

Ein Dataset hat sowohl die Spalte sample_time_utc als auch collection_time_utc, wenn es Proben enthält, die vor der Erfassung der Zeile durch den Datenbankwatcher beobachtet wurden. Ansonsten sind Beobachtungszeit und Erfassungszeit gleich, und das Dataset enthält nur die Spalte sample_time_utc.

Beispielsweise wird das Dataset sqldb_database_resource_utilization aus der dynamischen Verwaltungssicht (DMV) sys.dm_db_resource_stats abgeleitet. Die DMV enthält die Spalte end_time, bei der es sich um die Beobachtungszeit für jede Zeile handelt, die aggregierte Ressourcenstatistiken für ein Intervall von 15-Sekunden angibt. Diese Zeit wird in der Spalte sample_time_utc angegeben. Wenn der Datenbankwatcher diese DMV abfragt, enthält das Resultset möglicherweise mehrere Zeilen, jeweils mit einem anderen end_time. Alle diese Zeilen haben denselben Wert collection_time_utc.

Zugehöriger Inhalt