Amazon Redshift non supporterà più la creazione di nuove UDF Python a partire dalla Patch 198. Le UDF Python esistenti continueranno 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à.
# Scrittura e operazioni read/write
È 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, sia UPDATE che DELETE devono leggere una snapshot 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 la situazione di stallo in queste situazioni, è possibile separare le istruzioni che richiedono un blocco esclusivo (UPDATE/MERGE/DELETE/DDL istruzioni) da una transazione diversa, in modo che tutte INSERT/COPY le istruzioni possano procedere contemporaneamente e le istruzioni che richiedono blocchi esclusivi possano essere eseguite dopo di esse. In alternativa, per le transazioni con INSERT/COPY rendiconti e MERGE/UPDATE/MERGE istruzioni sulla stessa tabella, è possibile includere nelle applicazioni la logica di ripetizione dei tentativi per aggirare potenziali situazioni di stallo.