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. # Lock:Relation Das `Lock:Relation`-Ereignis tritt ein, wenn eine Abfrage darauf wartet, eine Sperre für eine Tabelle oder Sicht (Relation) zu erhalten, die derzeit von einer anderen Transaktion gesperrt ist. **Topics** + [Unterstützte Engine-Versionen](#apg-waits.lockrelation.context.supported) + [Kontext](#apg-waits.lockrelation.context) + [Wahrscheinliche Ursachen für erhöhte Wartezeiten](#apg-waits.lockrelation.causes) + [Aktionen](#apg-waits.lockrelation.actions) ## Unterstützte Engine-Versionen Diese Warteereignisinformationen werden für alle Versionen von Aurora PostgreSQL unterstützt. ## Kontext Die meisten PostgreSQL-Befehle verwenden implizit Sperren, um den gleichzeitigen Zugriff auf Daten in Tabellen zu steuern. Sie können diese Sperren auch explizit mit dem `LOCK`-Befehl in Ihrem Anwendungscode verwenden. Viele Sperrmodi sind nicht miteinander kompatibel und können Transaktionen blockieren, wenn sie versuchen, auf dasselbe Objekt zuzugreifen. In diesem Fall generiert Aurora PostgreSQL ein `Lock:Relation`-Ereignis. Einige gängige Beispiele sind die folgenden: + Exklusive Sperren wie `ACCESS EXCLUSIVE` können alle gleichzeitigen Zugriffe blockieren. Vorgänge in der Datendefinitionssprache (DDL) wie `DROP TABLE`, `TRUNCATE`, `VACUUM FULL` und `CLUSTER` erwerben implizit `ACCESS EXCLUSIVE`-Sperren. `ACCESS EXCLUSIVE` ist auch der Standardsperrmodus für `LOCK TABLE`-Anweisungen, die keinen Modus explizit angeben. + Die Verwendung von `CREATE INDEX (without CONCURRENT)` für eine Tabelle steht in Konflikt mit den DML-Anweisungen `UPDATE`, `DELETE` und `INSERT`, die `ROW EXCLUSIVE`-Sperren anfordern. Weitere Informationen zu Sperren auf Tabellenebene und widersprüchlichen Sperrmodi finden Sie unter [Explizite Sperren](https://www.postgresql.org/docs/13/explicit-locking.html) in der PostgreSQL-Dokumentation. Blockieren von Abfragen und Transaktionen entsperren in der Regel auf eine der folgenden Arten: + Blockierende Abfrage — Die Anwendung kann die Abfrage abbrechen oder der Benutzer kann den Prozess beenden. Die Engine kann die Abfrage auch aufgrund des Statement-Timeouts einer Sitzung oder eines Deadlock-Erkennungsmechanismus zum Ende zwingen. + Blockieren einer Transaktion – Eine Transaktion stoppt die Blockierung, wenn sie eine `ROLLBACK`- oder `COMMIT`-Anweisung ausführt. Rollbacks erfolgen auch automatisch, wenn Sitzungen von einem Client oder durch Netzwerkprobleme getrennt oder beendet werden. Sitzungen können beendet werden, wenn das Datenbank-Engine heruntergefahren wird, wenn das System keinen Arbeitsspeicher mehr hat usw. ## Wahrscheinliche Ursachen für erhöhte Wartezeiten Wenn das `Lock:Relation`-Ereignis häufiger als normal auftritt, kann dies auf ein Leistungsproblem hinweisen. Zu den typischen Ursachen zählen auch die Folgenden: **Gleichzeitige Sitzungen mit widersprüchlichen Tabellensperren erhöht** Es kann zu einer Zunahme der Anzahl gleichzeitiger Sitzungen mit Abfragen kommen, die dieselbe Tabelle mit widersprüchlichen Sperrmodi sperren. **Wartungsvorgänge** Zustandswartungsvorgänge wie `VACUUM` und `ANALYZE` können die Anzahl widersprüchlicher Sperren erheblich erhöhen. `VACUUM FULL` erhält eine `ACCESS EXCLUSIVE`-Sperre und `ANALYZE` erhält eine `SHARE UPDATE EXCLUSIVE`-Sperre. Beide Arten von Sperren können ein `Lock:Relation`-Wait-Ereignis verursachen. Wartungsvorgänge für Anwendungsdaten wie das Aktualisieren einer materialisierten Ansicht können auch blockierte Abfragen und Transaktionen erhöhen. **Sperrt bei Reader-In** Es könnte ein Konflikt zwischen den Beziehungssperren bestehen, die vom Writer und den Readern gehalten werden. Derzeit werden nur `ACCESS EXCLUSIVE`-Beziehungssperren auf Reader-Instances repliziert. Allerdings gerät die `ACCESS EXCLUSIVE`-Beziehungssperre in Konflikt mit jeder `ACCESS SHARE`-Beziehungssperre, die vom Reader gehalten wird. Dies kann zu einer Erhöhung der Warteereignisse für die Sperrbeziehung des Readers führen. ## Aktionen Abhängig von den Ursachen Ihres Warteereignisses empfehlen wir verschiedene Aktionen. **Topics** + [Reduzieren Sie die Auswirkungen der Blockierung von SQL-Anweisungen](#apg-waits.lockrelation.actions.reduce-blocks) + [Minimieren Sie die Auswirkungen von Wartungsvorgängen](#apg-waits.lockrelation.actions.maintenance) + [Auf Lesersperren überprüfen](#apg-waits.lockrelation.actions.readerlocks) ### Reduzieren Sie die Auswirkungen der Blockierung von SQL-Anweisungen Um die Auswirkungen des Blockierens von SQL-Anweisungen zu reduzieren, ändern Sie Ihren Anwendungscode nach Möglichkeit. Es folgen zwei gängige Techniken zum Reduzieren von Blöcken: + Verwenden Sie die Option `NOWAIT` – Einige SQL-Befehle, wie z. B. `SELECT`- und `LOCK`-Anweisungen, unterstützen diese Option. Die `NOWAIT`-Direktive bricht die Sperre anfordernde Abfrage ab, wenn die Sperre nicht sofort erworben werden kann. Diese Technik kann dazu beitragen, zu verhindern, dass eine Blockiersitzung eine Anhäufung blockierter Sitzungen dahinter verursacht. Beispiel: Angenommen, Transaktion A wartet auf eine Sperre, die von Transaktion B gehalten wird. Wenn B nun eine Sperre für eine Tabelle anfordert, die durch Transaktion C gesperrt ist, könnte Transaktion A blockiert werden, bis die Transaktion C abgeschlossen ist. Wenn Transaktion B jedoch ein `NOWAIT` verwendet, wenn sie die Sperre für C anfordert, kann sie schnell fehlschlagen und sicherstellen, dass Transaktion A nicht unbegrenzt warten muss. + Verwenden Sie `SET lock_timeout` – Legen Sie einen `lock_timeout`-Wert fest, um die Zeit zu begrenzen, die eine SQL-Anweisung wartet, um eine Sperre für eine Beziehung zu erhalten. Wenn die Sperre nicht innerhalb des angegebenen Timeouts erworben wird, wird die Transaktion, die die Sperre anfordert, abgebrochen. Stellen Sie diesen Wert auf Sitzungsebene ein. ### Minimieren Sie die Auswirkungen von Wartungsvorgängen Wartungsvorgänge wie `VACUUM` und `ANALYZE` sind wichtig. Wir empfehlen, sie nicht zu deaktivieren, da Sie `Lock:Relation`-Warteereignisse im Zusammenhang mit diesen Wartungsvorgängen finden. Die folgenden Ansätze können die Auswirkungen dieser Vorgänge minimieren: + Führen Sie Wartungsvorgänge während außerhalb der Hauptverkehrszeiten manuell aus. + Um `Lock:Relation`-Wartezeiten zu reduzieren, die durch Autovacuum-Aufgaben verursacht werden, führen Sie alle erforderlichen Autovacuum-Optimierungen durch. Informationen zum Optimieren von Autovacuum finden Sie unter [Arbeiten mit PostgreSQL Autovacuum auf Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html) im *Amazon-RDS-Benutzerhandbuch*. ### Auf Lesersperren überprüfen Sie können sehen, wie gleichzeitige Sitzungen bei einem Autor und Lesern Sperren halten, die sich gegenseitig blockieren. Eine Möglichkeit dazu besteht darin, Abfragen auszuführen, die den Sperrtyp und die Beziehung zurückgeben. Die Tabelle enthält eine Abfolge von Abfragen für zwei dieser gleichzeitigen Sitzungen, eine Writer-Sitzung und eine Reader-Sitzung. Der Wiedergabeprozess wartet die Dauer von `max_standby_streaming_delay` ab, bevor die Reader-Abfrage abgebrochen wird. Wie im Beispiel gezeigt, liegt das Sperr-Timeout von 100 ms deutlich unter dem standardmäßigen `max_standby_streaming_delay`-Wert von 30 Sekunden. Für die Sperre tritt ein Timeout auf, bevor ein Problem entsteht. | Sequenzereignis | Sitzung | Befehl oder Ausgabe | | --- | --- | --- | | Dieses legt eine Umgebungsvariable namens READER mit dem angegebenen Wert fest und versucht, mit diesem Endpunkt eine Verbindung zur DB-Instance herzustellen. | Lesersitzung | CLI-Befehl:
export READER=aurorapg2.12345678910.us-west-1.rds.amazonaws.com

psql -h $READER

Ausgabe: ``` psql (15devel, server 10.14) Type "help" for help. ``` | | Dieses legt eine Umgebungsvariable namens WRITER fest und versucht, mit diesem Endpunkt eine Verbindung zur DB-Instance herzustellen. | Writer session | CLI-Befehl:
export WRITER=aurorapg1.12345678910.us-west-1.rds.amazonaws.com
psql -h $WRITER

Ausgabe: ``` psql (15devel, server 10.14) Type "help" for help. ``` | | Die Schreibsitzung erstellt die Tabelle t1 auf der Writer-Instance. | Writer session | PostgreSQL-Abfrage:
postgres=> CREATE TABLE t1(b integer);
CREATE TABLE
| | Wenn es keine widersprüchlichen Abfragen für den Writer gibt, wird sofort die ACCESS EXCLUSIVE-Sperre für den Writer erworben. | Writer session | `ACCESS EXCLUSIVE`-Sperre aktiviert | | Die Lesesitzung legt ein Sperr-Timeout-Intervall von 100 Millisekunden fest. | Lesersitzung | PostgreSQL-Abfrage:
postgres=> SET lock_timeout=100;
SET
| | Die Lesesitzung versucht, Daten aus der Tabelle t1 auf der Reader-Instance zu lesen. | Lesersitzung | PostgreSQL-Abfrage:
postgres=> SELECT * FROM t1;

Beispielausgabe: ``` b --- (0 rows) ``` | | Die Schreibsitzung verwirft t1. | Writer session | PostgreSQL-Abfrage:
postgres=> BEGIN;
BEGIN
postgres=> DROP TABLE t1;
DROP TABLE
postgres=>
| | Die Abfrage ist abgelaufen und wird im Reader abgebrochen. | Lesersitzung | PostgreSQL-Abfrage:
postgres=> SELECT * FROM t1;

Beispielausgabe: ``` ERROR: canceling statement due to lock timeout LINE 1: SELECT * FROM t1; ^ ``` | | Die Lesesitzung fragt `pg_locks` und `pg_stat_activity` ab, um die Fehlerursache zu ermitteln. | Lesersitzung | PostgreSQL-Abfrage:
postgres=> SELECT locktype, relation, mode, backend_type
postgres=> FROM pg_locks l, pg_stat_activity t1
postgres=> WHERE l.pid=t1.pid AND relation = 't1'::regclass::oid;
| | Das Ergebnis zeigt an, dass der `aurora wal replay`-Prozess eine `ACCESS EXCLUSIVE`-Sperre für Tabelle t1 hält. | Lesersitzung | Abfrageergebnis:
 locktype | relation |        mode         |   backend_type
----------+----------+---------------------+-------------------
 relation | 68628525 | AccessExclusiveLock | aurora wal replay
(1 row)
|