Datensammlung und Datasets des Datenbankwatchers (Vorschau)

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 der Datenbanküberwachung wirkt sich wahrscheinlich nicht erheblich auf die Leistung der Anwendungsworkloads aus. 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.

USE master;
GO

CREATE OR ALTER FUNCTION dbo.dbw_classifier()
RETURNS sysname
WITH SCHEMABINDING
AS
BEGIN

DECLARE @WorkloadGroupName sysname = 'default';

IF APP_NAME() IN (N'SQLExternalMonitoring',N'x_ms_reserved_sql_external_monitoring')
    SET @WorkloadGroupName = N'database_watcher_workload_group'

RETURN @WorkloadGroupName;

END;
GO

BEGIN TRY

IF EXISTS (
          SELECT 1
          FROM sys.resource_governor_configuration
          WHERE classifier_function_id <> 0 OR is_enabled <> 0
          )
    THROW 50001, 'Resource Governor is already configured. No changes were made.', 1;

CREATE RESOURCE POOL database_watcher_resource_pool
WITH (MIN_CPU_PERCENT = 5, MAX_CPU_PERCENT = 10, CAP_CPU_PERCENT = 30);

CREATE WORKLOAD GROUP database_watcher_workload_group
WITH (REQUEST_MAX_MEMORY_GRANT_PERCENT = 10)
USING database_watcher_resource_pool;

ALTER RESOURCE GOVERNOR WITH (CLASSIFIER_FUNCTION = dbo.dbw_classifier);

ALTER RESOURCE GOVERNOR RECONFIGURE;

END TRY
BEGIN CATCH
    THROW;
END CATCH;

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.

Möglicherweise kommt es in den gesammelten Daten zu Lücken, wenn die Gesamtressourcenauslastung hoch ist oder Konflikte bei der Parallelität auftreten. In diesen Fällen wird die Priorität der Überwachungsabfragen eventuell zugunsten von Anwendungsworkloads heruntergestuft.

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.

Die von der Ankerdatenbank gesammelten Daten enthalten Metriken auf Poolebene und bestimmte Leistungsmetriken auf Datenbankebene für jede Datenbank im Pool, z. B. zur Ressourcenauslastung und zur Anforderungsrate für jede Datenbank. In einigen Szenarien ist es möglicherweise nach dem Hinzufügen eines SQL-Ziels aus einem Pool für elastische Datenbanken zur Überwachung des gesamten Pools nicht mehr erforderlich, jede einzelne Datenbank im Pool zu überwachen.

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 Statistiken zur Abfragelaufzeit, Datenbankeigenschaften, Tabellen- und Indexmetadaten nur verfügbar, wenn Sie einzelne Datenbanken als SQL-Ziele hinzufügen.

Wenn Sie einzelne Datenbanken aus einem Pool für elastische Datenbanken als SQL-Ziele hinzufügen, sollten Sie auch den Pool für elastische Datenbanken als SQL-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.

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.

Kunden können die Geografie und Region ihres Azure Data Explorer-Clusters an die Geografie und Region der zu überwachenden Azure SQL-Ressourcen anpassen. 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

In diesem Abschnitt werden die Datasets beschrieben, die für jeden SQL-Zieltyp verfügbar sind, einschließlich der Sammlungshäufigkeit und der Tabellennamen im Datenspeicher.

Allgemeine Spalten

Bei allen SQL-Zieltypen haben die Datasets gemeinsame Spalten, wie in den folgenden Tabellen beschrieben.

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

• Überwachen von Azure SQL-Workloads mit Datenbankwatcher (Vorschau)
• Schnellstart: Erstellen eines Datenbankwatchers zum Überwachen von Azure SQL (Vorschau)
• Erstellen und Konfigurieren eines Datenbankwatchers (Vorschau)
• Analysieren von Überwachungsdaten des Datenbankwatchers (Vorschau)
• Häufig gestellte Fragen zum Datenbankwatcher