Überwachen der Leistung mit Abfragespeicher
GILT FÜR: 
Azure Database for PostgreSQL – Flexibler Server
Das Abfragespeicher-Feature in Azure Database for PostgreSQL Flexible Server bietet eine Möglichkeit, um die Abfrageleistung im Zeitverlauf nachzuverfolgen. Der Abfragespeicher vereinfacht das Beheben von Leistungsproblemen, da er es Ihnen ermöglicht, die am längsten ausgeführten und ressourcenintensivsten Abfragen schnell zu ermitteln. 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. Die Daten für alle Benutzer*innen, Datenbanken und Abfragen werden in einer Datenbank namens azure_sys in der Azure Database for PostgreSQL Flexible Server-Instanz gespeichert.
Wichtig
Nehmen Sie an der azure_sys-Datenbank oder ihrem Schema keine Änderungen vor. Andernfalls funktionieren der Abfragespeicher und die entsprechenden Leistungsfeatures nicht mehr ordnungsgemäß.
Aktivieren des Abfragedatenspeichers
Der Abfragespeicher ist in allen Regionen ohne zusätzliche Gebühren verfügbar. Er ist ein optionales Feature. Daher ist er auf einem Server nicht standardmäßig aktiviert. Der Abfragespeicher kann global für alle Datenbanken auf einem bestimmten Server aktiviert oder deaktiviert werden. Ein Aktivieren oder Deaktivieren für einzelne Datenbanken ist nicht möglich.
Wichtig
Aktivieren Sie den Abfragespeicher im Burstable-Tarif nicht, da dadurch die Leistung beeinträchtigt würde.
Aktivieren von Abfragespeicher im Azure-Portal
- Melden Sie sich beim Azure-Portal an, und wählen Sie Ihre Azure Database for PostgreSQL Flexible Server-Instanz aus.
- Wählen Sie im Bereich Einstellungen im Menü die Option Serverparameter aus.
- Suchen Sie nach dem Parameter
pg_qs.query_capture_mode. - Legen Sie den Wert auf
TOPoderALLfest, je nachdem, ob Sie Abfragen der obersten Ebene oder auch geschachtelte Abfragen nachverfolgen möchten (die in einer Funktion oder Prozedur ausgeführt werden), und klicken Sie auf Speichern. 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 Abfragespeicher
- Suchen Sie nach dem Parameter
pgms_wait_sampling.query_capture_mode. - Legen Sie für den Wert
ALLfest und Speichern.
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ührungsdauer einer Abfrage für bestimmte Zeitfenster zum Ermitteln großer Abweichungen
- Ermitteln der am längsten ausgeführten Abfragen in den vergangenen Stunden
- Ermitteln der Top-N-Abfragen, die auf Ressourcen warten
- Nachvollziehen des Warteverhaltens auf 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. Die Informationen in diesen Speichern können mithilfe von Ansichten abgefragt werden.
Zugreifen auf Abfragespeicherinformationen
Abfragespeicherdaten werden in der Datenbank „azure_sys“ in Ihrer Azure Database for PostgreSQL Flexible Server-Instanz gespeichert. Die folgende Abfrage gibt Informationen über Abfragen im Abfragespeicher zurück:
SELECT * FROM query_store.qs_view;
Diese Abfrage gibt Informationen über Wartestatistiken zurück:
SELECT * FROM query_store.pgms_wait_sampling_view;
Suchen von wartenden Abfragen
Warteereignistypen kombinieren verschiedene Warteereignisse nach Ähnlichkeit in Buckets. Der Abfragespeicher enthält den Warteereignistyp, den spezifischen Warteereignisnamen und die entsprechende Abfrage. Die Möglichkeit zum Korrelieren dieser Warteinformationen mit den Abfragelaufzeitstatistiken bedeutet, dass Sie einen ausführlicheren Überblick darüber erhalten, welche Faktoren sich auf die Abfrageleistung auswirken.
Im Folgenden finden Sie einige Beispiele dafür, wie Sie mithilfe der Wartestatistiken im Abfragespeicher weitere Erkenntnisse zur Ihrer Workload erhalten:
| Beobachtung | Aktion |
|---|---|
| Lange Sperrwartevorgänge | Überprüfen Sie die Abfragetexte der betroffenen Abfragen, und identifizieren Sie die Zielentitäten. Suchen Sie im Abfragespeicher nach anderen Abfragen, die die gleiche Entität ändern, welche häufig ausgeführt wird bzw. eine lange Dauer aufweist. Nachdem Sie diese Abfragen ermittelt haben, ändern Sie ggf. die Anwendungslogik, um die Parallelität zu verbessern, oder verwenden Sie eine weniger restriktive Isolationsstufe. |
| Lange Puffer-E/A-Wartevorgänge | Suchen Sie die Abfragen mit einer hohen Anzahl an physischen Lesevorgängen im Abfragespeicher. Wenn diese mit Abfragen mit langen E/A-Wartevorgängen übereinstimmen, führen Sie ggf. einen Index für die zugrunde liegenden Entität ein, um Such- anstelle von Scanvorgängen durchzuführen. Dies verringert den E/A-Aufwand der Abfragen. Überprüfen Sie die Leistungsempfehlungen für Ihren Server im Portal, um festzustellen, ob Indexempfehlungen für diesen Server vorhanden sind, die die Abfragen optimieren. |
| Lange Arbeitsspeicher-Wartevorgänge | Suchen Sie die im Abfragespeicher die speicherintensivsten Abfragen. Diese Abfragen verzögern wahrscheinlich zusätzlich den Fortschritt der betroffen Abfragen. Überprüfen Sie die Leistungsempfehlungen für Ihren Server im Portal, um festzustellen, ob Indexempfehlungen vorhanden sind, die diese Abfragen optimieren. |
Konfigurationsoptionen
Wenn der Abfragespeicher aktiviert ist, werden Daten in Aggregationsfenstern gespeichert, die durch den Serverparameter pg_qs.interval_length_minutes bestimmt werden (standardmäßig auf 15 Minuten festgelegt). Für jedes Fenster werden bis zu 500 unterschiedliche Abfragen (mit unterschiedlichen Benutzer-ID-, Datenbank-ID und Abfrage-ID) gespeichert. Wenn während eines Intervalls die Anzahl der unterschiedlichen Abfragen 500 erreicht, werden die Reservierungen für die 5 % mit geringerer Nutzung aufgehoben, um Platz zu schaffen.
Die folgenden Optionen stehen für die Konfiguration der Abfragespeicher-Parameter zur Verfügung:
| Parameter | Beschreibung | Standard | Bereich |
|---|---|---|---|
| pg_qs.query_capture_mode | Legt fest, welche Anweisungen nachverfolgt werden. | none | none, top, all |
| pg_qs.interval_length_minutes (*) | Legt das Erfassungsintervall „query_store“ in Minuten für „pg_qs“ fest (die Häufigkeit der Datenpersistenz) | 15 | 1 – 30 |
| pg_qs.store_query_plans | Aktiviert oder deaktiviert das Speichern von Abfrageplänen für „pg_qs“ | aus | on, off |
| pg_qs.max_plan_size | Legt die maximale Anzahl von Bytes fest, die für den Abfrageplantext für pg_qs gespeichert wird. Längere Pläne werden abgeschnitten. | 7.500 | 100 – 10.000 |
| pg_qs.max_query_text_length | Legt die maximale Abfragelänge fest, die gespeichert werden kann – längere Abfragen werden abgeschnitten. | 6000 | 100 – 10.000 |
| pg_qs.retention_period_in_days | Legt das Aufbewahrungszeitfenster in Tagen für „pg_qs“ fest – nach diesem Zeitpunkt werden Daten gelöscht. | 7 | 1 – 30 |
| pg_qs.track_utility | Legt fest, ob Dienstprogrammbefehle von „pg_qs“ nachverfolgt werden | on | on, off |
(*) Statischer Serverparameter, der einen Serverneustart erfordert, damit eine Änderung des Werts wirksam wird
Die folgenden Optionen gelten speziell für Wartestatistiken:
| Parameter | Beschreibung | Standard | Bereich |
|---|---|---|---|
| pgms_wait_sampling.query_capture_mode | Wählt aus, welche Anweisungen von der Erweiterung „pgms_wait_sampling“ nachverfolgt werden | Keine | none, all |
| Pgms_wait_sampling.history_period | Legt die Häufigkeit in Millisekunden fest, mit der Stichproben von Wartezeitereignissen erfasst werden | 100 | 1 – 600000 |
Hinweis
pg_qs.query_capture_mode ersetzt pgms_wait_sampling.query_capture_mode. Wenn für pg_qs.query_capture_mode NONE festgelegt ist, hat die Einstellung pgms_wait_sampling.query_capture_mode keine Auswirkungen.
Verwenden Sie dasAzure-Portal, um für einen Parameter einen anderen Wert abzurufen oder festzulegen.
Ansichten und Funktionen
Mithilfe der folgenden Ansichten und Funktionen können Sie den Abfragespeicher anzeigen und verwalten. 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 allen Abfragen, die mit demselben query_id-Wert identifiziert wurden, entspricht deren 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
Im Folgenden sind einige Beispiele aufgeführt, um zu veranschaulichen, wie diese Normalisierung funktioniert:
Nehmen Sie an, dass Sie eine Tabelle mit der folgenden Anweisung erstellen:
create table tableOne (columnOne int, columnTwo int);
Sie aktivieren die Datensammlung im Abfragespeicher, und ein oder mehrere Benutzer*innen führen die folgenden Abfragen in genau dieser 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 denselben query_id-Wert. Der Text, den der Abfragespeicher speichert, ist der der ersten Abfrage, die nach dem Aktivieren der Datensammlung ausgeführt wird. Daher würde dieser select * from tableOne; lauten.
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 Abfrageset verwenden jedoch denselben query_id-Wert, und der Text, der zum Identifizieren dieser Abfragen verwendet wird, ist der der ersten Abfrage im Batch select columnOne as c1, columnTwo as c2 from tableOne as t1 where columnOne = 1 and columnTwo = 1;.
Schließlich sehen Sie unten einige Abfragen, die nicht mit dem query_id-Wert derjenigen im vorherigen Batch übereinstimmen. Das hat folgende Gründe:
Abfrage:
select columnTwo as c2, columnOne as c1 from tableOne as t1 where columnOne = 1 and columnTwo = 1;
Grund für Nichtübereinstimmung: Die Liste der Spalten bezieht sich auf die gleichen beiden Spalten (columnOne und ColumnTwo), aber die Reihenfolge, in der auf sie verwiesen werden, wird von columnOne, ColumnTwo im vorherigen Batch zu ColumnTwo, columnOne in dieser Abfrage umgekehrt.
Abfrage:
select * from tableOne where columnTwo = 25 and columnOne = 25;
Grund für Nichtübereinstimmung: Die Reihenfolge, in der auf die in der WHERE-Klausel ausgewerteten Ausdrücke verwiesen wird, wird von columnOne = ? and ColumnTwo = ? im vorherigen Batch zu ColumnTwo = ? and columnOne = ? in dieser Abfrage umgekehrt.
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 Funktion abs 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 Funktion ceiling, das über ein Literal ausgewertet wird, was nicht semantisch gleichwertig ist.
Ansichten
query_store.qs_view
Diese Ansicht gibt alle Daten zurück, die bereits in den unterstützenden Tabellen des Abfragespeichers gespeichert wurden. Daten, die im Arbeitsspeicher für das derzeit aktive Zeitfenster aufgezeichnet werden, werden erst angezeigt, wenn das Zeitfenster zu Ende ist, und die veränderlichen Daten im Arbeitsspeicher werden gesammelt und in Tabellen gespeichert, die auf dem Datenträger gespeichert sind. Diese Ansicht gibt eine andere Zeile für jede unterschiedliche Datenbank (db_id), jede*n Benutzer*in (user_id) und jede Abfrage (query_id) zurück.
| Name | Typ | Referenzen | Beschreibung |
|---|---|---|---|
| runtime_stats_entry_id | BIGINT | Die ID aus der Tabelle runtime_stats_entries | |
| user_id | oid | pg_authid.oid | Die OID des Benutzers oder der Benutzerin, der oder die die Anweisung ausgeführt hat |
| db_id | oid | pg_database.oid | Die OID der Datenbank, in der die Anweisung ausgeführt wurde |
| query_id | BIGINT | Interner Hash, der von der Analysestruktur der Anweisung berechnet wurde | |
| query_sql_text | varchar(10000) | Der Text einer repräsentativen Anweisung. Unterschiedliche Abfragen mit der gleichen Struktur werden gruppiert; dieser Text ist der Text für die erste Abfrage im Cluster. Der Standardwert für die maximale Länge des Abfragetextes beträgt 6000 und kann mithilfe des Abfragespeicherparameters pg_qs.max_query_text_length geändert werden. Wenn der Text der Abfrage diesen Maximalwert überschreitet, wird er auf die ersten pg_qs.max_query_text_length Zeichen abgeschnitten. |
|
| plan_id | BIGINT | ID des Plans, der dieser Abfrage entspricht | |
| start_time | Zeitstempel | Abfragen werden nach Zeitfenstern aggregiert, deren Zeitspanne durch den Serverparameter pg_qs.interval_length_minutes definiert wird (Standardwert ist 15 Minuten). Dies ist die Startzeit, die dem Zeitfenster für diesen Eintrag entspricht. |
|
| end_time | Zeitstempel | Dies ist die Endzeit, die dem Zeitfenster für diesen Eintrag entspricht. | |
| calls | BIGINT | Häufigkeit, mit der die Abfrage in diesem Zeitfenster ausgeführt wird. Beachten Sie, dass für parallele Abfragen die Anzahl der Aufrufe für jede Ausführung 1 für den Back-End-Prozess entspricht, der die Ausführung der Abfrage verursacht, sowie viele weitere Einheiten für jeden Back-End-Workerprozess, der gestartet wurde, um die parallelen Verzweigungen der Ausführungsstruktur auszuführen. | |
| total_time | double precision | Gesamte Abfrageausführungsdauer in Millisekunden | |
| min_time | double precision | Minimale Abfrageausführungsdauer in Millisekunden | |
| max_time | double precision | Maximale Abfrageausführungsdauer in Millisekunden | |
| mean_time | double precision | Durchschnittliche Abfrageausführungsdauer in Millisekunden | |
| stddev_time | double precision | Standardabweichung der Abfrageausführungsdauer in Millisekunden | |
| rows | BIGINT | Gesamtanzahl der Zeilen, die abgerufen wurden oder von der Anweisung betroffen sind. Beachten Sie, dass bei parallelen Abfragen die Anzahl der Zeilen für jede Ausführung der Anzahl der Zeilen entspricht, die vom Back-End-Prozess an den Client zurückgegeben werden, der die Ausführung der Abfrage verursacht, plus die Summe aller Zeilen, die jeder Back-End-Arbeitsprozess gestartet hat, um die parallelen Verzweigungen der Ausführungsstruktur auszuführen, zum verursachenden Back-End-Prozess zurück. | |
| shared_blks_hit | BIGINT | Gesamtanzahl der freigegebenen Blockcachetreffer der Anweisung | |
| shared_blks_read | BIGINT | Gesamtanzahl der freigegebenen Blöcke, die von der Anweisung gelesen wurden | |
| shared_blks_dirtied | BIGINT | Gesamtanzahl der freigegebenen Blöcke, die von der Anweisung geändert wurden | |
| shared_blks_written | BIGINT | Gesamtanzahl der freigegebenen Blöcke, die von der Anweisung geschrieben wurden | |
| local_blks_hit | BIGINT | Gesamtanzahl der lokalen Blockcachetreffer der Anweisung | |
| local_blks_read | BIGINT | Gesamtanzahl der lokalen Blöcke, die von der Anweisung gelesen wurden | |
| local_blks_dirtied | BIGINT | Gesamtanzahl der lokalen Blöcke, die von der Anweisung geändert wurden | |
| local_blks_written | BIGINT | Gesamtanzahl der lokalen Blöcke, die von der Anweisung geschrieben wurden | |
| temp_blks_read | BIGINT | Gesamtanzahl der temporären Blöcke, die von der Anweisung gelesen wurden | |
| temp_blks_written | BIGINT | Gesamtanzahl der temporären Blöcke, die von der Anweisung geschrieben wurden | |
| blk_read_time | double precision | Gesamtzeit in Millisekunden, die die Anweisung zum Lesen von Blöcken benötigt hat (wenn „track_io_timing“ aktiviert ist, andernfalls 0) | |
| blk_write_time | double precision | Gesamtzeit in Millisekunden, die die Anweisung zum Schreiben von Blöcken benötigt hat (wenn „track_io_timing“ aktiviert ist, andernfalls 0) | |
| is_system_query | boolean | Bestimmt, ob die Abfrage mithilfe der Rolle mit „user_id = 10“ (azuresu) ausgeführt wurde, die über Superuserberechtigungen verfügt und zum Ausführen von Steuerungsebenenvorgängen verwendet wird. Da dieser Dienst ein verwalteter PaaS-Dienst ist, ist nur Microsoft Mitglied der Rolle „Superuser“. | |
| query_type | text | Art des Vorgangs der Abfrage. Mögliche Werte sind unknown, select, update, insert, delete, merge, utility, nothing und undefined. |
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.
| Name | Art | Beschreibung |
|---|---|---|
| query_text_id | BIGINT | ID der Tabelle query_texts |
| query_sql_text | varchar(10000) | Der Text einer repräsentativen Anweisung. Unterschiedliche Abfragen mit der gleichen Struktur werden gruppiert; dieser Text ist der Text für die erste Abfrage im Cluster. |
| query_type | smallint | Art des Vorgangs der Abfrage. In PostgreSQL <= 14 lauten die möglichen Werte 0 (unbekannt), 1 (auswählen), 2 (aktualisieren), 3 (einfügen), 4 (löschen), 5 (Hilfsprogramm), 6 (nichts). In PostgreSQL >= 15 lauten die möglichen Werte 0 (unbekannt), 1 (auswählen), 2 (aktualisieren), 3 (einfügen), 4 (löschen), 5 (zusammenführen), 6 (Hilfsprogramm), 7 (nichts). |
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), jede*n Benutzer*in (user_id), jede Abfrage (query_id) und jedes Ereignis (event) zurück.
| Name | Typ | Referenzen | Beschreibung |
|---|---|---|---|
| start_time | Zeitstempel | Abfragen werden nach Zeitfenstern aggregiert, deren Zeitspanne durch den Serverparameter pg_qs.interval_length_minutes definiert wird (Standardwert ist 15 Minuten). Dies ist die Startzeit, die dem Zeitfenster für diesen Eintrag entspricht. |
|
| end_time | Zeitstempel | Dies ist die Endzeit, die dem Zeitfenster für diesen Eintrag entspricht. | |
| user_id | oid | pg_authid.oid | Die OID des Benutzers oder der Benutzerin, der oder die die Anweisung ausgeführt hat |
| db_id | oid | pg_database.oid | Die OID der Datenbank, in der die Anweisung ausgeführt wurde |
| query_id | BIGINT | Interner Hash, der von der Analysestruktur der Anweisung berechnet wurde | |
| event_type | text | Art des Ereignisses, auf das das Back-End wartet | |
| event | text | Der Warteereignisname, wenn das Back-End derzeit wartet | |
| calls | integer | Häufigkeit, mit der dasselbe Ereignis erfasst wurde |
Hinweis
Eine Liste der möglichen Werte in den event_type- und event-Spalten der Ansicht query_store.pgms_wait_sampling_view finden Sie in der offiziellen Dokumentation zu pg_stat_activity. Suchen Sie dort nach Informationen zu Spalten mit denselben Namen.
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. Dadurch werden nur Abfragepläne für Abfragen ohne Hilfsprogramme gespeichert.
| plan_id | db_id | query_id | plan_text |
|---|---|---|---|
| plan_id | BIGINT | Der Hashwert aus dem normalisierten Abfrageplan, der von EXPLAIN erstellt wird. Er wird als normalisiert betrachtet, da er die geschätzten Kosten für Planknoten und die Verwendung von Puffern ausschließt. | |
| db_id | oid | pg_database.oid | Die OID der Datenbank, in der die Anweisung ausgeführt wurde |
| query_id | BIGINT | Interner Hash, der von der Analysestruktur der Anweisung berechnet wurde | |
| plan_text | varchar(10000) | Ausführungsplan der Anweisung mit den Angaben costs=false, buffers=false und format=text. Dies ist die gleiche Ausgabe, die von EXPLAIN angegeben wird. |
Funktionen
query_store.qs_reset
Diese Funktion verwirft alle Statistiken, die bisher vom Abfragespeicher gesammelt wurden. Sie verwirft sowohl die Statistiken für bereits abgeschlossene Zeitfenster, die auf Datenträgertabellen gespeichert wurden, als auch diejenigen für das aktuelle Zeitfenster, die weiterhin im Arbeitsspeicher gespeichert sind. Diese Funktion kann nur von der Serveradministratorrolle (azure_pg_admin) ausgeführt werden.
query_store.staging_data_reset
Mit dieser Funktion werden alle Statistiken verworfen, die vom Abfragespeicher im Arbeitsspeicher gesammelt wurden (d. h. die Daten im Arbeitsspeicher, die noch nicht geleert und in die Datenträgertabellen verschoben wurden, die Persistenz von gesammelten Daten für den Abfragespeicher unterstützen). Diese Funktion kann nur von der Serveradministratorrolle (azure_pg_admin) ausgeführt werden.
Einschränkungen und bekannte Probleme
Kompatibilität zwischen Azure Storage und Abfragespeicher
Aufgrund von Kompatibilitätsproblemen können Sie Azure Storage- und Abfragespeichererweiterungen nicht gleichzeitig aktivieren. Aktivieren Sie jeweils nur eine dieser Erweiterungen, um eine ordnungsgemäße Funktionsweise sicherzustellen und potenzielle Konflikte zu vermeiden.
Verwenden von Azure Storage:
- Deaktivieren Sie den Abfragespeicher, indem Sie den Parameter
pg_qs.query_capture_modeaufNONE. Dieser Parameter ist dynamisch, sodass Sie nicht neu starten müssen.
So verwenden Sie den Abfragespeicher:
- Deaktivieren Sie die Azure Storage-Erweiterung durch Ausstellen von
DROP EXTENSION azure_storage;. - Entfernen Sie Azure Storage aus
shared_preload_libraries. - Starten Sie den Datenbankserver neu.
Diese Schritte sind erforderlich, um Konflikte zu vermeiden und sicherzustellen, dass Ihr System ordnungsgemäß funktioniert. Wir arbeiten daran, diese Kompatibilitätsprobleme zu beheben, und halten Sie über alle Updates auf dem Laufenden.
Schreibgeschützter Modus
Wenn sich eine Azure Database for PostgreSQL Flexible Server-Instanz im schreibgeschützten Modus befindet, z. B. weil der Parameter default_transaction_read_only auf on festgelegt ist oder der schreibgeschützte Modus automatisch aktiviert ist, da die Speicherkapazität voll ist, erfasst der Abfragespeicher keine Daten.