Freigeben über

Überwachen von Azure SQL-Workloads mit Datenbankwatcher (Vorschau)

  • Artikel

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

Der Datenbankwatcher ist eine verwaltete Überwachungslösung für Datenbankdienste in der Azure SQL-Familie. Unterstützt werden Azure SQL-Datenbank und Azure SQL Managed Instance.

Der Datenbankwatcher erfasst detaillierte Workload-Überwachungsdaten und vermittelt Ihnen detaillierte Einblicke in die Datenbankleistung, Konfiguration und Integrität. Die Überwachungsdaten den von Ihnen ausgewählten Datenbanken, Pools für elastische Datenbanken und SQL Managed Instances werden in einem zentralen Datenspeicher in Ihrem Azure-Abonnement erfasst. Dashboards im Azure-Portal vermitteln einen umfassenden Überblick über Ihre Azure SQL-Umgebung und detaillierte Einblicke in alle Datenbanken, Pools für elastische Datenbanken und SQL Managed Instances.

Ein Diagramm zeigt die Komponenten des Datenbankwatchers und den Datenfluss von den überwachten Ressourcen zum Watcher, zum Datenspeicher und zu den Dashboards im Azure-Portal.

Zum Speichern und Analysieren der SQL-Überwachungsdaten kann der Datenbankwatcher entweder den Azure Data Explorer oder die Echtzeitanalyse in Microsoft Fabric verwenden. Der Azure Data Explorer ist ein vollständig verwalteter, hochgradig skalierbarer Datendienst, der speziell auf die schnelle Erfassung und Analyse von Zeitreihen-Überwachungsdaten ausgelegt ist. Ein einzelner Azure Data Explorer-Cluster kann so skaliert werden, dass er Überwachungsdaten aus Tausenden von Azure SQL-Ressourcen unterstützt. Die Echtzeitanalyse verwendet dieselbe Kern-Engine wie ein SaaS-Angebot in Microsoft Fabric.

Sie können Daten in einer Azure Data Explorer- oder einer Echtzeitanalyse-Datenbank mittels KQL oder T-SQL abfragen, benutzerdefinierte Visualisierungen mit Azure Data Explorer-Dashboards, Power BI oder Grafana erstellen und Daten in Excel analysieren. Sie können eine Richtlinie für die Datenaufbewahrung pro Datenbank oder pro Tabelle festlegen und Ihren Azure Data Explorer-Cluster automatisch oder manuell so skalieren, dass ein optimales Preis-/Leistungsverhältnis erzielt wird.

Um mit der Überwachung Ihrer Azure SQL-Ressourcen zu beginnen, müssen Sie eine Watcher-Ressource in Ihrem Azure-Abonnement erstellen. Konfigurieren Sie den Watcher durch Auswählen eines Datenspeichers und einer Reihe von zu überwachenden Datenbanken, Pools für elastische Datenbanken oder SQL Managed Instances, den sogenannten SQL-Zielen. Gewähren Sie dem Watcher Zugriff auf Ziele, und starten Sie den Watcher.

Hinweis

Der Datenbankwatcher befindet sich derzeit in der Vorschau. Die Vorschaufunktionen werden mit eingeschränkter Funktionalität veröffentlicht, jedoch auf Basis einer Vorschau zur Verfügung gestellt, sodass Kunden frühzeitigen Zugriff erhalten und Feedback geben können. Die Vorschaufunktionen unterliegen separaten ergänzenden Vorschaubedingungen und keinen SLAs. In bestimmten Fällen wird bestmöglicher Support geleistet. Der Microsoft-Support ist jedoch an Ihrem Feedback zu den Vorschaufunktionen interessiert und bietet möglicherweise in bestimmten Fällen bestmöglichen Support. Vorschaufunktionen haben gegebenenfalls eine begrenzte oder eingeschränkte Funktionalität und sind eventuell nur in ausgewählten geografischen Regionen verfügbar.

Unterstützte Azure SQL-Ziele

Der Datenbankwatcher unterstützt alle Dienstebenen, Computeebenen und Dienstziele in Azure SQL-Datenbank und Azure SQL Managed Instance. Dazu gehören vCore- und DTU-Kaufmodelle, bereitgestellte und serverlose Computeebenen, Singletons und Pools für elastische Datenbanken sowie Hyperscale.

Der Datenbankwatcher kann alle Typen sekundärer lesbarer Replikate überwachen, einschließlich Hochverfügbarkeitsreplikate, Georeplikate und benannte sekundäre Hyperscale-Replikate.

Bei einem bestimmten Watcher können sich die SQL-Ziele in jedem Abonnement innerhalb desselben Microsoft Entra ID-Mandanten befinden.

Preis des Datenbankwatchers

Die Kosten des Datenbankwatchers fallen wie folgt durch seine einzelnen Komponenten an:

Komponente Preis Hinweise
Überwachungselemente Free
Dashboards Free
Azure Data Explorer-Cluster* Preisübersicht Die optimale Cluster-SKU hängt von der Anzahl der Überwachungsziele und der Abfrageworkload des Clusters ab. Überlegungen zur Clustergröße finden Sie unter Verwalten des Azure Data Explorer-Clusters.
Echtzeitanalyse in Microsoft Fabric Enthalten im Verbrauchsmodell des Power BI Premium-Arbeitsbereichs. Abrechnung erfolgt pro Nutzung. Sie können entweder den Azure Data Explorer oder die Echtzeitanalyse verwenden. Nur eines dieser Angebote ist erforderlich.
Ein Tresor in Azure Key Vault Preisübersicht Nur erforderlich, wenn die optionale SQL-Authentifizierung anstelle der standardmäßigen Microsoft Entra-Authentifizierung verwendet wird.
Bandbreite des Azure-Netzwerks Preisübersicht Es fallen keine Kosten an, wenn ein Watcher, seine Ziele und sein Datenspeicher in derselben Azure-Region bereitgestellt werden.

*Sie können einen kostenlosen Azure Data Explorer-Cluster nutzen, wenn keine Vereinbarung zum Servicelevel erforderlich ist und die Anforderungen an Abfrageleistung und Speicher von den Spezifikationen des kostenlosen Clusters erfüllt werden. Der kostenlose Testzeitraum des Clusters beträgt ein Jahr und kann automatisch verlängert werden.

Es wird keine Gebühr pro überwachter Azure SQL-Ressource oder pro Benutzer erhoben, was den Datenbankwatcher für größere Azure SQL-Umgebungen und größere Teams zu einer kostengünstigen Überwachungslösung macht.

Regionale Verfügbarkeit

Derzeit können Datenbankwatcher in den folgenden Azure-Regionen erstellt werden:

Azure-Geografie Azure-Region
Asien-Pazifik Australien (Osten)
Asien-Pazifik Asien, Südosten
Canada Kanada, Mitte
Europa Nordeuropa
Europa UK, Süden
Europa Schweden, Mitte
Europa Europa, Westen
USA East US
USA USA (Ost) 2
USA USA (Mitte)
USA USA (Westen)

Tipp

Ein Watcher in einer Azure-Region kann Ziele in einer anderen Region überwachen. Ebenso können sich ein Watcher und sein Datenspeicher in verschiedenen Regionen befinden.

Nach Möglichkeit sollten ein Watcher, seine Ziele und sein Datenspeicher in derselben Region untergebracht werden. Wenn der Datenbankwatcher in Ihrer Region noch nicht verfügbar ist, können Sie eine Region in derselben Azure-Geografie wählen. Dies kann die Kosten der Azure-Netzwerkbandbreite verringern.

Grenzwerte

Es gibt einen Grenzwert für die Anzahl der SQL-Ziele pro Watcher und die Anzahl der Watcher pro Abonnement. Bereitstellungen, die diese Grenzwerte überschreiten, werden nicht unterstützt.

Parameter Begrenzung
SQL-Ziele pro Watcher1 50
Watchers pro Abonnement 20

1Ein Hochverfügbarkeitsreplikat einer Datenbank, eines Pools für elastische Datenbanken oder einer SQL Managed Instance wird unabhängig von seinem übergeordneten Replikat überwacht und gilt als separates Ziel.

Hinweis

Während der Vorschau können sich dies Grenzwerte noch ändern.

Dashboards

Der Datenbankwatcher verwendet Azure-Arbeitsmappen zum Bereitstellen von Überwachungsdashboards auf Umgebungs- und auf Ressourcenebene.

Hier ist ein Beispiel für ein Wärmebild der CPU-Auslastung der Datenbank im Umgebungsdashboard. Jedes Sechseck stellt ein SQL-Ziel dar. Es gibt zwei logische Server, einen mit sechs Datenbanken und einen mit drei Datenbanken. Die sekundären Replikate mit hoher Verfügbarkeit werden im Wärmebild als separate Ziele angezeigt. Wählen Sie das Bild aus, um weitere Details anzuzeigen, einschließlich Statistiken zur Datenerfassung.

Screenshot mit einem Beispiel für ein Wärmebild der CPU-Auslastung im Umgebungsdashboard des Datenbankwatchers.

Hier ist ein Beispiel für eine Teilansicht der Registerkarte Leistung eines Azure SQL-Datenbank-Dashboards. Wählen Sie das Bild aus, um Details zu vergrößern.

Screenshot mit einem Beispiel für ein Datenbankwatcher-Dashboard für eine Azure SQL-Datenbank.

Die folgende Tabelle beschreibt die Funktionalitäten des Datenbankwatcher-Dashboards im Azure-Portal.

Funktion Beschreibung
Umgebungsdashboards Visualisieren Sie Überwachungsdaten auf hoher Ebene für mehrere überwachte Ressourcen in einer gemeinsamen Ansicht. Verwenden Sie Vorgehensweisen, um die wichtigsten Ressourcen zu finden, die Datenbanken, elastische Pools oder von SQL verwaltete Instanzen verwenden.

In der Ansicht der höchstrangigen Abfragen

können Sie die Abfragen mit dem höchsten Ressourcenverbrauch in Ihrer Azure SQL-Umgebung ermitteln, eine Rangfolge der Abfragen nach CPU, Dauer, Anzahl der Ausführungen usw. erstellen.

Verwenden Sie die Filter „Subscription“, „Ressourcengruppe“ und „Ressourcenname“, um den Schwerpunkt auf Teilmengen Ihrer Azure SQL-Umgebung zu legen.Per Drillthrough gelangen Sie zu detaillierten Dashboards für bestimmte Ressourcen.
Ressourcendashboards Visualisieren Sie detaillierte Überwachungsdaten für eine Datenbank, einen Pool für elastische Datenbanken oder eine SQL Managed Instance, einschließlich aktiver

-Sitzungen.
– Sicherungsverlauf
– Allgemeine Leistungsindikatoren
– Verbindungstests
– Eigenschaften und Konfiguration von Datenbank und Instanz
– Georeplikation
– Indexmetadaten, Nutzungsstatistiken, Warnungen und Vorschläge
– Ressourceneinsatz
– Sitzungs- und Verbindungsstatistiken
– SQL-Agent-Auftragsstatus und -Verlauf
– Speicherverbrauch und Leistung
– Tabellenmetadaten
– Höchstrangige Abfragen
– Wartezeitstatistiken

Mit Ressourcen-Dropdowns können Sie schnell von einer Ressource zu einer anderen wechseln. Über den Link Umgebung können Sie aus einem Umgebungsdashboard herauszoomen.
Filtern nach Zeitbereich In jedem Dashboard können Sie den Zeitbereich festlegen, um sich auf das gewünschte Zeitintervall zu konzentrieren. Sie können standardmäßige oder benutzerdefinierte Zeitbereiche verwenden. Sie können den Zeitbereich auf ein interessantes Intervall eingrenzen, indem Sie über ein Diagramm „wischen“ oder den Mauszeiger darüber ziehen, um einen kürzeren Zeitbereich auszuwählen.
Historische Daten Je nach Dataset zeigen Dashboards entweder eine Zusammenfassung für das ausgewählte Zeitintervall oder die neueste im Zeitintervall erfasste Probe an.

Wechseln Sie zwischen der neuesten und einer historischen Ansicht, um Datenbeispiele weiter oben im ausgewählten Zeitbereich anzuzeigen. Anstatt beispielsweise die derzeit aktiven Sitzungen zu betrachten, können Sie sich eine vorangehende Probe aktiver Sitzungen ansehen, die bei einer Spitze im Ressourceneinsatz erfasst wurde.
Sekundäre Replikate Überwachen Sie alle Arten von Replikaten, wie z. B. sekundäre Replikate mit hoher Verfügbarkeit (HA), in den Umgebungsdashboards. In den Ressourcendashboards können Sie wechseln zwischen der Ansicht des primären Replikats und seinem sekundären HA-Replikat.
Herunterladen von Daten in Excel Laden Sie Daten aus Diagrammen und Rastern als csv-Dateien herunter und öffnen Sie sie in Excel zur weitere Analyse.
Datenaktualisierung Rufen Sie die neuesten Daten aus dem Überwachungsdatenspeicher ab, wenn Sie ein Dashboard öffnen und von Registerkarte zu Registerkarte wechseln. Wenn ein Dashboard eine Zeit lang geöffnet ist, können Sie es manuell aktualisieren, um die neuesten Daten anzuzeigen, oder die automatische Dashboardaktualisierung aktivieren.
Ad-hoc-KQL-Abfrage Über einen Link in jedem Dashboard können Sie die Web-Benutzeroberfläche des Azure Data Explorers öffnen und Ihre Überwachungsdaten mit KQL abfragen. Weitere Informationen finden Sie unter Datasets und Einsatz von KQL zum Analysieren von Überwachungsdaten.
Beschreibungen Sie können den Parameter Beschreibungen anzeigen umschalten, um Beschreibungen anzuzeigen, mit deren Hilfe sie die angezeigte Daten interpretieren und Links zu relevanten Dokumentationen aufnehmen können.
Quickinfos Zeigen Sie auf ein Feld, um weitere Details und Kontext zu den angezeigte Daten zu sehen.
Erfassungsstatistiken Über den Link Erfassungsstatistik können Sie die Datenerfassungslatenz und andere Erfassungsstatistiken pro Dataset anzeigen.
Dunkler Modus Sie können die Darstellung des Azure-Portals umschalten, so dass die Dashboards des Datenbankwatchers im dunklen Modus angezeigt werden.

Hinweis

Während der Vorschau können sich Visualisierungen und Funktionalitäten des Dashboards noch ändern.

SQL-Überwachungsdaten

Der Datenbankwatcher erfasst Überwachungsdaten aus mehr als 70 SQL-Katalogsichten und dynamischen Verwaltungssichten (DMVs). Daten aus einer oder mehreren entsprechenden Sichten werden in ein Dataset umgewandelt. So bilden z. B. Daten aus sys.dm_exec_sessions, sys.dm_exec_requests und anderen Sichten das Dataset Aktive Sitzungen. Für jedes Dataset gibt es eine separate Tabelle im der Azure Data Explorer- oder Echtzeitanalyse-Datenbank.

Der Datenbankwatcher verfügt über separate Datasetgruppen für Datenbanken, Pools für elastische Datenbanken und SQL Managed Instances. Es gibt 10 bis 30 Datasets in jeder Gruppe, die detaillierte Einblicke in die Datenbankleistung, Konfiguration und Integrität Ihrer Azure SQL-Ressourcen vermitteln.

Weitere Informationen finden Sie unter Datensammlung und Datasets des Datenbankwatchers.

Netzwerkkonnektivität

Der Datenbankwatcher setzt einen Remotedatensammlungs-Agent ein, der über das Netzwerk eine Verbindung mit Zielen, Datenspeichern und Schlüsseltresor herstellt. Abhängig von den Sicherheitsanforderungen für Ihr Netzwerk und der Konfiguration Ihrer Azure-Ressourcen kann der Datenbankwatcher entweder private oder öffentliche Verbindungen verwenden. Sie haben immer die volle Kontrolle über die Netzwerkverbindung vom Datenbankwatcher zu Ihren Azure-Ressourcen.

Weitere Informationen zur Netzwerkverbindung in Azure SQL finden Sie unter Verbindungsarchitektur von Azure SQL-Datenbank und Verbindungsarchitektur von Azure SQL Managed Instance.

Private Konnektivität

Für private Verbindungen verwendet der Datenbankwatcher Azure Private Link. Wenn Sie einen Watcher konfigurieren, können Sie verwaltete private Endpunkte erstellen, damit der Watcher eine Verbindung mit Datenbanken und Pools für elastische Datenbanken auf logischen Servern oder mit SQL Managed Instances herstellen kann. Sie können auch einen privaten Endpunkt für den Azure Data Explorer-Cluster und für den Schlüsseltresor erstellen, in dem die Anmeldedaten für die SQL-Authentifizierung gespeichert sind. Derzeit stehen für die Echtzeitanalyse in Microsoft Fabric keine privaten Verbindungen zur Verfügung.

Ein Ressourcenbesitzer muss einen privaten Endpunkt genehmigen, bevor er vom Datenbankwatcher verwendet werden kann. Umgekehrt können Ressourcenbesitzer einen privaten Endpunkt für den Datenbankwatcher jederzeit löschen, um die Datensammlung zu beenden.

Sobald ein privater Endpunkt für eine Azure-Ressource erstellt und genehmigt ist, nutzt der gesamte Netzwerkdatenverkehr zwischen einem Watcher und der Ressource private Verbindungen, auch wenn öffentliche Verbindungen für die Ressource aktiviert bleiben.

Weitere Informationen zu privaten Endpunkten in Azure SQL finden Sie unter Azure Private Link für Azure SQL-Datenbank and Azure Private Link für Azure SQL Managed Instance.

Öffentliche Konnektivität

Wenn keine private Verbindung erforderlich ist, kann der Datenbankwatcher die Verbindung mit Azure-Ressourcen über private Verbindungen herstellen. Damit ein Watcher eine Verbindung mit Datenbanken und Pools für elastische Datenbanken auf einem logischen Server für Azure SQL-Datenbank herstellen kann, muss der öffentliche Zugriff auf den Server aktiviert sein, und die IP-basierte Firewall muss Verbindungen von allen Azure-Diensten zulassen.

Damit ein Watcher eine Verbindung mit einer SQL Managed Instance über eine öffentliche Verbindung herstellen kann, muss der öffentliche Endpunkt für die Instanz aktiviert sein. Darüber hinaus muss bei einer Regel für die Netzwerksicherheitsgruppe (NSG), die den an TCP-Port 3342 eingehenden Datenverkehr zum Subnetz der verwalteten Instanz zulässt, die Quelle auf AzureCloud festgelegt sein. Weitere Informationen finden Sie unter Konfigurieren von öffentlichen Endpunkten in Azure SQL Managed Instance.

Damit ein Watcher eine Verbindung mit einem Azure Data Explorer-Cluster oder einem Schlüsseltresor über eine öffentliche Verbindung herstellen kann, muss für den Cluster oder Tresor der Netzwerkzugriff aus allen Netzwerken aktiviert sein.

Datenzugriff

Ebenso wie bei der Netzwerkverbindung haben Sie die volle Kontrolle über den Zugriff des Datenbankwatchers auf Ihre Datenbanken. Sie gewähren den Zugriff, indem Sie dedizierter Anmeldungen für den Datenbankwatcher auf logischen Servern und SQL Managed Instances erstellen und dann bestimmte, eingeschränkte Berechtigungen zum Erfassen von Überwachungsdaten aus SQL-Systemansichten erteilen.

Watcher-Authentifizierung

Der Datenbankwatcher unterstützt die Microsoft Entra-Authentifizierung (früher Azure Active Directory-Authentifizierung genannt). Dies ist die bevorzugte und empfohlene Methode für die Authentifizierung eines Watcher bei einem SQL-Ziel. Sie erstellen eine Anmeldung zur Microsoft Entra-Authentifizierung für die verwaltete Identität des Watchers auf allen logischen Servern und SQL Managed Instances, die Sie überwachen möchten.

Der Datenbankwatcher unterstützt auch die kennwortbasierte SQL-Authentifizierung. Sie können die SQL-Authentifizierung verwenden, wenn die Microsoft Entra-Authentifizierung für Ihre Azure SQL-Ressourcen nicht aktiviert ist. Weitere Informationen finden Sie unter Zusätzliche Konfiguration zur Verwendung der SQL-Authentifizierung.

Watcher-Autorisierung

Zum Erfassen von Überwachungsdaten benötigt der Datenbankwatcher den spezifischen, eingeschränkten Zugriff auf jedes Überwachungsziel, wie in der folgenden Tabelle beschrieben. Diese Rollenmitgliedschaften und Berechtigungen gewähren dem Watcher den erforderlichen Zugriff auf die Systemüberwachungsdaten, aber nicht auf andere Daten in Ihren Datenbanken.

Azure SQL-Datenbank Verwaltete Azure SQL-Datenbank-Instanz
Mitgliedschaft in allen folgenden Serverrollen:
##MS_ServerPerformanceStateReader##
##MS_DefinitionReader##
##MS_DatabaseConnector##		 Die folgenden Serverberechtigungen:
CONNECT SQL
CONNECT ANY DATABASE
VIEW ANY DATABASE
VIEW ANY DEFINITION
VIEW SERVER PERFORMANCE STATE

Die SELECT-Berechtigung in den folgenden Tabellen in der msdb-Datenbank:
dbo.backupmediafamily
dbo.backupmediaset
dbo.backupset
dbo.suspect_pages
dbo.syscategories
dbo.sysjobactivity
dbo.sysjobhistory
dbo.sysjobs
dbo.sysjobsteps
dbo.sysoperators
dbo.syssessions

Wichtig

Wenn ein Watcher eine Verbindung mit einer Azure SQL-Ressource herstellt, überprüft er deren SQL-Berechtigungen. Wenn die erteilten Berechtigungen nicht genügen oder unnötige Berechtigungen erteilt wurden, trennt der Watcher die Verbindung. Dadurch wird sichergestellt, dass der Watcher Systemüberwachungsdaten erfassen kann, aber nicht versehentlich auf andere Daten in Ihren Datenbanken zugreifen kann.

Erstellen Sie beim Konfigurieren des Watcher-Zugriffs auf ein SQL-Ziel immer eine dedizierte Anmeldung mithilfe der bereitgestellten Skripts. Fügen Sie die Watcher-Anmeldung oder den Benutzer nicht zu SQL-Rollen hinzu und erteilen Sie keine anderen als die in der Tabelle aufgeführten SQL-Berechtigungen.

Wenn Sie der Anmeldung oder dem Benutzer des Datenbankwatchers oder einer Rolle, die die Anmeldung oder den Benutzer des Datenbankwatchers als Mitglied aufweist (einschließlich der Datenbankrolle public), die erforderlichen Berechtigungen verweigern, erfasst der Datenbankwatcher unter Umständen keine Überwachungsdaten. Je nachdem, welche Berechtigungen verweigert werden, wirkt sich dies möglicherweise auf einige oder alle Datasets aus.

Wenn Sie hingegen der Anmeldung oder dem Benutzer des Datenbankwatchers oder einer Rolle, die die Anmeldung oder den Benutzer des Datenbankwatchers als Mitglied enthält, unnötige Berechtigungen erteilen, erfasst der Datenbankwatcher für einige oder für alle DataSets unter Umständen keine Überwachungsdaten. Desgleichen werden Daten möglicherweise nicht erfasst, wenn Sie die Anmeldung oder den Benutzer des Datenbankwatchers einer integrierten Server- oder Datenbankrolle hinzufügen.

Neuerungen

In diesem Abschnitt werden aktuelle Korrekturen, Änderungen und Verbesserungen beim Datenbankwatcher beschrieben.

Zeitraum Änderungen
Oktober 2024 – Behebung eines Fehlers, bei dem das Dataset Tabellenmetadaten nicht erfasst wurde, wenn es Ansichten mit ungültigen Tabellenverweisen oder Tabellen mit mehreren Spaltenüberprüfungseinschränkungen gibt.
– Fügen Sie Unterstützung für die zugewiesene Benutzeridentität hinzu. Weitere Informationen finden Sie unter Ändern der Watcher-Identität.
– Gewähren Sie dem Watcher automatisch Zugriff auf Schlüsseltresorschlüssel, wenn Sie ein SQL-Ziel hinzufügen, das die SQL-Authentifizierung verwendet.
– Gewähren Sie dem Watcher automatisch Zugriff auf eine Azure Data Explorer-Datenbank, wenn Sie einem vorhandenen Watcher einen Datenspeicher hinzufügen.
– Fügen Sie die Feedbackschaltfläche auf der Seite Übersicht und anderen Seiten hinzu.
September 2024 – Behebung eines Bugs, bei dem die Anzahl der logischen Benutzersitzungen im DataSet Sitzungsstatistik selbst bei Nutzung logischer MARS-Sitzungen immer mit der Anzahl der Benutzersitzungen übereinstimmte.
– Behebung eines Bugs, bei dem die Speicherauslastung von Pools für elastische Datenbanken für Hyperscale-Pools für elastische Datenbanken nicht ordnungsgemäß gemeldet wurde.
– Behebung eines Problems, beim dem für bestimmte DataSets die erste nach einem Neustart des Watchers erfasste Probe Daten enthalten kann, die bereits vor dem Neustart erfasst wurden.
– Verbesserung der Leistung von Sammlungsabfragen, um Timeouts für das DataSet Tabellenmetadaten zu vermeiden.
– Verbesserung der Zuverlässigkeit der Sammlung für die DataSets Statistik zur Abfragelaufzeit und Statistik zur Abfragewartezeit in SQL Managed Instance.
– Hinzufügen von failoverbezogenen Spalten zum DataSet Datenbankreplikate für SQL Managed Instance.
– Hinzufügen von Spalten für Index-Betriebsstatistiken zu den DataSets Indexmetadaten.
– Hinzufügen von Unterstützung für die Auswahl mehrerer Azure SQL-Datenbanken im Blatt SQL-Ziel hinzufügen.
August 2024 - Aktivieren Sie den Datenbank-Watcher in den Azure-Regionen USA, Mitte, USA, Osten 2, Europa, Norden und Schweden, Mitte.
- Hinzufügen von Abonnement- und Ressourcengruppenfiltern in Immobilien-Dashboards.
Juli 2024 – Behebung eines Fehlers, bei dem die Leistungsindikator-Datasets nicht aus Datenbanken mit Groß-/Kleinschreibung in der Katalogsortierung oder verwalteten Instanzen mit Groß- und Kleinschreibung bei der Datenbanksortierung gesammelt wurden.
– Behebung eines Fehlers, bei dem Daten nicht gesammelt wurden, wenn der Datenbankname in den SQL-Metadaten einen anderen Fall als der Datenbankname in den Azure Resource Manager (ARM)-Metadaten hatte.
– Behebung eines Fehlers, bei dem die Abfragelaufzeitstatistiken und Abfragewartestatistik-Datasets nicht in Datenbanken gesammelt wurden, bei denen eine große Menge neuer Abfragen und Abfragepläne in Abfragespeichertabellen eingefügt wurden.
– Behebung eines Problems, bei dem die Datasets für Georeplikate und Replikate nicht aus Hyperscale-Datenbanken gesammelt wurden.
– Hinzufügen der gemeinsamen Spalten subscription_id und resource_group_name zu allen Datasets. Erfordert einen einmaligen Neustart eines Watchers.
- Hinzufügen der resource_id-gemeinsamen Spalten zu allen Datasets. Die Daten werden für SQL-Ziele angezeigt, die im Juli 2024 oder später hinzugefügt wurden. Wenn Daten für ein vorhandenes SQL-Ziel angezeigt werden sollen, entfernen Sie das Ziel, fügen Sie es erneut hinzu und starten Sie den Watcher neu .
Juni 2024 – Behebung eines Fehlers, bei dem Daten nicht aus einigen SQL-Zielen gesammelt wurden, die über Bicep oder eine ARM-Vorlage hinzugefügt wurden.
– Behebung eines Fehlers, bei dem das Dataset der Sicherungshistorie für einige Azure SQL-Datenbanken nicht erfasst wurde.
– Behebung eines Fehlers, bei dem der Replikattyp einer verwalteten Instanz fälschlicherweise als Georeplikationsweiterleitung bestimmt wurde, wenn die Instanz eine Datenbank mit verwaltete Instanz Link aufwies. Derselbe Fehler verursachte die Datasets Abfrage-Runtime-Statistik und Abfragewartestatistik, die in diesem Fall nicht erfasst werden.
– Behebung eines Fehlers, durch den ein Fehler Ziele konnten nicht geladen werden auf dem Blatt SQL-Ziele im Azure-Portal verursacht wurde, wenn der Benutzer keinen Zugriff auf das Abonnement des SQL-Ziels hat oder wenn das Abonnement gelöscht wurde.
– Behebung eines Fehlers, bei dem der Aufbewahrungs- und Cache-Zeitraum für eine standardmäßige Azure Data Explorer-Datenbank beim Erstellen eines Watchers im Azure-Portal auf unbegrenzt festgelegt wurde, anstatt 365 bzw. 31 Tage.
– Behebung eines Fehlers, bei dem bestimmte Verwaltungsoperationen wie das Erstellen oder Löschen eines verwalteten privaten Endpunkts im Azure-Portal als erfolgreich gemeldet wurden, obwohl sie fehlgeschlagen sind.
– Behebung eines Fehlers, bei dem für die Ziele der SQL-Datenbank die Liste der Datenbanken im Dropdown unvollständig war, wenn der logische SQL-Server mehr als 1.000 Datenbanken enthielt.
– Behebung eines Fehlers, bei dem die Auswahl einer Azure Data Explorer-Datenbank als Datenspeicher den Zugriff entfernen würde, den ein anderer Watcher in derselben Ressourcengruppe in dieser Datenbank hatte.
– Aktivieren des Watcher ARM-Vorlagenexports im Azure-Portal.
– Fügen Sie während der Erstellung eine Warnung hinzu, wenn der Microsoft.Network-Ressourcenanbieter nicht im Abonnement registriert ist, das für den Watcher ausgewählt ist.
– Fügen Sie einen detaillierten Fehler hinzu, wenn das Löschen eines Watchers oder eines verwalteten privaten Endpunkts fehlschlägt, da im Ressourcenbereich eine Sperre einer Löschung vorhanden ist.
April 2024 – Aktivieren Sie den Datenbank-Watcher in den Azure-Regionen Australien Ost und Vereinigtes Königreich, Süden.
– Beheben Sie Fehler beim Hinzufügen eines verwalteten privaten Endpunkts, wenn mehrere private Endpunkte für denselben Watcher schnell hinzugefügt werden.
– Korrigieren Sie das Dataset für den Sicherungsverlauf für SQL-Datenbanken, um vollständige Sicherungen miteinzuschließen.
– Verbessern Sie die Leistung von Sammelabfragen, um Timeouts für die Datensätze Index-Metadaten, Abfrage-Laufzeitstatistiken, Abfrage-Wartestatistiken und Tabellen-Metadaten zu vermeiden.
– Beheben Sie Fehler, bei denen für bestimmte Datensätze keine Daten erfasst wurden, nachdem eine Datenbank aus einer Sicherung wiederhergestellt wurde.
– Beheben Sie Fehler, bei denen der Index-Metadatensatz nicht erfasst wurde, wenn Indizes viele Schlüssel- oder eingeschlossene Spalten haben oder wenn die Namen dieser Spalten lang sind.
– Fügen Sie das SOS-Planer-Dataset hinzu.
– Fügen Sie eine Schaltfläche hinzu, um den ausgewählten Abfrageplan aus den Dashboards der obersten Abfragen herunterzuladen.
– Fügen Sie ein Schnellstartbeispiel hinzu, um einen Watcher mit Bicep oder einer ARM-Vorlage zu erstellen und zu konfigurieren.

Begrenzungen

In diesem Abschnitt werden Einschränkungen des Datenbankwatchers beschrieben. Falls verfügbar, werden Problemumgehungen angegeben.

Einschränkung Problemumgehung
Bei Verwendung kleinerer Azure Data Explorer-SKUs wie Dev/Test oder Sehr klein kann es gelegentlich vorkommen, dass Dashboardabfragen mit der Fehlermeldung „aufgrund von Drosselung abgebrochenen“ nicht ausgeführt werden. Laden Sie das Dashboard neu oder skalieren Sie den Azure Data Explorer-Cluster hoch auf die nächsthöhere SKU.
Wenn Sie über die Datenbankwatcher-Benutzeroberfläche im Azure-Portal einen kostenlosen Azure Data Explorer-Cluster erstellen, erhalten Sie womöglich eine Fehlermeldung „Mit Cluster konnte keine Verbindung hergestellt, 403-Verboten“, wenn Sie versuchen, in der Web-Benutzeroberfläche des Azure Data Explorers auf den Cluster zuzugreifen. Dieses Problem tritt nicht auf, wenn Sie den kostenlosen Cluster mithilfe von https://aka.ms/kustofree verwenden.

Gehen Sie folgendermaßen vor, wenn Sie bereits einen kostenlosen Cluster über das Azure-Portal erstellt haben:

Wählen Sie in der Web-Benutzeroberfläche des Azure Data Explorers Ihren Profilnamen in der Hauptleiste aus, um den Kontomanager zu öffnen, und wählen Sie Verzeichnis wechseln aus. Wählen Sie ein anderes Verzeichnis als das Microsoft-Konto aus und wählen Sie dann Wechseln. Nun sollte der erstellte kostenlose Azure Data Explorer-Cluster angezeigt werden.

Alternativ können Sie die Clusterverbindung in der Web-Benutzeroberfläche des Azure Data Explorers über Schaltfläche Bearbeiten (Bleistift) bearbeiten und das Verzeichnis entsprechend wechseln.
Wenn der CPU-Verbrauch für eine Datenbank, einen Pool für elastische Datenbanken oder eine SQL Managed Instance nahe 100 % bleibt, sind die verbleibenden CPU-Ressourcen für Abfragen des Datenbankwatchers zur Datenerfassung eventuell nicht ausreichend, wodurch Lücken in den erfassten Daten entstehen. Wenn Datenlücken festzustellen sind, die mit hoher CPU-Auslastung in der Datenbank, dem Pool für elastische Datenbanken oder einer SQL Managed Instance korrelieren, sollten Sie eine Optimierung Ihrer Anwendungsworkload in Betracht ziehen, um den CPU-Verbrauch zu reduzieren, oder die Anzahl der virtuellen Kerne oder DTUs erhöhen, um eine zuverlässige Überwachung zu ermöglichen.

Bekannte Probleme

Während der Vorschau gibt es beim Datenbankwatcher die folgenden bekannten Probleme.

Problem Lösung oder Problemumgehung
Wenn die Datensammlung aufgrund eines Fehlers (z. B. unzureichender Zugriff auf ein SQL-Ziel oder auf den Datenspeicher) nicht gestartet oder fortgesetzt werden kann, wird der Fehler nicht angezeigt. Informationen zur Problembehandlung finden Sie unter Daten werden nicht gesammelt.
Wenn für eine serverlose Datenbank das automatische Anhalten aktiviert ist und sie als Ziel des Datenbankwatchers hinzugefügt wird, wird sie möglicherweise nicht erwartungsgemäß automatisch angehalten. Bei einer kostenlosen Datenbank könnte dadurch das kostenlose monatliche Guthaben schneller aufgebraucht sein als erwartet. Wenn die Funktion zum automatischen Anhalten beibehalten werden muss, sollten Sie den Datenbankwatcher vorerst nicht zum Überwachen serverloser Datenbanken einsetzen.
Bei Azure SQL Managed Instance, werden bei Verwendung der SQL-Authentifizierung keine Daten aus dem lesbaren Replikat mit hoher Verfügbarkeit oder aus einem Georeplikat erfasst. Es gibt zwei Möglichkeiten zur Problemumgehung:
1. Verwenden Sie die Microsoft Entra ID-Authentifizierung (bevorzugt).
2. Deaktivieren Sie die Überprüfung der Kennwortrichtlinie. Führen Sie ALTER LOGIN [database-watcher-login-placeholder] WITH CHECK_POLICY = OFF; aus und ersetzen Sie database-watcher-login-placeholder durch den Namen der Anmeldung für die SQL-Authentifizierung des Watchers. Führen Sie diesen Befehl für das primäre Replikat und ggf. für das Georeplikat aus.
In Azure SQL Managed Instance werden keine Daten gesammelt, wenn die Berechtigung EXECUTE für die gespeicherte Systemprozedur sys.xp_msver widerrufen oder der Rolle public verweigert wird. Erteilen Sie der Datenbank-Watcher-Anmeldung die Berechtigung EXECUTE auf sys.xp_msver.

Führen Sie auf jeder SQL Managed Instance, die als Datenbank-Watcher-Ziel hinzugefügt wurde, USE master; CREATE USER [database-watcher-login-placeholder] FOR LOGIN [database-watcher-login-placeholder]; GRANT EXECUTE ON sys.xp_msver TO [database-watcher-login-placeholder]; aus und ersetzen Sie dabei database-watcher-login-placeholder mit dem Namen des Watcher-Logins.
Wenn Sie einen verwalteten privaten Endpunkt für einen Watcher erstellen, um eine Verbindung zu einer verwalteten SQL-Instanz herzustellen, die gestoppt ist, wird der Bereitstellungsstatus des privaten Endpunkts als Fehlgeschlage gemeldet und der Watcher kann keine Verbindung zu der Instanz herstellen. Löschen Sie den verwalteten privaten Endpunkt mit dem Bereitstellungsstatus Fehlgeschlagen und starten Sie die verwaltete SQL-Instanz. Nachdem der fehlgeschlagene private Endpunkt gelöscht wurde und die Instanz ausgeführt wird, erstellen Sie den verwalteten privaten Endpunkt erneut.
Es werden keine Daten erfasst, wenn Sie eine Datenbank in Echtzeitanalyse als Datenspeicher verwenden und die Option OneLake-Verfügbarkeit aktiviert ist. Deaktivieren Sie die Option OneLake-Verfügbarkeit und starten Sie den Watcher neu, um die Datensammlung fortzusetzen.
Datenbank-Watcher-Bereitstellungen über Bicep- oder ARM-Vorlagen sind nicht idempotent. Wenn bereits ein Watcher, ein SQL-Ziel oder ein verwalteter privater Endpunkt vorhanden ist, schlägt die Bereitstellung fehl. Verwenden Sie die bedingte Bereitstellung, um die Bereitstellung vorhandener Ressourcen zu überspringen. Weitere Informationen finden Sie unter Bedingte Bereitstellungen in Bicep mit dem if-Ausdruck und Bedingte Bereitstellung in ARM-Vorlagen.
Aufgrund eines bekannten Problems in der Azure SQL-Datenbank werden Daten im Dataset Sicherungsverlauf für Azure SQL-Datenbanken nicht erfasst, wenn die Sortierung des Datenbankkatalogs nicht der Standard „SQL_Latin1_General_CP1_CI_AS“ ist. Zurzeit keine.

Problembehandlung

In diesem Abschnitt werden die Schritte zum Beheben häufiger Probleme beschrieben. Wenn sich das Problem mit den Schritten in diesem Abschnitt nicht beheben lässt, öffnen Sie einen Supportfall.

Es werden keine Daten gesammelt

Wenn Sie einen neuen Watcher erstellen und keine Überwachungsdaten auf Dashboards und im Datenspeicher sehen oder wenn nur ältere Daten angezeigt werden, lesen Sie diesen Abschnitt.

  • Überprüfen Sie in der Übersicht für den Watcher das Feld Status, ob der Watcher ausgeführt wird. Wenn nicht, können Sie über die Schaltfläche Start auf derselben Seite die Datensammlung zu starten. Ein neuer Watcher wird nicht automatisch gestartet.

  • Überprüfen Sie, ob der Watcher Zugriff auf den Datenspeicher hat.

  • Wenn Sie eine Azure Data Explorer-Datenbank als Datenspeicher verwenden, überprüfen Sie, ob der Azure Data Explorer-Cluster gestartet wird. Weitere Informationen finden Sie unter Gestoppte Azure Data Explorer-Cluster.

  • Vergewissern Sie sich, dass der Beobachter den spezifischen, begrenzten Zugriff auf SQL-Ziele hat. Wenn Sie die SQL-Authentifizierung für Ziele verwenden, sollten Sie außerdem den Zugriff des Watchers auf den Schlüsseltresor prüfen oder stattdessen die empfohlene Microsoft Entra-Authentifizierung verwenden.

  • Wenn der Watcher die Verbindung mit SQL-Zielen über die Microsoft Entra-Authentifizierung herstellen soll, müssen Sie sicherstellen, dass die Microsoft Entra-Authentifizierung auf den logischen Servern aktiviert ist, auf denen die Ziele von Datenbank und Pools für elastische Datenbanken sowie die Ziele der verwalteten Instanz gehostet werden.

  • Wenn Sie private Endpunkte für den Watcher erstellt haben, müssen Sie sicherstellen, dass sie vom Ressourcenbesitzer genehmigt sind.

  • Stellen Sie bei Verwendung von öffentlichen Verbindungen sicher, dass die Anforderungen erfüllt sind, damit der Watcher eine Verbindung mit Zielen, Datenspeichern und Schlüsseltresor herstellen kann.

  • Der Azure Data Explorer-Cluster oder die Datenbank oder die Echtzeitanalyse-Datenbank wurden möglicherweise gelöscht, nachdem sie als Datenspeicher für Ihren Watcher ausgewählt wurden. Navigieren Sie zum Cluster und zur Datenbank, und bestätigen Sie, dass sie vorhanden sind.

  • Stellen Sie bei Verwendung des kostenlosen Azure Data Explorer-Clusters sicher, dass Sie die Speicherkapazität des Clusters nicht erreicht haben. Weitere Informationen finden Sie im kostenlosen Azure Data Explorer-Cluster.

Wenn Sie im Rahmen der Problembehandlung Änderungen am Watcher-Zugriff oder an der Konnektivität vornehmen, müssen Sie den Watcher gegebenenfalls beenden und neu starten, damit die Änderungen wirksam werden.

Dashboards sind leer

Wenn Sie die Seite Dashboards eines Watchers auswählen, aber keine Zusammenfassung der SQL-Ziele auf der Seite sehen, erweitern Sie den Abschnitt Datenspeicher. Wenn ein Fehler Verbindung kann nicht hergestellt werden… angezeigt wird, lesen Sie diesen Abschnitt.

Führen Sie die folgenden Schritte aus, um zu überprüfen, ob Sie Zugriff haben und eine Verbindung mit dem Datenspeicher herstellen können und ob die Datenspeicherdatenbank vorhanden ist:

  • Erweitern Sie auf der Seite Dashboards eines Watchers den Abschnitt Datenspeicher und kopieren Sie den Kusto-Abfrage-URI-Wert. Achten Sie darauf, die gesamte URI-Zeichenfolge zu kopieren. Notieren Sie sich auch den Kusto-Datenbank-Wert.

  • Öffnen Sie die Webbenutzeroberfläche von Azure Data Explorer. Melden Sie sich an, wenn Sie dazu aufgefordert werden.

  • Wählen Sie Hinzufügen, Verbindung aus und geben Sie den kopierten URI als Verbindungs-URI ein.

  • Wählen Sie zum Erstellen einer Verbindung die Option Hinzufügen aus.

  • Nachdem ein neuer Verbindungseintrag hinzugefügt wurde, erweitern Sie ihn, um die Datenbanken anzuzeigen.

  • Wählen Sie die Datenbank aus, die als Kusto-Datenbank auf der Dashboard-Seite Ihres Watchers referenziert ist und klicken Sie auf das +-Zeichen in der Registerkartenleiste, um eine neue Abfrage-Registerkarte zu öffnen, die mit dieser Datenbank verbunden ist.

  • Führen Sie den folgenden KQL-Befehl aus:

    .show database principals;

    Überprüfen Sie, ob eine Zeile für einen Viewer oder eine höhere privilegierte Rolle für Ihr Benutzerkonto oder für eine Microsoft Entra-ID-Gruppe vorhanden ist, die Ihr Benutzerkonto enthält.

Feedback senden

Das Datenbankwatcher-Team bei Microsoft freut sich auf Ihre Kommentare und Vorschläge. Feedback zum Produkt können Sie auf eine der folgenden Arten senden:

  • Posten Sie eine neue Idee im SQL-Feedbackforum. Wählen Sie auf der Seite Neue Idee posten SQL als Forum, wählen Sie die Azure SQL-Gruppe aus und fügen Sie Datenbankwatcher in den Titel ein. Das Feedback, das Sie im Feedbackforum übermitteln, ist öffentlich. Andere Communitymitglieder können Ihren Ideen und Vorschlägen zustimmen und sie kommentieren. Mithilfe der Stimmen und Kommentare aus der Community kann das Datenbankwatcher-Team Produktverbesserungen planen und priorisieren.
  • Verwenden Sie die Feedbackschaltfläche auf einer der Seite „Datenbank-Watcher“ im Azure-Portal. Sie finden beispielsweise die Feedbackschaltfläche auf der Watcher-Seite Übersicht oder auf Dashboards neben der Schaltfläche „Aktualisieren“. Das Feedback, das Sie auf diese Weise senden, ist nicht öffentlich. Wenn Sie Feedback übermitteln, können Sie Microsoft optional erlauben, Ihnen zwecks Nachverfolgung und Klarstellung eine E-Mail zu diesem Feedback zu senden.

Für technischen Support oder Hilfe beim Lösen eines Problems mit der Datenbankwatcher können Sie einen Supportfall öffnen.

Zugehöriger Inhalt