Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Lock:Relation
L’evento `Lock:Relation` si verifica quando una query è in attesa di acquisire un blocco su una tabella o vista (relazione) attualmente bloccata da un’altra transazione.
**Topics**
+ [Versioni del motore supportate](#wait-event.lockrelation.context.supported)
+ [Contesto](#wait-event.lockrelation.context)
+ [Probabili cause di aumento delle attese](#wait-event.lockrelation.causes)
+ [Azioni](#wait-event.lockrelation.actions)
## Versioni del motore supportate
Queste informazioni relative all'evento di attesa sono supportate per tutte le versioni di RDS per PostgreSQL.
## Contesto
La maggior parte dei comandi PostgreSQL utilizza implicitamente i blocchi per controllare l’accesso simultaneo ai dati nelle tabelle. È inoltre possibile utilizzare questi blocchi esplicitamente nel codice dell’applicazione con il comando `LOCK`. Molte modalità di blocco non sono compatibili tra loro e possono bloccare le transazioni quando cercano di accedere allo stesso oggetto. Quando ciò accade, RDS per PostgreSQL genera un evento `Lock:Relation`. Di seguito sono riportati alcuni esempi comuni:
+ Blocchi esclusivi come `ACCESS EXCLUSIVE` possono bloccare tutti gli accessi simultanei. Le operazioni DDL (Data Definition Language) come `DROP TABLE`, `TRUNCATE`, `VACUUM FULL`, e `CLUSTER` acquisiscono implicitamente i blocchi `ACCESS EXCLUSIVE`. `ACCESS EXCLUSIVE` è anche la modalità di blocco predefinita per le istruzioni `LOCK TABLE` che non specificano esplicitamente una modalità.
+ L’uso di `CREATE INDEX (without CONCURRENT)` su una tabella è in conflitto con le istruzioni DML (Data Manipulation Language) `UPDATE`, `DELETE`, e `INSERT`, che acquisiscono i blocchi `ROW EXCLUSIVE`.
Per ulteriori informazioni sui blocchi a livello di tabella e sulle modalità di blocco in conflitto, vedere [Blocco esplicito](https://www.postgresql.org/docs/13/explicit-locking.html) nella documentazione di PostgreSQL.
Il blocco di query e transazioni in genere si sblocca in uno dei seguenti modi:
+ Query di blocco: l’applicazione può annullare la query o l’utente può terminare il processo. Il motore può anche forzare la fine della query a causa del timeout dell’istruzione di una sessione o di un meccanismo di rilevamento del deadlock.
+ Blocco della transazione: una transazione smette di bloccarsi quando esegue un’istruzione `ROLLBACK` o `COMMIT`. I rollback si verificano automaticamente anche quando le sessioni vengono disconnesse da un client o da problemi di rete o terminano. Le sessioni possono essere terminate quando il motore di database è spento, quando il sistema è fuori memoria e così via.
## Probabili cause di aumento delle attese
Quando l’evento `Lock:Relation` si verifica più frequentemente del normale, può indicare un problema di prestazioni. Le cause tipiche sono:
**Sessioni simultanee aumentate con blocchi di tabella in conflitto**
Potrebbe esserci un aumento del numero di sessioni simultanee con query che inseriscono o aggiornano la stessa tabella.
**Operazioni di manutenzione**
Le operazioni di manutenzione Health come `VACUUM` e `ANALYZE` possono aumentare significativamente il numero di blocchi in conflitto. `VACUUM FULL` acquisisce un blocco `ACCESS EXCLUSIVE`, e `ANALYSE` acquisisce un blocco `SHARE UPDATE EXCLUSIVE`. Entrambi i tipi di blocchi possono causare un evento di attesa `Lock:Relation`. Le operazioni di manutenzione dei dati delle applicazioni, come l’aggiornamento di una vista materializzata, possono anche aumentare le query e le transazioni bloccate.
**Blocchi sulle istanze del lettore**
È possibile che si verifichi un conflitto tra i blocchi di relazione tenuti dallo scrittore e dai lettori. Attualmente solo i blocchi di relazione `ACCESS EXCLUSIVE` vengono replicati nelle istanze del lettore. Tuttavia, il blocco di relazione `ACCESS EXCLUSIVE` sarà in conflitto con qualsiasi blocco di relazione `ACCESS SHARE` tenuto dal lettore. Questo conflitto può causare un aumento degli eventi di attesa della relazione di blocco sul lettore.
## Azioni
Consigliamo azioni diverse a seconda delle cause dell’evento di attesa.
**Topics**
+ [Riduci l’impatto del blocco delle istruzioni SQL](#wait-event.lockrelation.actions.reduce-blocks)
+ [Riduci al minimo l’effetto delle operazioni di manutenzione](#wait-event.lockrelation.actions.maintenance)
### Riduci l’impatto del blocco delle istruzioni SQL
Per ridurre l’impatto del blocco delle istruzioni SQL, modificare il codice dell’applicazione laddove possibile. Di seguito sono riportate due tecniche comuni per ridurre i blocchi:
+ Utilizzo dell’opzione `NOWAIT` — Alcuni comandi SQL, come le istruzioni `SELECT` e `LOCK`, supportano questa opzione. La direttiva `NOWAIT` annulla la query richiedente il blocco se il blocco non può essere acquisito immediatamente. Questa tecnica può aiutare a impedire che una sessione di blocco provochi un accumulo di sessioni bloccate dietro di essa.
Ad esempio: si supponga che la transazione A sia in attesa di un blocco trattenuto dalla transazione B. Ora, se B richiede un blocco su una tabella bloccata dalla transazione C, la transazione A potrebbe essere bloccata fino al completamento della transazione C. Ma se la transazione B utilizza un `NOWAIT` quando richiede il blocco su C, può fallire rapidamente e garantire che la transazione A non debba attendere indefinitamente.
+ Utilizza `SET lock_timeout` — Imposta un valore `lock_timeout` per limitare il tempo in cui un'istruzione SQL attende di acquisire un blocco su una relazione. Se il blocco non viene acquisito entro il timeout specificato, la transazione che richiede il blocco viene annullata. Impostare questo valore a livello di sessione.
### Riduci al minimo l’effetto delle operazioni di manutenzione
Operazioni di manutenzione come `VACUUM` e `ANALYZE` sono importanti. Si consiglia di non spegnerli qualora vengano trovati eventi di attesa `Lock:Relation` relativi a queste operazioni di manutenzione. I seguenti approcci possono ridurre al minimo l’effetto di queste operazioni:
+ Eseguire manualmente le operazioni di manutenzione durante le ore non di punta.
+ Per ridurre le attese `Lock:Relation` causate da attività autovacuum, eseguire qualsiasi sintonizzazione automatica necessaria. Per informazioni sulla sintonizzazione autovacuum, fai riferimento a [Funzionamento di PostgreSQL Autovacuum in Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html) nella *Guida per l’utente di Amazon RDS*.