Nachverfolgen und Nachverfolgen von Aktivitäten

Abgeschlossen

Ein großer Teil der Aufrechterhaltung von Datenbanken ist die Leistungsoptimierung. Die gleichen Protokolldateien, die Sie zum Überprüfen Ihrer lokalen Datenbanken verwendet haben, sind weiterhin mit Azure Database für MySQL/PostgreSQL verfügbar.

Wenn Ihre Datenbanken zu Azure migriert wurden, müssen Sie die Protokolldateien weiterhin überprüfen, um sicherzustellen, dass die Leistung der Datenbanken beibehalten wird.

In dieser Einheit sehen Sie, wo die Protokolldateien für PostgreSQL und MySQL in Azure gespeichert sind und welche Detailebene sie enthalten.

Verwenden von Serverprotokollen zum Nachverfolgen von Datenbankaktivitäten

Azure Database for MySQL/PostgreSQL zeichnet auch Diagnoseinformationen in den Serverprotokollen auf. Serverprotokolle sind die systemeigenen Nachrichtenprotokolldateien für MySQL und PostgreSQL (nicht die Transaktionsprotokolldateien, auf die in der Azure-Datenbank für MySQL/PostgreSQL nicht zugegriffen werden kann). Diese Dateien enthalten Nachrichten, Serverstatus und andere Fehlerinformationen, die Sie zum Debuggen von Problemen mit Ihren Datenbanken verwenden. Die Serverprotokolle werden bis zu sieben Tage lang aufbewahrt (weniger, wenn die Gesamtgröße der Serverprotokolldateien 7 GB überschreitet).

Die Azure-Datenbank für MySQL und die Azure-Datenbank für PostgreSQL zeichnen unterschiedliche Details in den Serverprotokollen auf. In den folgenden Abschnitten werden die Serverprotokolle für jeden Dienst separat beschrieben.

Serverprotokolle in Der Azure-Datenbank für MySQL

In Azure Database for MySQL stellt das Serverprotokoll die Informationen bereit, die normalerweise im langsamen Abfrageprotokoll und das Überwachungsprotokoll auf einem MySQL-Server.

Sie verwenden die Informationen im langsamen Abfrageprotokoll, um langsam ausgeführte Abfragen zu identifizieren. Das Protokoll für langsame Abfragen ist standardmäßig deaktiviert. Sie aktivieren sie, indem Sie den slow_query_log Serverparameter auf ONfestlegen. Sie konfigurieren das langsame Abfrageprotokoll, um zu bestimmen, was mit einer langsamen Abfrage mit den folgenden Serverparametern gemeint ist:

• log_queries_not_using_indexes. Dieser Parameter ist entweder ON oder OFF. Legen Sie sie auf ON- fest, um alle Abfragen aufzuzeichnen, die wahrscheinlich eine vollständige Tabellenüberprüfung anstelle einer Indexsuche durchführen.
• log_throttle_queries_not_using_indexes. Gibt die maximale Anzahl langsamer Abfragen an, die keine Indizes verwenden, die pro Minute protokolliert werden können.
• log_slow_admin_queries. Legen Sie diesen Parameter auf ON- fest, um langsam ausgeführte administrative Abfragen in das Protokoll einzuschließen.
• long_query_time. Der Schwellenwert (in Sekunden) für eine Abfrage, die als langsam ausgeführtebetrachtet werden soll.

Nachdem Sie das langsame Abfrageprotokoll und das Überwachungsprotokoll aktiviert haben, werden die Protokolldateien in der Serverprotokolle Seite für den Server angezeigt. Täglich wird ein neues langsames Abfrageprotokoll erstellt. Klicken Sie auf eine Protokolldatei, um sie herunterzuladen:

Um die Überwachungsprotokollierung zu aktivieren, legen Sie den audit_log_enabled Serverparameter auf ONfest. Sie konfigurieren die Überwachungsprotokollierung mit den folgenden Parametern:

• audit_log_events. Geben Sie die zu überwachenden Ereignisse an. Im Azure-Portal stellt dieser Parameter eine Dropdownliste mit Ereignissen bereit, z. B. CONNECTION, DDL-, DML-, ADMIN-und andere.
• audit_log_exclude_users. Dieser Parameter ist eine durch Trennzeichen getrennte Liste von Benutzern, deren Aktivitäten nicht im Überwachungsprotokoll enthalten sind.

Wenn Sie das langsame Abfrageprotokoll und das Überwachungsprotokoll für mehr als sieben Tage beibehalten müssen, ordnen Sie sie an, dass sie in Azure Storage übertragen werden. Verwenden Sie die Diagnoseeinstellungen Seite für Ihren Server, und wählen Sie dann + Diagnoseeinstellung hinzufügenaus. Wählen Sie auf der Seite Diagnoseeinstellungen seite Auf einem Speicherkonto archivierenaus, wählen Sie ein Speicherkonto aus, in dem die Protokolldateien gespeichert werden sollen (dieses Speicherkonto muss bereits vorhanden sein), wählen Sie MySqlSlowLogs und MySqlAuditLogsaus, und geben Sie einen Aufbewahrungszeitraum von bis zu 365 Tagen an. Sie können die Protokolldateien jederzeit aus Azure Storage herunterladen. Wählen Sie Speichern aus:

Langsame Abfrageprotokolldaten werden im JSON-Format in Blobs in einem Container mit dem Namen insights-logs-mysqlslowlogsgeschrieben. Es kann bis zu 10 Minuten dauern, bis die Protokolldateien im Azure-Speicher angezeigt werden. Überwachungsdatensätze werden in den insights-logs-mysqlslowlogs BLOB-Container, erneut im JSON-Format gespeichert.

Serverprotokolle in Azure-Datenbank für PostgreSQL

In azure Database for PostgreSQL enthält das Serverprotokoll Fehlerprotokoll und Abfrageprotokolldateien. Verwenden Sie die Informationen in diesen Dateien, um die Quellen aller Fehler und ineffizienten Abfragen zu finden.

Sie aktivieren die Protokollierung, indem Sie die verschiedenen log_ Serverkonfigurationsparameter auf ONfestlegen. Diese Parameter umfassen:

• log_checkpoints. Ein Prüfpunkt tritt auf, wenn jede Datendatei mit den neuesten Informationen aus dem Transaktionsprotokoll aktualisiert wurde. Wenn ein Serverfehler auftritt, markiert dieser Punkt den Zeitpunkt, zu dem die Wiederherstellung beginnen muss, indem der Rollout aus dem Transaktionsprotokoll erfolgt.
• log_connection und log_disconnections. Diese Einstellungen zeichnen jede erfolgreiche Verbindung und das Ende jeder Sitzung auf.
• log_duration. Diese Einstellung bewirkt, dass die Dauer jeder abgeschlossenen SQL-Anweisung aufgezeichnet wird.
• log_lock_waits. Diese Einstellung bewirkt, dass Sperrwarteereignisse aufgezeichnet werden. Sperrwartevorgänge können durch schlecht implementierte Transaktionen im Anwendungscode verursacht werden.
• log_statement_stats. Diese Einstellung schreibt kumulative Informationen zur Leistung des Servers in das Protokoll.

Azure Database for PostgreSQL bietet auch weitere Parameter zur Feinabstimmung der aufgezeichneten Informationen:

• log_error_verbosity. Diese Einstellung gibt die Detailebene an, die für jede protokollierte Nachricht aufgezeichnet wurde.
• log_retention_days. Dies ist die Anzahl der Tage, an denen der Server jede Protokolldatei aufbewahrt, bevor sie entfernt wird. Der Standardwert ist drei Tage, und Sie können ihn auf maximal sieben Tage festlegen.
• log_min_messages und log_min_error_statement. Verwenden Sie diese Parameter, um die Warnungs- und Fehlerstufen für Aufzeichnungsanweisungen anzugeben.

Wie bei Der Azure-Datenbank für MySQL sind die von Azure Database für PostgreSQL generierten Protokolldateien auf der seite Serverprotokolle verfügbar. Sie können auch die Diagnoseeinstellungen Seite verwenden, um die Protokolle in Azure Storage zu kopieren.

Nachverfolgen der Abfrageleistung

Der Abfragespeicher ist ein zusätzliches Feature von Azure, das Ihnen hilft, schlecht ausgeführte Abfragen zu identifizieren und nachzuverfolgen. Sie verwenden es mit Azure-Datenbank für MySQL und Azure-Datenbank für PostgreSQL.

Aktivieren der Abfrageleistungsnachverfolgung

Abfragespeicher zeichnet Informationen im mysql Schema in Azure Database for MySQL und in einer Datenbank namens azure_sys in Azure Database for PostgreSQL auf. Der Abfragespeicher kann zwei Arten von Informationen erfassen: Daten zur Abfrageausführung und Informationen zu Wartestatistiken. Der Abfragespeicher ist standardmäßig deaktiviert. So aktivieren Sie sie:

• Wenn Sie Azure Database für MySQL verwenden, legen Sie die Serverparameter query_store_capture_mode und query_store_wait_sampling_capture_mode auf ALLfest.
• Wenn Sie Azure Database für PostgreSQL verwenden, legen Sie den Serverparameter pg_qs.query_capture_mode auf ALL oder TOPfest, und legen Sie den parameter pgms_wait_sampling.query_capture_mode auf ALLfest.

Analysieren von Abfrageleistungsdaten

Sie können die tabellen abfragen, die vom Abfragespeicher direkt verwendet werden. Wenn Sie Azure Database for MySQL ausführen, stellen Sie eine Verbindung mit Ihrem Server her, und führen Sie die folgenden Abfragen aus:

SELECT * FROM mysql.query_store;

SELECT * FROM mysql.query_store_wait_stats;

Wenn Sie Azure Database für PostgreSQL verwenden, führen Sie stattdessen die folgenden Abfragen aus:

SELECT * FROM query_store.qs_view;

SELECT * FROM query_store.pgms_wait_sampling_view;

In beiden Fällen zeigt die erste Abfrage den Text für jede kürzlich ausgeführte Abfrage und eine Reihe von Statistiken darüber an, wie lange die Abfrage zum Kompilieren und Ausführen benötigt wurde. Die zweite Abfrage zeigt Informationen zu Warteereignissen an. Ein Wait-Ereignis tritt auf, wenn eine Abfrage daran gehindert wird, ausgeführt zu werden, da sie die Ressourcen erfordert, die von einem anderen gehalten werden.

Wenn Sie den Abfragespeicher direkt untersuchen, können Sie eigene benutzerdefinierte Berichte generieren und einen detaillierten Einblick in die Funktionsweise des Systems erhalten. Die verfügbare Datenmenge kann es jedoch schwierig machen, zu verstehen, was passiert. Azure Database for MySQL/PostgreSQL bietet zwei zusätzliche Tools, mit denen Sie durch diese Daten navigieren können–Abfrageleistungserblickund Abfrageempfehlungen.

Query Performance Insight ist ein grafisches Hilfsprogramm, das auf der Seite Query Performance Insight für Ihren Server zur Verfügung steht. Auf der Registerkarte Abfragen mit langer Ausführung werden die Statistiken für die am häufigsten ausgeführten Abfragen angezeigt. Sie geben den Zeitraum an, und vergrößern Sie innerhalb weniger Minuten. Die Legende zeigt den Text jeder Abfrage zusammen mit der Dauer und der Häufigkeit, mit der die Abfrage ausgeführt wurde. Das Diagramm gibt eine vergleichende Ansicht der Dauer jeder Abfrage. Sie zeigen die Daten nach der durchschnittliche Zeit für jede Abfrage an, aber es ist auch anweisend, die Gesamtzeit (Dauer * Ausführungsanzahl) für jede Abfrage anzuzeigen. Die folgende Abbildung zeigt ein Beispiel:

Auf der Registerkarte Wait Statistics werden die Warteereignisinformationen für jede Abfrage angezeigt. Die von einer Abfrage aufgewendete Zeit, die auf verschiedene Ressourcen wartet, wird angezeigt.

Wait-Ereignisse fallen in der Regel in drei Kategorien:

• Lock wartet. Diese Ereignisse treten auf, wenn eine Abfrage versucht, Daten zu lesen oder zu ändern, die durch eine andere Abfrage gesperrt sind. Wenn eine große Anzahl von Sperrwartevorgängen auftreten, überprüfen Sie auf lange ausgeführte Transaktionen oder Vorgänge, die eine streng restriktive Isolationsstufe verwenden.
• E/A wartet. Diese Art von Wartezeit tritt auf, wenn eine Abfrage eine erhebliche Menge an E/A ausführt. Dies kann auf eine schlecht gestaltete Abfrage zurückzuführen sein (überprüfen Sie die WHERE--Klausel), einen ineffizienten Verknüpfungsvorgang oder einen vollständigen Tabellenscan aufgrund eines fehlenden Indexes.
• Speicher wartet. Eine Speicherwartevorgang tritt auf, wenn nicht genügend Arbeitsspeicher zum Verarbeiten einer Abfrage verfügbar ist. Ihre Abfrage könnte versuchen, eine große Menge an Daten zu lesen, oder sie wird möglicherweise durch andere Abfragen blockiert, die Arbeitsspeicher setzen. Dies kann wiederum darauf hindeuten, dass Indizes fehlen, was dazu führt, dass Abfragen ganze Tabellen im Arbeitsspeicher lesen.

Es ist auch sehr wahrscheinlich, dass eine Form von Wartezeit eine andere auslöst, sodass Sie diese Probleme nicht unbedingt isoliert untersuchen können. Beispielsweise kann eine Transaktion, die Daten in verschiedenen Tabellen liest und aktualisiert, einer Speicherwarteaufgabe unterliegen. Diese Transaktion könnte wiederum gesperrte Daten haben, die dazu führen, dass eine andere Transaktion eine Sperrwarte wartet.

Die Seite "Leistungsempfehlungen" Seite für den Server verwendet die informationen, die im Abfragespeicher gespeichert sind, und verwendet diese, um Empfehlungen für die Optimierung Ihrer Datenbank für die arbeitslasten zu erstellen, die sie erleben.