Amazon Redshift non supporterà più la creazione di nuove UDF Python a partire dal 1º novembre 2025. Se desideri utilizzare le UDF Python, creale prima di tale data. Le UDF Python esistenti continueranno a funzionare normalmente. Per ulteriori informazioni, consulta il post del blog.

Operazioni di scrittura e lettura/scrittura

È 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:

Le operazioni COPY e UPDATE sono operazioni di scrittura pura. Le operazioni DELETE e UPDATE sono operazioni di lettura/scrittura (per poter essere eliminate o aggiornate, 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; 
            <UPDATE/DELETE/MERGE/DDL statement> 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, puoi separare le istruzioni che richiedono un blocco esclusivo (istruzioni UPDATE/MERGE/DELETE/DDL) in una transazione diversa in modo che tutte le istruzioni INSERT/COPY possano avanzare contemporaneamente e le istruzioni che richiedono blocchi esclusivi possano essere eseguite dopo di esse. In alternativa, per le transazioni con istruzioni INSERT/COPY e istruzioni MERGE/UPDATE/MERGE per la stessa tabella, puoi includere la logica di ripetizione nelle applicazioni per aggirare potenziali deadlock.