Teilen über

Autonome Optimierung

Die autonome Optimierung ist ein Feature in Ihrer Azure-Datenbank für flexible Serverinstanz von PostgreSQL, die Abfragen analysiert, die von Ihrer Workload nachverfolgt werden, und bietet Empfehlungen zur Verbesserung der Leistung dieser Abfragen.

Es ist ein integriertes Angebot in Ihrer Azure-Datenbank für PostgreSQL-Flexible-Serverinstanz, das auf der Funktionalität des Abfragespeichers basiert. Die autonome Optimierung analysiert die workload, die vom Abfragespeicher nachverfolgt wird, und erzeugt Index- oder Tabellenempfehlungen, um die Leistung der analysierten Workload zu verbessern. Es kann Empfehlungen erstellen, um neue Indizes zu erstellen, doppelte oder nicht verwendete Indizes zu entfernen, Tabellen zu analysieren, die keine Statistiken oder veraltete Statistiken aufweisen, oder aufgeblähte Tabellen leeren.

Allgemeine Beschreibung des autonomen Optimierungsalgorithmus

Wenn der Serverparameter index_tuning.mode auf report festgelegt ist, werden Optimierungssitzungen automatisch mit der im Serverparameter index_tuning.analysis_interval konfigurierten Frequenz gestartet (ausgedrückt in Minuten).

In der ersten Phase sucht die Optimierungssitzung nach der Liste der Datenbanken, in denen sie der Ansicht ist, dass die von ihr erzeugten Empfehlungen die Gesamtleistung des Systems erheblich beeinträchtigen könnten. Hierzu werden alle vom Abfragespeicher erfassten Abfragen gesammelt, deren Ausführungen innerhalb des Suchintervalls erfasst wurden, auf das sich diese Optimierungssitzung konzentriert. Das Suchintervall umfasst derzeit die letzten index_tuning.analysis_interval Minuten (ab dem Startzeitpunkt der Optimierungssitzung).

Alle benutzerseitig initiierten Abfragen mit im Abfragespeicher erfassten Ausführungen und nicht zurückgesetzter Laufzeitstatistik werden vom System basierend auf der aggregierten Gesamtausführungszeit bewertet. Die Konzentration liegt auf den hervorstechendsten Abfragen, basierend auf ihrer Dauer.

Folgende Abfragen werden aus dieser Liste ausgeschlossen:

  • Systemseitig initiierte Abfragen. (also Abfragen, die von der azuresu-Rolle ausgeführt wurden)
  • Abfragen, die im Kontext einer beliebigen Systemdatenbank (azure_sys, template0, template1 und azure_maintenance) ausgeführt wurden.

Der Algorithmus durchläuft die Zieldatenbanken und sucht nach möglichen Indizes, die ggf. die Leistung der analysierten Workloads verbessern. Sucht auch nach Indizes, die eliminiert werden können, weil sie Duplikate sind oder nicht für einen konfigurierbaren Zeitraum verwendet werden. Identifiziert außerdem Tabellen, die keine aktuellen Statistiken oder aufgeblähten Tabellen aufweisen.

CREATE INDEX-Empfehlungen

Für jede Datenbank, die als Kandidat identifiziert werden soll, werden alle SELECT-, UPDATE-, INSERT- und DELETE-Abfragen, die während des Nachschlageintervalls und im Kontext dieser spezifischen Datenbank ausgeführt werden, analysiert.

Die resultierende Gruppe von Abfragen wird basierend auf ihrer aggregierten Gesamtausführungszeit bewertet, und die wichtigsten index_tuning.max_queries_per_database werden auf mögliche Indexempfehlungen analysiert.

Mögliche Empfehlungen zielen darauf ab, die Leistung folgender Arten von Abfragen zu verbessern:

  • Abfragen mit Filtern (also Abfragen mit Prädikaten in der WHERE-Klausel)
  • Abfragen, die mehrere Beziehungen miteinander verknüpfen – unabhängig davon, ob sie der Syntax folgen, in der Joins per JOIN-Klausel ausgedrückt werden, oder ob die Join-Prädikate in der WHERE-Klausel ausgedrückt werden
  • Abfragen, die Filter und Join-Prädikate miteinander kombinieren
  • Abfragen mit Gruppierung (Abfragen mit einer GROUP BY-Klausel)
  • Abfragen, die Filter und Gruppierung miteinander kombinieren
  • Abfragen mit Sortierung (Abfragen mit einer ORDER BY-Klausel)
  • Abfragen, die Filter und Sortierung miteinander kombinieren

Hinweis

Die einzige Art von Indizes, die das System derzeit empfiehlt, ist B-Tree.

Wenn eine Abfrage auf eine Spalte einer Tabelle verweist und diese Tabelle keine Statistiken enthält, werden keine Indexempfehlungen zur Verbesserung der Ausführung erzeugt. Es generiert jedoch eine Empfehlung, die Tabelle zu analysieren.

index_tuning.max_indexes_per_table gibt die Anzahl von Indizes an, die empfohlen werden können (mit Ausnahme von Indizes, die möglicherweise bereits für die Tabelle vorhanden sind) – für eine beliebige einzelne Tabelle, auf die während einer Optimierungssitzung durch eine beliebige Anzahl von Abfragen verwiesen wird.

index_tuning.max_index_count gibt die Anzahl von Indexempfehlungen an, die für alle Tabellen jeder Datenbank generiert werden, die während einer Optimierungssitzung analysiert wurde.

Damit eine Indexempfehlung ausgegeben wird, muss es für die Optimierungs-Engine wahrscheinlich sein, dass sich dadurch mindestens eine Abfrage in der analysierten Workload um einen mithilfe von index_tuning.min_improvement_factor angegebenen Faktor verbessert.

Ebenso werden alle Indexempfehlungen überprüft, um sicherzustellen, dass sie keine Regression für eine Abfrage in dieser Workload zur Folge haben, die einem mithilfe von index_tuning.max_regression_factor angegebenen Faktor entspricht.

Hinweis

index_tuning.min_improvement_factor und index_tuning.max_regression_factor beziehen sich auf die Kosten von Abfrageplänen, nicht auf ihre Dauer oder die Ressourcen, die sie bei der Ausführung nutzen.

Alle in den vorherigen Absätzen erwähnten Parameter sowie ihre Standardwerte und gültigen Bereiche sind in den Konfigurationsoptionen beschrieben.

Das Skript, das zusammen mit der Empfehlung zum Erstellen eines Index generiert wird, basiert auf folgendem Muster:

CREATE INDEX CONCURRENTLY {indexName} ON {schema}.{table}({column_name}[, ...])

Es beinhaltet die Klausel CONCURRENTLY. Weitere Informationen zu den Auswirkungen dieser Klausel finden Sie in der offiziellen PostgreSQL-Dokumentation für CREATE INDEX.

Die autonome Optimierung generiert automatisch die Namen der empfohlenen Indizes, die in der Regel aus den Namen der verschiedenen Schlüsselspalten bestehen, die durch "_" (Unterstriche) und mit einem Konstantensuffix "_idx" getrennt sind. Wenn die Gesamtlänge des Namens die Grenzwerte von PostgreSQL übersteigt oder wenn ein Konflikt mit bereits vorhandenen Beziehungen entsteht, weicht der Name geringfügig ab. Möglicherweise wird er abgeschnitten, oder es wird am Ende des Namens eine Zahl hinzugefügt.

Berechnen der Auswirkungen einer CREATE INDEX-Empfehlung

Die Auswirkungen der Erstellung einer Indexempfehlung werden anhand von „IndexSize“ (in Megabytes) und „QueryCostImprovement“ (in Prozent) bestimmt.

„IndexSize“ ist ein einzelner Wert, der die geschätzte Größe des Index darstellt, wobei die aktuelle Kardinalität der Tabelle und die Größe der Spalten berücksichtigt werden, auf die durch den empfohlenen Index verwiesen wird.

Bei „QueryCostImprovement“ handelt es sich um ein Array von Werten, in dem jedes Element die Verbesserung der Kosten des Plans für jede Abfrage darstellt, bei der davon ausgegangen wird, dass sich die Kosten ihres Plans verbessern, wenn dieser Index vorhanden wäre. Für jedes Element werden der Bezeichner der Abfrage (abgefragt) sowie der Prozentwert angezeigt, um den sich die Kosten des Plans verbessert würden, wenn die Empfehlung implementiert würde (dimensional).

DROP INDEX- und REINDEX-Empfehlungen

Für jede datenbank, die als Kandidat identifiziert wurde, sollte sie eine neue Sitzung initiieren, und nachdem die CREATE INDEX-Empfehlungenphase abgeschlossen ist, empfiehlt sie, vorhandene Indizes basierend auf den folgenden Kriterien abzulegen oder neu zu indizieren:

  • Lösen Sie die Verknüpfung auf, wenn sie als Duplikat von anderen betrachtet wird.
  • Lösen Sie die Verknüpfung auf, wenn sie nicht für eine konfigurierbare Zeitspanne verwendet wird.
  • Neuindizieren Sie Indizes, die als ungültig markiert sind.

Löschen doppelter Indizes

Empfehlungen für die Löschung doppelter Indizes: Identifizieren Sie zuerst, für welche Indizes Duplikate vorhanden sind.

Für Duplikate wird basierend auf verschiedenen Funktionen, die dem Index zugeordnet werden können, sowie basierend auf ihrer geschätzten Größe eine Rangfolge erstellt.

Abschließend wird empfohlen, alle Duplikate zu löschen, die über einen niedrigeren Rang verfügen als das zugehörige Referenzelement mit dem höchsten Rang, und es wird jeweils beschrieben, wie der Rang des jeweiligen Duplikats zustande kam.

Damit zwei Indizes als Duplikate betrachtet werden, muss Folgendes erfüllt sein:

  • Sie müssen für die gleiche Tabelle erstellt worden sein.
  • Sie müssen exakt den gleichen Typ haben.
  • Die Schlüsselspalten müssen übereinstimmen. Bei mehrspaltigen Indexschlüsseln muss außerdem die Reihenfolge übereinstimmen, in der auf sie verwiesen wird.
  • Die Ausdrucksbaumstruktur ihres Prädikats muss übereinstimmen. Dies gilt nur für partielle Indizes.
  • Die Ausdrucksbaumstruktur aller nicht einfachen Spaltenverweise muss übereinstimmen. Dies gilt nur für Indizes, die für Ausdrücke erstellt wurden.
  • Die Sortierung der einzelnen Spalten, auf die im Schlüssel verwiesen wird, muss übereinstimmen.

Löschen nicht verwendeter Indizes

Im Zusammenhang mit dem Löschen nicht verwendeter Indizes empfiehlt es sich, Indizes zu identifizieren, auf die Folgendes zutrifft:

  • Sie wurden mindestens index_tuning.unused_min_period Tage lang nicht verwendet.
  • Weisen Sie eine Mindestanzahl von index_tuning.unused_dml_per_table-DMLs (Tagesdurchschnitt) in der Tabelle auf, in welcher der Index erstellt wurde.
  • Weisen Sie eine Mindestanzahl von index_tuning.unused_reads_per_table-Lesevorgängen (Tagesdurchschnitt) in der Tabelle auf, in welcher der Index erstellt wurde.

Ungültige Indizes neu indizieren

Empfehlungen für eine erneute Indizierung vorhandener Indizes - identifizieren Sie die Indizes, die als ungültig gekennzeichnet sind. Weitere Informationen dazu, warum und wann Indizes als ungültig gekennzeichnet sind, finden Sie in der offiziellen Dokumentation zu REINDEX in PostgreSQL.

Berechnen der Auswirkungen einer DROP INDEX-Empfehlung

Die Auswirkung einer Empfehlung zum Löschen eines Index wird in zwei Dimensionen gemessen: „Benefit“ (in Prozent) und „IndexSize“ (in Megabytes).

„Benefit“ ist ein einzelner Wert, der vorerst ignoriert werden kann.

„IndexSize“ ist ein einzelner Wert, der die geschätzte Größe des Index darstellt, wobei die aktuelle Kardinalität der Tabelle und die Größe der Spalten berücksichtigt werden, auf die durch den empfohlenen Index verwiesen wird.

Tabellenempfehlungen

Für jede Datenbank, die als Kandidat zur Analyse identifiziert wurde, initiiert sie eine Sitzung, die darauf abzielt, Empfehlungen auf Tabellenebene zu erstellen. Diese Empfehlungen ermuntern Sie, ANALYSE oder VAKUUM auf den Tabellen auszuführen, auf die von den geprüften Abfragen zugegriffen wird und wofür das Tuning-Modul erachtet, dass die Ausführung dieser Befehle die Leistung Ihrer Arbeitslast verbessern könnte.

Empfehlungen zur Tabellenanalyse

Empfehlungen für die Analyse einer Tabelle identifizieren diese Tabellen, die:

  • In einer Abfrage wird auf eine Spalte dieser Tabelle verwiesen, die in einem der Prädikate (WHERE, JOIN, ORDER BY, GROUP BY) verwendet wird und eine der beiden folgenden Bedingungen erfüllt:
    • Wurden nie analysiert.
    • Wurden irgendwann analysiert, fehlen aber jetzt Statistiken (in der Regel weil der Server abgestürzt war, bevor die Statistiken auf dem Datenträger gespeichert wurden).

VACUUM-Tabellenempfehlungen

Empfehlungen für das Vakuumieren einer Tabelle identifizieren die Tabellen, die aufgebläht sind. Diese Empfehlungen werden nur erstellt, wenn autovacuum_enabled auf Serverebene nicht auf off festgelegt ist, wenn die Workload analysiert wird.

Konfigurieren der autonomen Anpassung

Die autonome Optimierung kann über eine Reihe von Parametern aktiviert, deaktiviert und konfiguriert werden, die ihr Verhalten steuern.

Wenn die autonome Optimierung aktiviert ist, erwacht sie mit einer Häufigkeit, die im Serverparameter index_tuning.analysis_interval konfiguriert ist (standardmäßig 720 Minuten oder 12 Stunden), und beginnt mit der Analyse der Workload, die während dieses Zeitraums vom Abfragespeicher aufgezeichnet wurde.

Hinweis: Wenn Sie den Wert für index_tuning.analysis_interval ändern, wird dies erst nach Abschluss der nächsten geplanten Ausführung berücksichtigt. Wenn Sie beispielsweise eine autonome Optimierung um 10:00 Uhr aktivieren, da der Standardwert index_tuning.analysis_interval 720 Minuten beträgt, wird die erste Ausführung am selben Tag um 10:00 Uhr gestartet. Alle Änderungen, die Sie am Wert von index_tuning.analysis_interval zwischen 10:00 Uhr und 22:00 Uhr vornehmen, wirken sich nicht auf diesen anfänglichen Zeitplan aus. Der aktuell für index_tuning.analysis_interval festgelegte Wert wird erst nach Abschluss der geplanten Ausführung gelesen, und die nächste Ausführung wird gemäß diesem Wert geplant.

Die folgenden Optionen stehen zum Konfigurieren autonomer Optimierungsparameter zur Verfügung:

Parameter Beschreibung Vorgabe Bereich Einheiten
index_tuning.analysis_interval Legt die Frequenz fest, mit der die einzelnen Indexoptimierungssitzungen ausgelöst werden, wenn „index_tuning.mode“ auf REPORT festgelegt ist. 720 60 - 10080 minutes
index_tuning.max_columns_per_index Maximale Anzahl von Spalten, die Teil des Indexschlüssels für einen empfohlenen Index sein können. 2 1 - 10
index_tuning.max_index_count Empfohlene maximale Indizes für die einzelnen Datenbanken während einer einzelnen Optimierungssitzung. 10 1 - 25
index_tuning.max_indexes_per_table Maximale Anzahl von Indizes, die pro Tabelle empfohlen werden können. 10 1 - 25
index_tuning.max_queries_per_database Anzahl der langsamsten Abfragen pro Datenbank, für die Indizes empfohlen werden können. 25 5 - 100
index_tuning.max_regression_factor Akzeptable Regression, die durch einen empfohlenen Index für beliebige der während einer Optimierungssitzung analysierten Abfragen eingeführt wird. 0.1 0.05 - 0.2 Prozentwert
index_tuning.max_total_size_factor Maximale Gesamtgröße in Prozent des gesamten Speicherplatzes, die von allen empfohlenen Indizes für eine bestimmte Datenbank genutzt werden kann. 0.1 0 - 1 Prozentwert
index_tuning.min_improvement_factor Kostenverbesserung, die ein empfohlener Index für mindestens eine der während einer Optimierungssitzung analysierten Abfragen erzielen muss. 0.2 0 - 20 Prozentwert
index_tuning.mode Konfiguriert die Indexoptimierung als deaktiviert (OFF) oder aktiviert, um nur Empfehlung auszugeben. Setzt die Aktivierung des Abfragespeichers durch Festlegen von pg_qs.query_capture_mode auf TOP oder ALL voraus. OFF OFF, REPORT
index_tuning.unused_dml_per_table Die Mindestanzahl durchschnittlicher DML-Vorgänge pro Tag, die sich auf die Tabelle auswirken, damit die Löschung ihrer nicht verwendeten Indizes in Betracht gezogen wird. 1000 0 - 9999999
index_tuning.unused_min_period Die Mindestanzahl von Tagen, die der Index nicht verwendet wurde (basierend auf Systemstatistiken), damit seine Löschung in Betracht gezogen wird. 35 30 - 70
index_tuning.unused_reads_per_table Die Mindestanzahl durchschnittlicher Lesevorgänge pro Tag, die sich auf die Tabelle auswirken, damit die Löschung ihrer nicht verwendeten Indizes in Betracht gezogen wird. 1000 0 - 9999999

Wenn Sie die CLI-Befehle az postgres flexible-server autonomous-tuning show-settings und az postgres flexible-server autonomous-tuning set-settings verwenden, um eine der Einstellungen für die autonome Optimierung anzuzeigen oder zu ändern, sind die Werte, die als Argumente für den --name-Parameter akzeptiert werden, die, die in der Spalte „Parameter“ der vorherigen Tabelle angezeigt werden, jedoch ohne das Präfix index_tuning..

Durch autonome Optimierung erzeugte Informationen

Verwenden Sie autonome Optimierungsempfehlungen , in denen ausführlich beschrieben wird, wie Sie die empfehlungen, die von autonomer Optimierung erzeugt werden, abrufen und verwenden.

Einschränkungen und Unterstützbarkeit

Nachfolgend sehen Sie die Liste der Einschränkungen und Unterstützungsmöglichkeiten für die autonome Optimierung.

Automatische Löschung von Empfehlungen

Empfehlungen werden 35 Tage nach der letzten Produktion automatisch gelöscht. Damit dieser automatische Löschmechanismus funktioniert, muss die autonome Optimierung aktiviert sein.

Abhängigkeit von der hypopg-Erweiterung

Für die autonome Optimierung zur Erstellung von CREATE INDEX-Empfehlungen verwendet sie die Hypopg-Erweiterung .

Wenn die Erweiterung bereits vorhanden ist, wenn eine Optimierungssitzung beginnt, wird sie für das Schema verwendet, in dem sie erstellt wurde. Und wenn die Optimierungssitzung abgeschlossen ist, wird die Erweiterung nicht gelöscht. Eine Ausnahme dieser Regel ist, wenn die Erweiterung im pg_catalog Schema erstellt wurde. Wenn dies der Fall ist, entfernt das automatische Tuning die Erweiterung.

Wenn die Erweiterung zunächst nicht vorhanden war oder wir sie gelöscht haben, weil sie im pg_catalog Schema erstellt wurde, erstellt die autonome Anpassung sie unter einem Schema namens ms_temp_recommendations709253. Wenn die Optimierungssitzung erfolgreich abgeschlossen ist, wird die Erweiterung entfernt und das Schema gelöscht.

Benutzer, die Mitglieder der azure_pg_admin Rolle sind, können die Hypopg-Erweiterung jederzeit ablegen, auch wenn sie von der autonomen Optimierungsfunktion erstellt wird. Das Abbrechen, während eine autonome Optimierungssitzung ausgeführt wird, kann jedoch dazu führen, dass diese Sitzung fehlschlägt und keine Empfehlungen liefert.

Unterstützte Computeebenen und SKUs

Die autonome Optimierung wird auf allen derzeit verfügbaren Ebenen unterstützt: Burstable, General Purpose und Memory Optimized, und auf allen derzeit unterstützten Compute-SKU mit mindestens 4 vCores.

Unterstützte Versionen von PostgreSQL

Die autonome Optimierung wird in den Hauptversionen12 oder höher von Azure Database für flexible Serverinstanzen von PostgreSQL unterstützt.

Verwendung von search_path

Die autonome Optimierung nutzt den in der Spalte search_path von query_store.qs_view gespeicherten Wert, sodass bei der Analyse jeder Abfrage derselbe Wert search_path verwendet wird, auf den sie beim ursprünglichen Ausführen festgelegt wurde, um mögliche Empfehlungen zu analysieren.

Parametrisierte Abfragen

Parametrisierte Abfragen, die mit PREPARE erstellt wurden oder das erweiterte Abfrageprotokoll verwenden, werden zerlegt und analysiert, um Indexempfehlungen auf ihnen zu erstellen.

Für die Analyse parametrisierter Abfragen erfordert die autonome Optimierung, dass pg_qs.parameters_capture_mode festgelegt ist, und dass capture_first_sample aktiv ist, wenn der Abfragespeicher die Ausführung der Abfrage erfasst. Außerdem müssen die Parameter beim Ausführen der Abfrage ordnungsgemäß vom Abfragespeicher erfasst werden. Anders gesagt, für die zu analysierende Abfrage query_store.qs_view muss die Spalte parameters_capture_status auf succeeded festgelegt sein.

Schreibgeschützter Modus und Lesereplikate

Da die autonome Optimierung auf den Daten basiert, die vom Abfragespeicher lokal in der azure_sys Datenbank gespeichert werden, was in Lesereplikaten nicht unterstützt wird oder wenn eine Instanz im schreibgeschützten Modus ist, wird sie nicht für Lesereplikate oder für Instanzen unterstützt, die sich im schreibgeschützten Modus befinden.

Alle Empfehlungen, die für ein Lesereplikat angezeigt werden, wurden im primären Replikat erstellt, nachdem sie ausschließlich die Workload analysiert haben, die für das primäre Replikat ausgeführt wurde.

Compute herunterskalieren

Wenn die autonome Optimierung auf einem Server aktiviert ist und Sie die Berechnung dieses Servers auf weniger als die Mindestanzahl der erforderlichen vCores verkleinern, bleibt das Feature aktiviert. Da das Feature auf Servern mit weniger als 4 vCores nicht unterstützt wird, wird es nicht ausgeführt, um die Workload zu analysieren und Empfehlungen zu erstellen, selbst wenn index_tuning.mode auf ON gesetzt wurde, als die Berechnung nach unten skaliert wurde. Während der Server nicht die Mindestanforderungen erfüllt, kann auf alle index_tuning.*-Serverparameter nicht zugegriffen werden. Immer wenn Sie den Server auf ein Compute skalieren, das die Mindestanforderungen erfüllt, wird er auf den zuvor festgelegten Wert konfiguriert index_tuning.mode, bevor Sie ihn auf ein Compute skalieren, das nicht den Anforderungen entspricht.

Hochverfügbarkeit und Lesereplikate

Falls Ihr Server mit Hochverfügbarkeit oder Lesereplikaten konfiguriert ist, beachten Sie die Auswirkungen, die mit der Erstellung schreibintensiver Workloads auf dem primären Server verbunden sind, wenn empfohlene Indizes implementiert werden. Seien Sie insbesondere vorsichtig, wenn Sie Indizes erstellen, die wahrscheinlich groß sind.

Gründe, warum die autonome Optimierung möglicherweise keine Empfehlungen zum Erstellen von Indizes für bestimmte Abfragen erzeugt

Es folgt eine Liste der Abfragetypen, für die autonome Optimierung keine CREATE INDEX-Empfehlungen generiert. Abfragen, die:

  • Tritt ein Fehler auf, wenn das autonome Tuningmodul versucht, die EXPLAIN-Ausgabe während der Analysephase abzurufen.
  • Referenzieren Sie Tabellen, die keine Statistiken über ihre Inhalte im pg_statistic Systemkatalog enthalten. Führen Sie "ANALYSIEREN" für diese Tabellen aus, damit das Optimierungsmodul diese Abfragen in Zukunft berücksichtigen kann.
  • Den Abfragetext im Abfragespeicher abgeschnitten lassen. Dies ist der Fall, wenn die Länge des Abfragetexts den in pg_qs.max_query_text_length konfigurierten Wert überschreitet.
  • Verweisen Sie auf Objekte, die vor dem Auftreten der Analyse verworfen oder umbenannt wurden. Diese Abfragen könnten weiterhin syntaktisch gültig, aber nicht semantisch gültig sein.
  • Greifen Sie auf temporäre Tabellen oder Indizes für temporäre Tabellen zu.
  • Zugreifen auf Ansichten oder materialisierte Ansichten.
  • Greifen Sie auf partitionierte Tabellen zu.
  • Werden als Hilfsprogrammanweisungen identifiziert. Hilfsanweisungen oder Hilfsbefehle sind im Grunde jede Anweisung, die nicht als SELECT, INSERT, UPDATE, DELETE oder MERGE gilt, und bestimmte Befehle, die einen dieser Befehle enthalten.
  • Gehören nicht zu den langsamsten index_tuning.max_queries_per_database für die Datenbank und den analysierten Zeitraum.
  • Wurden im Kontext einer bestimmten Datenbank ausgeführt, wenn keine dieser Abfragen als die langsamste auf Serverebene identifiziert wurde.

Verwandte Inhalte

  • Last updated on