Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Verwalten von Abfrageausführungsplänen für Aurora PostgreSQL
Die Abfrageplanverwaltung in Aurora PostgreSQL ist eine optionale Funktion, die Sie mit Ihrem DB-Cluster der mit Amazon Aurora PostgreSQL kompatiblen Edition verwenden können. Diese Funktion ist als `apg_plan_mgmt`-Erweiterung verpackt, die Sie in Ihrem DB-Cluster von Aurora PostgreSQL installieren können. Die Abfrageplanverwaltung ermöglicht Ihnen, die Abfrageausführungspläne zu verwalten, die vom Optimierer für Ihre SQL-Anwendungen generiert wurden. Die `apg_plan_mgmt` AWS Erweiterung baut auf der systemeigenen Abfrageverarbeitungsfunktionalität der PostgreSQL-Datenbank-Engine auf.
Im Folgenden finden Sie Informationen zu den Funktionen der Abfrageplanverwaltung in Aurora PostgreSQL sowie deren Einrichtung und Verwendung mit Ihrem DB-Cluster von Aurora PostgreSQL. Bevor Sie beginnen, sollten Sie alle Versionshinweise für die spezifische Version der `apg_plan_mgmt`-Erweiterung zu lesen, die für Ihre Aurora-PostgreSQL-Version verfügbar ist. Weitere Informationen finden Sie unter [Versionen der apg\$1plan\$1mgmt-Erweiterung von Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html#AuroraPostgreSQL.Extensions.apg_plan_mgmt) in den *Versionshinweisen für Aurora PostgreSQL*.
**Topics**
+ [Übersicht über die Abfrageplanverwaltung in Aurora PostgreSQL](AuroraPostgreSQL.Optimize.overview.md)
+ [Bewährte Methoden für die Aurora-PostgreSQL-Abfrageplanverwaltung](AuroraPostgreSQL.Optimize.BestPractice.md)
+ [Die Abfrageplanverwaltung in Aurora PostgreSQL](AuroraPostgreSQL.Optimize.Start.md)
+ [Erfassung von Aurora-PostgreSQL-Ausführungsplänen](AuroraPostgreSQL.Optimize.CapturePlans.md)
+ [Verwenden von Aurora-PostgreSQL-Plänen](AuroraPostgreSQL.Optimize.UsePlans.md)
+ [Untersuchen von Aurora-PostgreSQL-Abfrageplänen in der dba\$1plans-Ansicht](AuroraPostgreSQL.Optimize.ViewPlans.md)
+ [Verbessern von Aurora-PostgreSQL-Abfrageplänen](AuroraPostgreSQL.Optimize.Maintenance.md)
+ [Löschen von Aurora-PostgreSQL-Abfrageplänen](AuroraPostgreSQL.Optimize.Deleting.md)
+ [Exportieren und Importieren von verwalteten Plänen für Aurora PostgreSQL](AuroraPostgreSQL.Optimize.Maintenance.ExportingImporting.md)
+ [Parameterreferenz für Aurora-PostgreSQL-Abfrageplanverwaltung](AuroraPostgreSQL.Optimize.Parameters.md)
+ [Funktionsreferenz für die Aurora-PostgreSQL-Abfrageplanverwaltung](AuroraPostgreSQL.Optimize.Functions.md)
+ [Referenz für die apg\$1plan\$1mgmt.dba\$1plans-Ansicht für die Aurora-PostgreSQL-kompatible Edition](AuroraPostgreSQL.Optimize.dba_plans_view_Reference.md)
+ [Erweiterte Funktionen der Abfrageplanverwaltung](AuroraPostgreSQL.QPM.Advanced.md)
# Übersicht über die Abfrageplanverwaltung in Aurora PostgreSQL
Die Aurora-PostgreSQL-Abfrageplanverwaltung wurde entwickelt, um die Planstabilität unabhängig von Änderungen an der Datenbank zu gewährleisten, die eine Regression des Abfrageplans verursachen könnten. Eine *Regression des Abfrageplans* tritt auf, wenn der Optimierer nach System- oder Datenbankänderungen einen suboptimalen Plan für eine bestimmte SQL-Anweisung auswählt. Änderungen von Statistiken, Einschränkungen, Umgebungseinstellungen, Abfrageparameter-Bindungen und Upgrades der PostgreSQL-Datenbank-Engine können eine Planregression verursachen.
Mit der Abfrageplanverwaltung in Aurora PostgreSQL steuern Sie, wie und wann sich Abfrageausführungspläne ändern. Zu den Vorteilen der Abfrageplanverwaltung in Aurora PostgreSQL gehören die nachfolgend aufgeführten.
+ Verbesserung der Planstabilität, indem der Optimierer zur Auswahl aus einer kleinen Anzahl bekannter, bewährter Pläne gezwungen wird.
+ Zentrale Optimierung von Plänen, gefolgt von einer globalen Verteilung der besten Pläne.
+ Ermittlung von nicht verwendeten Indizes und Bewertung der Auswirkungen einer Indexerstellung oder -löschung.
+ Automatische Erkennung eines vom Optimierer ermittelten Minimalkostenplans.
+ Test neuer Optimierer-Funktionen mit geringerem Risiko, da Sie nur die Planänderungen genehmigen können, die zu Performance-Steigerungen führen.
Sie können die von der Abfrageplanverwaltung bereitgestellten Tools proaktiv verwenden, um den besten Plan für bestimmte Abfragen festzulegen. Sie können die Abfrageplanverwaltung auch verwenden, um auf sich ändernde Umstände zu reagieren und Planregressionen zu vermeiden. Weitere Informationen finden Sie unter [Bewährte Methoden für die Aurora-PostgreSQL-Abfrageplanverwaltung](AuroraPostgreSQL.Optimize.BestPractice.md).
**Topics**
+ [Unterstützte SQL-Anweisungen](#AuroraPostgreSQL.Optimize.overview.features)
+ [Einschränkungen der Abfrageplanverwaltung](#AuroraPostgreSQL.Optimize.overview.limitations)
+ [Terminologie der Abfrageplanverwaltung](#AuroraPostgreSQL.Optimize.Start-terminology)
+ [Die Abfrageplanverwaltung in Aurora-PostgreSQL-Versionen](#AuroraPostgreSQL.Optimize.overview.versions)
+ [Aktivieren der Abfrageplanverwaltung in Aurora PostgreSQL](#AuroraPostgreSQL.Optimize.Enable)
+ [Aktualisieren der Abfrageplanverwaltung in Aurora PostgreSQL](#AuroraPostgreSQL.Optimize.Upgrade)
+ [Deaktivieren der Abfrageplanverwaltung in Aurora PostgreSQL](#AuroraPostgreSQL.Optimize.Enable.turnoff)
## Unterstützte SQL-Anweisungen
Die Abfrageplanverwaltung unterstützt die folgenden Typen von SQL-Anweisungen.
+ SELECT-, INSERT-, UPDATE- oder DELETE-Anweisungen, unabhängig von ihrer Komplexität.
+ Vorbereitete Anweisungen. Weitere Informationen finden Sie unter [PREPARE](https://www.postgresql.org/docs/14/sql-prepare.html) in der PostgreSQL-Dokumentation.
+ Dynamische Anweisungen, einschließlich solcher, die im Sofortmodus ausgeführt werden. Weitere Informationen finden Sie unter [Dynamisches SQL](https://www.postgresql.org/docs/current/ecpg-dynamic.html) und [EXECUTE IMMEDIATE](https://www.postgresql.org/docs/current/ecpg-sql-execute-immediate.html) in der PostgreSQL-Dokumentation.
+ Eingebettete SQL-Befehle und -Anweisungen. Weitere Informationen finden Sie unter [Eingebettete SQL-Befehle](https://www.postgresql.org/docs/current/ecpg-sql-commands.html) in der PostgreSQL-Dokumentation.
+ Anweisungen innerhalb benannter Funktionen. Weitere Informationen finden Sie im Abschnitt [CREATE FUNCTION](https://www.postgresql.org/docs/current/sql-createfunction.html) der PostgreSQL-Dokumentation.
+ Anweisungen, die temporäre Tabellen enthalten.
+ Anweisungen innerhalb von Prozeduren und DO-Blöcken.
Sie können die Abfrageplanverwaltung mit `EXPLAIN` im manuellen Modus verwenden, um einen Plan zu erfassen, ohne ihn tatsächlich auszuführen. Weitere Informationen finden Sie unter [Analysieren des vom Optimierer ausgewählten Plans](AuroraPostgreSQL.Optimize.UsePlans.md#AuroraPostgreSQL.Optimize.UsePlans.AnalyzePlans). Weitere Informationen zu den Modi der Abfrageplanverwaltung (manuell, automatisch) finden Sie unter [Erfassung von Aurora-PostgreSQL-Ausführungsplänen](AuroraPostgreSQL.Optimize.CapturePlans.md).
Die Verwaltung von Aurora PostgreSQL-Abfrageplänen unterstützt alle Funktionen der PostgreSQL-Sprache, einschließlich partitionierter Tabellen, Vererbung, Sicherheit auf Zeilenebene und rekursive allgemeine Tabellenausdrücke (). CTEs Weitere Informationen zu diesen PostgreSQL-Sprachfunktionen finden Sie unter [Table Partitioning](https://www.postgresql.org/docs/current/ddl-partitioning.html) (Tabellenpartitionierung), [Row Security Policies](https://www.postgresql.org/docs/current/ddl-rowsecurity.html) (Zeilensicherheitsrichtlinien) und [WITH Queries (Common Table Expressions)](https://www.postgresql.org/docs/current/queries-with.html) (WITH-Abfragen (allgemeine Tabellenausdrücke)) und anderen Themen in der PostgreSQL-Dokumentation.
Informationen zu den verschiedenen Versionen der Abfrageplanverwaltung von Aurora PostgreSQL finden Sie unter [Versionen der apg\$1plan\$1mgmt-Erweiterung](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html#AuroraPostgreSQL.Extensions.apg_plan_mgmt) in den *Versionshinweisen für Aurora PostgreSQL*.
## Einschränkungen der Abfrageplanverwaltung
Die aktuelle Version der Abfrageplanverwaltung von Aurora PostgreSQL unterliegt folgenden Einschränkungen.
+ **Pläne werden nicht für Anweisungen erfasst, die auf Systembeziehungen verweisen** – Anweisungen, die auf Systembeziehungen verweisen, wie z. B. `pg_class`, werden nicht erfasst. Dies ist beabsichtigt, um zu verhindern, dass eine große Anzahl von systemgenerierten Plänen, die intern verwendet werden, erfasst werden. Dies gilt auch für Systemtabellen innerhalb von Ansichten.
+ **Für Ihren Aurora PostgreSQL-DB-Cluster ist möglicherweise eine größere DB-Instance-Klasse erforderlich** — Je nach Arbeitslast benötigt das Abfrageplanmanagement möglicherweise eine DB-Instance-Klasse mit mehr als 2 v. CPUs Die Anzahl von `max_worker_processes` ist durch die Größe der DB-Instance-Klasse begrenzt. Die Anzahl von `max_worker_processes`, die von einer 2-vCPU-DB-Instance-Klasse (z. B. db.t3.medium) bereitgestellt wird, ist möglicherweise für eine bestimmte Workload nicht ausreichend. Wir empfehlen Ihnen, eine DB-Instance-Klasse mit mehr als 2 v CPUs für Ihren Aurora PostgreSQL-DB-Cluster zu wählen, wenn Sie die Abfrageplanverwaltung verwenden.
Wenn die DB-Instance-Klasse Ihre Workload nicht unterstützen kann, gibt die Abfrageplanverwaltung eine Fehlermeldung wie die folgende aus.
```
WARNING: could not register plan insert background process
HINT: You may need to increase max_worker_processes.
```
In diesem Fall sollten Sie Ihren DB-Cluster von Aurora PostgreSQL auf eine DB-Instance-Klassengröße mit mehr Speicher hochskalieren. Weitere Informationen finden Sie unter [Unterstützte DB-Engines für DB-Instance-Klassen](Concepts.DBInstanceClass.SupportAurora.md).
+ **Pläne, die bereits in Sitzungen gespeichert sind, sind nicht betroffen**. – Die Abfrageplanverwaltung bietet eine Möglichkeit, Abfragepläne zu beeinflussen, ohne den Anwendungscode ändern zu müssen. Wenn jedoch ein generischer Plan bereits in einer vorhandenen Sitzung gespeichert ist und Sie den Abfrageplan ändern möchten, müssen Sie zunächst `plan_cache_mode` in der DB-Cluster-Parametergruppe auf `force_custom_plan` setzen.
+ `queryid` in `apg_plan_mgmt.dba_plans` und `pg_stat_statements` kann in folgenden Fällen abweichen:
+ Objekte werden nach dem Speichern in apg\$1plan\$1mgmt.dba\$1plans gelöscht und neu erstellt.
+ Die Tabelle `apg_plan_mgmt.plans` wird aus einem anderen Cluster importiert.
Informationen zu den verschiedenen Versionen der Abfrageplanverwaltung von Aurora PostgreSQL finden Sie unter [Versionen der apg\$1plan\$1mgmt-Erweiterung](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html#AuroraPostgreSQL.Extensions.apg_plan_mgmt) in den *Versionshinweisen für Aurora PostgreSQL*.
## Terminologie der Abfrageplanverwaltung
Die folgenden Begriffe werden in diesem Thema verwendet.
**verwaltete Anweisung**
Eine SQL-Anweisung, die vom Optimierer im Rahmen der Abfrageplanverwaltung erfasst wurde. Eine verwaltete Anweisung verfügt über einen oder mehrere Abfrageausführungspläne, die in der `apg_plan_mgmt.dba_plans`-Ansicht gespeichert sind.
**Plan-Baseline**
Die Menge der genehmigten Pläne für eine bestimmte verwaltete Anweisung. Das heißt, alle Pläne für die verwaltete Anweisung, für die in der `status`-Spalte der `dba_plan`-Ansicht „Approved“ angegeben ist.
**Planverlauf**
Die Menge der erfassten Pläne für eine bestimmte verwaltete Anweisung. Der Planverlauf enthält alle Pläne, die für die Anweisung erfasst wurden, unabhängig vom Status.
**Abfrageplanregression**
Tritt auf, wenn der Optimierer einen weniger optimalen Plan als vor einer bestimmten Änderung an der Datenbankumgebung auswählt, z. B. eine neue PostgreSQL-Version oder Änderungen an Statistiken.
## Die Abfrageplanverwaltung in Aurora-PostgreSQL-Versionen
Die Abfrageplanverwaltung wird von allen derzeit verfügbaren Aurora-PostgreSQL-Versionen unterstützt. Weitere Informationen finden Sie unter [Aktualisierungen von Amazon Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html) im Abschnitt *Versionshinweise für Aurora PostgreSQL*.
Die Funktion für die Abfrageplanverwaltung wird Ihrem DB-Cluster von Aurora PostgreSQL hinzugefügt, wenn Sie die `apg_plan_mgmt`-Erweiterung installieren. Verschiedene Versionen von Aurora PostgreSQL unterstützen unterschiedliche Versionen der `apg_plan_mgmt`-Erweiterung. Wir empfehlen Ihnen, die Erweiterung für die Abfrageplanverwaltung auf die neueste Version für Ihre Version von Aurora PostgreSQL zu aktualisieren.
**Anmerkung**
Versionshinweise für die Versionen jeder `apg_plan_mgmt`-Erweiterung finden Sie unter [Aurora PostgreSQL apg\$1plan\$1mgmt extension versions](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html#AuroraPostgreSQL.Extensions.apg_plan_mgmt) (Versionen der apg\$1plan\$1mgmgmt-Erweiterung von Aurora PostgreSQL) in den *Release Notes for Aurora PostgreSQL* (Versionshinweisen für Aurora PostgreSQL).
Sie können die in Ihrem Cluster ausgeführte Version identifizieren, indem Sie mit `psql` eine Verbindung mit einer Instance herstellen und den Metabefehl \$1dx verwenden, um Erweiterungen aufzulisten, wie nachfolgend gezeigt.
```
labdb=> \dx
List of installed extensions
Name | Version | Schema | Description
---------------+---------+---------------+-------------------------------------------------------------------
apg_plan_mgmt | 1.0 | apg_plan_mgmt | Amazon Aurora with PostgreSQL compatibility Query Plan Management
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
(2 rows)
```
Die Ausgabe zeigt, dass dieser Cluster die Version 1.0 der Erweiterung verwendet. Für eine bestimmte Aurora-PostgreSQL-Version sind nur bestimmte `apg_plan_mgmt`-Versionen verfügbar. In einigen Fällen müssen Sie möglicherweise den DB-Cluster von Aurora PostgreSQL auf eine neue Nebenversion aktualisieren oder einen Patch anwenden, damit Sie ein Upgrade auf die neueste Version der Abfrageplanverwaltung durchführen können. Die in der Ausgabe angezeigte `apg_plan_mgmt`-Version 1.0 stammt von einem DB-Cluster von Aurora-PostgreSQL-Version 10.17, für den keine neuere `apg_plan_mgmt`-Version verfügbar ist. In diesem Fall sollte der DB-Cluster von Aurora PostgreSQL auf eine neuere Version von PostgreSQL aktualisiert werden.
Weitere Informationen über die Aktualisierung Ihres DB-Clusters von Aurora PostgreSQL auf eine neue PostgreSQL-Version finden Sie unter [Aktualisierungen der Datenbank-Engine für Amazon Aurora PostgreSQL](AuroraPostgreSQL.Updates.md).
Informationen zum Upgrade der `apg_plan_mgmt`-Erweiterung finden Sie unter [Aktualisieren der Abfrageplanverwaltung in Aurora PostgreSQL](#AuroraPostgreSQL.Optimize.Upgrade).
## Aktivieren der Abfrageplanverwaltung in Aurora PostgreSQL
Das Einrichten der Abfrageplanverwaltung für Ihren DB-Cluster von Aurora PostgreSQL umfasst die Installation einer Erweiterung und das Ändern mehrerer DB-Cluster-Parametereinstellungen. Sie benötigen `rds_superuser`-Berechtigungen, um die `apg_plan_mgmt`-Erweiterung zu installieren und die Funktion für den DB-Cluster von Aurora PostgreSQL zu aktivieren.
Durch die Installation der Erweiterung wird eine neue Rolle, `apg_plan_mgmt`, erstellt. Diese Rolle ermöglicht Datenbankbenutzern, Abfragepläne anzuzeigen, zu verwalten und zu pflegen. Als Administrator mit `rds_superuser`-Berechtigungen müssen Sie die `apg_plan_mgmt`-Rolle Datenbankbenutzern nach Bedarf zuweisen.
Nur Benutzer mit der `rds_superuser`-Rolle können den folgenden Vorgang ausführen. `rds_superuser` ist erforderlich, um die Erweiterung `apg_plan_mgmt` und die zugehörige Rolle `apg_plan_mgmt` zu erstellen. Benutzer benötigen die Rolle `apg_plan_mgmt` zur Verwaltung der Erweiterung `apg_plan_mgmt`.
**So aktivieren Sie die Abfrageplanverwaltung für Ihren DB-Cluster von Aurora PostgreSQL**
Mit den folgenden Schritten wird die Abfrageplanverwaltung für alle SQL-Anweisungen aktiviert, die an den DB-Cluster von Aurora PostgreSQL übermittelt werden. Dies wird als *automatischer* Modus bezeichnet. Weitere Informationen zum Unterschied zwischen den Modi finden Sie unter [Erfassung von Aurora-PostgreSQL-Ausführungsplänen](AuroraPostgreSQL.Optimize.CapturePlans.md).
1. Öffnen Sie die Amazon RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Erstellen Sie eine benutzerdefinierte DB-Cluster-Parametergruppe für Ihren DB-Cluster von Aurora PostgreSQL. Sie müssen bestimmte Parameter ändern, um die Abfrageplanverwaltung zu aktivieren und ihr Verhalten festzulegen. Weitere Informationen finden Sie unter [Erstellen einer DB-Parametergruppe in Amazon Aurora](USER_WorkingWithParamGroups.Creating.md).
1. Öffnen Sie die benutzerdefinierte DB-Cluster-Parametergruppe und legen Sie den `rds.enable_plan_management`-Parameter auf `1` fest, wie in der folgenden Abbildung gezeigt.
![\[Bild der DB-Cluster-Parametergruppe\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-qpm-custom-db-cluster-param-change-1.png)
Weitere Informationen finden Sie unter [Ändern von Parametern in einer DB-Cluster-Parametergruppe in Amazon Aurora](USER_WorkingWithParamGroups.ModifyingCluster.md).
1. Erstellen Sie eine benutzerdefinierte DB-Parametergruppe, mit der Sie Abfrageplanparameter auf Instance-Ebene festlegen können. Weitere Informationen finden Sie unter [Eine DB-Cluster-Parametergruppe in Amazon Aurora erstellen](USER_WorkingWithParamGroups.CreatingCluster.md).
1. Ändern Sie die Writer-Instance des DB-Clusters von Aurora PostgreSQL, um die benutzerdefinierte DB-Parametergruppe zu verwenden. Weitere Informationen finden Sie unter [Ändern einer DB-Instance in einem DB-Cluster](Aurora.Modifying.md#Aurora.Modifying.Instance).
1. Ändern Sie den DB-Cluster von Aurora PostgreSQL, um die benutzerdefinierte DB-Parametergruppe zu verwenden. Weitere Informationen finden Sie unter [Ändern des DB-Clusters über die Konsole, die CLI und die API](Aurora.Modifying.md#Aurora.Modifying.Cluster).
1. Starten Sie Ihre DB-Instance neu, um die Einstellungen der benutzerdefinierten Parametergruppe zu aktivieren.
1. Stellen Sie eine Verbindung mit dem DB-Instance-Endpunkt Ihres DB-Clusters von Aurora PostgreSQL mit `psql` oder `pgAdmin` her. Im folgenden Beispiel wird das `postgres`-Standardkonto für die `rds_superuser`-Rolle verwendet.
```
psql --host=cluster-instance-1.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=my-db
```
1. Erstellen Sie die `apg_plan_mgmt`-Erweiterung für Ihre DB-Instance, wie nachfolgend gezeigt.
```
labdb=> CREATE EXTENSION apg_plan_mgmt;
CREATE EXTENSION
```
**Tipp**
Installieren Sie die `apg_plan_mgmt`-Erweiterung in der Vorlagendatenbank für Ihre Anwendung. Der Name der Standard-Vorlagendatenbank lautet `template1`. Weitere Informationen finden Sie unter [Template Databases](https://www.postgresql.org/docs/current/manage-ag-templatedbs.html) (Vorlagendatenbanken) in der PostgreSQL-Dokumentation.
1. Ändern Sie den Parameter `apg_plan_mgmt.capture_plan_baselines` in `automatic`. Diese Einstellung veranlasst den Optimierer, Pläne für jede SQL-Anweisung zu generieren, die entweder geplant oder mindestens zweimal ausgeführt wird.
**Anmerkung**
Die Abfrageplanverwaltung verfügt auch über einen *manuellen* Modus, den Sie für bestimmte SQL-Anweisungen verwenden können. Weitere Informationen hierzu finden Sie unter [Erfassung von Aurora-PostgreSQL-Ausführungsplänen](AuroraPostgreSQL.Optimize.CapturePlans.md).
1. Ändern Sie den Wert des `apg_plan_mgmt.use_plan_baselines`-Parameters in „on“. Dieser Parameter veranlasst den Optimierer, einen Plan für die Anweisung aus der Plan-Baseline auszuwählen. Weitere Informationen hierzu finden Sie unter [Verwenden von Aurora-PostgreSQL-Plänen](AuroraPostgreSQL.Optimize.UsePlans.md).
**Anmerkung**
Sie können den Wert eines dieser dynamischen Parameter für die Sitzung ändern, ohne die Instance neu starten zu müssen.
Wenn die Einrichtung der Abfrageplanverwaltung abgeschlossen ist, müssen Sie die `apg_plan_mgmt`-Rolle allen Datenbankbenutzern zuweisen, die Abfragepläne anzeigen, verwalten oder pflegen müssen.
## Aktualisieren der Abfrageplanverwaltung in Aurora PostgreSQL
Wir empfehlen Ihnen, die Erweiterung für die Abfrageplanverwaltung auf die neueste Version für Ihre Version von Aurora PostgreSQL zu aktualisieren.
1. Stellen Sie eine Verbindung mit der Writer-Instance Ihres DB-Clusters von Aurora PostgreSQL als Benutzer mit `rds_superuser`-Berechtigungen her. Wenn Sie beim Einrichten Ihrer Instance den Standardnamen beibehalten haben, stellen Sie eine Verbindung als `postgres` her. In diesem Beispiel wird die Verwendung von `psql` gezeigt, Sie können jedoch auch pgAdmin verwenden, wenn Sie möchten.
```
psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Führen Sie die folgende Abfrage aus, um die Erweiterung zu aktualisieren.
```
ALTER EXTENSION apg_plan_mgmt UPDATE TO '2.1';
```
1. Verwenden Sie die Funktion [apg\$1plan\$1mgmt.validate\$1plans](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.validate_plans), um die Hashes aller Pläne zu aktualisieren. Der Optimierer validiert alle genehmigten, nicht genehmigten und abgelehnten Pläne, um sicherzustellen, dass es sich weiterhin um durchführbare Pläne für die neue Version der Erweiterung handelt.
```
SELECT apg_plan_mgmt.validate_plans('update_plan_hash');
```
Weitere Informationen zu dieser Funktion finden Sie unter [Validieren von Plänen](AuroraPostgreSQL.Optimize.Deleting.md#AuroraPostgreSQL.Optimize.Maintenance.ValidatingPlans).
1. Verwenden Sie die Funktion [apg\$1plan\$1mgmt.reload](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.reload), um alle Pläne im gemeinsam genutzten Arbeitsspeicher mit den validierten Plänen aus der dba\$1plans-Ansicht zu aktualisieren.
```
SELECT apg_plan_mgmt.reload();
```
Weitere Informationen zu allen Funktionen, die für die Abfrageplanverwaltung verfügbar sind, finden Sie unter [Funktionsreferenz für die Aurora-PostgreSQL-Abfrageplanverwaltung](AuroraPostgreSQL.Optimize.Functions.md).
## Deaktivieren der Abfrageplanverwaltung in Aurora PostgreSQL
Sie können die Abfrageplanverwaltung jederzeit deaktivieren, indem Sie die `apg_plan_mgmt.use_plan_baselines` und `apg_plan_mgmt.capture_plan_baselines` deaktivieren.
```
labdb=> SET apg_plan_mgmt.use_plan_baselines = off;
labdb=> SET apg_plan_mgmt.capture_plan_baselines = off;
```
# Bewährte Methoden für die Aurora-PostgreSQL-Abfrageplanverwaltung
Mit der Abfrageplanverwaltung steuern Sie, wie und wann sich Abfrageverwaltungspläne ändern. Als DBA gehören zu Ihren Hauptzielen bei der Verwendung von QPM, Regressionen bei Änderungen an Ihrer Datenbank zu verhindern und zu kontrollieren, ob der Optimierer einen neuen Plan verwenden darf. Im Folgenden finden Sie einige empfohlene bewährte Methoden zur Verwendung der Abfrageplanverwaltung. Proaktive und reaktive Planverwaltungsansätze unterscheiden sich hinsichtlich der Frage, wie und wann neue Pläne zur Verwendung genehmigt werden.
**Contents**
+ [Proaktive Planverwaltung zur Vermeidung von Performancerückgängen](#AuroraPostgreSQL.Optimize.BestPractice.Proactive)
+ [Sicherstellen der Planstabilität nach einem größeren Versions-Upgrade](#AuroraPostgreSQL.Optimize.BestPractice.MajorVersionUpgrade)
+ [Reaktive Planverwaltung zur Erkennung und Behebung von Performancerückgängen](#AuroraPostgreSQL.Optimize.BestPractice.Reactive)
## Proaktive Planverwaltung zur Vermeidung von Performancerückgängen
Um Regressionen bei der Planleistung zu verhindern, *entwickeln* Sie den Basisplan weiter. Dazu führen Sie ein Verfahren aus, das die Leistung neu entdeckter Pläne mit der Leistung des vorhandenen Basisplans der genehmigten Pläne vergleicht und dann automatisch die schnellsten Pläne als neuen Basisplan genehmigt. Auf diese Weise verbessert sich die Ausgangsbasis der Pläne im Laufe der Zeit, da schnellere Pläne entdeckt werden.
1. Bestimmen Sie in einer Entwicklungsumgebung die SQL-Anweisungen, die die größten Auswirkungen auf die Performance oder den Durchsatz des Systems haben. Erfassen Sie dann die Pläne für diese Anweisungen anhand der unter [Manuelles Erfassen von Plänen für bestimmte SQL-Anweisungen](AuroraPostgreSQL.Optimize.CapturePlans.md#AuroraPostgreSQL.Optimize.CapturePlans.Manual) und [Automatisches Erfassen von Plänen](AuroraPostgreSQL.Optimize.CapturePlans.md#AuroraPostgreSQL.Optimize.CapturePlans.Automatic) beschriebenen Vorgehensweise.
1. Exportieren Sie die erfassten Pläne aus der Entwicklungsumgebung und importieren Sie sie in die Produktionsumgebung. Weitere Informationen finden Sie unter [Exportieren und Importieren von verwalteten Plänen für Aurora PostgreSQL](AuroraPostgreSQL.Optimize.Maintenance.ExportingImporting.md).
1. Führen Sie in der Produktion Ihre Anwendung aus und erzwingen Sie die Verwendung genehmigter verwalteter Pläne. Weitere Informationen finden Sie unter [Verwenden von Aurora-PostgreSQL-Plänen](AuroraPostgreSQL.Optimize.UsePlans.md). Fügen Sie bei laufender Anwendung auch neue Pläne hinzu, sobald diese vom Optimierer erkannt werden. Weitere Informationen finden Sie unter [Automatisches Erfassen von Plänen](AuroraPostgreSQL.Optimize.CapturePlans.md#AuroraPostgreSQL.Optimize.CapturePlans.Automatic).
1. Analysieren Sie die nicht genehmigten Pläne und genehmigen Sie jene, die ordnungsgemäß funktionieren. Weitere Informationen finden Sie unter [Auswerten der Performance von Plänen](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.EvaluatingPerformance).
1. Während Ihre Anwendung ausgeführt wird, verwendet der Optimierer die neuen Pläne bei Bedarf.
### Sicherstellen der Planstabilität nach einem größeren Versions-Upgrade
Jede Hauptversion von PostgreSQL enthält Verbesserungen und Änderungen am Abfrageoptimierer, die auf eine Leistungssteigerung ausgelegt sind. Pläne zur Abfrageausführung, die in früheren Versionen vom Optimierer generiert wurden, können jedoch in neueren, aktualisierten Versionen zu Leistungseinbußen führen. Sie können das Abfrageplan-Management verwenden, um diese Leistungsprobleme zu beheben und die Planstabilität nach einem größeren Versions-Upgrade sicherzustellen.
Der Optimierer verwendet immer den kostengünstigsten genehmigten Plan, auch wenn mehr als ein genehmigter Plan für die gleiche Anweisung vorhanden ist. Nach einem Upgrade ermittelt der Optimierer möglicherweise neue Pläne, diese werden jedoch als nicht genehmigte Pläne gespeichert. Diese Pläne werden nur ausgeführt, wenn sie im reaktiven Planverwaltungsstil mit dem Parameter unapproved\$1plan\$1execution\$1threshold genehmigt wurden. Sie können die Planstabilität maximieren, indem Sie den proaktiven Planverwaltungsstil mit dem Parameter evolve\$1plan\$1baselines verwenden. Dadurch werden die Leistung der neuen Pläne mit den alten Plänen verglichen und Pläne genehmigt oder abgelehnt, die mindestens 10 % schneller sind als der nächstbeste Plan.
Nach dem Upgrade können Sie die Funktion `evolve_plan_baselines` verwenden, um die Planleistung vor und nach dem Upgrade mit Ihren Abfrageparameter-Bindungen zu vergleichen. Die folgenden Schritte gehen davon aus, dass Sie genehmigte verwaltete Pläne in Ihrer Produktionsumgebung verwendet haben, wie in [Verwenden von Aurora-PostgreSQL-Plänen](AuroraPostgreSQL.Optimize.UsePlans.md) ausgeführt.
1. Führen Sie Ihre Anwendung vor dem Upgrade mit dem laufenden Abfrageplan-Manager aus. Fügen Sie bei laufender Anwendung neue Pläne hinzu, sobald diese vom Optimierer erkannt werden. Weitere Informationen finden Sie unter [Automatisches Erfassen von Plänen](AuroraPostgreSQL.Optimize.CapturePlans.md#AuroraPostgreSQL.Optimize.CapturePlans.Automatic).
1. Bewerten Sie die Leistung jedes Plans. Weitere Informationen finden Sie unter [Auswerten der Performance von Plänen](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.EvaluatingPerformance).
1. Analysieren Sie nach dem Upgrade Ihre genehmigten Pläne erneut mit der Funktion `evolve_plan_baselines`. Vergleichen Sie die Leistung vor und nach der Verwendung Ihrer Abfrageparameter-Bindungen. Wenn der neue Plan schnell ist, können Sie ihn zu Ihren genehmigten Plänen hinzufügen. Wenn er für dieselben Parameter-Bindungen schneller als ein anderer Plan ist, können Sie den langsameren Plan als „Rejected“ (Abgelehnt) markieren.
Weitere Informationen finden Sie unter [Genehmigen besserer Pläne](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.EvaluatingPerformance.Approving). Referenzinformationen zu dieser Funktion finden Sie unter [apg\$1plan\$1mgmt.evolve\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.evolve_plan_baselines).
Weitere Informationen finden Sie unter [Sicherstellen einer konsistenten Leistung nach größeren Versions-Upgrades mit der Abfrageplanverwaltung der PostgreSQL-kompatiblen Edition von Amazon Aurora](https://aws.amazon.com/blogs/database/ensuring-consistent-performance-after-major-version-upgrades-with-amazon-aurora-postgresql-query-plan-management/).
**Anmerkung**
Wenn Sie ein Upgrade der Hauptversion mithilfe der logischen Replikation oder mit AWS DMS durchführen, stellen Sie sicher, dass Sie das Schema `apg_plan_mgmt` replizieren, damit die vorhandenen Pläne auf die aktualisierte Instance kopiert werden. Weitere Informationen zur logischen Replikation finden Sie unter [Verwenden der logischen Replikation, um ein Hauptversions-Upgrade für Aurora PostgreSQL durchzuführen](AuroraPostgreSQL.MajorVersionUpgrade.md).
## Reaktive Planverwaltung zur Erkennung und Behebung von Performancerückgängen
Durch Überwachen Ihrer laufende Anwendung können Sie Pläne erkennen, die zu Performancerückgängen führen. Werden Rückgänge erkannt, können Sie die nicht funktionierenden Pläne manuell ablehnen oder reparieren. Führen Sie dazu die folgenden Schritte aus:
1. Erzwingen Sie bei laufender Anwendung die Verwendung verwalteter Pläne und fügen Sie automatisch neu entdeckte Pläne als nicht genehmigte Pläne hinzu. Weitere Informationen erhalten Sie unter [Verwenden von Aurora-PostgreSQL-Plänen](AuroraPostgreSQL.Optimize.UsePlans.md) und [Automatisches Erfassen von Plänen](AuroraPostgreSQL.Optimize.CapturePlans.md#AuroraPostgreSQL.Optimize.CapturePlans.Automatic).
1. Überwachen Sie die laufende Anwendung auf Performance-Regressionen.
1. Setzen Sie den Status des Plans auf , wenn Sie eine Planregression feststelle `rejected`. Wenn der Optimierer die SQL-Anweisung das nächste Mal ausführt, wird der abgelehnte Plan automatisch ignoriert und stattdessen ein anderer genehmigter Plan verwendet. Weitere Informationen finden Sie unter [Ablehnen oder Deaktivieren langsamerer Pläne](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.EvaluatingPerformance.Rejecting).
In einigen Fällen ist es möglicherweise sinnvoll, einen nicht funktionierenden Plan zu reparieren, anstatt ihn abzulehnen, zu deaktivieren oder zu löschen. Verwenden Sie die Erweiterung `pg_hint_plan`, um das Verbessern eines Plans zu testen. Mit `pg_hint_plan` nutzen Sie besondere Kommentare, um die üblicherweise vom Optimierer angewendete Planerstellungsmethode zu überschreiben. Weitere Informationen finden Sie unter [Reparieren von Plänen mit pg\$1hint\$1plan](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.pg_hint_plan).
# Die Abfrageplanverwaltung in Aurora PostgreSQL
Wenn die Abfrageplanverwaltung für Ihren DB-Cluster von Aurora PostgreSQL aktiviert ist, generiert und speichert der Optimierer Abfrageausführungspläne für jede SQL-Anweisung, die er mehr als einmal verarbeitet. Der Status des zuerst generierten Plans einer verwalteten Anweisung wird vom Optimierer immer auf `Approved` festgelegt und in der `dba_plans`-Ansicht gespeichert.
Der Satz an genehmigten Plänen, der für eine verwaltete Anweisung gespeichert wird, wird als *Plan-Baseline* bezeichnet. Während der Ausführung Ihrer Anwendung generiert der Optimierer möglicherweise zusätzliche Pläne für verwaltete Anweisungen. Der Status zusätzlich erfasster Pläne wird vom Optimierer auf `Unapproved` festgelegt.
Später können Sie entscheiden, ob die `Unapproved`-Pläne ordnungsgemäß funktionieren und ihren Status bei Bedarf in `Approved`, `Rejected` oder `Preferred` ändern. Dazu verwenden Sie die Funktion `apg_plan_mgmt.evolve_plan_baselines` oder `apg_plan_mgmt.set_plan_status`.
Wenn der Optimierer einen Plan für eine SQL-Anweisung generiert, speichert die Abfrageplanverwaltung den Plan in der `apg_plan_mgmt.plans`-Tabelle. Datenbankbenutzer, denen die `apg_plan_mgmt`-Rolle zugewiesen wurde, können die Plandetails anzeigen, indem sie die `apg_plan_mgmt.dba_plans`-Ansicht abfragen. Die folgende Abfrage listet beispielsweise Details zu Plänen auf, die sich derzeit in der Ansicht für einen DB-Cluster von Aurora PostgreSQL außerhalb der Produktion befinden.
+ `sql_hash`: Ein Bezeichner für die SQL-Anweisung, der der Hashwert für den normalisierten Text der SQL-Anweisung ist.
+ `plan_hash`: Ein eindeutiger Bezeichner für den Plan, der eine Kombination aus dem `sql_hash` und einem Hash des Plans ist.
+ `status`: der Status des Plans Der Optimierer kann einen genehmigten Plan ausführen.
+ `enabled`: Gibt an, ob der Plan einsatzbereit ist (true) oder nicht (false).
+ `plan_outline`: Eine Darstellung des Plans, mit der der tatsächliche Ausführungsplan neu erstellt wird. Operatoren in der Baumstruktur werden Operatoren in der EXPLAIN-Ausgabe zugeordnet.
Die `apg_plan_mgmt.dba_plans`-Ansicht hat viele weitere Spalten, die alle Details des Plans enthalten, z. B. wann der Plan zuletzt verwendet wurde. Vollständige Details finden Sie unter [Referenz für die apg\$1plan\$1mgmt.dba\$1plans-Ansicht für die Aurora-PostgreSQL-kompatible Edition](AuroraPostgreSQL.Optimize.dba_plans_view_Reference.md).
## Normalisierung und der SQL-Hash
In der `apg_plan_mgmt.dba_plans`-Ansicht können Sie eine verwaltete Anweisung anhand ihres SQL-Hash-Werts erkennen. Der SQL-Hash wird auf Basis einer normalisierten Darstellung der SQL-Anweisung berechnet, bei der einige Unterschiede (z. B. Literalwerte) nicht berücksichtigt sind.
Beim *Normalisierungsprozess* für jede SQL-Anweisung werden Leerzeichen und Groß- und Kleinschreibung beibehalten, sodass Sie das Wesentliche der SQL-Anweisung weiterhin lesen und verstehen können. Durch die Normalisierung werden die folgenden Elemente entfernt oder ersetzt.
+ Führende Blockkommentare
+ Das Schlüsselwort EXPLAIN und EXPLAIN-Optionen sowie EXPLAIN ANALYZE
+ Leerzeichen am Zeilenende
+ Alle Literale
Sehen Sie sich die folgende Anweisung als Beispiel an.
```
/*Leading comment*/ EXPLAIN SELECT /* Query 1 */ * FROM t WHERE x > 7 AND y = 1;
```
Die Abfrageplanverwaltung normalisiert diese Anweisung wie im Folgenden gezeigt:
```
SELECT /* Query 1 */ * FROM t WHERE x > CONST AND y = CONST;
```
Durch die Normalisierung kann derselbe SQL-Hash für ähnliche SQL-Anweisungen verwendet werden, die sich ggf. ausschließlich in ihren Literal- oder Parameterwerten unterscheiden. Mit anderen Worten, es können mehrere Pläne für denselben SQL-Hash existieren, wobei ein anderer Plan unter anderen Bedingungen optimal ist.
**Anmerkung**
Eine einzelne SQL-Anweisung, die mit verschiedenen Schemas verwendet wird, hat unterschiedliche Pläne, da sie an das spezifische Schema zur Laufzeit gebunden ist. Der Planer verwendet die Statistiken für die Schemabindung, um den optimalen Plan auszuwählen.
Weitere Informationen dazu, wie der Optimierer den Plan auswählt, finden Sie unter [Verwenden von Aurora-PostgreSQL-Plänen](AuroraPostgreSQL.Optimize.UsePlans.md). In diesem Abschnitt erfahren Sie, wie Sie einen Plan mit `EXPLAIN` und `EXPLAIN ANALYZE` in der Vorschau anzeigen, bevor er tatsächlich verwendet wird. Details hierzu finden Sie unter [Analysieren des vom Optimierer ausgewählten Plans](AuroraPostgreSQL.Optimize.UsePlans.md#AuroraPostgreSQL.Optimize.UsePlans.AnalyzePlans). Ein Abbildung, die den Prozess zur Auswahl eines Plans beschreibt, finden Sie unter [Erfahren Sie, wie der Optimierer bestimmt, welche Pläne ausgeführt werden.](AuroraPostgreSQL.Optimize.UsePlans.md#AuroraPostgreSQL.Optimize.UsePlans.ChoosePlans).
# Erfassung von Aurora-PostgreSQL-Ausführungsplänen
Die Aurora-PostgreSQL-Abfrageplanverwaltung bietet zwei verschiedene Modi zum Erfassen von Abfrageausführungsplänen: automatisch oder manuell. Sie wählen den Modus aus, indem Sie den Wert `apg_plan_mgmt.capture_plans_baselines` auf `automatic` oder `manual` festlegen. Sie können Ausführungspläne für bestimmte SQL-Anweisungen mit der manuellen Planerfassung erfassen. Alternativ können Sie mit der automatischen Planerfassung alle (oder nur die langsamsten) Pläne erfassen, die bei laufender Anwendung mindestens zwei Mal ausgeführt werden.
Bei der Planerfassung wird der Status des zuerst erfassten Plans einer verwalteten Anweisung vom Optimierer auf gesetz `approved`. Der Status zusätzlich hinzugefügter Pläne, die für eine verwaltete Anweisung erfasst wurden, wird vom Optimierer auf festgeleg `unapproved`. Gelegentlich wird jedoch mehr als ein Plan möglicherweise mit dem Status `approved` gespeichert. Dies kann passieren, wenn für eine Anweisung mehrere Pläne gleichzeitig erstellt werden und der erste Plan für die Anweisung noch nicht übermittelt wurde.
Legen Sie den Parameter `dba_plans` in der Parametergruppe der DB-Instance-Ebene fest, um die maximale Anzahl an Plänen zu bestimmen, die in der `apg_plan_mgmt.max_plans`-Ansicht erfasst und gespeichert werden können. Damit der Parameter `apg_plan_mgmt.max_plans` geändert werden und ein neuer Wert übernommen werden kann, muss die DB-Instance neu gestartet werden. Informieren Sie sich über den Parameter [apg\$1plan\$1mgmt.max\$1plans](AuroraPostgreSQL.Optimize.Parameters.md#AuroraPostgreSQL.Optimize.Parameters.max_plans), um weitere Informationen hierzu zu erhalten.
## Manuelles Erfassen von Plänen für bestimmte SQL-Anweisungen
Wenn Sie einen bekannten Satz an SQL-Anweisungen verwalten, verschieben Sie die Anweisungen in eine SQL-Skriptdatei und erfassen Sie anschließend Pläne manuell. Im folgenden psql-Beispiel wird gezeigt, wie Abfragepläne für einen Satz an SQL-Anweisungen manuell erfasst werden.
```
psql> SET apg_plan_mgmt.capture_plan_baselines = manual;
psql> \i my-statements.sql
psql> SET apg_plan_mgmt.capture_plan_baselines = off;
```
Nachdem für jede SQL-Anweisung ein Plan erfasst wurde, fügt der Optimierer der `apg_plan_mgmt.dba_plans`-Ansicht eine neue Zeile hinzu.
Wir empfehlen, dass Sie in der SQL-Skriptdatei entweder EXPLAN- oder EXPLAIN EXECUTE-Anweisungen verwenden. Stellen Sie sicher, dass eine ausreichende Auswahl an Parameterwerten einzukalkulieren, damit alle relevanten Pläne erfasst werden.
Falls Sie einen besseren Plan als den Minimalkostenplan des Optimierers nutzen möchten, können Sie den Optimierer zur Verwendung dieses bevorzugten Plans zwingen, indem Sie einen oder mehrere Optimierungshinweise angeben. Geben Sie hierzu mindestens einen Optimierungshinweis an. Weitere Informationen finden Sie unter [Reparieren von Plänen mit pg\$1hint\$1plan](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.pg_hint_plan). Unter `unapproved` erfahren Sie, wie Sie die Performance der `approved`- und [Auswerten der Performance von Plänen](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.EvaluatingPerformance)-Pläne vergleichen und diese genehmigen, ablehnen oder löschen.
## Automatisches Erfassen von Plänen
Verwenden Sie die automatische Planerfassung u. a. in den folgenden Fällen:
+ Sie wissen nicht, welche spezifischen SQL-Anweisungen Sie verwalten möchten.
+ Sie müssen hunderte oder tausende von SQL-Anweisungen verwalten.
+ Ihre Anwendung verwendet eine Client-API. Beispielsweise verwendet JDBC unbenannte vorbereitete Anweisungen oder Anweisungen in großen Mengen, die in psql nicht wiedergegeben werden können.
**So erfassen Sie Pläne automatisch:**
1. Aktivieren Sie die automatische Planerfassung, indem Sie in der Parametergruppe der DB-Instance-Ebene `apg_plan_mgmt.capture_plan_baselines` auf `automatic` setzen. Weitere Informationen finden Sie unter [Ändern von Parametern in einer DB-Parametergruppe in Amazon Aurora](USER_WorkingWithParamGroups.Modifying.md).
1. Während der Ausführung der Anwendung erfasst der Optimierer Pläne für alle SQL-Anweisungen, die mindestens zwei Mal ausgeführt werden.
Wenn die Anwendung mit den standardmäßigen Parametereinstellungen für die Abfrageplanverwaltung ausgeführt wird, erfasst der Optimierer Pläne für alle SQL-Anweisungen, die mindestens zwei Mal ausgeführt werden. Das Erfassen aller Pläne mit den Standardeinstellungen ist mit einem sehr geringen Laufzeitaufwand verbunden und kann in der Produktivumgebung erfolgen.
**So deaktivieren Sie die automatische Planerfassung:**
+ Setzen Sie in der Parametergruppe der DB-Instance-Ebene den Parameter `apg_plan_mgmt.capture_plan_baselines` auf `off`.
Erfahren Sie unter , wie Sie die Performance der nicht genehmigten Pläne messen und diese Pläne genehmigen, ablehnen oder lösche [Auswerten der Performance von Plänen](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.EvaluatingPerformance).
# Verwenden von Aurora-PostgreSQL-Plänen
Setzen Sie den Parameter `apg_plan_mgmt.use_plan_baselines` auf `true`, damit der Optimierer erfasste Pläne für Ihre verwalteten Anweisungen verwendet. Im Folgenden wird ein Beispiel mit einer lokalen Instance gezeigt:
```
SET apg_plan_mgmt.use_plan_baselines = true;
```
Diese Einstellung führt bei laufender Anwendung dazu, dass der Optimierer für jede verwaltete Anweisung jenen kostengünstigsten, bevorzugten oder genehmigten Plan verwendet, der gültig und aktiviert ist.
## Analysieren des vom Optimierer ausgewählten Plans
Wenn der Parameter `apg_plan_mgmt.use_plan_baselines` auf `true` gesetzt ist, können Sie mit SQL-Anweisungen vom Typ EXPLAIN ANALYZE erfahren, welchen Plan der Optimierer zum Ausführen der Anweisung auswählen würde. Im Folgenden wird ein -Beispiel gezeigt.
```
EXPLAIN ANALYZE EXECUTE rangeQuery (1,10000);
```
```
QUERY PLAN
--------------------------------------------------------------------------
Aggregate (cost=393.29..393.30 rows=1 width=8) (actual time=7.251..7.251 rows=1 loops=1)
-> Index Only Scan using t1_pkey on t1 t (cost=0.29..368.29 rows=10000 width=0) (actual time=0.061..4.859 rows=10000 loops=1)
Index Cond: ((id >= 1) AND (id <= 10000))
Heap Fetches: 10000
Planning time: 1.408 ms
Execution time: 7.291 ms
Note: An Approved plan was used instead of the minimum cost plan.
SQL Hash: 1984047223, Plan Hash: 512153379
```
Die Ausgabe zeigt den genehmigten Plan aus der Baseline, der ausgeführt werden würde. Die Ausgabe zeigt jedoch auch, dass ein kostengünstigerer Plan gefunden wurde. In diesem Fall erfassen Sie diesen neuen Minimalkostenplan, indem Sie die unter beschriebene automatische Planerfassung aktiviere [Automatisches Erfassen von Plänen](AuroraPostgreSQL.Optimize.CapturePlans.md#AuroraPostgreSQL.Optimize.CapturePlans.Automatic).
Neue Pläne werden vom Optimierer immer als `Unapproved` erfasst. Mit der Funktion `apg_plan_mgmt.evolve_plan_baselines` vergleichen Sie Pläne und können deren Status zu „Genehmigt“, „Abgelehnt“ oder „Deaktiviert“ ändern. Weitere Informationen finden Sie unter [Auswerten der Performance von Plänen](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.EvaluatingPerformance).
## Erfahren Sie, wie der Optimierer bestimmt, welche Pläne ausgeführt werden.
Die Kosten für einen Ausführungsplan stellen eine Schätzung dar, die der Optimierer zum Vergleichen verschiedener Pläne durchführt. Bei der Berechnung der Kosten eines Plans berücksichtigt der Optimierer Faktoren wie die CPU und die für diesen Plan erforderlichen I/O Operationen. Um mehr über Kostenschätzungen des PostgreSQL-Abfrageplaners zu erfahren, lesen Sie bitte [Query Planning (Abfrageplanung)](https://www.postgresql.org/docs/current/runtime-config-query.html) in der PostgreSQL-Dokumentation.
Die folgende Abbildung zeigt, wie ein Plan für eine bestimmte SQL-Anweisung ausgewählt wird, wenn die Abfrageplanverwaltung aktiv und nicht aktiv ist.
![\[Abfrageplanverwaltung-Workflow in Aurora PostgreSQL\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-query-plan-mgmt_processing-flow.png)
Der Ablauf ist wie folgt:
1. Der Optimierer erstellt einen Minimalkostenplan für die SQL-Anweisung.
1. Wenn die Abfrageplanverwaltung nicht aktiv ist, wird der Plan des Optimierers sofort ausgeführt (A. Optimizer-Plan ausführen). Die Abfrageplanverwaltung ist inaktiv, wenn die `apg_plan_mgmt.capture_plan_baselines` und `apg_plan_mgmt.use_plan_baselines`-Parameter beide ihre Standardeinstellungen haben („off“ bzw. „false“).
Andernfalls ist die Abfrageplanverwaltung aktiv. In diesem Fall werden die SQL-Anweisung und der Plan des Optimierers dafür weiter bewertet, bevor ein Plan ausgewählt wird.
**Tipp**
Datenbankbenutzer mit der `apg_plan_mgmt`-Rolle können proaktiv Pläne vergleichen, den Status von Plänen ändern und die Verwendung bestimmter Pläne nach Bedarf erzwingen. Weitere Informationen finden Sie unter [Verbessern von Aurora-PostgreSQL-Abfrageplänen](AuroraPostgreSQL.Optimize.Maintenance.md).
1. Die SQL-Anweisung enthält möglicherweise bereits Pläne, die in der Vergangenheit von der Abfrageplanverwaltung gespeichert wurden. Pläne werden in der `apg_plan_mgmt.dba_plans` aufbewahrt, zusammen mit Informationen über die SQL-Anweisungen, mit denen sie erstellt wurden. Informationen zu einem Plan beinhalten seinen Status. Der Status eines Plans kann wie folgt bestimmen, ob er verwendet wird oder nicht.
1. Wenn der Plan nicht zu den gespeicherten Plänen für die SQL-Anweisung gehört, bedeutet dies, dass dieser spezielle Plan zum ersten Mal vom Optimierer für die angegebene SQL-Anweisung generiert wurde. Der Plan wird an die Erfassungsplanverarbeitung gesendet (4).
1. Wenn der Plan zu den gespeicherten Plänen gehört und sein Status Genehmigt oder Bevorzugt ist, wird der Plan ausgeführt (A. Optimizer-Plan ausführen).
Wenn der Plan zu den gespeicherten Plänen gehört, aber weder Genehmigt noch Bevorzugt ist, wird der Plan an die Erfassungsplanverarbeitung gesendet (4).
1. Wenn ein Plan zum ersten Mal für eine bestimmte SQL-Anweisung erfasst wird, wird der Status des Plans immer auf Genehmigt (P1) festgelegt. Wenn der Optimierer anschließend denselben Plan für dieselbe SQL-Anweisung generiert, wird der Status dieses Plans in Nicht genehmigt (P1\$1n) geändert.
Nachdem der Plan erfasst und sein Status aktualisiert wurde, wird die Bewertung im nächsten Schritt fortgesetzt (5).
1. Die *Baseline* eines Plans besteht aus der Historie der SQL-Anweisung und ihrer Pläne in verschiedenen Stadien. Die Abfrageplanverwaltung kann den Basisplan bei der Auswahl eines Plans berücksichtigen, je nachdem, ob die Option Plan-Baselines verwenden aktiviert ist oder nicht, wie folgt.
+ Plan-Baselines ist „Aus“ verwenden, wenn der `apg_plan_mgmt.use_plan_baselines`-Parameter auf den Standardwert (`false`) festgelegt ist. Der Plan wird nicht mit der Baseline verglichen, bevor er ausgeführt wird (A. Optimizer-Plan ausführen).
+ Plan-Baselines ist „Ein“ verwenden, wenn der `apg_plan_mgmt.use_plan_baselines`-Parameter auf den Standardwert (`true`) festgelegt ist. Der Plan wird anhand der Basislinie weiter bewertet (6).
1. Der Plan wird mit anderen Plänen für den Kontoauszug in der Basislinie verglichen.
1. Wenn der Plan des Optimierers zu den Plänen in der Baseline gehört, wird sein Status überprüft (7a).
1. Befindet sich der Plan des Optimierers nicht unter den Plänen in der Baseline, wird der Plan als neuer `Unapproved`-Plan zu den Plänen für die Anweisung hinzugefügt.
1. Der Status des Plans wird überprüft, um nur festzustellen, ob er nicht genehmigt ist.
1. Wenn der Status des Plans Nicht genehmigt lautet, werden die geschätzten Kosten des Plans mit der Kostenschätzung verglichen, die für den Schwellenwert für den nicht genehmigten Ausführungsplan angegeben wurde.
+ Wenn die geschätzten Kosten des Plans unter dem Schwellenwert liegen, verwendet der Optimierer ihn, obwohl es sich um einen nicht genehmigten Plan handelt (A. Optimizer-Plan ausführen). Im Allgemeinen führt der Optimierer keinen nicht genehmigten Plan aus. Wenn der `apg_plan_mgmt.unapproved_plan_execution_threshold`-Parameter jedoch einen Kostenschwellenwert angibt, vergleicht der Optimierer die Kosten des nicht genehmigten Plans mit dem Schwellenwert. Falls die geschätzten Kosten niedriger als der Schwellenwert sind, führt der Optimierer den Plan aus. Weitere Informationen finden Sie unter [apg\$1plan\$1mgmt.unapproved\$1plan\$1execution\$1threshold](AuroraPostgreSQL.Optimize.Parameters.md#AuroraPostgreSQL.Optimize.Parameters.unapproved_plan_execution_threshold).
+ Wenn die geschätzten Kosten des Plans nicht unter dem Schwellenwert liegen, werden die anderen Attribute des Plans überprüft (8a).
1. Wenn der Status des Plans etwas anderes als Nicht genehmigt ist, werden seine anderen Attribute überprüft (8a).
1. Der Optimierer wird keinen Plan verwenden, der deaktiviert ist. Das heißt, der Plan, dessen `enable`-Attribut auf ‚f‘ (false) festgelegt ist. Der Optimierer verwendet auch keinen Plan mit dem Status Abgelehnt.
Der Optimierer kann keine Pläne verwenden, die nicht gültig sind. Pläne können mit der Zeit ungültig werden, wenn die Objekte, von denen sie abhängen, wie Indizes und Tabellenpartitionen, entfernt oder gelöscht werden.
1. Falls die Anweisung über aktivierte und gültige bevorzugte Pläne verfügt, wählt der Optimierer den kostengünstigsten Plan aus den für diese SQL-Anweisung gespeicherten bevorzugten Plan aus. Der Optimierer führt dann den kostengünstigsten bevorzugten Plan aus.
1. Wenn die Abrechnung keine aktivierten und gültigen Preferred-Pläne enthält, wird sie im nächsten Schritt bewertet (9).
1. Falls die Anweisung über aktivierte und gültige Genehmigte Pläne verfügt, wählt der Optimierer den kostengünstigsten Plan aus den für diese SQL-Anweisung gespeicherten Genehmigten Plan aus. Der Optimierer führt dann den kostengünstigsten genehmigten Plan aus.
Wenn die Abrechnung keine gültigen und aktivierten Genehmigten Pläne enthält, verwendet der Optimierer den Mindestkostenplan (A. Optimierer-Plan ausführen).
# Untersuchen von Aurora-PostgreSQL-Abfrageplänen in der dba\$1plans-Ansicht
Datenbankbenutzer und Administratoren, denen die `apg_plan_mgmt`-Rolle zugewiesen wurde, können die in `apg_plan_mgmt.dba_plans` gespeicherten Pläne anzeigen und verwalten. Der Administrator eines DB-Clusters von Aurora PostgreSQL (ein Benutzer mit `rds_superuser`-Berechtigungen) muss diese Rolle explizit den Datenbankbenutzern zuweisen, die mit der Abfrageplanverwaltung arbeiten müssen.
Die `apg_plan_mgmt`-Ansicht enthält den Planverlauf für alle verwalteten SQL-Anweisungen für jede Datenbank auf der Writer-Instance des DB-Clusters von Aurora PostgreSQL. In dieser Ansicht können Sie Pläne, ihren Status, wann sie zuletzt verwendet wurden und alle anderen relevanten Details untersuchen.
Wie in [Normalisierung und der SQL-Hash](AuroraPostgreSQL.Optimize.Start.md#AuroraPostgreSQL.Optimize.Start.hash-and-normalization) erörtert, wird jeder verwaltete Plan anhand der Kombination aus einem SQL- und einem Plan-Hash-Wert identifiziert. Mit diesen IDs können Sie Tools wie Amazon RDS-Performance-Insights nutzen, um die Performance einzelner Pläne nachzuverfolgen. Weitere Informationen über Performance-Insights finden Sie unter [Verwenden von Amazon RDS-Performance-Insights]( https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html).
## Auflisten von verwalteten Plänen.
Mit der SELECT-Anweisung in der Ansicht `apg_plan_mgmt.dba_plans` listen Sie die verwalteten Pläne auf. Im folgenden Beispiel werden einige Spalten in der `dba_plans`-Ansicht aufgeführt, so z. B. die Spalte `status`, in der Sie sehen können, ob ein Plan genehmigt oder nicht genehmigt wurde.
```
SELECT sql_hash, plan_hash, status, enabled, stmt_name
FROM apg_plan_mgmt.dba_plans;
sql_hash | plan_hash | status | enabled | stmt_name
------------+-----------+------------+---------+------------
1984047223 | 512153379 | Approved | t | rangequery
1984047223 | 512284451 | Unapproved | t | rangequery
(2 rows)
```
Zur besseren Lesbarkeit listen die Abfrage und die angezeigte Ausgabe nur einige Spalten aus der `dba_plans`-Ansicht auf. Ausführliche Informationen finden Sie unter [Referenz für die apg\$1plan\$1mgmt.dba\$1plans-Ansicht für die Aurora-PostgreSQL-kompatible Edition](AuroraPostgreSQL.Optimize.dba_plans_view_Reference.md).
# Verbessern von Aurora-PostgreSQL-Abfrageplänen
Verbessern Sie die Verwaltung von Abfrageplänen, indem Sie die Leistung des Plans bewerten und Pläne korrigieren. Weitere Informationen zum Verbessern Ihrer Abfragepläne finden Sie in den folgenden Themen.
**Topics**
+ [Auswerten der Performance von Plänen](#AuroraPostgreSQL.Optimize.Maintenance.EvaluatingPerformance)
+ [Reparieren von Plänen mit pg\$1hint\$1plan](#AuroraPostgreSQL.Optimize.Maintenance.pg_hint_plan)
## Auswerten der Performance von Plänen
Nachdem der Optimierer Pläne als „Nicht genehmigt“ erfasst hat, können Sie mit der Funktion `apg_plan_mgmt.evolve_plan_baselines` Pläne hinsichtlich ihrer tatsächlichen Performance miteinander vergleichen. Je nach Ergebnis dieses Performance-Vergleichs können Sie den Status eines Plans von „Nicht genehmigt“ zu „Genehmigt“ oder „Abgelehnt“ ändern. Alternativ besteht die Möglichkeit, mit der Funktion `apg_plan_mgmt.evolve_plan_baselines` einen Plan auf bestimmte Zeit zu deaktivieren, falls er Ihre Anforderungen nicht erfüllt.
### Genehmigen besserer Pläne
Im folgenden Beispiel wird beschrieben, wie der Status verwalteter Pläne mit der Funktion `apg_plan_mgmt.evolve_plan_baselines` auf „Genehmigt“ geändert werden kann.
```
SELECT apg_plan_mgmt.evolve_plan_baselines (
sql_hash,
plan_hash,
min_speedup_factor := 1.0,
action := 'approve'
)
FROM apg_plan_mgmt.dba_plans WHERE status = 'Unapproved';
```
```
NOTICE: rangequery (1,10000)
NOTICE: Baseline [ Planning time 0.761 ms, Execution time 13.261 ms]
NOTICE: Baseline+1 [ Planning time 0.204 ms, Execution time 8.956 ms]
NOTICE: Total time benefit: 4.862 ms, Execution time benefit: 4.305 ms
NOTICE: Unapproved -> Approved
evolve_plan_baselines
-----------------------
0
(1 row)
```
In der Ausgabe wird ein Performance-Bericht für die`rangequery`-Anweisung mit Parameterbindungen von 1 und 10 000 angezeigt. Der neue nicht genehmigte Plan (`Baseline+1`) ist besser als der beste zuvor genehmigte Plan (`Baseline`). Rufen Sie die `Approved`-Ansicht auf, um zu sehen, ob der neue Plan nun den Status „`apg_plan_mgmt.dba_plans`“ aufweist.
```
SELECT sql_hash, plan_hash, status, enabled, stmt_name
FROM apg_plan_mgmt.dba_plans;
```
```
sql_hash | plan_hash | status | enabled | stmt_name
------------+-----------+----------+---------+------------
1984047223 | 512153379 | Approved | t | rangequery
1984047223 | 512284451 | Approved | t | rangequery
(2 rows)
```
Der verwaltete Plan enthält jetzt zwei genehmigte Pläne, die zusammen die Plan-Baseline der Anweisung bilden. Sie können auch die Funktion „`apg_plan_mgmt.set_plan_status`“ aufrufen, um das Statusfeld eines Plans direkt auf `'Approved'`, `'Rejected'`, `'Unapproved'` oder `'Preferred'` festzulegen.
### Ablehnen oder Deaktivieren langsamerer Pläne
Leiten Sie `'reject'` oder `'disable' ` als Aktionsparameter an die Funktion `apg_plan_mgmt.evolve_plan_baselines` weiter, um Pläne abzulehnen oder zu deaktivieren. In diesem Beispiel wird jeder erfasste Plan mit dem Status „`Unapproved`“ deaktiviert, der um mindestens 10 Prozent langsamer als der beste Plan mit dem Status „`Approved`“ der Anweisung ist.
```
SELECT apg_plan_mgmt.evolve_plan_baselines(
sql_hash, -- The managed statement ID
plan_hash, -- The plan ID
1.1, -- number of times faster the plan must be
'disable' -- The action to take. This sets the enabled field to false.
)
FROM apg_plan_mgmt.dba_plans
WHERE status = 'Unapproved' AND -- plan is Unapproved
origin = 'Automatic'; -- plan was auto-captured
```
Sie können den Status eines Plans auch direkt auf „Abgelehnt“ oder „Deaktiviert“ setzen. Rufen Sie die Funktion `true` auf, um das aktivierte Feld eines Plans direkt auf `false` oder `apg_plan_mgmt.set_plan_enabled` festzulegen. Mit der Funktion „`'Approved'`“ legen Sie das Statusfeld eines Plans direkt auf `'Rejected'`, `'Unapproved'`, `'Preferred'` oder `apg_plan_mgmt.set_plan_status` fest.
Verwenden Sie die `apg_plan_mgmt.validate_plans`-Funktion, um Pläne zu löschen, die nicht gültig sind und voraussichtlich ungültig bleiben werden. Mit dieser Funktion können Sie ungültige Pläne löschen oder deaktivieren. Weitere Informationen finden Sie unter [Validieren von Plänen](AuroraPostgreSQL.Optimize.Deleting.md#AuroraPostgreSQL.Optimize.Maintenance.ValidatingPlans).
## Reparieren von Plänen mit pg\$1hint\$1plan
Mit dem Abfrageoptimierer kann für jede Anweisung der bestmögliche Plan gefunden werden. In den meisten Fällen findet der Abfrageoptimierer in der Tat einen guten Plan. Manchmal gibt es jedoch einen weitaus besseren als den vom Optimierer erstellten Plan. Um zu gewährleisten, dass der Optimierer einen passenden Plan erstellt, wird zum einen die Verwendung der Erweiterung `pg_hint_plan`, zum anderen die Festlegung der Grand Unified Configuration (GUC)-Variablen in PostgreSQL empfohlen:
+ `pg_hint_plan`-Erweiterung – Geben Sie mithilfe der `pg_hint_plan`-Erweiterung von PostgreSQL einen „Hinweis“, um die Arbeitsweise des Planers zu ändern. Informationen zur Installation und Verwendung der `pg_hint_plan`-Erweiterung finden Sie in der [pg\$1hint\$1plan-Dokumentation](https://github.com/ossc-db/pg_hint_plan).
+ GUC-Variablen: Überschreiben Sie einen oder mehrere Kostenmodellparameter oder Parameter des Optimierers, wie z. B. `from_collapse_limit` oder `GEQO_threshold`.
Wenn Sie den Abfrageoptimierer mit einer dieser Methoden zur Verwendung eines Plans zwingen, können Sie auch die Abfrageplanverwaltung nutzen, um den neuen Plan zu erfassen und dessen Anwendung durchzusetzen.
Mit der Erweiterung `pg_hint_plan` können Sie die Join-Reihenfolge, die Join-Methoden oder die Zugriffspfade für eine SQL-Anweisung ändern. Sie nutzen einen SQL-Kommentar mit einer besonderen `pg_hint_plan`-Syntax, um die üblicherweise vom Optimierer angewendete Planerstellungsmethode zu ändern. Angenommen, die entsprechende SQL-Anweisung verfügt über eine Zwei-Wege-Verknüpfung.
```
SELECT *
FROM t1, t2
WHERE t1.id = t2.id;
```
Der Optimierer wählt nun die Join-Reihenfolge (t1, t2) aus. Wir wissen jedoch, dass die Reihenfolge (t2, t1) schneller ist. Der folgende Hinweis zwingt den Optimierer dazu, die schnellere Join-Reihenfolge (t2, t1) zu wählen. Schließen Sie EXPLAIN ein, damit der Optimierer einen Plan für die SQL-Anweisung generiert, ohne jedoch die Anweisung auszuführen. (Ausgabe wird nicht angezeigt.)
```
/*+ Leading ((t2 t1)) */ EXPLAIN SELECT *
FROM t1, t2
WHERE t1.id = t2.id;
```
Im Folgenden wird beschrieben, wie Sie verwende `pg_hint_plan`.
**So ändern und erfassen Sie mit pg\$1hint\$1plan den vom Optimierer erstellten Plan:**
1. Aktivieren Sie den manuellen Erfassungsmodus.
```
SET apg_plan_mgmt.capture_plan_baselines = manual;
```
1. Geben Sie für die entsprechende SQL-Anweisung einen Hinweis an.
```
/*+ Leading ((t2 t1)) */ EXPLAIN SELECT *
FROM t1, t2
WHERE t1.id = t2.id;
```
Nach der Ausführung erfasst der Optimierer den Plan in der `apg_plan_mgmt.dba_plans`-Ansicht. Der erfasste Plan berücksichtigt nicht die Syntax des besonderen Kommentars `pg_hint_plan`, weil die Abfrageplanverwaltung die Anweisung durch das Entfernen führender Kommentare normalisiert.
1. Sie können die verwalteten Pläne über die `apg_plan_mgmt.dba_plans`-Ansicht anzeigen.
```
SELECT sql_hash, plan_hash, status, sql_text, plan_outline
FROM apg_plan_mgmt.dba_plans;
```
1. Legen Sie den Status des Plans auf fes `Preferred`. Dadurch wird sichergestellt, dass der Optimierer den Plan ausführt, anstatt ihn aus dem Satz an genehmigten Plänen auszuwählen, wenn der Minimalkostenplan nicht bereits `Approved` oder `Preferred` ist.
```
SELECT apg_plan_mgmt.set_plan_status(sql-hash, plan-hash, 'preferred' );
```
1. Deaktivieren Sie die manuelle Planerfassung und erzwingen Sie die Verwendung verwalteter Pläne.
```
SET apg_plan_mgmt.capture_plan_baselines = false;
SET apg_plan_mgmt.use_plan_baselines = true;
```
Während der Ausführung der ursprünglichen SQL-Anweisung wählt der Optimierer einen Plan aus, der entweder `Approved` oder `Preferred` ist. Wenn der Minimalkostenplan weder den Status „`Approved`“ noch „`Preferred`“ aufweist, wählt der Optimierer den Plan mit Status „`Preferred`“ aus.
# Löschen von Aurora-PostgreSQL-Abfrageplänen
Löschen Sie Ausführungspläne, die Sie nicht verwenden, oder Pläne, die nicht gültig sind. Weitere Informationen zum Löschen von Plänen finden Sie in den folgenden Abschnitten.
**Topics**
+ [Löschen von Plänen](#AuroraPostgreSQL.Optimize.Maintenance.DeletingPlans)
+ [Validieren von Plänen](#AuroraPostgreSQL.Optimize.Maintenance.ValidatingPlans)
## Löschen von Plänen
Pläne werden automatisch gelöscht, wenn sie seit über einem Monat, genauer gesagt 32 Tagen, nicht mehr verwendet wurden. Dies ist die Standardeinstellung des Parameters `apg_plan_mgmt.plan_retention_period`. Sie können den Aufbewahrungszeitraum des Plans zu einem längeren oder kürzeren Zeitraum ändern, beginnend mit dem Wert 1. Die Bestimmung der Anzahl von Tagen, seit ein Plan zuletzt verwendet wurde, wird berechnet, indem das `last_used`-Datum vom aktuellen Datum abgezogen wird. Das `last_used`-Datum ist das letzte Datum, an dem der Optimierer den Plan als Minimalkostenplan ausgewählt hat oder der Plan ausgeführt wurde. Das Datum wird in der `apg_plan_mgmt.dba_plans`-Ansicht für den Plan gespeichert.
Wir empfehlen Ihnen, Pläne zu löschen, die lange nicht mehr verwendet wurden oder nicht nützlich sind. Jeder Plan verfügt über ein `last_used`-Datum, das vom Optimierer aktualisiert wird, wenn er einen Plan ausführt oder den Plan als Minimalkostenplan für eine Anweisung auswählt. Überprüfen Sie die letzten `last_used`-Daten, um die Pläne zu identifizieren, die Sie ohne Bedenken löschen können.
Die folgende Abfrage gibt eine dreispaltige Tabelle mit der Gesamtanzahl der Pläne, der Anzahl der Pläne, die nicht gelöscht wurden, und der Anzahl der Pläne, die erfolgreich gelöscht wurden, zurück. Sie enthält eine verschachtelte Abfrage, die ein Beispiel dafür ist, wie Sie die `apg_plan_mgmt.delete_plan`-Funktion verwenden, um alle Pläne zu löschen, die in den letzten 31 Tagen nicht als Minimalkostenplan ausgewählt wurden und deren Status nicht `Rejected` lautet.
```
SELECT (SELECT COUNT(*) from apg_plan_mgmt.dba_plans) total_plans,
COUNT(*) FILTER (WHERE result = -1) failed_to_delete,
COUNT(*) FILTER (WHERE result = 0) successfully_deleted
FROM (
SELECT apg_plan_mgmt.delete_plan(sql_hash, plan_hash) as result
FROM apg_plan_mgmt.dba_plans
WHERE last_used < (current_date - interval '31 days')
AND status <> 'Rejected'
) as dba_plans ;
```
```
total_plans | failed_to_delete | successfully_deleted
-------------+------------------+----------------------
3 | 0 | 2
```
Weitere Informationen finden Sie unter [apg\$1plan\$1mgmt.delete\$1plan](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.delete_plan).
Verwenden Sie die `apg_plan_mgmt.validate_plans`-Funktion, um Pläne zu löschen, die nicht gültig sind und voraussichtlich ungültig bleiben werden. Mit dieser Funktion können Sie ungültige Pläne löschen oder deaktivieren. Weitere Informationen finden Sie unter [Validieren von Plänen](#AuroraPostgreSQL.Optimize.Maintenance.ValidatingPlans).
**Wichtig**
Wenn Sie Ihre irrelevanten Pläne nicht löschen, verfügen Sie möglicherweise über keinen gemeinsam genutzten Speicher mehr, der für die Abfrageplanverwaltung reserviert wird. Mit dem Parameter `apg_plan_mgmt.max_plans` legen Sie fest, wie viel Speicher für verwaltete Pläne zur Verfügung steht. Legen Sie diesen Parameter in der benutzerdefinierten Parametergruppe fest und starten Sie Ihre DB-Instance neu, damit die Änderungen wirksam werden. Informieren Sie sich über den Parameter [apg\$1plan\$1mgmt.max\$1plans](AuroraPostgreSQL.Optimize.Parameters.md#AuroraPostgreSQL.Optimize.Parameters.max_plans), um weitere Informationen hierzu zu erhalten.
## Validieren von Plänen
Verwenden Sie die Funktion `apg_plan_mgmt.validate_plans`, um ungültige Pläne zu löschen oder zu deaktivieren.
Pläne können ungültig oder veraltet werden, wenn Objekte entfernt werden, von denen sie abhängig sind (z. B. ein Index oder eine Tabelle). Wenn das entfernte Objekt jedoch erneut erstellt wird, kann ein Plan auch nur für eine bestimmte Zeit ungültig sein. Falls ein ungültiger Plan zu einem späteren Zeitpunkt gültig werden kann, ist es möglicherweise sinnvoller, diesen nicht zu löschen, sondern zu deaktivieren oder einfach nichts zu unternehmen.
Über die Funktion `apg_plan_mgmt.validate_plans ` suchen und löschen Sie alle ungültigen und während der vergangenen Woche nicht verwendeten Pläne. Gehen Sie hierzu folgendermaßen vor:
```
SELECT apg_plan_mgmt.validate_plans(sql_hash, plan_hash, 'delete')
FROM apg_plan_mgmt.dba_plans
WHERE last_used < (current_date - interval '7 days');
```
Verwenden Sie die Funktion `apg_plan_mgmt.set_plan_enabled` zum direkten Aktivieren oder Deaktivieren eines Plans.
# Exportieren und Importieren von verwalteten Plänen für Aurora PostgreSQL
Sie können Ihre verwalteten Pläne exportieren und in eine andere DB-Instance importieren.
**So exportieren Sie verwaltete Pläne:**
Autorisierte Benutzer können ein beliebiges Subset der `apg_plan_mgmt.plans`-Tabelle in eine andere Tabelle kopieren und dann mit dem Befehl `pg_dump` speichern. Im Folgenden wird ein Beispiel gezeigt.
```
CREATE TABLE plans_copy AS SELECT *
FROM apg_plan_mgmt.plans [ WHERE predicates ] ;
```
```
% pg_dump --table apg_plan_mgmt.plans_copy -Ft mysourcedatabase > plans_copy.tar
```
```
DROP TABLE apg_plan_mgmt.plans_copy;
```
**So importieren Sie verwaltete Pläne:**
1. Kopieren Sie die .tar-Datei der exportierten verwalteten Pläne in das System, in dem die Pläne wiederhergestellt werden sollen.
1. Verwenden Sie den Befehl `pg_restore`, um die .tar-Datei in eine neue Tabelle zu kopieren.
```
% pg_restore --dbname mytargetdatabase -Ft plans_copy.tar
```
1. Führen Sie die Tabellen `plans_copy` und `apg_plan_mgmt.plans` entsprechend dem folgenden Beispiel zusammen.
**Anmerkung**
In einigen Fällen verwenden Sie möglicherweise für die Sicherung eine bestimmte Version der Erweiterung `apg_plan_mgmt` und für die Wiederherstellung eine andere Version der Erweiterung. In diesem Fällen fallen die Spalten in der Plantabelle möglicherweise unterschiedlich aus. Geben Sie den Spalten in diesem Fall einen bestimmten Namen, anstatt SELECT\$1 zu verwenden.
```
INSERT INTO apg_plan_mgmt.plans SELECT * FROM plans_copy
ON CONFLICT ON CONSTRAINT plans_pkey
DO UPDATE SET
status = EXCLUDED.status,
enabled = EXCLUDED.enabled,
-- Save the most recent last_used date
--
last_used = CASE WHEN EXCLUDED.last_used > plans.last_used
THEN EXCLUDED.last_used ELSE plans.last_used END,
-- Save statistics gathered by evolve_plan_baselines, if it ran:
--
estimated_startup_cost = EXCLUDED.estimated_startup_cost,
estimated_total_cost = EXCLUDED.estimated_total_cost,
planning_time_ms = EXCLUDED.planning_time_ms,
execution_time_ms = EXCLUDED.execution_time_ms,
total_time_benefit_ms = EXCLUDED.total_time_benefit_ms,
execution_time_benefit_ms = EXCLUDED.execution_time_benefit_ms;
```
1. Laden Sie die verwalteten Pläne erneut in den gemeinsam genutzten Speicher und entfernen Sie die Tabelle für die temporären Pläne.
```
SELECT apg_plan_mgmt.reload(); -- refresh shared memory
DROP TABLE plans_copy;
```
# Parameterreferenz für Aurora-PostgreSQL-Abfrageplanverwaltung
Sie können Ihre Einstellungen für die `apg_plan_mgmt`-Erweiterung unter Verwendung der in diesem Abschnitt aufgeführten Parameter vornehmen. Diese sind im benutzerdefinierten DB-Cluster-Parameter und in der DB-Parametergruppe verfügbar, die Ihrem Aurora PostgreSQL DB-Cluster zugeordnet ist. Diese Parameter steuern das Verhalten der Abfrageplanverwaltungsfunktion und deren Auswirkungen auf den Optimierer. Weitere Informationen zum Einrichten einer Abfrageverwaltung finden Sie unter [Aktivieren der Abfrageplanverwaltung in Aurora PostgreSQL](AuroraPostgreSQL.Optimize.overview.md#AuroraPostgreSQL.Optimize.Enable). Das Ändern der folgenden Parameter hat keine Auswirkung, wenn die `apg_plan_mgmt`-Erweiterung nicht wie in diesem Abschnitt beschrieben eingerichtet ist. Weitere Informationen zum Ändern von Parametern finden Sie unter [Ändern von Parametern in einer DB-Cluster-Parametergruppe in Amazon Aurora](USER_WorkingWithParamGroups.ModifyingCluster.md) und [DB-Parametergruppen für DB-Instances von Amazon Aurora](USER_WorkingWithDBInstanceParamGroups.md).
**Topics**
+ [apg\$1plan\$1mgmt.capture\$1plan\$1baselines](#AuroraPostgreSQL.Optimize.Parameters.capture_plan_baselines)
+ [apg\$1plan\$1mgmt.plan\$1capture\$1threshold](#AuroraPostgreSQL.Optimize.Parameters.plan_capture_threshold)
+ [apg\$1plan\$1mgmt.explain\$1hashes](#AuroraPostgreSQL.Optimize.Parameters.explain_hashes)
+ [apg\$1plan\$1mgmt.log\$1plan\$1enforcement\$1result](#AuroraPostgreSQL.Optimize.Parameters.log_plan_enforcement_result)
+ [apg\$1plan\$1mgmt.max\$1databases](#AuroraPostgreSQL.Optimize.Parameters.max_databases)
+ [apg\$1plan\$1mgmt.max\$1plans](#AuroraPostgreSQL.Optimize.Parameters.max_plans)
+ [apg\$1plan\$1mgmt.plan\$1hash\$1version](#AuroraPostgreSQL.Optimize.Parameters.plan_hash_version)
+ [apg\$1plan\$1mgmt.plan\$1retention\$1period](#AuroraPostgreSQL.Optimize.Parameters.plan_retention_period)
+ [apg\$1plan\$1mgmt.unapproved\$1plan\$1execution\$1threshold](#AuroraPostgreSQL.Optimize.Parameters.unapproved_plan_execution_threshold)
+ [apg\$1plan\$1mgmt.use\$1plan\$1baselines](#AuroraPostgreSQL.Optimize.Parameters.use_plan_baselines)
+ [auto\$1explain.hashes](#AuroraPostgreSQL.Optimize.Parameters.auto_explain.hashes)
## apg\$1plan\$1mgmt.capture\$1plan\$1baselines
Erfasst Abfrageausführungspläne, die vom Optimierer für jede SQL-Anweisung generiert wurden, und speichert sie im der `dba_plans`-Ansicht. Standardmäßig beträgt die maximale Anzahl von Plänen, die gespeichert werden können, 10 000, wie im `apg_plan_mgmt.max_plans`-Parameter angegeben. Referenzinformationen finden Sie unter [apg\$1plan\$1mgmt.max\$1plans](#AuroraPostgreSQL.Optimize.Parameters.max_plans).
Sie können diesen Parameter in der benutzerdefinierten DB-Cluster-Parametergruppe oder in der benutzerdefinierten DB-Parametergruppe festlegen. Um den Wert dieses Parameters zu ändern, ist kein Neustart erforderlich.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Parameters.html)
Weitere Informationen finden Sie unter [Erfassung von Aurora-PostgreSQL-Ausführungsplänen](AuroraPostgreSQL.Optimize.CapturePlans.md).
## apg\$1plan\$1mgmt.plan\$1capture\$1threshold
Gibt einen Schwellenwert an, sodass der Plan nicht in der Ansicht `apg_plan_mgmt.dba_plans` erfasst wird, wenn die Gesamtkosten des Abfrageausführungsplans unter dem Schwellenwert liegen.
Um den Wert dieses Parameters zu ändern, ist kein Neustart erforderlich.
| Standard | Zulässige Werte | Description |
| --- | --- | --- |
| 0 | 0 – 1.79769e\$1308 | Legt den Schwellenwert der Gesamtausführungskosten des Abfrageplans `apg_plan_mgmt` für die Erfassung von Plänen fest. |
Weitere Informationen finden Sie unter [Untersuchen von Aurora-PostgreSQL-Abfrageplänen in der dba\$1plans-Ansicht](AuroraPostgreSQL.Optimize.ViewPlans.md).
## apg\$1plan\$1mgmt.explain\$1hashes
Gibt an, ob der `EXPLAIN [ANALYZE]` am Ende seiner Ausgabe `sql_hash` und `plan_hash` anzeigt. Um den Wert dieses Parameters zu ändern, ist kein Neustart erforderlich.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Parameters.html)
## apg\$1plan\$1mgmt.log\$1plan\$1enforcement\$1result
Gibt an, ob die Ergebnisse aufgezeichnet werden müssen, um zu überprüfen, ob die von QPM verwalteten Pläne ordnungsgemäß verwendet werden. Wenn ein gespeicherter generischer Plan verwendet wird, werden keine Datensätze in die Protokolldateien geschrieben. Um den Wert dieses Parameters zu ändern, ist kein Neustart erforderlich.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Parameters.html)
## apg\$1plan\$1mgmt.max\$1databases
Gibt die maximale Anzahl an Datenbanken in der Writer-Instance Ihres Aurora-PostgreSQL-Datenbank-Clusters an, die die Abfrageplanverwaltung nutzen können. Standardmäßig können bis zu 10 Datenbanken die Abfrageplanverwaltung verwenden. Wenn die Instance über mehr als 10 Datenbanken verfügt, können Sie den Wert dieser Einstellung ändern. Um herauszufinden, wie viele Datenbanken sich in einer bestimmten Instance befinden, stellen Sie eine Verbindung mit der Instance über `psql` her. Verwenden Sie dann den psql-Meta-Befehl, `\l`, um die Datenbanken aufzulisten.
Wenn Sie den Wert dieses Parameters ändern, müssen Sie die Instance neu starten, damit die Einstellung wirksam wird.
| Standard | Zulässige Werte | Description |
| --- | --- | --- |
| 10 | 10-2147483647 | Maximale Anzahl von Datenbanken, die die Abfrageplanverwaltung auf der Instance verwenden können. |
Sie können diesen Parameter in der benutzerdefinierten DB-Cluster-Parametergruppe oder in der benutzerdefinierten DB-Parametergruppe festlegen.
## apg\$1plan\$1mgmt.max\$1plans
Legt die maximale Anzahl von SQL-Anweisungen fest, die die Abfrageplanverwaltung in der Ansicht `apg_plan_mgmt.dba_plans` anzeigen kann. Wir empfehlen, diesen Parameter für alle Aurora-PostgreSQL-Versionen auf `10000` oder höher zu setzen.
Sie können diesen Parameter in der benutzerdefinierten DB-Cluster-Parametergruppe oder in der benutzerdefinierten DB-Parametergruppe festlegen. Wenn Sie den Wert dieses Parameters ändern, müssen Sie die Instance neu starten, damit die Einstellung wirksam wird.
| Standard | Zulässige Werte | Description |
| --- | --- | --- |
| 10000 | 10-2147483647 | Maximale Anzahl von Plänen, die in der `apg_plan_mgmt.dba_plans`-Ansicht gespeichert werden können. Die Standardeinstellung für Aurora-PostgreSQL-Version 10 und älter ist 1000. |
Weitere Informationen finden Sie unter [Untersuchen von Aurora-PostgreSQL-Abfrageplänen in der dba\$1plans-Ansicht](AuroraPostgreSQL.Optimize.ViewPlans.md).
## apg\$1plan\$1mgmt.plan\$1hash\$1version
Gibt die Anwendungsfälle an, für die die plan\$1hash-Berechnung konzipiert ist. Eine höhere Version von `apg_plan_mgmt.plan_hash_version` deckt den gesamten Funktionsumfang der niedrigeren Version ab. Version 3 deckt beispielsweise die von Version 2 unterstützten Anwendungsfälle ab.
Auf die Änderung des Werts dieses Parameters muss ein Aufruf von `apg_plan_mgmt.validate_plans('update_plan_hash')` folgen. Dadurch werden die plan\$1hash-Werte in jeder Datenbank, in der apg\$1plan\$1mgmt installiert ist, und Einträge in der Plantabelle aktualisiert. Weitere Informationen finden Sie unter [Validieren von Plänen](AuroraPostgreSQL.Optimize.Deleting.md#AuroraPostgreSQL.Optimize.Maintenance.ValidatingPlans).
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Parameters.html)
## apg\$1plan\$1mgmt.plan\$1retention\$1period
Gibt an, wie viele Tage lang Pläne in der `apg_plan_mgmt.dba_plans`-Ansicht aufbewahrt werden, danach werden sie automatisch gelöscht. Standardmäßig wird ein Plan gelöscht, wenn 32 Tage seit der letzten Verwendung des Plans vergangen sind (Die `last_used`-Spalte in der `apg_plan_mgmt.dba_plans`-Ansicht). Sie können diese Einstellung auf eine beliebige Zahl ändern (1 und höher).
Wenn Sie den Wert dieses Parameters ändern, müssen Sie die Instance neu starten, damit die Einstellung wirksam wird.
| Standard | Zulässige Werte | Description |
| --- | --- | --- |
| 32 | 1-2147483647 | Maximale Anzahl von Tagen seit der letzten Nutzung eines Plans, bevor er gelöscht wird. |
Weitere Informationen finden Sie unter [Untersuchen von Aurora-PostgreSQL-Abfrageplänen in der dba\$1plans-Ansicht](AuroraPostgreSQL.Optimize.ViewPlans.md).
## apg\$1plan\$1mgmt.unapproved\$1plan\$1execution\$1threshold
Gibt einen Kostenschwellenwert an, unterhalb dessen ein nicht genehmigter Plan vom Optimierer verwendet werden kann. Der Schwellenwert lautet standardmäßig 0, nicht genehmigte Pläne werden vom Optimierer also nicht ausgeführt. Wenn dieser Parameter auf einen belanglos niedrigen Kostenschwellenwert wie 100 gesetzt wird, wird der Overhead für die Plandurchsetzung bei trivialen Plänen vermieden. Sie können diesen Parameter auch unter Verwendung des reaktiven Planverwaltungstils auf einen extrem hohen Wert wie 10000000 festlegen. Auf diese Weise kann der Optimierer alle ausgewählten Pläne ohne Overhead für die Plandurchsetzung verwenden. Wenn jedoch ein fehlerhafter Plan gefunden wird, können Sie diesen manuell als „abgelehnt“ markieren, sodass er beim nächsten Mal nicht verwendet wird.
Der Wert dieses Parameters stellt eine Kostenschätzung für die Ausführung eines bestimmten Plans dar. Wenn ein nicht genehmigter Plan unter diesen geschätzten Kosten liegt, verwendet der Optimierer ihn für die SQL-Anweisung. Sie können erfasste Pläne und ihren Status (Genehmigt, Nicht genehmigt) in der `dba_plans`-Ansicht anzeigen. Weitere Informationen hierzu finden Sie unter [Untersuchen von Aurora-PostgreSQL-Abfrageplänen in der dba\$1plans-Ansicht](AuroraPostgreSQL.Optimize.ViewPlans.md).
Um den Wert dieses Parameters zu ändern, ist kein Neustart erforderlich.
| Standard | Zulässige Werte | Description |
| --- | --- | --- |
| 0 | 0-2147483647 | Geschätzte Plankosten, unter denen ein nicht genehmigter Plan verwendet wird. |
Weitere Informationen finden Sie unter [Verwenden von Aurora-PostgreSQL-Plänen](AuroraPostgreSQL.Optimize.UsePlans.md).
## apg\$1plan\$1mgmt.use\$1plan\$1baselines
Gibt an, dass der Optimierer einen der genehmigten Pläne verwenden soll, der in der `apg_plan_mgmt.dba_plans`-Ansicht erfasst und gespeichert ist. Standardmäßig ist dieser Parameter deaktiviert (false), was dazu führt, dass der Optimierer den von ihm generierten Mindestkostenplan ohne weitere Bewertung verwendet. Wenn Sie diesen Parameter aktivieren (ihn auf true setzen), muss der Optimierer einen Abfrageausführungsplan für die Anweisung aus seiner Plan-Baseline auswählen. Weitere Informationen finden Sie unter [Verwenden von Aurora-PostgreSQL-Plänen](AuroraPostgreSQL.Optimize.UsePlans.md). Ein Bild, das diesen Prozess detailliert beschreibt, finden Sie unter [Erfahren Sie, wie der Optimierer bestimmt, welche Pläne ausgeführt werden.](AuroraPostgreSQL.Optimize.UsePlans.md#AuroraPostgreSQL.Optimize.UsePlans.ChoosePlans).
Sie können diesen Parameter in der benutzerdefinierten DB-Cluster-Parametergruppe oder in der benutzerdefinierten DB-Parametergruppe festlegen. Um den Wert dieses Parameters zu ändern, ist kein Neustart erforderlich.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Parameters.html)
Sie können die Reaktionszeiten verschiedener erfasster Pläne auswerten und den Planstatus nach Bedarf ändern. Weitere Informationen finden Sie unter [Verbessern von Aurora-PostgreSQL-Abfrageplänen](AuroraPostgreSQL.Optimize.Maintenance.md).
## auto\$1explain.hashes
Gibt an, ob die auto\$1explain-Ausgabe sql\$1hash und plan\$1hash anzeigt. Um den Wert dieses Parameters zu ändern, ist kein Neustart erforderlich.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Parameters.html)
# Funktionsreferenz für die Aurora-PostgreSQL-Abfrageplanverwaltung
Die Erweiterung `apg_plan_mgmt` stellt die folgenden Funktionen bereit:
**Topics**
+ [apg\$1plan\$1mgmt.copy\$1outline](#AuroraPostgreSQL.Optimize.Functions.copy_outline)
+ [apg\$1plan\$1mgmt.delete\$1plan](#AuroraPostgreSQL.Optimize.Functions.delete_plan)
+ [apg\$1plan\$1mgmt.evolve\$1plan\$1baselines](#AuroraPostgreSQL.Optimize.Functions.evolve_plan_baselines)
+ [apg\$1plan\$1mgmt.get\$1explain\$1plan](#AuroraPostgreSQL.Optimize.Functions.get_explain_plan)
+ [apg\$1plan\$1mgmt.plan\$1last\$1used](#AuroraPostgreSQL.Optimize.Functions.plan_last_used)
+ [apg\$1plan\$1mgmt.reload](#AuroraPostgreSQL.Optimize.Functions.reload)
+ [apg\$1plan\$1mgmt.set\$1plan\$1enabled](#AuroraPostgreSQL.Optimize.Functions.set_plan_enabled)
+ [apg\$1plan\$1mgmt.set\$1plan\$1status](#AuroraPostgreSQL.Optimize.Functions.set_plan_status)
+ [apg\$1plan\$1mgmt.update\$1plans\$1last\$1used](#AuroraPostgreSQL.Optimize.Functions.update_plans_last_used)
+ [apg\$1plan\$1mgmt.validate\$1plans](#AuroraPostgreSQL.Optimize.Functions.validate_plans)
## apg\$1plan\$1mgmt.copy\$1outline
Kopiert einen bestimmten SQL-Plan-Hash und eine Plangliederung in einen Ziel-SQL-Plan-Hash und eine Gliederung, wodurch der Plan-Hash und die Gliederung des Ziels überschrieben werden. Diese Funktion ist in `apg_plan_mgmt` 2.3 und höheren Versionen verfügbar.
**Syntax**
```
apg_plan_mgmt.copy_outline(
source_sql_hash,
source_plan_hash,
target_sql_hash,
target_plan_hash,
force_update_target_plan_hash
)
```
**Rückgabewert**
Gibt 0 zurück, wenn das Kopieren erfolgreich ist. Löst Ausnahmen bei ungültigen Eingaben aus.
**Parameter**
****
| Parameter | Description |
| --- | --- |
| source\$1sql\$1hash | Die sql\$1hash-ID, die mit plan\$1hash verknüpft ist, um sie in die Zielabfrage zu kopieren. |
| source\$1plan\$1hash | Die plan\$1hash-ID, die in die Zielabfrage kopiert werden soll. |
| target\$1sql\$1hash | Die sql\$1hash-ID der Abfrage, die mit dem Hash und der Gliederung des Quellplans aktualisiert werden soll. |
| target\$1plan\$1hash | Die plan\$1hash-ID der Abfrage, die mit dem Hash und der Gliederung des Quellplans aktualisiert werden soll. |
| force\$1update\$1target\$1plan\$1hash | (Optional) Die target\$1plan\$1hash-ID der Abfrage wird aktualisiert, auch wenn der Quellplan für den target\$1sql\$1hash nicht reproduzierbar ist. Bei der Einstellung „true“ kann die Funktion verwendet werden, um Pläne über Schemas hinweg zu kopieren, bei denen die Namen und Spalten der Beziehungen konsistent sind. |
**Nutzungshinweise**
Mit dieser Funktion können Sie einen Plan-Hash und eine Plangliederung kopieren, die Hinweise auf andere, ähnliche Anweisungen verwendet, und Ihnen so die Verwendung von Inline-Hinweisanweisungen bei jedem Vorkommen in den Zielanweisungen erspart. Wenn die aktualisierte Zielabfrage zu einem ungültigen Plan führt, löst diese Funktion einen Fehler aus und macht den Aktualisierungsversuch rückgängig.
## apg\$1plan\$1mgmt.delete\$1plan
Löschen Sie einen verwalteten Plan.
**Syntax**
```
apg_plan_mgmt.delete_plan(
sql_hash,
plan_hash
)
```
**Rückgabewert**
Gibt bei erfolgreichen Löschvorgängen „0“, bei gescheiterten Löschvorgängen „-1“ zurück.
**Parameter**
****
| Parameter | Beschreibung |
| --- | --- |
| sql\$1hash | Die sql\$1hash-ID der verwalteten SQL-Anweisung des Plans. |
| plan\$1hash | Die plan\$1hash-ID des verwalteten Plans. |
## apg\$1plan\$1mgmt.evolve\$1plan\$1baselines
Dieser Parameter überprüft, ob ein bereits genehmigter Plan oder ein vom Optimierer erkannter Minimalkostenplan schneller ist.
**Syntax**
```
apg_plan_mgmt.evolve_plan_baselines(
sql_hash,
plan_hash,
min_speedup_factor,
action
)
```
**Rückgabewert**
Die Anzahl der Pläne, die nicht schneller als der beste genehmigte Plan waren.
**Parameter**
****
| Parameter | Beschreibung |
| --- | --- |
| sql\$1hash | Die sql\$1hash-ID der verwalteten SQL-Anweisung des Plans. |
| plan\$1hash | Die plan\$1hash-ID des verwalteten Plans. Verwenden Sie NULL, um alle Pläne mit demselben sql\$1hash-ID-Wert anzugeben. |
| min\$1speedup\$1factor | Der *Mindestbeschleunigungsfaktor* kann angeben, um wie viel schneller ein Plan im Vergleich zum besten der bereits genehmigten Pläne sein muss, um genehmigt zu werden. Alternativ kann dieser Faktor auch angeben, um wie viel langsamer ein Plan sein muss, um abgelehnt oder deaktiviert zu werden. Dieser Wert ist ein positiver Gleitkommawert. |
| action | Bezeichnet die Aktion, die von der Funktion ausgeführt wird. Im Folgenden sind Beispiele für gültige Werte aufgeführt. Die Groß-/Kleinschreibung muss nicht beachtet werden. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Functions.html) |
**Nutzungshinweise**
Je nachdem, ob die kombinierte Planungs- und Ausführungszeit eines Plans kürzer ist als beim schnellsten genehmigten Plan, können Sie anhand eines von Ihnen festlegbaren Faktors den Status bestimmter Pläne auf „Genehmigt“, „Abgelehnt“ oder „Deaktiviert“ setzen. Der Aktionsparameter kann auf `'approve'` oder `'reject'` gesetzt werden, um einen Plan automatisch zu genehmigen oder abzulehnen, wenn er die Performance-Kriterien erfüllt. Alternativ kann auch die Einstellung '' (leere Zeichenfolge) gewählt werden, um den Performance-Vergleich durchzuführen und einen Bericht zu erstellen, wobei in diesem Fall keine Aktion ausgeführt wird.
Sie können vermeiden, dass die Funktion `apg_plan_mgmt.evolve_plan_baselines` bei einem Plan unnötigerweise erneut ausgeführt wird. Dazu schränken Sie die Auswahl der Pläne auf die kürzlich erstellten, nicht genehmigten Pläne ein. Das Ausführen der Funktion `apg_plan_mgmt.evolve_plan_baselines` kann auch vermieden werden, wenn ein genehmigter Plan über einen aktuellen `last_verified`-Zeitstempel verfügt.
Führen Sie einen Performance-Vergleich durch, um die kombinierte Planungs- und Ausführungszeit aller Baseline-Pläne miteinander zu vergleichen. In einigen Fällen gibt es für eine Anweisung nur einen Plan, der dann auch genehmigt wird. Vergleichen Sie in einem solchen Fall die kombinierte Planungs- und Ausführungszeit des Plans mit der kombinierten Planungs- und Ausführungszeit, die sich ergibt, wenn kein Plan verwendet wird.
Der inkrementelle Vorteil (oder Nachteil) aller Pläne wird in der `apg_plan_mgmt.dba_plans`-Ansicht in der Spalte `total_time_benefit_ms` aufgezeichnet. Ist dieser Wert positiv, führt die Aufnahme dieses Plans in die Baseline zu einem messbaren Performance-Vorteil.
Zusätzlich zur Planungs- und Ausführungszeit aller ausgewählten Pläne wird in der Spalte `last_verified` der `apg_plan_mgmt.dba_plans`-Ansicht auch der aktuelle `current_timestamp` angezeigt. Durch den Zeitstempel `last_verified` kann das erneute Ausführen dieser Funktion bei einem Plan vermieden werden, dessen Performance erst kürzlich verifiziert wurde.
## apg\$1plan\$1mgmt.get\$1explain\$1plan
Erzeugt den Text einer `EXPLAIN`-Anweisung für die angegebene SQL-Anweisung.
**Syntax**
```
apg_plan_mgmt.get_explain_plan(
sql_hash,
plan_hash,
[explainOptionList]
)
```
**Rückgabewert**
Gibt Laufzeitstatistiken für die angegebenen SQL-Anweisungen zurück. Verwenden ohne `explainOptionList`, um einen einfachen `EXPLAIN`-Plan zurückzugeben.
**Parameter**
****
| Parameter | Beschreibung |
| --- | --- |
| sql\$1hash | Die sql\$1hash-ID der verwalteten SQL-Anweisung des Plans. |
| plan\$1hash | Die plan\$1hash-ID des verwalteten Plans. |
| explainOptionList | Eine durch Kommas getrennte Liste von Explain-Optionen. Gültige Werte sind `'analyze'`, `'verbose'`, `'buffers'`, `'hashes'` und `'format json'`. Wenn `explainOptionList` NULL ist oder eine leere Zeichenfolge („), generiert diese Funktion eine `EXPLAIN`-Anweisung, ohne irgendwelche Statistiken. |
**Nutzungshinweise**
Für `explainOptionList` können Sie eine der gleichen Optionen verwenden, die Sie mit einer `EXPLAIN`-Anweisung verwenden würden. Der Aurora-PostgreSQL-Optimizer verkettet die Liste der Optionen, die Sie für die `EXPLAIN`-Anweisung bereitstellen.
## apg\$1plan\$1mgmt.plan\$1last\$1used
Gibt das `last_used`-Datum des angegebenen Plans aus dem gemeinsam genutzten Speicher zurück.
**Anmerkung**
Der Wert im gemeinsam genutzten Speicher ist auf der primären DB-Instance im DB-Cluster immer aktuell. Der Wert wird nur periodisch in die `last_used`-Spalte der `apg_plan_mgmt.dba_plans`-Ansicht gespült.
**Syntax**
```
apg_plan_mgmt.plan_last_used(
sql_hash,
plan_hash
)
```
**Rückgabewert**
Gibt das Datum des Typs `last_used` zurück.
**Parameter**
****
| Parameter | Beschreibung |
| --- | --- |
| sql\$1hash | Die sql\$1hash-ID der verwalteten SQL-Anweisung des Plans. |
| plan\$1hash | Die plan\$1hash-ID des verwalteten Plans. |
## apg\$1plan\$1mgmt.reload
Laden Sie Pläne in der `apg_plan_mgmt.dba_plans`-Ansicht erneut in den gemeinsam genutzten Speicher.
**Syntax**
```
apg_plan_mgmt.reload()
```
**Rückgabewert**
Keine.
**Parameter**
Keine.
**Nutzungshinweise**
Rufen Sie `reload` in den folgenden Fällen auf:
+ Verwenden Sie diesen Parameter, um den gemeinsam genutzten Speicher eines schreibgeschützten Replica sofort zu aktualisieren. So müssen Sie nicht warten, bis neue Pläne an das Replica übermittelt werden.
+ Verwenden Sie diesen Parameter auch nach dem Import verwalteter Pläne.
## apg\$1plan\$1mgmt.set\$1plan\$1enabled
Aktivieren oder deaktivieren Sie einen verwalteten Plan.
**Syntax**
```
apg_plan_mgmt.set_plan_enabled(
sql_hash,
plan_hash,
[true | false]
)
```
**Rückgabewert**
Gibt bei erfolgreicher Einstellung „0“ und „-1“ zurück, wenn die Einstellung nicht übernommen wurde.
**Parameter**
****
| Parameter | Beschreibung |
| --- | --- |
| sql\$1hash | Die sql\$1hash-ID der verwalteten SQL-Anweisung des Plans. |
| plan\$1hash | Die plan\$1hash-ID des verwalteten Plans. |
| enabled | Boolescher Wert („true“ oder „false“) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Functions.html) |
## apg\$1plan\$1mgmt.set\$1plan\$1status
Legen Sie den Status eines verwalteten Plans auf `Approved`, `Unapproved`, `Rejected` oder `Preferred` fest.
**Syntax**
```
apg_plan_mgmt.set_plan_status(
sql_hash,
plan_hash,
status
)
```
**Rückgabewert**
Gibt bei erfolgreicher Einstellung „0“ und „-1“ zurück, wenn die Einstellung nicht übernommen wurde.
**Parameter**
****
| Parameter | Beschreibung |
| --- | --- |
| sql\$1hash | Die sql\$1hash-ID der verwalteten SQL-Anweisung des Plans. |
| plan\$1hash | Die plan\$1hash-ID des verwalteten Plans. |
| status | Eine Zeichenfolge mit einem der folgenden Werte: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Functions.html) Der von Ihnen verwendete Fall spielt keine Rolle, aber der Statuswert wird in der `apg_plan_mgmt.dba_plans`-Ansicht auf anfängliche Großbuchstaben gesetzt. Weitere Informationen zu diesen Werten finden Sie unter `status`. [Referenz für die apg\$1plan\$1mgmt.dba\$1plans-Ansicht für die Aurora-PostgreSQL-kompatible Edition](AuroraPostgreSQL.Optimize.dba_plans_view_Reference.md) |
## apg\$1plan\$1mgmt.update\$1plans\$1last\$1used
Aktualisiert die Plantabelle sofort mit dem `last_used`-Datum, das im freigegebenen Speicher gespeichert ist.
**Syntax**
```
apg_plan_mgmt.update_plans_last_used()
```
**Rückgabewert**
Keine.
**Parameter**
Keine.
**Nutzungshinweise**
Rufen Sie `update_plans_last_used` auf, um sicherzustellen, dass Abfragen für die Spalte `dba_plans.last_used` die neusten Informationen verwenden. Wenn das `last_used`-Datum nicht sofort aktualisiert wird, aktualisiert ein Hintergrundprozess die Plantabelle einmal stündlich mit dem `last_used`-Datum (standardmäßig).
Wenn beispielsweise eine Anweisung mit einem bestimmten `sql_hash` langsam ausgeführt wird, können Sie feststellen, welche Pläne für diese Anweisung seit Beginn der Leistungsregression ausgeführt wurden. Leeren Sie dazu zuerst die Daten im freigegebenen Speicher auf die Festplatte, damit die `last_used`-Daten aktuell sind, und fragen Sie dann alle Pläne des `sql_hash` der Anweisung mit der Leistungsregression ab. Stellen Sie in der Abfrage sicher, dass das Datum `last_used` größer oder gleich dem Datum ist, an dem die Leistungsregression begann. Die Abfrage identifiziert den Plan oder die Gruppe von Plänen, die für die Leistungsregression verantwortlich sein könnten. Sie können `apg_plan_mgmt.get_explain_plan` verwenden, wenn `explainOptionList` auf `verbose, hashes` gesetzt ist. Sie können `apg_plan_mgmt.evolve_plan_baselines` auch verwenden, um den Plan und alle alternativen Pläne zu analysieren, die möglicherweise eine bessere Leistung erbringen.
Die `update_plans_last_used`-Funktion wirkt sich nur auf die primäre DB-Instance des DB-Clusters aus.
## apg\$1plan\$1mgmt.validate\$1plans
Überprüfen Sie, ob der Optimierer immer noch eine Neuerstellung von Plänen durchführen kann. Der Optimierer überprüft die Pläne `Approved`, `Unapproved` und `Preferred` dahingehend, ob der Plan aktiviert oder deaktiviert ist. `Rejected`-Pläne werden nicht validiert. Alternativ können Sie auch die Funktion `apg_plan_mgmt.validate_plans` verwenden, um ungültige Pläne zu löschen oder zu deaktivieren.
**Syntax**
```
apg_plan_mgmt.validate_plans(
sql_hash,
plan_hash,
action)
apg_plan_mgmt.validate_plans(
action)
```
**Rückgabewert**
Die Anzahl ungültiger Pläne
**Parameter**
****
| Parameter | Beschreibung |
| --- | --- |
| sql\$1hash | Die sql\$1hash-ID der verwalteten SQL-Anweisung des Plans. |
| plan\$1hash | Die plan\$1hash-ID des verwalteten Plans. Verwenden Sie NULL, um alle Pläne für denselben sql\$1hash-ID-Wert anzugeben. |
| action | Die Aktion, die die Funktion für ungültige Pläne ausführen wird. Gültige Zeichenfolgenwerte sind unter anderem die folgenden: Die Groß-/Kleinschreibung muss nicht beachtet werden. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Functions.html) Alle anderen Werte werden wie die leere Zeichenfolge behandelt. |
**Nutzungshinweise**
Mit dem Formular `validate_plans(action)` validieren Sie alle verwalteten Pläne für alle verwalteten Anweisungen in der gesamten `apg_plan_mgmt.dba_plans`-Ansicht.
Nutzen Sie das Formular `validate_plans(sql_hash, plan_hash, action)`, um einen mit `plan_hash` angegebenen verwalteten Plan für eine mit `sql_hash` spezifizierte verwaltete Anweisung zu validieren.
Mit dem Formular `validate_plans(sql_hash, NULL, action)` können Sie alle verwalteten Pläne für die verwaltete Anweisung validieren, die über den Parameter `sql_hash` spezifiziert wird.
# Referenz für die apg\$1plan\$1mgmt.dba\$1plans-Ansicht für die Aurora-PostgreSQL-kompatible Edition
Die `apg_plan_mgmt.dba_plans`-Ansicht enthält die folgenden Spalten mit Planinformationen:
| dba\$1plans-Spalte | Beschreibung |
| --- | --- |
| cardinality\$1error | Hierbei handelt es sich um ein Maß zur Angabe des Fehlers zwischen der geschätzten und der tatsächlichen Kardinalität. Bei der *Kardinalität* handelt es sich um die Anzahl der Tabellenzeilen, die der Plan verarbeiten soll. Bei einem schwerwiegenden Kardinalitätsfehler besteht eine erhöhte Wahrscheinlichkeit dafür, dass ein Plan nicht optimal funktioniert. Diese Spalte ist durch die Funktion [apg\$1plan\$1mgmt.evolve\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.evolve_plan_baselines) ausgefüllt. |
| compatibility\$1level | Dieser Parameter zeigt an, wann ein Abfrageplan zuletzt validiert wurde. In den Aurora-PostgreSQL-Versionen 12.19, 13.15, 14.12, 15.7, 16.3 und höher wird die Aurora-Versionsnummer angezeigt. Bei früheren Versionen wird eine funktionsspezifische Versionsnummer angezeigt. Belassen Sie diesen Parameterwert bei der Standardeinstellung. Aurora PostgreSQL legt diesen Wert automatisch fest und aktualisiert ihn. |
| created\$1by | Hier sehen Sie den authentifizierten Benutzer (session\$1user), der den Plan erstellt hat. |
| enabled | Gibt an, ob der Plan aktiviert oder deaktiviert ist. Alle Pläne sind standardmäßig aktiviert. Sie können Pläne deaktivieren, damit sie nicht vom Optimierer verwendet werden können. Verwenden Sie die Funktion [apg\$1plan\$1mgmt.set\$1plan\$1enabled](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.set_plan_enabled), um diesen Wert zu ändern. |
| environment\$1variables | Gibt Aufschluss über die Parameter und Werte der PostgreSQL Grand Unified Configuration (GUC), die vom Optimierer zum Zeitpunkt der Planerfassung überschrieben wurden. |
| estimated\$1startup\$1cost | Diese Spalte bezieht sich auf die geschätzten Einrichtungskosten für den Optimierer, bevor dieser Tabellenzeilen übermittelt. |
| estimated\$1total\$1cost | Diese Spalte informiert über die geschätzten Optimiererkosten für das Übermitteln der letzten Tabellenzeile. |
| execution\$1time\$1benefit\$1ms | Die Ausführungszeitersparnis (in Millisekunden), die beim Aktivieren des Plans erzielt wird Diese Spalte ist durch die Funktion [apg\$1plan\$1mgmt.evolve\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.evolve_plan_baselines) ausgefüllt. |
| execution\$1time\$1ms | Diese Spalte informiert über die geschätzte Laufzeit des Plans (in Millisekunden). Diese Spalte ist durch die Funktion [apg\$1plan\$1mgmt.evolve\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.evolve_plan_baselines) ausgefüllt. |
| has\$1side\$1effects | Dieser Wert gibt an, dass die SQL-Anweisung eine Data Manipulation Language (DML)- oder eine SELECT-Anweisung ist, die eine Funktion des Typs TEMPORÄR enthält. |
| last\$1used | Dieser Wert wird auf das aktuelle Datum aktualisiert, wenn der Plan ausgeführt wird oder als Minimalkostenplan des Abfrageoptimierers fungiert. Dieser Wert wird im gemeinsam genutzten Speicher gespeichert und regelmäßig an den Datenträger übertragen. Um den größtmöglichen up-to-date Wert zu erhalten, lesen Sie das Datum aus dem gemeinsamen Speicher, indem Sie die Funktion aufrufen, apg\$1plan\$1mgmt.plan\$1last\$1used(sql\$1hash, plan\$1hash) anstatt den last\$1used Wert zu lesen. Weitere Informationen erhalten Sie, indem Sie sich über den [apg\$1plan\$1mgmt.plan\$1retention\$1period](AuroraPostgreSQL.Optimize.Parameters.md#AuroraPostgreSQL.Optimize.Parameters.plan_retention_period)-Parameter informieren. |
| last\$1validated | Informiert über den letzten Zeitpunkt, an dem verifiziert wurde, dass der Plan entweder über die Funktion [apg\$1plan\$1mgmt.validate\$1plans](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.validate_plans) oder die Funktion [apg\$1plan\$1mgmt.evolve\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.evolve_plan_baselines) neu erstellt werden könnte. |
| last\$1verified | Informiert über den letzten Zeitpunkt, an dem ein Plan über die Funktion [apg\$1plan\$1mgmt.evolve\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.evolve_plan_baselines) als bester Plan für die angegebenen Parameter ermittelt wurde. |
| origin | Gibt an, wie der Plan mithilfe des Parameters [apg\$1plan\$1mgmt.capture\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Parameters.md#AuroraPostgreSQL.Optimize.Parameters.capture_plan_baselines) erfasst wurde. Gültige Werte sind unter anderem: `M`: Der Plan wurde mit manueller Planerfassung erfasst. `A`: Der Plan wurde mit automatischer Planerfassung erfasst. |
| param\$1list | Die Parameterwerte, die an die Anweisung gesendet wurden, falls es sich um eine vorbereitete Anweisung handelt. |
| plan\$1created | Datum und Uhrzeit der Planerstellung |
| plan\$1hash | Die ID des Plans. Durch die Kombination von plan\$1hash und sql\$1hash wird ein bestimmter Plan eindeutig identifiziert. |
| plan\$1outline | Eine datenbankunabhängige Darstellung des Plans, mit der der tatsächliche Ausführungsplan neu erstellt wird. Die Operatoren in der Strukturansicht entsprechen den Operatoren in der EXPLAIN-Ausgabe. |
| planning\$1time\$1ms | Die tatsächliche Zeit (in Millisekunden), die zum Ausführen des Planers benötigt wird. Diese Spalte ist durch die Funktion [apg\$1plan\$1mgmt.evolve\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.evolve_plan_baselines) ausgefüllt. |
| queryId | Ein von der Erweiterung pg\$1stat\$1statements berechneter Anweisungs-Hash. Dies ist kein stabiler oder datenbankunabhängiger Bezeichner, da er von Objektbezeichnern () abhängt. OIDs Der Wert wird 0 sein, wenn compute\$1query\$1id bei der Erfassung des Abfrageplans auf off gesetzt ist. |
| sql\$1hash | Ein Hash-Wert des SQL-Anweisungstexts, normalisiert und ohne Literale |
| sql\$1text | Der vollständige Text der SQL-Anweisung. |
| status | Informiert über den Status eines Plans. Der Status bestimmt, wie ein Plan vom Optimierer verwendet wird. Im Folgenden sind Beispiele für gültige Werte aufgeführt. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.dba_plans_view_Reference.html) |
| stmt\$1name | Der Name der SQL-Anweisung innerhalb einer PREPARE-Anweisung. Dieser Wert ist eine leere Zeichenfolge für eine namenlose vorbereitete Anweisung. Dieser Wert beträgt bei nicht vorbereiteten Anweisungen NULL. |
| total\$1time\$1benefit\$1ms | Die gesamte Zeitersparnis (in Millisekunden), die beim Aktivieren dieses Plans erzielt wird. Dieser Wert berücksichtigt sowohl die Planungs- als auch die Ausführungszeit. Ist dieser Wert negativ, sind mit dem Aktivieren dieses Plans Nachteile verbunden. Diese Spalte ist durch die Funktion [apg\$1plan\$1mgmt.evolve\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.evolve_plan_baselines) ausgefüllt. |
# Erweiterte Funktionen der Abfrageplanverwaltung
Im Folgenden finden Sie Informationen zu den erweiterten Funktionen der Abfrageplanverwaltung (Query Plan Management, QPM) in Aurora PostgreSQL:
**Topics**
+ [Erfassung von Aurora-PostgreSQL-Ausführungsplänen](AuroraPostgreSQL.QPM.Plancapturereplicas.md)
+ [Unterstützung der Tabellenpartition](AuroraPostgreSQL.QPM.Partitiontable.md)
# Erfassung von Aurora-PostgreSQL-Ausführungsplänen
QPM (Query Plan Management) ermöglicht es Ihnen, die von Aurora Replicas generierten Abfragepläne zu erfassen und sie in der primären DB-Instance des Aurora-DB-Clusters zu speichern. Sie können die Abfragepläne von allen Aurora Replicas sammeln und eine Reihe optimaler Pläne in einer zentralen persistenten Tabelle auf der primären Instance verwalten. Sie können diese Pläne dann bei Bedarf auf andere Replicas anwenden. Dies hilft Ihnen, die Stabilität der Ausführungspläne aufrechtzuerhalten und die Leistung der Abfragen in den DB-Clustern und Engine-Versionen zu verbessern.
**Topics**
+ [Voraussetzungen](#AuroraPostgreSQL.QPM.Plancapturereplicas.Prereq)
+ [Verwaltung der Planerfassung für Aurora Replicas](#AuroraPostgreSQL.QPM.Plancapturereplicas.managing)
+ [Fehlerbehebung](#AuroraPostgreSQL.QPM.Plancapturereplicas.Troubleshooting)
## Voraussetzungen
**Aktivieren Sie `capture_plan_baselines parameter` in Aurora Replica** – Setzen Sie den `capture_plan_baselines`-Parameter auf automatisch oder manuell, um Pläne in Aurora Replicas zu erfassen. Weitere Informationen finden Sie unter [apg\$1plan\$1mgmt.capture\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Parameters.md#AuroraPostgreSQL.Optimize.Parameters.capture_plan_baselines).
**Installieren Sie die postgres\$1fdw-Erweiterung** – Sie müssen die `postgres_fdw`-Foreign-Data-Wrapper-Erweiterung installieren, um Pläne in Aurora Replicas zu erfassen. Führen Sie den folgenden Befehl in jeder Datenbank aus, um die Erweiterung zu installieren.
```
postgres=> CREATE EXTENSION IF NOT EXISTS postgres_fdw;
```
## Verwaltung der Planerfassung für Aurora Replicas
**Aktivierung der Planerfassung für Aurora Replicas**
Sie müssen über `rds_superuser`-Berechtigungen verfügen, um die Planerfassung in Aurora Replicas zu erstellen oder zu entfernen. Weitere Informationen zu Benutzerrollen und Berechtigungen finden Sie unter [PostgreSQL-Rollen und -Berechtigungen verstehen](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Roles.html).
Um Pläne zu erfassen, rufen Sie die Funktion apg\$1plan\$1mgmt.create\$1replica\$1plan\$1capture in der Writer-DB-Instance auf, wie im Folgenden dargestellt:
```
postgres=> CALL apg_plan_mgmt.create_replica_plan_capture('endpoint', 'password');
```
+ endpoint – Der Schreiber-Endpunkt von Aurora Global Database oder cluster\$1endpoint bietet Failover-Unterstützung für die Planerfassung in Aurora-Replikaten.
Weitere Informationen zum Schreiber-Endpunkt von Aurora Global Database finden Sie unter [Anzeigen der Endpunkte einer globalen Amazon-Aurora-Datenbank](aurora-global-database-connecting.md#viewing-endpoints).
Weitere Informationen zu Cluster-Endpunkten finden Sie unter [Cluster-Endpunkte für Amazon Aurora](Aurora.Endpoints.Cluster.md).
+ password – Wir empfehlen, bei der Erstellung des Passworts die folgenden Richtlinien zu beachten, um die Sicherheit zu erhöhen:
+ Es muss mindestens 8 Zeichen enthalten.
+ Es muss mindestens einen Großbuchstaben, einen Kleinbuchstaben und eine Ziffer enthalten.
+ Es muss mindestens ein Sonderzeichen (`?`, `!`, `#`, `<`, `>`, `*` usw.) enthalten.
**Anmerkung**
Wenn Sie den Endpunkt, das Passwort oder die Portnummer ändern, müssen Sie `apg_plan_mgmt.create_replica_plan_capture()` erneut mit dem Endpunkt und dem Passwort ausführen, um die Planerfassung erneut zu initialisieren. Andernfalls schlägt die Erfassung von Plänen von Aurora Replicas fehl.
**Deaktivieren der Planerfassung für Aurora Replicas**
Sie können den `capture_plan_baselines`-Parameter in Aurora Replica deaktivieren, indem Sie seinen Wert in der Gruppe Parameter auf `off` setzen.
**Entfernen der Planerfassung für Aurora Replicas**
Sie können die Planerfassung in Aurora Replicas vollständig entfernen, stellen vorher jedoch Folgendes sicher: Rufen Sie `apg_plan_mgmt.remove_replica_plan_capture` wie folgt auf, um Plan Capture zu entfernen:
```
postgres=> CALL apg_plan_mgmt.remove_replica_plan_capture();
```
Sie müssen apg\$1plan\$1mgmt.create\$1replica\$1plan\$1capture () erneut aufrufen, um die Planerfassung in Aurora-Replikaten mit dem Endpunkt und dem Passwort zu aktivieren.
## Fehlerbehebung
Im Folgenden finden Sie Tipps zur Fehlerbehebung und Workarounds für den Fall, dass der Plan nicht wie erwartet in Aurora Replicas erfasst wird.
+ **Parametereinstellungen** – Prüfen Sie, ob der `capture_plan_baselines`-Parameter auf den richtigen Wert gesetzt ist, um die Planerfassung zu aktivieren.
+ **Die `postgres_fdw`-Erweiterung ist installiert** – Verwenden Sie die folgende Abfrage, um zu überprüfen, ob `postgres_fdw` installiert ist.
```
postgres=> SELECT * FROM pg_extension WHERE extname = 'postgres_fdw'
```
+ **create\$1replica\$1plan\$1capture() wird aufgerufen** – Verwenden Sie den folgenden Befehl, um zu überprüfen, ob die Benutzerzuordnung vorhanden ist. Rufen Sie andernfalls `create_replica_plan_capture()` auf, um das Feature zu initialisieren.
```
postgres=> SELECT * FROM pg_foreign_server WHERE srvname = 'apg_plan_mgmt_writer_foreign_server';
```
+ **Endpunkt und Portnummer** – Überprüfen Sie, ob der Endpunkt und die Portnummer korrekt sind. Wenn diese Werte inkorrekt sind, wird keine Fehlermeldung angezeigt.
Verwenden Sie den folgenden Befehl, um zu überprüfen, ob der Endpunkt in create () verwendet wurde und in welcher Datenbank er sich befindet:
```
postgres=> SELECT srvoptions FROM pg_foreign_server WHERE srvname = 'apg_plan_mgmt_writer_foreign_server';
```
+ **reload()** – Sie müssen apg\$1plan\$1mgmt.reload() aufrufen, nachdem Sie apg\$1plan\$1mgmt.delete\$1plan() in Aurora Replicas aufgerufen haben, damit die Löschfunktion wirksam wird. Dadurch wird sichergestellt, dass die Änderung erfolgreich implementiert wurde.
+ **Passwort** – Sie müssen das Passwort in create\$1replica\$1plan\$1capture() gemäß den genannten Richtlinien eingeben. Andernfalls wird eine Fehlermeldung angezeigt. Weitere Informationen finden Sie unter [Verwaltung der Planerfassung für Aurora Replicas](#AuroraPostgreSQL.QPM.Plancapturereplicas.managing). Verwenden Sie ein anderes Passwort, das den Anforderungen entspricht.
+ **Regionsübergreifende Verbindung** – Die Planerfassung in Aurora Replicas wird auch in der globalen Aurora-Datenbank unterstützt, wo sich Writer-Instance und Aurora Replicas in verschiedenen Regionen befinden können. Stellen Sie sicher, dass Sie den Schreiber-Endpunkt von Aurora Global Database verwenden, um die Konnektivität nach Failover- oder Umstellungsereignissen aufrechtzuerhalten. Weitere Informationen zu den Endpunkten von Aurora Global Database finden Sie unter [Anzeigen der Endpunkte einer Amazon Aurora Global Database](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-connecting.html#viewing-endpoints). Die Writer-Instance und das regionsübergreifende Replikat müssen in der Lage sein, mithilfe von VPC-Peering zu kommunizieren. Weitere Informationen finden Sie unter [VPC-Peering](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html). Wenn ein regionsübergreifendes Failover auftritt, müssen Sie den Endpunkt auf einen neuen primären DB-Cluster-Endpunkt umkonfigurieren.
**Anmerkung**
Wenn Sie einen Cluster-Endpunkt anstelle eines Schreiber-Endpunkts von Aurora Global Database verwenden, müssen Sie den Cluster-Endpunkt aktualisieren, nachdem Sie entweder eine globale Failover- oder Umstellungsoperation durchgeführt haben.
# Unterstützung der Tabellenpartition
Aurora PostgreSQL Query Plan Management (QPM) unterstützt die deklarative Tabellenpartitionierung in den folgenden Versionen:
+ 15.3 und höhere 15-Versionen
+ 14.8 und höhere 14-Versionen
+ 13.11 und höhere 13-Versionen
Weitere Informationen finden Sie unter [Table Partitioning](https://www.postgresql.org/docs/current/ddl-partitioning.html).
**Topics**
+ [Einrichten der Tabellenpartition](#AuroraPostgreSQL.QPM.Partitiontable.setup)
+ [Erfassen von Plänen für die Tabellenpartition](#AuroraPostgreSQL.QPM.Partitiontable.capture)
+ [Erzwingen eines Tabellenpartitionsplans](#AuroraPostgreSQL.QPM.Partitiontable.enforcement)
+ [Namenskonvention](#AuroraPostgreSQL.QPM.Partitiontable.naming.convention)
## Einrichten der Tabellenpartition
Gehen Sie wie folgt vor, um die Tabellenpartition in Aurora PostgreSQL QPM einzurichten:
1. Setzen Sie `apg_plan_mgmt.plan_hash_version` in der DB-Cluster-Parametergruppe auf 3 oder mehr.
1. Navigieren Sie zu einer Datenbank, die Query Plan Management verwendet und Einträge in der Ansicht `apg_plan_mgmt.dba_plans` aufweist.
1. Rufen Sie `apg_plan_mgmt.validate_plans('update_plan_hash')` auf, um den `plan_hash`-Wert in der Plantabelle zu aktualisieren.
1. Wiederholen Sie die Schritte 2 bis 3 für alle Datenbanken, für die Query Plan Management aktiviert ist und die Einträge in `apg_plan_mgmt.dba_plans` aufweisen.
Weitere Informationen zu diesen Parametern finden Sie unter [Parameterreferenz für Aurora-PostgreSQL-Abfrageplanverwaltung](AuroraPostgreSQL.Optimize.Parameters.md).
## Erfassen von Plänen für die Tabellenpartition
In QPM werden verschiedene Pläne durch ihren `plan_hash`-Wert unterschieden. Um die Änderungen am `plan_hash` zu verstehen, müssen Sie zunächst ähnliche Pläne verstehen.
Die Kombination von Zugriffsmethoden, Indexnamen ohne Ziffern und Partitionsnamen ohne Ziffern, die auf der Ebene des Append-Knotens gespeichert sind, muss konstant sein, damit die Pläne als identisch gelten. Die spezifischen Partitionen, auf die in den Plänen zugegriffen wird, sind nicht wichtig. Im folgenden Beispiel wird eine Tabelle `tbl_a` mit 4 Partitionen erstellt.
```
postgres=>create table tbl_a(i int, j int, k int, l int, m int) partition by range(i);
CREATE TABLE
postgres=>create table tbl_a1 partition of tbl_a for values from (0) to (1000);
CREATE TABLE
postgres=>create table tbl_a2 partition of tbl_a for values from (1001) to (2000);
CREATE TABLE
postgres=>create table tbl_a3 partition of tbl_a for values from (2001) to (3000);
CREATE TABLE
postgres=>create table tbl_a4 partition of tbl_a for values from (3001) to (4000);
CREATE TABLE
postgres=>create index t_i on tbl_a using btree (i);
CREATE INDEX
postgres=>create index t_j on tbl_a using btree (j);
CREATE INDEX
postgres=>create index t_k on tbl_a using btree (k);
CREATE INDEX
```
Die folgenden Pläne gelten als identisch, da unabhängig von der Anzahl der Partitionen, nach denen die Abfrage sucht, eine einzige Scanmethode zum Scannen von `tbl_a` verwendet wird.
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 999 and j < 9910 and k > 50;
QUERY PLAN
-------------------------------------------------------------------
Seq Scan on tbl_a1 tbl_a
Filter: ((i >= 990) AND (i <= 999) AND (j < 9910) AND (k > 50))
SQL Hash: 1553185667, Plan Hash: -694232056
(3 rows)
```
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 1100 and j < 9910 and k > 50;
QUERY PLAN
-------------------------------------------------------------------
Append
-> Seq Scan on tbl_a1 tbl_a_1
Filter: ((i >= 990) AND (i <= 1100) AND (j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 1100) AND (j < 9910) AND (k > 50))
SQL Hash: 1553185667, Plan Hash: -694232056
(6 rows)
```
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 2100 and j < 9910 and k > 50;
QUERY PLAN
--------------------------------------------------------------------------
Append
-> Seq Scan on tbl_a1 tbl_a_1
Filter: ((i >= 990) AND (i <= 2100) AND (j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 2100) AND (j < 9910) AND (k > 50))
-> Seq Scan on tbl_a3 tbl_a_3
Filter: ((i >= 990) AND (i <= 2100) AND (j < 9910) AND (k > 50))
SQL Hash: 1553185667, Plan Hash: -694232056
(8 rows)
```
Die folgenden 3 Pläne gelten ebenfalls als identisch, da auf der übergeordneten Ebene die Zugriffsmethoden, Indexnamen ohne Ziffern und Partitionsnamen ohne Ziffern `SeqScan tbl_a` und `IndexScan (i_idx) tbl_a` lauten.
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 1100 and j < 9910 and k > 50;
QUERY PLAN
--------------------------------------------------------------------------
Append
-> Seq Scan on tbl_a1 tbl_a_1
Filter: ((i >= 990) AND (i <= 1100) AND (j < 9910) AND (k > 50))
-> Index Scan using tbl_a2_i_idx on tbl_a2 tbl_a_2
Index Cond: ((i >= 990) AND (i <= 1100))
Filter: ((j < 9910) AND (k > 50))
SQL Hash: 1553185667, Plan Hash: -993736942
(7 rows)
```
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 2100 and j < 9910 and k > 50;
QUERY PLAN
--------------------------------------------------------------------------
Append
-> Index Scan using tbl_a1_i_idx on tbl_a1 tbl_a_1
Index Cond: ((i >= 990) AND (i <= 2100))
Filter: ((j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 2100) AND (j < 9910) AND (k > 50))
-> Index Scan using tbl_a3_i_idx on tbl_a3 tbl_a_3
Index Cond: ((i >= 990) AND (i <= 2100))
Filter: ((j < 9910) AND (k > 50))
SQL Hash: 1553185667, Plan Hash: -993736942
(10 rows)
```
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 3100 and j < 9910 and k > 50;
QUERY PLAN
--------------------------------------------------------------------------
Append
-> Seq Scan on tbl_a1 tbl_a_1
Filter: ((i >= 990) AND (i <= 3100) AND (j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 3100) AND (j < 9910) AND (k > 50))
-> Seq Scan on tbl_a3 tbl_a_3
Filter: ((i >= 990) AND (i <= 3100) AND (j < 9910) AND (k > 50))
-> Index Scan using tbl_a4_i_idx on tbl_a4 tbl_a_4
Index Cond: ((i >= 990) AND (i <= 3100))
Filter: ((j < 9910) AND (k > 50))
SQL Hash: 1553185667, Plan Hash: -993736942
(11 rows)
```
Unabhängig von der unterschiedlichen Reihenfolge und Anzahl der Vorkommen in untergeordneten Partitionen sind die Zugriffsmethoden, Indexnamen ohne Ziffern und Partitionsnamen ohne Ziffern auf der übergeordneten Ebene für jeden der oben aufgeführten Pläne konstant.
Die Pläne würden jedoch nicht als identisch gelten, wenn eine der folgenden Bedingungen erfüllt ist:
+ Es werden zusätzliche Zugriffsmethoden im Plan verwendet.
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 2100 and j < 9910 and k > 50;
QUERY PLAN
--------------------------------------------------------------------------
Append
-> Seq Scan on tbl_a1 tbl_a_1
Filter: ((i >= 990) AND (i <= 2100) AND (j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 2100) AND (j < 9910) AND (k > 50))
-> Bitmap Heap Scan on tbl_a3 tbl_a_3
Recheck Cond: ((i >= 990) AND (i <= 2100))
Filter: ((j < 9910) AND (k > 50))
-> Bitmap Index Scan on tbl_a3_i_idx
Index Cond: ((i >= 990) AND (i <= 2100))
SQL Hash: 1553185667, Plan Hash: 1134525070
(11 rows)
```
+ Eine der im Plan enthaltenen Zugriffsmethoden wird nicht mehr verwendet.
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 1100 and j < 9910 and k > 50;
QUERY PLAN
--------------------------------------------------------------------------
Append
-> Seq Scan on tbl_a1 tbl_a_1
Filter: ((i >= 990) AND (i <= 1100) AND (j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 1100) AND (j < 9910) AND (k > 50))
SQL Hash: 1553185667, Plan Hash: -694232056
(6 rows)
```
+ Der einer Indexmethode zugeordnete Index wird geändert.
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 1100 and j < 9910 and k > 50;
QUERY PLAN
--------------------------------------------------------------------------
Append
-> Seq Scan on tbl_a1 tbl_a_1
Filter: ((i >= 990) AND (i <= 1100) AND (j < 9910) AND (k > 50))
-> Index Scan using tbl_a2_j_idx on tbl_a2 tbl_a_2
Index Cond: (j < 9910)
Filter: ((i >= 990) AND (i <= 1100) AND (k > 50))
SQL Hash: 1553185667, Plan Hash: -993343726
(7 rows)
```
## Erzwingen eines Tabellenpartitionsplans
Genehmigte Pläne für partitionierte Tabellen werden durch Positionskorrespondenz erzwungen. Die Pläne sind nicht spezifisch für die Partitionen und können für andere Partitionen als die in der ursprünglichen Abfrage referenzierten Pläne erzwungen werden. Pläne können auch für Abfragen erzwungen werden, die auf eine andere Anzahl von Partitionen als die ursprünglich genehmigte Gliederung zugreifen.
Beispiel: Die genehmigte Gliederung gilt für den folgenden Plan:
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 2100 and j < 9910 and k > 50;
QUERY PLAN
--------------------------------------------------------------------------
Append
-> Index Scan using tbl_a1_i_idx on tbl_a1 tbl_a_1
Index Cond: ((i >= 990) AND (i <= 2100))
Filter: ((j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 2100) AND (j < 9910) AND (k > 50))
-> Index Scan using tbl_a3_i_idx on tbl_a3 tbl_a_3
Index Cond: ((i >= 990) AND (i <= 2100))
Filter: ((j < 9910) AND (k > 50))
SQL Hash: 1553185667, Plan Hash: -993736942
(10 rows)
```
Dann kann dieser Plan auch für SQL-Abfragen erzwungen werden, die 2, 4 oder mehr Partitionen referenzieren. Die möglichen Pläne, die sich aus diesen Szenarien für den Zugriff auf 2 und 4 Partitionen ergeben könnten, sind folgende:
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 1100 and j < 9910 and k > 50;
QUERY PLAN
----------------------------------------------------------------------------------
Append
-> Index Scan using tbl_a1_i_idx on tbl_a1 tbl_a_1
Index Cond: ((i >= 990) AND (i <= 1100))
Filter: ((j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 1100) AND (j < 9910) AND (k > 50))
Note: An Approved plan was used instead of the minimum cost plan.
SQL Hash: 1553185667, Plan Hash: -993736942, Minimum Cost Plan Hash: -1873216041
(8 rows)
```
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 3100 and j < 9910 and k > 50;
QUERY PLAN
--------------------------------------------------------------------------
Append
-> Index Scan using tbl_a1_i_idx on tbl_a1 tbl_a_1
Index Cond: ((i >= 990) AND (i <= 3100))
Filter: ((j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 3100) AND (j < 9910) AND (k > 50))
-> Index Scan using tbl_a3_i_idx on tbl_a3 tbl_a_3
Index Cond: ((i >= 990) AND (i <= 3100))
Filter: ((j < 9910) AND (k > 50))
-> Seq Scan on tbl_a4 tbl_a_4
Filter: ((i >= 990) AND (i <= 3100) AND (j < 9910) AND (k > 50))
Note: An Approved plan was used instead of the minimum cost plan.
SQL Hash: 1553185667, Plan Hash: -993736942, Minimum Cost Plan Hash: -1873216041
(12 rows)
```
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 3100 and j < 9910 and k > 50;
QUERY PLAN
----------------------------------------------------------------------------------
Append
-> Index Scan using tbl_a1_i_idx on tbl_a1 tbl_a_1
Index Cond: ((i >= 990) AND (i <= 3100))
Filter: ((j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 3100) AND (j < 9910) AND (k > 50))
-> Index Scan using tbl_a3_i_idx on tbl_a3 tbl_a_3
Index Cond: ((i >= 990) AND (i <= 3100))
Filter: ((j < 9910) AND (k > 50))
-> Index Scan using tbl_a4_i_idx on tbl_a4 tbl_a_4
Index Cond: ((i >= 990) AND (i <= 3100))
Filter: ((j < 9910) AND (k > 50))
Note: An Approved plan was used instead of the minimum cost plan.
SQL Hash: 1553185667, Plan Hash: -993736942, Minimum Cost Plan Hash: -1873216041
(14 rows)
```
Betrachten Sie einen anderen genehmigten Plan mit unterschiedlichen Zugriffsmethoden für jede Partition:
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 2100 and j < 9910 and k > 50;
QUERY PLAN
--------------------------------------------------------------------------
Append
-> Index Scan using tbl_a1_i_idx on tbl_a1 tbl_a_1
Index Cond: ((i >= 990) AND (i <= 2100))
Filter: ((j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 2100) AND (j < 9910) AND (k > 50))
-> Bitmap Heap Scan on tbl_a3 tbl_a_3
Recheck Cond: ((i >= 990) AND (i <= 2100))
Filter: ((j < 9910) AND (k > 50))
-> Bitmap Index Scan on tbl_a3_i_idx
Index Cond: ((i >= 990) AND (i <= 2100))
SQL Hash: 1553185667, Plan Hash: 2032136998
(12 rows)
```
In diesem Fall würde jeder Plan, der aus zwei Partitionen liest, nicht erzwungen werden. Solange nicht alle Kombinationen (Zugriffsmethode, Indexname) aus dem genehmigten Plan verwendet werden können, kann der Plan nicht erzwungen werden. Die folgenden Pläne haben beispielsweise unterschiedliche Plan-Hashes und der genehmigte Plan kann in diesen Fällen nicht erzwungen werden:
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 1900 and j < 9910 and k > 50;
QUERY PLAN
-------------------------------------------------------------------------
Append
-> Bitmap Heap Scan on tbl_a1 tbl_a_1
Recheck Cond: ((i >= 990) AND (i <= 1900))
Filter: ((j < 9910) AND (k > 50))
-> Bitmap Index Scan on tbl_a1_i_idx
Index Cond: ((i >= 990) AND (i <= 1900))
-> Bitmap Heap Scan on tbl_a2 tbl_a_2
Recheck Cond: ((i >= 990) AND (i <= 1900))
Filter: ((j < 9910) AND (k > 50))
-> Bitmap Index Scan on tbl_a2_i_idx
Index Cond: ((i >= 990) AND (i <= 1900))
Note: This is not an Approved plan. No usable Approved plan was found.
SQL Hash: 1553185667, Plan Hash: -568647260
(13 rows)
```
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 1900 and j < 9910 and k > 50;
QUERY PLAN
--------------------------------------------------------------------------
Append
-> Index Scan using tbl_a1_i_idx on tbl_a1 tbl_a_1
Index Cond: ((i >= 990) AND (i <= 1900))
Filter: ((j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 1900) AND (j < 9910) AND (k > 50))
Note: This is not an Approved plan. No usable Approved plan was found.
SQL Hash: 1553185667, Plan Hash: -496793743
(8 rows)
```
## Namenskonvention
Damit QPM einen Plan mit deklarativ partitionierten Tabellen durchsetzen kann, müssen Sie bestimmte Benennungsregeln für übergeordnete Tabellen, Tabellenpartitionen und Indizes befolgen:
+ **Namen von übergeordneten Tabellen** – Diese Namen müssen sich durch alphanumerische oder Sonderzeichen und nicht nur durch Ziffern unterscheiden. Beispielsweise sind tA, tB und tC zulässige Namen für separate übergeordnete Tabellen, t1, t2 und t3 hingegen nicht.
+ **Namen einzelner Partitionstabellen** – Partitionen derselben übergeordneten Tabelle dürfen sich nur durch Ziffern voneinander unterscheiden. Zulässige Partitionsnamen von tA könnten beispielsweise tA1, tA2 oder t1A, t2A oder auch mehrere Ziffern sein.
Alle anderen Unterschiede (Buchstaben, Sonderzeichen) garantieren das Erzwingen des Plans nicht.
+ **Indexnamen** – Stellen Sie in der Hierarchie der Partitionstabellen sicher, dass alle Indizes eindeutige Namen haben. Das bedeutet, dass die nicht numerischen Teile der Namen unterschiedlich sein müssen. Wenn Sie beispielsweise eine partitionierte Tabelle namens `tA` mit einem Index namens `tA_col1_idx1` haben, können Sie keinen anderen Index namens `tA_col1_idx2` haben. Sie können jedoch einen Index namens `tA_a_col1_idx2` haben, da der nicht numerische Teil des Namens eindeutig ist. Diese Regel gilt für Indizes, die sowohl für die übergeordnete Tabelle als auch für einzelne Partitionstabellen erstellt wurden.
Wenn die oben genannten Namenskonventionen nicht eingehalten werden, kann dies dazu führen, dass die genehmigten Pläne nicht erzwungen werden. Das folgende Beispiel veranschaulicht ein fehlgeschlagenes Erzwingen:
```
postgres=>create table t1(i int, j int, k int, l int, m int) partition by range(i);
CREATE TABLE
postgres=>create table t1a partition of t1 for values from (0) to (1000);
CREATE TABLE
postgres=>create table t1b partition of t1 for values from (1001) to (2000);
CREATE TABLE
postgres=>SET apg_plan_mgmt.capture_plan_baselines TO 'manual';
SET
postgres=>explain (hashes true, costs false) select count(*) from t1 where i > 0;
QUERY PLAN
--------------------------------------------------------------------------
Aggregate
-> Append
-> Seq Scan on t1a t1_1
Filter: (i > 0)
-> Seq Scan on t1b t1_2
Filter: (i > 0)
SQL Hash: -1720232281, Plan Hash: -1010664377
(7 rows)
```
```
postgres=>SET apg_plan_mgmt.use_plan_baselines TO 'on';
SET
postgres=>explain (hashes true, costs false) select count(*) from t1 where i > 1000;
QUERY PLAN
-------------------------------------------------------------------------
Aggregate
-> Seq Scan on t1b t1
Filter: (i > 1000)
Note: This is not an Approved plan. No usable Approved plan was found.
SQL Hash: -1720232281, Plan Hash: 335531806
(5 rows)
```
Auch wenn die beiden Pläne identisch erscheinen mögen, unterscheiden sich ihre `Plan Hash`-Werte aufgrund der Namen der untergeordneten Tabellen. Die Tabellennamen unterscheiden sich nach Alphazeichen und nicht nur nach Ziffern, was dazu führt, dass die Durchsetzung fehlschlägt.