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à.
È 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 INSERT sono operazioni di scrittura pura. Le operazioni DELETE e UPDATE sono operazioni di lettura/scrittura (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.
Potenziale situazione di stallo per transazioni di scrittura simultanee che coinvolgono più tabelle
Quando le transazioni comportano l'aggiornamento di più di una tabella, esiste sempre la possibilità che le transazioni eseguite contemporaneamente vengano bloccate quando entrambe tentano di scrivere sullo stesso set di tabelle. Una transazione rilascia tutti i blocchi della tabella contemporaneamente quando esegue il commit o il rollback; non cede 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 sulla tabella A e T2 inizia a scrivere sulla tabella B, entrambe le transazioni possono procedere senza conflitti. Tuttavia, se T1 termina di scrivere sulla tabella A e deve iniziare a scrivere sulla tabella B, non sarà in grado di procedere perché T2 mantiene ancora il blocco su B. Allo stesso modo, se T2 finisce di scrivere sulla tabella B e deve iniziare a scrivere sulla tabella A, non sarà in grado di procedere perché T1 mantiene ancora il blocco su A. Poiché nessuna transazione può rilasciare i blocchi finché non vengono eseguite tutte le operazioni di scrittura, nessuna transazione può continuare. Per evitare questo tipo di deadlock, è necessario pianificare con attenzione 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 stallo per transazioni di scrittura simultanee che coinvolgono una singola tabella
In un ambiente di isolamento basato su snapshot, possono verificarsi dei deadlock quando si eseguono transazioni di scrittura simultanee sulla stessa tabella. Il deadlock di isolamento delle istantanee si verifica quando le istruzioni INSERT o COPY simultanee condividono un blocco e procedono, e un'altra istruzione deve eseguire un'operazione (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_AUn punto morto può verificarsi quando più transazioni con operazioni INSERT o COPY vengono eseguite contemporaneamente sulla stessa tabella con un blocco condiviso e una di queste transazioni segue la sua pura operazione di scrittura 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 (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), puoi includere la logica di riprova nelle tue applicazioni per aggirare potenziali deadlock.
