Amazon Redshift non supporterà più la creazione di nuovi Python UDFs a partire dalla Patch 198. Python esistente UDFs continuerà a funzionare fino al 30 giugno 2026. Per ulteriori informazioni, consulta il [post del blog](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/). 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à. # Gestione delle operazioni di scrittura simultanee Alcune applicazioni richiedono non solo query e caricamento simultanei, ma anche la possibilità di scrivere simultaneamente su più tabelle o sulla stessa tabella. In questo contesto, *simultaneamente* significa una sovrapposizione non pianificata per l'esecuzione simultanea. Due transazioni sono considerate simultanee se la seconda inizia prima del primo commit. Le operazioni simultanee possono provenire da sessioni diverse controllate dallo stesso utente o da utenti diversi. Amazon Redshift supporta questi tipi di applicazioni consentendo la lettura delle tabelle mentre vengono modificate o caricate in modo incrementale. Le query visualizzano semplicemente l'ultima versione di cui è stato eseguito il commit o la *snapshot* dei dati, invece di attendere che venga eseguito il commit della successiva versione. Se desideri che una determinata query attenda il commit da un'altra operazione di scrittura, è necessario pianificarla di conseguenza. **Nota** Amazon Redshift supporta un comportamento di *commit automatico* di default in cui viene eseguito singolarmente il commit di ogni comando SQL eseguito separatamente. Se si racchiude un set di comandi in un blocco di transazione (definito dalle istruzioni [BEGIN](r_BEGIN.md) e [END](r_END.md)), viene eseguito il commit del blocco come una transazione, quindi è possibile eseguirne il rollback se necessario. Eccezioni a questo comportamento sono i comandi TRUNCATE e VACUUM, che eseguono automaticamente il commit di tutte le modifiche in sospeso apportate nella transazione corrente. Alcuni client SQL eseguono automaticamente i comandi BEGIN e COMMIT, pertanto il client controlla se un gruppo di istruzioni viene eseguito come transazione o se ogni singola istruzione viene eseguita come transazione propria. Controlla la documentazione per l'interfaccia che stai utilizzando. Ad esempio, quando si utilizza il driver JDBC di Amazon Redshift, un'istruzione JDBC `PreparedStatement` con una stringa di query che contiene più comandi SQL (separati da punto e virgola) esegue tutte le istruzioni come una singola transazione. Al contrario, se usi SQL Workbench/J e imposti AUTO COMMIT ON, se esegui più istruzioni, ogni istruzione viene eseguita come transazione a sé stante. I seguenti argomenti descrivono alcuni concetti chiave e casi d'uso che riguardano transazioni, snapshot del database, aggiornamenti e comportamento simultaneo. **Topics** + [Livelli di isolamento in Amazon Redshift](c_serial_isolation.md) + [Scrittura e read/write operazioni](c_write_readwrite.md) + [Esempi di scrittura simultanea](r_Serializable_isolation_example.md) + [Risoluzione degli errori di isolamento serializzabile](c_serial_isolation-serializable-isolation-troubleshooting.md) # Livelli di isolamento in Amazon Redshift Le operazioni di scrittura simultanee sono supportate in Amazon Redshift in modo protettivo utilizzando i blocchi di scrittura sulle tabelle e il principio di *isolamento serializzabile*. L'isolamento serializzabile mantiene l'illusione che una transazione in esecuzione su una tabella sia l'unica transazione in esecuzione su quella tabella. I database Amazon Redshift supportano le operazioni di scrittura simultanee facendo in modo che ogni operazione utilizzi l’ultima versione con commit, o snapshot, dei propri dati all’inizio della transazione. Una snapshot del database viene creata all'interno di una transazione alla prima occorrenza della maggior parte delle istruzioni SELECT, dei comandi DML come COPY, DELETE, INSERT, UPDATE e TRUNCATE e dei seguenti comandi DDL: + ALTER TABLE (per aggiungere o eliminare colonne) + CREATE TABLE + DROP TABLE + TRUNCATE TABLE Nessun’altra transazione è in grado di modificare questo snapshot, il che significa che le transazioni sono isolate l’una dall’altra. In altre parole le transazioni simultanee sono invisibili l’una all’altra e non possono rilevare le modifiche reciproche. Qualsiasi esecuzione simultanea di transazioni deve produrre gli stessi risultati dell’esecuzione seriale di tali transazioni. Se nessuna esecuzione seriale di tali transazioni produce gli stessi risultati, la transazione che esegue un'istruzione che potrebbe interrompere la serializzabilità viene arrestata e ne viene eseguito il rollback. Ad esempio, supponiamo che un utente tenti di eseguire due transazioni simultanee, T1 e T2. L’esecuzione di T1 e T2 deve produrre gli stessi risultati di almeno uno degli scenari seguenti: + T1 e T2 vengono eseguite in serie in questo ordine + T2 e T1 vengono eseguite in serie in questo ordine I livelli di isolamento in Amazon Redshift prevengono i seguenti problemi: + Letture non corrette: una lettura errata si verifica quando una transazione legge dati che non sono ancora stati sottoposti a commit. Ad esempio, supponiamo che la transazione 1 aggiorni una riga. La transazione 2 legge la riga aggiornata prima che T1 esegua il commit dell’aggiornamento. Se T1 esegue il rollback della modifica, T2 ha letto i dati in righe non sottoposte a commit che Amazon Redshift ora ritiene non siano mai esistite. + Letture non ripetibili: una lettura non ripetibile si verifica quando una singola transazione legge due volte la stessa riga, ma riceve dati diversi ogni volta. Ad esempio, supponiamo che la transazione 1 legga una riga. La transazione 2 aggiorna o elimina tale riga ed esegue il commit dell’aggiornamento o dell’eliminazione. Se T1 rilegge la riga, recupera valori di riga diversi o scopre che la riga è stata eliminata. + Fantasmi: un fantasma è una riga che corrisponde ai criteri di ricerca ma inizialmente non viene visualizzata. Ad esempio, supponiamo che la transazione 1 legga un insieme di righe che soddisfano i criteri di ricerca. La transazione 2 genera una nuova riga in un’istruzione UPDATE o INSERT che corrisponde ai criteri di ricerca per T1. Se T1 esegue nuovamente l’istruzione di ricerca, ottiene un set di righe diverso. ## Isolamento SNAPSHOT e SERIALIZABLE In Amazon Redshift gli isolamenti SERIALIZABLE e SNAPSHOT sono due livelli di isolamento serializzabili. L’isolamento SNAPSHOT è il livello di isolamento predefinito per la creazione di cluster con provisioning e gruppi di lavoro serverless e consente di elaborare volumi di dati più grandi rispetto all’isolamento SERIALIZABLE in meno tempo. L’isolamento SERIALIZABLE richiede più tempo, ma implementa vincoli più severi per le transazioni simultanee. Questo livello di isolamento previene problemi come le anomalie di inclinazione della scrittura perché consente il commit di una sola transazione e annulla tutte le altre transazioni simultanee con un errore di violazione dell’isolamento serializzabile. Di seguito è riportato un esempio cronologico di come verrebbero gestite due operazioni di scrittura simultanee quando utilizzi l’isolamento SNAPSHOT. È consentito eseguire il commit dell’istruzione UPDATE di ogni utente in quanto non crea conflitti se tenti di aggiornare le stesse righe. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/redshift/latest/dg/c_serial_isolation.html) Se lo stesso scenario viene eseguito utilizzando l'isolamento serializzabile, Amazon Redshift termina l'utente 2 a causa di una violazione della serializzazione e restituisce un errore `1023`. Per ulteriori informazioni, consulta [Risoluzione degli errori di isolamento serializzabile](c_serial_isolation-serializable-isolation-troubleshooting.md). In questo caso, solo l'utente 1 può eseguire correttamente il commit. ## Considerazioni Quando utilizzi livelli di isolamento in Amazon Redshift, considera quanto segue: + Esegui query sulla vista del catalogo STV\$1DB\$1ISOLATION\$1LEVEL per visualizzare il livello di isolamento utilizzato dal database. Per ulteriori informazioni, consulta [STV\$1DB\$1ISOLATION\$1LEVEL](r_STV_DB_ISOLATION_LEVEL.md). + Esegui query sulla vista PG\$1DATABASE\$1INFO per visualizzare quante transazioni simultanee sono supportate per il database. Per ulteriori informazioni, consulta [PG\$1DATABASE\$1INFO](r_PG_DATABASE_INFO.md). + Le tabelle del catalogo di sistema (PG) e altre tabelle di sistema Amazon Redshift non sono bloccate in una transazione. Di conseguenza, le modifiche agli oggetti di database che derivano dalle operazioni di DDL e TRUNCATE sono visibili al commit in qualsiasi transazione simultanea. Ad esempio, supponiamo che la tabella A esiste nel database quando iniziano due transazioni simultanee, T1 e T2. Supponiamo che T2 restituisca un elenco di tabelle selezionandole dalla tabella catalogo PG\$1TABLES. Quindi T1 rilascia la tabella A ed esegue il commit, quindi T2 elenca nuovamente le tabelle. La tabella A non è più elencata. Se T2 prova a eseguire una query sulla tabella rilasciata, Amazon Redshift restituisce un errore di relazione inesistente. La query di catalogo che restituisce l'elenco di tabelle a T2 o verifica che la tabella A esista non è soggetta alle stesse regole di isolamento delle operazioni sulle tabelle utente. Le transazioni per gli aggiornamenti a queste tabelle vengono eseguite in modalità di isolamento con lettura sottoposta al commit. + Le tabelle del catalogo dei prefissi PG non supportano l’isolamento SNAPSHOT. # Scrittura e read/write operazioni È possibile gestire il comportamento specifico delle operazioni simultanee di scrittura decidendo quando e come eseguire diversi tipi di comandi. I seguenti comandi sono rilevanti a tal riguardo: + Comandi COPY, che eseguono caricamenti (iniziali o incrementali) + Comandi INSERT, che aggiungono una o più righe alla volta + Comandi UPDATE, che modificano le righe esistenti + Comandi DELETE, che rimuovono le righe esistenti Le operazioni COPY e UPDATE sono operazioni di scrittura pura. Le operazioni DELETE e UPDATE sono read/write operazioni (per eliminare o aggiornare le righe, devono prima essere lette). I risultati delle operazioni di scrittura simultanee dipendono dai comandi specifici che vengono eseguiti simultaneamente. Le operazioni di UPDATE e DELETE si comportano in modo diverso perché si basano su una tabella iniziale prima di eseguire qualsiasi scrittura. Dato che le transazioni simultanee sono invisibili l'una all'altra, entrambe UPDATEs DELETEs devono leggere un'istantanea dei dati dell'ultimo commit. Quando il primo UPDATE o DELETE rilascia il suo blocco, il secondo UPDATE o DELETE deve determinare se i dati con cui lavorerà sono potenzialmente obsoleti. Non saranno obsoleti, perché la seconda transazione non ottiene la sua snapshot di dati fino a quando la prima transazione non ha rilasciato il blocco. ## Situazione potenziale di deadlock per le transazioni di scrittura simultanee che coinvolgono più tabelle Quando le transazioni coinvolgono aggiornamenti di più di una tabella, esiste sempre la possibilità di eseguire simultaneamente le transazioni in deadlock quando entrambe cercano di scrivere nello stesso set di tabelle. Una transazione rilascia tutti i blocchi della tabella in una volta sola quando esegue il commit o il rollback. Non rilascia i blocchi uno alla volta. Ad esempio, supponiamo che le transazioni simultanee, T1 e T2 inizino circa nello stesso momento. Se T1 inizia a scrivere nella tabella A e T2 inizia a scrivere nella tabella B, entrambe le transazioni possono procedere senza conflitti. Tuttavia, se T1 inizia a scrivere nella tabella A e ha bisogno di iniziare a scrivere nella tabella B, non è in grado di procedere perché T2 mantiene ancora il blocco su B. Allo stesso modo, se T2 finisce di scrivere nella tabella B e deve iniziare a scrivere nella tabella A, non è in grado di procedere perché T1 mantiene ancora il blocco su A. Poiché nessuna transazione può rilasciare i blocchi finché tutte le operazioni di scrittura non vengono eseguite, l’altra transazione non può procedere. Per evitare questo tipo di deadlock, devi pianificare attentamente le operazioni di scrittura simultanee. Ad esempio, è necessario aggiornare sempre le tabelle nello stesso ordine nelle transazioni e, se si specificano i blocchi, bloccare le tabelle nello stesso ordine prima di eseguire qualsiasi operazione di DML. ## Potenziale situazione di deadlock per le transazioni di scrittura simultanee che coinvolgono una singola tabella In un ambiente di isolamento degli snapshot, possono verificarsi dei deadlock quando esegui transazioni di scrittura simultanee nella stessa tabella. Il deadlock di isolamento degli snapshot si verifica quando le istruzioni INSERT o COPY simultanee condividono un blocco e procedono e un’altra istruzione deve eseguire un’operazione (UPDATE, DELETE, MERGE o DDL) che richiede un blocco esclusivo sulla stessa tabella. Considera il seguente scenario: Transazione 1 (T1): ``` INSERT/COPY INTO table_A; ``` Transazione 2 (T2): ``` INSERT/COPY INTO table_A; table_A ``` Un deadlock può verificarsi quando più transazioni con le operazioni INSERT o COPY vengono eseguite simultaneamente nella stessa tabella con un blocco condiviso e una di queste transazioni segue l’operazione di scrittura pura con un’operazione che richiede un blocco esclusivo, come un’istruzione UPDATE, MERGE, DELETE o DDL. Per evitare il deadlock in queste situazioni, è possibile separare le istruzioni che richiedono un blocco esclusivo (UPDATE/MERGE/DELETE/DDL statements) to a different transaction so that any INSERT/COPY statements can progress simultaneously, and the statements requiring exclusive locks can execute after them. Alternatively, for transactions with INSERT/COPY statements and MERGE/UPDATE/MERGEistruzioni sulla stessa tabella) e includere la logica di ripetizione nelle applicazioni per aggirare potenziali situazioni di stallo. # Esempi di scrittura simultanea I seguenti esempi di pseudo codice dimostrano come, quando vengono eseguite simultaneamente, le transazioni procedono o attendono. ## Esempi di scrittura simultanea con isolamento serializzabile ### Operazioni COPY simultanee nella stessa tabella con isolamento serializzabile La transazione 1 copia le righe nella tabella LISTING: ``` begin; copy listing from ...; end; ``` La transazione 2 inizia simultaneamente in una sessione separata e prova a copiare più righe nella tabella LISTING. La transazione 2 deve attendere che la transazione 1 rilasci il blocco di scrittura sulla tabella LISTING, quindi può procedere. ``` begin; [waits] copy listing from ; end; ``` Lo stesso comportamento si verificherebbe se una o entrambe le transazioni contenessero un comando INSERT anziché un comando COPY. ### Operazioni DELETE simultanee nella stessa tabella con isolamento serializzabile La transazione 1 elimina le righe da una tabella: ``` begin; delete from listing where ...; end; ``` La transazione 2 inizia simultaneamente e prova a eliminare le righe dalla stessa tabella. Avrà esito positivo perché attende il completamento della transazione 1 prima di provare eliminare le righe. ``` begin [waits] delete from listing where ; end; ``` Lo stesso comportamento si verificherebbe se una o entrambe le transazioni contenessero un comando UPDATE nella stessa tabella anziché un comando DELETE. ### Transazioni simultanee con una combinazione di operazioni di lettura e scrittura e isolamento serializzabile In questo esempio, la transazione 1 elimina le righe dalla tabella USERS, ricarica la tabella, esegue una query su COUNT (\$1) e quindi ANALYZE prima di eseguire il commit: ``` begin; delete one row from USERS table; copy ; select count(*) from users; analyze ; end; ``` Allo stesso tempo, inizia la transazione 2. Questa transazione prova a copiare righe aggiuntive nella tabella USERS, ad analizzare la tabella e quindi a eseguire la stessa query su COUNT (\$1) come la prima transazione: ``` begin; [waits] copy users from ...; select count(*) from users; analyze; end; ``` La seconda transazione avrà esito positivo perché deve attendere il completamento della prima. La sua query su COUNT restituirà il conteggio in base al caricamento che ha completato. ## Esempi di scrittura simultanea con isolamento degli snapshot ### Operazioni simultanee di COPY nella stessa tabella con isolamento degli snapshot La transazione 1 copia le righe nella tabella LISTING: ``` begin; copy listing from ...; end; ``` La transazione 2 inizia simultaneamente in una sessione separata e prova a copiare più righe nella tabella LISTING. La transazione 2 può procedere simultaneamente fino a quando una delle due transazioni non deve scrivere i dati nella tabella di destinazione `listing`, dopodiché vengono eseguite in sequenza. ``` begin; //When the COPY statement from T1 needs to write data to the table, the COPY statement from T2 waits. copy listing from ...; end; ``` Lo stesso comportamento si verificherebbe se una o entrambe le transazioni contenessero un comando INSERT anziché un comando COPY. ### Operazioni DELETE simultanee nella stessa tabella con isolamento degli snapshot Le operazioni DELETE o UPDATE simultanee nella stessa tabella con l’isolamento degli snapshot vengono eseguite allo stesso modo delle operazioni eseguite con l’isolamento serializzabile. ### Transazioni simultanee con una combinazione di operazioni di lettura e scrittura e l’isolamento degli snapshot Le transazioni simultanee eseguite con combinazioni di operazioni con l’isolamento degli snapshot vengono eseguite allo stesso modo delle transazioni con combinazioni di operazioni eseguite con l’isolamento serializzabile. # Risoluzione degli errori di isolamento serializzabile ## ERROR:1023 DETAIL: violazione di isolamento serializzabile su una tabella in Redshift Quando Amazon Redshift rileva un errore di isolamento serializzabile, compare un messaggio di errore simile al seguente. ``` ERROR:1023 DETAIL: Serializable isolation violation on table in Redshift ``` Per risolvere un errore di isolamento serializzabile, si possono tentare i seguenti metodi: + Riprovare la transazione annullata. Amazon Redshift ha rilevato che un carico di lavoro simultaneo non è serializzabile. Suggerisce lacune nella logica dell'applicazione, che di solito possono essere risolte provando a eseguire di nuovo la transazione che ha riscontrato l'errore. Se il problema persiste, provare uno degli altri metodi. + Spostare al di fuori della transazione tutte le operazioni che non devono essere nella stessa transazione atomica. Questo metodo si applica quando singole operazioni all'interno di due transazioni fanno riferimento reciprocamente in modo tale da influire sul risultato dell'altra transazione. Ad esempio, ciascuna delle seguenti due sessioni avvia una transazione. ``` Session1_Redshift=# begin; ``` ``` Session2_Redshift=# begin; ``` Il risultato di un'istruzione SELECT in una delle transazioni potrebbe essere compromesso da un'istruzione INSERT nell'altra. In altre parole, si presuppone che le seguenti istruzioni vengano eseguite in serie, in qualunque ordine. In ogni caso, il risultato è che una delle istruzioni SELECT restituisce una riga in più rispetto all'esecuzione simultanea delle transazioni. Non esiste un ordine in cui le operazioni in serie possono produrre lo stesso risultato dell'esecuzione simultanea. Di conseguenza, l'ultima operazione eseguita genera un errore di isolamento serializzabile. ``` Session1_Redshift=# select * from tab1; Session1_Redshift=# insert into tab2 values (1); ``` ``` Session2_Redshift=# insert into tab1 values (1); Session2_Redshift=# select * from tab2; ``` In molti casi il risultato delle istruzioni SELECT non è importante. In altre parole, l'atomicità delle operazioni nelle transazioni non è importante. In questi casi, occorre spostare le istruzioni SELECT al di fuori delle transazioni, come illustrato nei seguenti esempi. ``` Session1_Redshift=# begin; Session1_Redshift=# insert into tab1 values (1) Session1_Redshift=# end; Session1_Redshift=# select * from tab2; ``` ``` Session2_Redshift # select * from tab1; Session2_Redshift=# begin; Session2_Redshift=# insert into tab2 values (1) Session2_Redshift=# end; ``` In questi esempi non ci sono riferimenti reciproci nelle transazioni. Le due istruzioni INSERT non si compromettono reciprocamente. In questi esempi c'è almeno un ordine in cui le transazioni possono essere eseguite in serie producendo lo stesso risultato dell'esecuzione simultanea. Ciò vuol dire che le transazioni sono serializzabili. + Forzare la serializzazione bloccando tutte le tabelle in ciascuna sessione. Il comando [LOCK](r_LOCK.md) blocca le operazioni che possono generare errori di isolamento serializzabile. Quando utilizzi il comando LOCK, ricorda di fare quanto segue: + Bloccare tutte le tabelle interessate dalla transazione, incluse quelle interessate dalle istruzioni SELECT di sola lettura all'interno della transazione. + Bloccare le tabelle nello stesso ordine, indipendentemente da quello in cui vengono eseguite le operazioni. + Bloccare tutte le tabelle all'inizio delle transazione, prima di eseguire qualunque operazione. + Utilizzo dell'isolamento degli snapshot per le transazioni simultanee Utilizza un comando ALTER DATABASE con isolamento degli snapshot. Per ulteriori informazioni sul parametro SNAPSHOT per ALTER DATABASE, consulta [Parameters](r_ALTER_DATABASE.md#r_ALTER_DATABASE-parameters). ## ERROR:1018 DETAIL: la relazione non esiste Quando le operazioni simultanee di Amazon Redshift vengono eseguite in sessioni diverse, viene visualizzato un messaggio di errore simile al seguente. ``` ERROR: 1018 DETAIL: Relation does not exist. ``` Le transazioni in Amazon Redshift seguono l'isolamento degli snapshot. Dopo l'inizio di una transazione, Amazon Redshift acquisisce uno snapshot del database. Per l'intero ciclo di vita della transazione, la transazione opera sullo stato del database come indicato nello snapshot. Se la transazione legge da una tabella che non esiste nello snapshot, genera il messaggio di errore 1018 mostrato in precedenza. Anche quando un'altra transazione simultanea crea una tabella dopo che la transazione ha acquisito lo snapshot, la transazione non può leggere dalla tabella appena creata. Per risolvere questo errore di isolamento della serializzazione, è possibile provare a spostare l'inizio della transazione in un punto in cui si sa che la tabella esiste. Se la tabella viene creata da un'altra transazione, questo punto è almeno dopo il commit della transazione. Inoltre, assicurarsi che non sia stata eseguita alcuna transazione simultanea che potrebbe aver eliminato la tabella. ``` session1 = # BEGIN; session1 = # DROP TABLE A; session1 = # COMMIT; ``` ``` session2 = # BEGIN; ``` ``` session3 = # BEGIN; session3 = # CREATE TABLE A (id INT); session3 = # COMMIT; ``` ``` session2 = # SELECT * FROM A; ``` Di conseguenza, l'ultima operazione eseguita come operazione di lettura da session2 genera un errore di isolamento serializzabile. Questo errore si verifica quando session2 esegue uno snapshot e la tabella è già stata eliminata da una sessione di commit 1. In altre parole, anche se una session3 simultanea ha creato la tabella, session2 non vede la tabella perché non è nello snapshot. Per risolvere questo errore, è possibile ordinare nuovamente le sessioni come segue. ``` session1 = # BEGIN; session1 = # DROP TABLE A; session1 = # COMMIT; ``` ``` session3 = # BEGIN; session3 = # CREATE TABLE A (id INT); session3 = # COMMIT; ``` ``` session2 = # BEGIN; session2 = # SELECT * FROM A; ``` Ora, quando session2 effettua il suo snapshot, per session3 è già stato eseguito il commit e la tabella è nel database. Session2 può leggere dalla tabella senza alcun errore.