Abfragespeicher in Azure Database for PostgreSQL flexiblen Server

Der Abfragespeicher ist ein Feature in einem Azure Database for PostgreSQL flexiblen Server, der eine Möglichkeit zum Nachverfolgen der Abfrageleistung im Laufe der Zeit bietet. Der Abfragespeicher vereinfacht die Problembehandlung bei Leistungsproblemen, indem Sie schnell die längsten und ressourcenintensiven Abfragen finden. Der Abfragespeicher erfasst automatisch einen Verlauf der Abfragen und Laufzeitstatistiken und bewahrt diese auf, damit Sie sie überprüfen können. Es teilt die Daten nach Zeit auf, so dass Sie zeitliche Nutzungsmuster sehen können. Daten für alle Benutzer, Datenbanken und Abfragen werden in einer Datenbank gespeichert, die im Azure Database for PostgreSQL flexiblen Server benannt azure_sys ist.

Aktivieren des Abfragespeichers

Der Abfragespeicher ist kostenlos verfügbar. Es handelt sich um ein Opt-In-Feature, sodass es nicht standardmäßig auf einem Server aktiviert ist. Sie können den Abfragespeicher global für alle Datenbanken auf einem bestimmten Server aktivieren oder deaktivieren. Sie können sie nicht pro Datenbank aktivieren oder deaktivieren.

Aktivieren des Abfragespeichers im Azure-Portal

1. Melden Sie sich beim Azure Portal an, und wählen Sie Ihren Azure Database for PostgreSQL flexiblen Server aus.
2. Wählen Sie " Parameter" im Abschnitt "Einstellungen" des Menüs aus.
3. Suchen Sie nach dem Parameter pg_qs.query_capture_mode.
4. Legen Sie den Wert top auf oder all, je nachdem, ob Sie Abfragen der obersten Ebene oder geschachtelte Abfragen nachverfolgen möchten (die in einer Funktion oder Prozedur ausgeführt werden), und wählen Sie "Speichern" aus. Es kann bis zu 20 Minuten dauern, bis der erste Datenbatch in der azure_sys-Datenbank gespeichert ist.

Aktivieren der Stichprobenentnahme für Wartezeiten für den Abfragespeicher

1. Suchen Sie nach dem Parameter pgms_wait_sampling.query_capture_mode.
2. Legen Sie für den Wert all fest und Speichern Sie.

Informationen im Abfragespeicher

Der Abfragespeicher besteht aus zwei Speichern:

• Ein Speicher für Laufzeitstatistiken zum Aufbewahren der Informationen aus den Abfragespeicherstatistiken.
• Ein Speicher für Wartestatistiken zum Aufbewahren der Informationen aus den Wartestatistiken.

Häufige Szenarien für die Verwendung des Abfragespeichers sind u. a.:

• Bestimmen der Häufigkeit, mit der eine Abfrage in einem bestimmten Zeitfenster ausgeführt wurde.
• Vergleichen der durchschnittlichen Ausführungszeit einer Abfrage über mehrere Zeitfenster hinweg, um große Abweichungen zu erkennen.
• Ermitteln der am längsten ausgeführten Abfragen in den vergangenen Stunden.
• Ermitteln der Top-N-Abfragen, die auf Ressourcen warten.
• Verstehen der Wartezeiten für eine bestimmte Abfrage.

Um die Speicherverwendung zu minimieren, werden die Laufzeit-Ausführungsstatistiken im Speicher für Laufzeitstatistiken für ein festes, konfigurierbares Zeitfenster zusammengefasst. Sie können die Informationen in diesen Datenspeichern mithilfe von Ansichten abfragen.

Zugreifen auf Abfragespeicherinformationen

Azure Database for PostgreSQL Flexible Server speichert Abfragespeicherdaten in der Datenbank azure_sys. Die folgende Abfrage gibt Informationen zu Abfragen zurück, die der Abfragespeicher aufgezeichnet hat:

SELECT * FROM  query_store.qs_view;

Diese Abfrage gibt Informationen zu Wartestatistiken zurück:

SELECT * FROM  query_store.pgms_wait_sampling_view;

Suchen von wartenden Abfragen

Typen von Warteereignissen gruppieren verschiedene Warteereignisse basierend auf ihrer Ähnlichkeit in Kategorien. Abfragespeicher stellt den Typ des Wait-Ereignisses, den spezifischen Namen des Wait-Ereignisses und die fragliche Abfrage bereit. Wenn Sie diese Wartezeitinformationen mit den Abfragelaufzeitstatistiken korrelieren, erhalten Sie ein tieferes Verständnis darüber, was zur Abfrageleistungsmerkmale beiträgt.

Im Folgenden finden Sie einige Beispiele dafür, wie Sie mithilfe der Wartezeitstatistiken in Abfragespeicher mehr Einblicke in Ihre Arbeitsauslastung erhalten können:

Konfigurationsoptionen

Wenn Sie den Abfragespeicher aktivieren, werden Daten in Aggregationsfenstern gespeichert. Die Länge dieser Fenster wird durch den Parameter pg_qs.interval_length_minutes bestimmt, der standardmäßig 15 Minuten beträgt. Für jedes Fenster speichert der Abfragespeicher bis zu 500 unterschiedliche Abfragen. Die Attribute, die die Eindeutigkeit jeder Abfrage unterscheiden, sind user_id (Bezeichner des Benutzers, der die Abfrage ausführt), db_id (Bezeichner der Datenbank, in dem die Abfrage ausgeführt wird) und query_id (ein ganzzahliger Wert, der die ausgeführte Abfrage eindeutig identifiziert). Wenn die Anzahl der unterschiedlichen Abfragen während des konfigurierten Intervalls 500 erreicht, führt der Abfragespeicher 5% der aufgezeichneten Abfragen aus, um Mehr Platz zu schaffen. Die zuerst freigegebenen Abfragen sind diejenigen, die am seltensten ausgeführt wurden.

Verwenden Sie die folgenden Optionen, um Abfragespeicher Parameter zu konfigurieren:

Die folgenden Optionen gelten speziell für Wartestatistiken:

Verwenden Sie dasAzure-Portal, um für einen Parameter einen anderen Wert abzurufen oder festzulegen.

Ansichten und Funktionen

Sie können die vom Query Store erfassten Informationen abfragen und löschen, indem Sie die im Schema query_store der azure_sys-Datenbank verfügbaren Sichten und Funktionen verwenden. In der öffentlichen PostgreSQL-Rolle kann jeder diese Ansichten verwenden, um die Daten im Abfragespeicher anzuzeigen. Diese Ansichten sind nur in der azure_sys-Datenbank verfügbar.

Abfragen werden normalisiert, indem ihre Struktur analysiert und alles ignoriert wird, das nicht semantisch signifikant ist, z. B. Literale, Konstanten, Aliase oder Unterschiede bei der Groß-/Kleinschreibung.

Wenn zwei Abfragen semantisch identisch sind, auch wenn sie unterschiedliche Aliase für die gleichen Spalten und Tabellen verwenden, werden sie mit demselben query_id-Wert identifiziert. Wenn sich zwei Abfragen nur in den darin verwendeten Literalwerten unterscheiden, werden sie auch mit demselben query_id-Wert identifiziert. Bei Abfragen, die mit demselben query_id-Wert identifiziert wurden, entspricht der sql_query_text-Wert der Abfrage, die seit dem Beginn der Aufzeichnungsaktivität im Abfragespeicher zuerst ausgeführt wurde, oder seit dem letzten Verwerfen der gespeicherten Daten, da die Funktion query_store.qs_reset ausgeführt wurde.

Funktionsweise der Abfragenormalisierung

Die folgenden Beispiele veranschaulichen, wie die Abfragenormalisierung funktioniert:

Angenommen, Sie erstellen eine Tabelle mithilfe der folgenden Anweisung:

create table tableOne (columnOne int, columnTwo int);

Sie aktivieren Abfragespeicher Datensammlung, und mindestens ein Benutzer führt die folgenden Abfragen in dieser genauen Reihenfolge aus:

select * from tableOne;
select columnOne, columnTwo from tableOne;
select columnOne as c1, columnTwo as c2 from tableOne as t1;
select columnOne as "column one", columnTwo as "column two" from tableOne as "table one";

Alle vorherigen Abfragen verwenden dieselbe Abfrage-ID. Abfragespeicher behält den Text der ersten Abfrage bei, die ausgeführt wird, nachdem Sie die Datensammlung aktiviert haben. Daher ist der Text select * from tableOne;.

Sobald die folgenden Abfragen normalisiert sind, stimmen sie nicht mit den vorherigen Abfragen überein, da die WHERE-Klausel sie semantisch unterschiedlich macht:

select columnOne as c1, columnTwo as c2 from tableOne as t1 where columnOne = 1 and columnTwo = 1;
select * from tableOne where columnOne = -3 and columnTwo = -3;
select columnOne, columnTwo from tableOne where columnOne = '5' and columnTwo = '5';
select columnOne as "column one", columnTwo as "column two" from tableOne as "table one" where columnOne = 7 and columnTwo = 7;

Alle Abfragen in diesem letzten Satz verwenden jedoch dieselbe Abfrage-ID. Der Text, der sie identifiziert, ist der Text der ersten Abfrage im Batch: select columnOne as c1, columnTwo as c2 from tableOne as t1 where columnOne = 1 and columnTwo = 1;.

Schließlich stimmen die folgenden Abfragen nicht mit der Abfrage-ID der Abfragen im vorherigen Batch überein. Der Grund, warum sie nicht übereinstimmen, wird in der folgenden Liste erläutert:

Abfrage:

select columnTwo as c2, columnOne as c1 from tableOne as t1 where columnOne = 1 and columnTwo = 1;

Grund für den Nichtabgleich: Die Liste der Spalten bezieht sich auf die gleichen beiden Spalten (columnOne und ColumnTwo), aber die Reihenfolge wird umgekehrt. Die Reihenfolge ändert sich vom vorherigen Batch mit columnOne, ColumnTwo zu dieser Abfrage mit ColumnTwo, columnOne.

Abfrage:

select * from tableOne where columnTwo = 25 and columnOne = 25;

Grund für den Nichtabgleich: Die Reihenfolge, in der die Ausdrücke in der WHERE-Klausel ausgewertet werden, wird umgekehrt. Die Reihenfolge ändert sich von columnOne = ? and ColumnTwo = ? im vorherigen Batch zu ColumnTwo = ? and columnOne = ? in dieser Abfrage.

Abfrage:

select abs(columnOne), columnTwo from tableOne where columnOne = 12 and columnTwo = 21;

Grund für Nichtübereinstimmung: Der erste Ausdruck in der Spaltenliste ist nicht mehr columnOne, aber die abs-Funktion wird über columnOne (abs(columnOne)) ausgewertet, was nicht semantisch gleichwertig ist.

Abfrage:

select columnOne as "column one", columnTwo as "column two" from tableOne as "table one" where columnOne = ceiling(16) and columnTwo = 16;

Grund für Nichtübereinstimmung: Der erste Ausdruck in der WHERE-Klausel wertet die Gleichheit von columnOne nicht mehr mit einem Literal aus, sondern mit dem Ergebnis der ceiling-Funktion, das über ein Literal ausgewertet wird, was nicht semantisch gleichwertig ist.

Ansichten

query_store.qs_view

Diese Ansicht gibt alle Daten zurück, die der Abfragespeicher in den unterstützenden Tabellen enthält. Daten, die der Query Store für das derzeit aktive Zeitfenster noch im Arbeitsspeicher erfasst, sind erst sichtbar, wenn das Zeitfenster endet und die flüchtigen Daten im Arbeitsspeicher gesammelt und in auf dem Datenträger gespeicherten Tabellen gespeichert werden. Diese Ansicht gibt eine andere Zeile für jede unterschiedliche Datenbank (db_id), alle Benutzenden (user_id) und jede Abfrage (query_id) zurück.

query_store.query_texts_view

Diese Ansicht gibt alle Abfragetextdaten im Abfragespeicher zurück. Für jede unterschiedliche query_sql_text-Wert gibt es eine Zeile.

query_store.pgms_wait_sampling_view

Diese Ansicht gibt Warteereignisdaten im Abfragespeicher zurück. Diese Ansicht gibt eine andere Zeile für jede unterschiedliche Datenbank (db_id), alle Benutzenden (user_id), jede Abfrage (query_id) und jedes Ereignis (event) zurück.

query_store.query_plans_view

Diese Ansicht gibt den Abfrageplan zurück, der zum Ausführen einer Abfrage verwendet wurde. Es gibt eine Zeile für jede einzelne Datenbank-ID und Abfrage-ID. Der Abfragespeicher zeichnet nur Abfragepläne für Abfragen ohne Hilfsprogramme auf.

Funktionen

query_store.qs_reset

Diese Funktion verwirft alle Statistiken, die der Abfragespeicher sammelt. Sie verwirft die Statistiken für abgeschlossene Zeitfenster, die bereits in Tabellen auf dem Datenträger gespeichert wurden. Außerdem werden die Statistiken für das aktuelle Zeitfenster verworfen, die nur im Arbeitsspeicher vorhanden sind. Nur Mitglieder der Rolle „Serveradministrator“ (azure_pg_admin) können diese Funktion ausführen.

query_store.staging_data_reset

Diese Funktion verwirft alle Statistiken, die vom Abfragespeicher im Arbeitsspeicher erfasst wurden. Diese Daten wurden noch nicht in die auf dem Datenträger gespeicherten Tabellen geschrieben, die die persistente Speicherung der für den Abfragespeicher erfassten Daten unterstützen. Nur Mitglieder der Rolle „Serveradministrator“ (azure_pg_admin) können diese Funktion ausführen.

Schreibgeschützter Modus

Wenn ein flexibler Azure Database for PostgreSQL-Server im schreibgeschützten Modus ist, zum Beispiel wenn der default_transaction_read_only-Parameter auf on gesetzt ist, oder wenn der schreibgeschützte Modus aufgrund des Erreichens der Speicherkapazität automatisch aktiviert wird, erfasst der Abfragespeicher keine Daten.

Das Aktivieren des Abfragespeichers auf einem Server, auf dem Lesereplikate vorhanden sind, aktiviert nicht automatisch den Abfragespeicher für eines der gelesenen Replikate. Auch wenn Sie sie für eines der gelesenen Replikate aktivieren, zeichnet der Abfragespeicher die abfragen, die für lesereplikate ausgeführt werden, nicht auf. Die Lesereplikate arbeiten im schreibgeschützten Modus, bis Sie sie zur Primärinstanz heraufstufen.

Verwandte Inhalte

• Verwendungsszenarien für den Abfragespeicher
• Bewährte Methoden für den Abfragespeicher
• Abfrageleistungserblick