Teilen über

Überwachen der Leistung mit Abfragespeicher

  • Artikel

GILT FÜR: Azure Database for PostgreSQL – Flexible 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

  1. Melden Sie sich beim Azure-Portal an, und wählen Sie Ihre Azure Database for PostgreSQL Flexible Server-Instanz aus.
  2. Wählen Sie im Bereich Einstellungen im Menü die Option Serverparameter aus.
  3. Suchen Sie nach dem Parameter pg_qs.query_capture_mode.
  4. Legen Sie den Wert auf TOP oder ALL fest, 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

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

Informationen im Abfragespeicher

Der Abfragespeicher besteht aus zwei Speichern:

  1. Ein Speicher für Laufzeitstatistiken zum Aufbewahren der Informationen aus den Abfragespeicherstatistiken.
  2. 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). Pro Fenster speichert er 500 verschiedene Abfragen. 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_mode auf NONE. Dieser Parameter ist dynamisch, sodass Sie nicht neu starten müssen.

So verwenden Sie den Abfragespeicher:

  1. Deaktivieren Sie die Azure Storage-Erweiterung durch Ausstellen vonDROP EXTENSION azure_storage;.
  2. Entfernen Sie Azure Storage aus shared_preload_libraries.
  3. 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.

Zugehöriger Inhalt