Transazioni

I componenti script in questa pagina sono utilizzati solo per scopi di navigazione e non alterano in alcun modo il contenuto.

Questo capitolo definisce una transazione e descrive come il database elabora le transazioni.

Introduzione alle transazioni

Una transazione è un'unità di lavoro logica e atomica che contiene una o più istruzioni SQL.

Una transazione raggruppa le istruzioni SQL in modo che siano tutte sottoposte a commit, il che significa che vengono applicate al database o tutte sottoposte a rollback, il che significa che vengono annullate dal database. Oracle AI Database assegna a ogni transazione un identificativo univoco chiamato ID transazione.

Tutte le transazioni Oracle rispettano le proprietà di base di una transazione di database, note come proprietà ACID. ACID è un acronimo dei seguenti:

L'uso delle transazioni è uno dei modi più importanti in cui un sistema di gestione del database differisce da un file system.

Transazione campione: dare e avere conto

Per illustrare il concetto di transazione, considerare un database bancario.

Quando un cliente trasferisce denaro da un conto di risparmio a un conto corrente, la transazione deve consistere in tre operazioni distinte:

Oracle AI Database deve consentire due situazioni. Se tutte e tre le istruzioni SQL mantengono i conti in un saldo adeguato, gli effetti della transazione possono essere applicati al database. Tuttavia, se un problema come fondi insufficienti, numero di conto non valido o errore hardware impedisce il completamento di uno o due dei rendiconti della transazione, il database deve eseguire il rollback dell'intera transazione in modo che il saldo di tutti i conti sia corretto.

Il grafico seguente illustra una transazione bancaria. Il primo estratto conto sottrae $ 500 dal conto di risparmio 3209. Il secondo estratto conto aggiunge $ 500 al conto corrente 3208. La terza istruzione inserisce un record del trasferimento nella tabella delle scritture contabili. Il rendiconto finale esegue il commit della transazione.

Figura 1: Una transazione bancaria

Descrizione dell'illustrazione cncpt025.gif

Struttura di una transazione

Una transazione di database è costituita da una o più istruzioni.

In particolare, una transazione è costituita da uno dei seguenti elementi:

Una transazione ha un inizio e una fine.

Vedere anche:

Inizio di una transazione

Una transazione inizia quando viene rilevata la prima istruzione SQL eseguibile.

Un'istruzione SQL eseguibile è un'istruzione SQL che genera chiamate a un'istanza di database, incluse le istruzioni DML e DDL e l'istruzione SET TRANSACTION.

All'inizio di una transazione, Oracle AI Database assegna la transazione a un segmento annulla dati disponibile per registrare le voci di annullamento per la nuova transazione. Un ID transazione non viene allocato finché non vengono allocati un segmento di annullamento e uno slot tabella di transazioni, che si verifica durante la prima istruzione DML. Un ID transazione è univoco per una transazione e rappresenta il numero di segmento di annullamento, lo slot e il numero di sequenza.

Nell'esempio seguente viene eseguita un'istruzione UPDATE per avviare una transazione e viene eseguita una query su V$TRANSACTION per i dettagli relativi alla transazione.

SQL> UPDATE hr.employees SET salary=salary;

107 rows updated.

SQL> SELECT XID AS "txn id", XIDUSN AS "undo seg", XIDSLOT AS "slot",
  2  XIDSQN AS "seq", STATUS AS "txn status"
  3  FROM V$TRANSACTION;

txn id             undo seg       slot        seq txn status
---------------- ---------- ---------- ---------- ----------------
0600060037000000          6          6         55 ACTIVE

Vedere anche: "Annulla segmenti"

Fine di una transazione

Una transazione può terminare in circostanze diverse.

Una transazione termina quando si verifica una delle seguenti azioni:

Al termine di una transazione, la successiva istruzione SQL eseguibile avvia automaticamente la transazione seguente. L'esempio seguente esegue un UPDATE per avviare una transazione, termina la transazione con un'istruzione ROLLBACK, quindi esegue un UPDATE per avviare una nuova transazione (si noti che gli ID transazione sono diversi):

SQL> UPDATE hr.employees SET salary=salary;
107 rows updated.

SQL> SELECT XID, STATUS FROM V$TRANSACTION;

XID              STATUS
---------------- ----------------
0800090033000000 ACTIVE

SQL> ROLLBACK;

Rollback complete.

SQL> SELECT XID FROM V$TRANSACTION;

no rows selected

SQL> UPDATE hr.employees SET last_name=last_name;

107 rows updated.

SQL> SELECT XID, STATUS FROM V$TRANSACTION;

XID              STATUS
---------------- ----------------
0900050033000000 ACTIVE

Vedere anche:

Atomicità a livello di rendiconto

Oracle AI Database supporta l'atomicità a livello di istruzione, il che significa che un'istruzione SQL è un'unità atomica di lavoro e riesce completamente o non riesce completamente.

Un rendiconto riuscito è diverso da una transazione impegnata. Una singola istruzione SQL viene eseguita correttamente se il database la analizza ed esegue senza errori come unità atomica, come quando tutte le righe vengono modificate in un aggiornamento multiriga.

Se un'istruzione SQL causa un errore durante l'esecuzione, non riesce e quindi viene eseguito il rollback di tutti gli effetti dell'istruzione. Questa operazione è un backback a livello di istruzione. Questa operazione presenta le seguenti caratteristiche:

Un esempio di errore che causa un rollback a livello di istruzione è il tentativo di inserire una chiave primaria duplicata. Le singole istruzioni SQL coinvolte in un deadlock, che è concorrenza per gli stessi dati, possono anche causare un rollback a livello di istruzione. Tuttavia, gli errori rilevati durante l'analisi delle istruzioni SQL, ad esempio un errore di sintassi, non sono stati ancora eseguiti e pertanto non causano un rollback a livello di istruzione.

Vedere anche:

Numeri di modifica sistema (SCN)

Un numero di modifica del sistema (SCN, System Change Number) è un indicatore orario interno logico utilizzato da Oracle AI Database.

Gli SCN ordinano gli eventi che si verificano all'interno del database, necessari per soddisfare le proprietà ACID di una transazione. Oracle AI Database utilizza gli SCN per contrassegnare l'SCN prima del quale tutte le modifiche sono note sul disco in modo che il ripristino evita l'applicazione di redo non necessari. Il database utilizza inoltre SCN per contrassegnare il punto in cui non esiste alcun redo per un set di dati in modo che il recupero possa arrestarsi.

Gli SCN si verificano in una sequenza monotonicamente crescente. Oracle AI Database può utilizzare un SCN come un orologio perché un SCN osservato indica un point-in-time logico e le osservazioni ripetute restituiscono valori uguali o maggiori. Se un evento ha un SCN inferiore a un altro evento, si è verificato in un momento precedente nel database. Diversi eventi possono condividere lo stesso SCN, il che significa che si sono verificati contemporaneamente nel database.

Ogni transazione ha un SCN. Ad esempio, se una transazione aggiorna una riga, il database registra l'SCN in cui si è verificato l'aggiornamento. Altre modifiche in questa transazione hanno lo stesso SCN. Quando si esegue il commit di una transazione, il database registra un SCN per questo commit.

Oracle AI Database incrementa gli SCN nell'area globale del sistema (SGA). Quando una transazione modifica i dati, il database scrive un nuovo SCN nel segmento di dati di annullamento assegnato alla transazione. Il processo di scrittura log scrive quindi il record di commit della transazione immediatamente nel redo log in linea. Il record commit ha l'SCN univoco della transazione. Oracle AI Database utilizza anche gli SCN come parte dei meccanismi di recupero dell'istanza e di recupero dei supporti.

Vedere anche: "Panoramica sul recupero delle istanze"

Panoramica del controllo delle transazioni

Il controllo delle transazioni consente di gestire le modifiche apportate dalle istruzioni DML e di raggruppare le istruzioni DML in transazioni.

In generale, i progettisti di applicazioni si occupano del controllo delle transazioni in modo che il lavoro venga eseguito in unità logiche e che i dati siano coerenti.

Il controllo delle transazioni implica l'utilizzo delle seguenti istruzioni, come descritto in "Transaction Control Statements":

La sessione nella Tabella 13-1 illustra i concetti di base del controllo delle transazioni.

Tabella 1 Controllo transazione

T Sessione Spiegazione
t0 
COMMIT;
 Questa istruzione termina qualsiasi transazione esistente nella sessione.
t1 
SET TRANSACTION NAME 'sal_update';
 Questa istruzione inizia una transazione e la nomina sal_update.
t2 
UPDATE employees
 SET salary = 7000
  WHERE last_name = 'Banda';
 Questa dichiarazione aggiorna lo stipendio di Banda a 7000.
t3 
SAVEPOINT after_banda_sal;
 Questa istruzione crea un savepoint denominato after_banda_sal, consentendo il rollback delle modifiche in questa transazione a questo punto.
t4 
UPDATE employees
 SET salary = 12000
  WHERE last_name = 'Greene';
 Questa dichiarazione aggiorna lo stipendio di Greene al 12000.
t5 
SAVEPOINT after_greene_sal;
 Questa istruzione crea un savepoint denominato after_greene_sal, consentendo il rollback delle modifiche in questa transazione a questo punto.
t6 
ROLLBACK TO SAVEPOINT
 after_banda_sal;
 Questa istruzione esegue il rollback della transazione a t3, annullando l'aggiornamento dello stipendio di Greene all'indirizzo t4. La transazione sal_update non è terminata.
t7 
UPDATE employees
 SET salary = 11000
  WHERE last_name = 'Greene';
 Questa dichiarazione aggiorna lo stipendio per Greene a 11000 nella transazione sal_update.
t8 
ROLLBACK;
 Questa istruzione esegue il rollback di tutte le modifiche apportate alla transazione sal_update, terminando la transazione.
t9 
SET TRANSACTION NAME 'sal_update2';
 Questa istruzione inizia una nuova transazione nella sessione e la nomina sal_update2.
t10 
UPDATE employees
 SET salary = 7050
  WHERE last_name = 'Banda';
 Questa dichiarazione aggiorna lo stipendio di Banda a 7050.
t11 
UPDATE employees
 SET salary = 10950
  WHERE last_name = 'Greene';
 Questa dichiarazione aggiorna lo stipendio di Greene al 10950.
t12 
COMMIT;
 Questa istruzione esegue il commit di tutte le modifiche apportate nella transazione sal_update2, terminando la transazione. Il commit garantisce che le modifiche vengano salvate nei redo log file in linea.

Nomi transazione

Un nome transazione è un tag facoltativo specificato dall'utente che funge da promemoria del lavoro svolto dalla transazione. L'utente denomina una transazione con l'istruzione SET TRANSACTION ... NAME, che se utilizzata deve essere la prima istruzione della transazione.

Nella Tabella 13-1, la prima transazione era denominata sal_update e la seconda era denominata sal_update2.

I nomi delle transazioni offrono i seguenti vantaggi:

Vedere anche:

Transazioni attive

Una transazione attiva è una transazione avviata ma non ancora sottoposta a commit o rollback.

Nella Tabella 13-1, la prima istruzione per modificare i dati nella transazione sal_update è l'aggiornamento allo stipendio di Banda. Dall'esecuzione riuscita di questo aggiornamento fino alla fine della transazione da parte dell'istruzione ROLLBACK, la transazione sal_update è attiva.

Le modifiche apportate ai dati da una transazione sono temporanee fino a quando non viene eseguito il commit o il rollback della transazione. Prima del termine della transazione, lo stato dei dati è quello indicato nella tabella seguente.

Tabella 2 Stato dei dati prima della fine della transazione

Stato Descrizione Per saperne di più
Oracle AI Database ha generato informazioni di annullamento nell'area SGA. I dati di annullamento contengono i vecchi valori di dati modificati dalle istruzioni SQL della transazione. "Leggi la coerenza nel livello di isolamento impegnato in lettura"
Oracle AI Database ha generato redo nel redo log buffer in linea dell'area SGA. Il record di redo log contiene la modifica al blocco di dati e la modifica al blocco di annullamento. "Redo Log Buffer"
Sono state apportate modifiche ai buffer di database della SGA. Le modifiche ai dati per una transazione di cui è stato eseguito il commit, memorizzate nei buffer di database della SGA, non vengono necessariamente scritte immediatamente nei file di dati dal database writer (DBW). La scrittura del disco può essere eseguita prima o dopo il commit. "Database Buffer Cache"
Le righe interessate dalla modifica dei dati sono bloccate. Gli altri utenti non possono modificare i dati nelle righe interessate, né possono visualizzare le modifiche non sottoposte a commit. "Riepilogo del funzionamento del blocco"

Savepoint

Un punto di salvataggio è un indicatore intermedio dichiarato dall'utente nel contesto di una transazione.

Internamente, l'indicatore del savepoint viene risolto in un SCN. Savepoints dividono una lunga transazione in parti più piccole.

Se si utilizzano i savepoint in una transazione lunga, in seguito sarà possibile eseguire il rollback del lavoro prima del punto corrente della transazione, ma dopo un savepoint dichiarato all'interno della transazione. Pertanto, se si commette un errore, non è necessario risottomettere ogni istruzione. La Tabella 13-1 crea il savepoint after_banda_sal in modo che sia possibile eseguire il rollback dell'aggiornamento allo stipendio Greene a questo savepoint.

Rollback al savepoint

Un rollback a un savepoint in una transazione non impegnata significa annullare le modifiche apportate dopo il savepoint specificato, ma non significa un rollback della transazione stessa.

Quando viene eseguito il rollback di una transazione a un savepoint, come quando ROLLBACK TO SAVEPOINT after_banda_sal viene eseguito nella Tabella 13-1, si verifica quanto riportato di seguito.

  1. Oracle AI Database esegue il rollback solo delle istruzioni eseguite dopo il savepoint.

    Nella Tabella 13-1, ROLLBACK TO SAVEPOINT comporta il rollback del file UPDATE per Greene, ma non del file UPDATE per Banda.

  2. Oracle AI Database conserva il savepoint specificato nell'istruzione ROLLBACK TO SAVEPOINT, ma tutti i savepoint successivi vengono persi.

    Nella Tabella 13-1, ROLLBACK TO SAVEPOINT determina la perdita del savepoint after_greene_sal.

  3. Oracle AI Database rilascia tutti i lock di tabella e riga acquisiti dopo il savepoint specificato, ma conserva tutti i lock di dati acquisiti prima del savepoint.

La transazione rimane attiva e può essere continuata.

Vedere anche:

Transazioni accodate

A seconda dello scenario, le transazioni in attesa di risorse bloccate in precedenza potrebbero essere ancora bloccate dopo un rollback per salvare il punto.

Quando una transazione è bloccata da un'altra transazione, viene accodata alla transazione di blocco stessa, in modo che l'intera transazione di blocco debba eseguire il commit o il rollback affinché la transazione bloccata continui.

Nello scenario mostrato nella tabella seguente, la sessione 1 esegue il rollback a un savepoint creato prima di eseguire un'istruzione DML. Tuttavia, la sessione 2 è ancora bloccata perché è in attesa del completamento della transazione della sessione 1.

Esempio di rollback della tabella 3 al savepoint

T Sessione 1 Sessione 2 Sessione 3 Spiegazione
t0 
UPDATE employees
  SET salary=7000
  WHERE last_name=
  'Banda';
     La sessione 1 inizia una transazione. La sessione posiziona un blocco esclusivo sulla riga Banda (TX) e un blocco di tabella secondario (SX) sulla tabella.
t1 
SAVEPOINT
  after_banda_sal;
     La sessione 1 crea un savepoint denominato after_banda_sal.
t2 
UPDATE employees
  SET salary=12000
  WHERE last_name=
  'Greene';
     La sessione 1 blocca la riga Greene.
t3   
UPDATE employees
  SET salary=14000
  WHERE last_name=
 'Greene';
   La sessione 2 tenta di aggiornare la riga Greene, ma non acquisisce un lock perché la sessione 1 contiene un lock su questa riga. Nessuna transazione iniziata nella sessione 2.
t4 
ROLLBACK
 TO SAVEPOINT
  after_banda_sal;
    

La sessione 1 esegue il rollback dell'aggiornamento allo stipendio per Greene, che rilascia il blocco delle righe per Greene. Il blocco tabella acquisito in t0 non è stato rilasciato.

A questo punto, la sessione 2 è ancora bloccata dalla sessione 1 perché la sessione 2 si accoda alla transazione della sessione 1, che non è stata ancora completata.

t5     
UPDATE employees
  SET salary=11000
 WHERE last_name=
 'Greene';
 La riga Greene è attualmente sbloccata, pertanto la sessione 3 acquisisce un blocco per un aggiornamento alla riga Greene. Questa dichiarazione inizia una transazione nella sessione 3.
t6 
COMMIT;
     La sessione 1 esegue il commit, terminando la transazione. La sessione 2 è ora accodata per l'aggiornamento alla riga Greene dietro la transazione nella sessione 3.

Vedere anche: "Blocca durata" per ulteriori informazioni su quando Oracle AI Database rilascia i blocchi

Rollback delle transazioni

Un rollback di una transazione di cui non è stato eseguito il commit annulla le modifiche apportate ai dati eseguite dalle istruzioni SQL all'interno della transazione.

Dopo il rollback di una transazione, gli effetti del lavoro svolto nella transazione non esistono più. Nel rollback di un'intera transazione, senza fare riferimento a punti di salvataggio, Oracle AI Database esegue le azioni riportate di seguito.

La durata di un rollback è una funzione della quantità di dati modificati.

Vedere anche:

Commit delle transazioni

Un commit termina la transazione corrente e rende permanenti tutte le modifiche eseguite nella transazione.

Nella Tabella 13-1, una seconda transazione inizia con sal_update2 e termina con un'istruzione COMMIT esplicita. Le modifiche risultanti dalle due istruzioni UPDATE vengono ora rese permanenti.

Quando si esegue il commit di una transazione, si verificano le azioni riportate di seguito.

Dopo il commit di una transazione, gli utenti possono visualizzare le modifiche.

In genere, un commit è un'operazione rapida, indipendentemente dalle dimensioni della transazione. La velocità di un commit non aumenta con la dimensione dei dati modificati nella transazione. La parte più lunga del commit è l'I/O del disco fisico eseguito da LGWR. Tuttavia, la quantità di tempo spesa da LGWR è ridotta perché è stata scritta in modo incrementale il contenuto del redo log buffer in background.

Il funzionamento predefinito prevede che LGWR scriva il redo nel redo log in linea in modo sincrono e che le transazioni attendano che il redo inserito nel buffer sia su disco prima di restituire un commit all'utente. Tuttavia, per ridurre la latenza di commit delle transazioni, gli sviluppatori di applicazioni possono specificare che il redo deve essere scritto in modo asincrono in modo che le transazioni non debbano attendere che il redo sia su disco e possa tornare immediatamente dalla chiamata COMMIT.

Vedere anche:

Panoramica delle transazioni in quarantena

Una transazione di quarantena è una transazione isolata e non recuperata durante il recupero del database. Richiede l'intervento del DBA per risolvere il problema prima che i blocchi possano essere rilasciati.

Oracle AI Database utilizza redo e undo per garantire la coerenza dei dati. Quando il database viene aperto in seguito a un arresto anomalo, l'applicazione di redo esegue il rollback del database per ottenere tutte le modifiche di cui è stato eseguito il commit, noto come recupero della cache, e l'annullamento esegue il rollback delle modifiche apportate da non sottoposte a commit e ora inattive a causa dell'arresto anomalo, delle transazioni. Questo processo è noto come crash recovery. L'apertura del database non attende che l'annullamento delle transazioni non impegnate venga applicato per ottenere un avvio più rapido. Invece, contrassegna lo stato della transazione come "inattivo" nella tabella delle transazioni e il database viene aperto rapidamente. L'applicazione di undo per le transazioni inattive viene quindi eseguita in modo asincrono dal processo di background SMON (System Monitor) ed è nota come recupero delle transazioni.

L'altra volta che le transazioni inattive vengono recuperate da SMON si verifica durante il recupero dell'istanza. Un'istanza Oracle RAC può bloccarsi con transazioni in esecuzione. Le transazioni inattive contengono lock di riga che bloccano le transazioni sulle stesse righe nelle altre istanze RAC rimanenti. Il processo in background SMON su una delle istanze rimanenti esegue il recupero dell'istanza in due fasi, il recupero della cache seguito dal recupero della transazione.

Il processo in background PMON può anche scaricare il lavoro di interruzione di una transazione di grandi dimensioni durante il cleanup del processo non riuscito in SMON.

Il processo SMON esegue attività a livello di sistema come la pulizia di segmenti temporanei inutilizzati, estensioni contigue a coalescenza e molte altre attività. Si tratta di un processo irreversibile, il che significa che un crash in SMON porta a un crash dell'istanza CDB. L'errore di recupero delle transazioni SMON può verificarsi per una serie di motivi:

Non solo un crash arresta il recupero della transazione che viene attivamente recuperata da SMON, ma il recupero si interrompe anche per il resto delle transazioni inattive. In caso di errore persistente, il supporto Oracle consiglia ai clienti di disabilitare il recupero delle transazioni SMON e di aprire il database per ridurre l'impatto. Ciò fa sì che i lock di riga vengano bloccati dalle transazioni inattive per un periodo più lungo. Ciò ha un impatto significativo sulle operazioni aziendali critiche.

Qualsiasi transazione che non può essere recuperata viene messa in quarantena e lasciata non coperta fino a quando il DBA non sarà in grado di risolvere il problema. Il DBA riceve una notifica relativa alla transazione in quarantena e deve intraprendere un'azione immediata per consentire il rilascio dei blocchi di riga detenuti dalla transazione in quarantena.

Il DBA viene avvisato della presenza di transazioni in quarantena in vari registri e punti di vista per aiutare a identificare le transazioni in quarantena e il motivo per cui vengono messe in quarantena. Il DBA utilizza queste informazioni per risolvere il problema specifico in modo che la quarantena possa essere eliminata.

Quando si verificano errori in più transazioni o si estendono sull'intero PDB, ad esempio il danneggiamento dei dati logici dovuto a un bug di codice, il danneggiamento fisico di più blocchi o un danneggiamento SGA del PDB, la messa in quarantena del recupero delle transazioni inattive non riuscite può essere utile o meno. Dipende se la causa principale di questi errori è la stessa o meno, perché il recupero di altre transazioni inattive potrebbe verificarsi nello stesso problema. Il sistema continua a funzionare in uno stato incoerente anche dopo aver messo in quarantena alcune transazioni. Può essere pericoloso quando l'errore è dovuto alla corruzione logica dei dati, perché si diffonde nel tempo. Per evitare che ciò si verifichi, esiste un limite di quarantena delle transazioni di tre (3), dopo il quale la quarantena viene escalata a livello di database e il PDB verrà arrestato utilizzando shutdown abort se il log di archivio è abilitato per il PDB ed è possibile arrestare il PDB. Il recupero delle transazioni per il PDB viene disabilitato automaticamente in modo che il DBA possa correggere i problemi all'avvio successivo. Dopo aver risolto i problemi, il DBA dovrebbe abilitare il recupero per l'avvio successivo.

Nota: poiché Oracle Data Guard utilizza la replica logica, i metadati di quarantena non vengono replicati nel server in standby quando si utilizza Oracle Data Guard. Pertanto, i contenuti delle viste di quarantena delle transazioni, ad esempio DBA_QUARANTINED_TRANSACTIONS, sul server in standby possono essere diversi dalle voci sul server primario.

Argomenti correlati

Panoramica di Transaction Guard

Transaction Guard è un'API che le applicazioni possono utilizzare per fornire l'idempotenza della transazione, ovvero la capacità del database di conservare un risultato di commit garantito che indica se una transazione è stata sottoposta a commit e completata. Oracle AI Database fornisce l'API per JDBC thin, OCI, OCCI e ODP.Net.

Un errore recuperabile è causato da un errore del sistema esterno, indipendentemente dalla logica della sessione dell'applicazione in esecuzione. Si verificano errori recuperabili in seguito a interruzioni pianificate e non pianificate di processi in primo piano, reti, nodi, storage e database. Se un'interruzione interrompe la connessione tra un'applicazione client e il database, l'applicazione riceve un messaggio di errore di disconnessione. La transazione in esecuzione al guasto della connessione viene definita transazione in esecuzione.

Per decidere se risottomettere la transazione o restituire il risultato (impegnato o non impegnato) al cliente, l'applicazione deve determinare il risultato della transazione in volo. Prima di Oracle Database 12c, i messaggi di commit restituiti al client non erano persistenti. Il controllo di una transazione non garantiva che non avrebbe eseguito il commit dopo essere stata controllata, consentendo transazioni duplicate e altre forme di danneggiamento logico. Ad esempio, un utente potrebbe aggiornare un browser Web quando acquista un libro online e ricevere due addebiti per lo stesso libro.

Vedere anche:

Vantaggi di Transaction Guard

A partire da Oracle Database 12c, Transaction Guard fornisce alle applicazioni uno strumento per determinare lo stato di una transazione in esecuzione in seguito a un'indisponibilità recuperabile.

Utilizzando Transaction Guard, un'applicazione può garantire che una transazione venga eseguita non più di una volta. Ad esempio, se un'applicazione libreria in linea determina che il commit sottomesso in precedenza non è riuscito, l'applicazione può eseguire di nuovo la sottomissione in modo sicuro.

Transaction Guard fornisce uno strumento per l'esecuzione quasi una volta per evitare che l'applicazione esegua sottomissioni duplicate. Transaction Guard fornisce un risultato noto per ogni transazione.

Transaction Guard è una funzionalità di base di Oracle AI Database. La continuità di applicazione utilizza Transaction Guard durante il mascheramento delle indisponibilità degli utenti finali. Senza Transaction Guard, un nuovo tentativo di applicazione dopo un errore potrebbe causare il commit di transazioni duplicate.

Vedere anche:

Funzionamento di Transaction Guard

Questa sezione spiega il problema dei messaggi di commit persi e il modo in cui Transaction Guard utilizza gli ID di transazione logici per risolvere il problema.

Messaggi di commit persi

Quando si progetta per l'idempotenza, gli sviluppatori devono affrontare il problema degli errori di comunicazione dopo la sottomissione delle istruzioni di commit. I messaggi di commit non sono persistenti nel database e pertanto non possono essere recuperati dopo un errore.

Il grafico seguente è una rappresentazione di alto livello di un'interazione tra un'applicazione client e un database.

Figura 2: Messaggio di commit perso

Descrizione dell'illustrazione cncpt356.png

Nel caso di commit standard, il database esegue il commit di una transazione e restituisce un messaggio di operazione riuscita al client. Nella Figura 13-2, il client sottomette un'istruzione di commit e riceve un messaggio che indica che la comunicazione non è riuscita. Questo tipo di errore può verificarsi per diversi motivi, tra cui un errore dell'istanza di database o un'indisponibilità di rete. In questo scenario, il cliente non conosce lo stato della transazione.

A seguito di un errore di comunicazione, il database potrebbe comunque eseguire l'invio e non essere a conoscenza della disconnessione del client. Il controllo dello stato della transazione non garantisce che non verrà eseguito il commit di una transazione attiva dopo la verifica. Se il client rinvia il commit a causa di queste informazioni non aggiornate, il database potrebbe ripetere la transazione, con conseguente danneggiamento logico.

ID transazione logica

Oracle AI Database risolve l'errore di comunicazione utilizzando un identificativo univoco a livello globale chiamato ID transazione logica.

Questo ID contiene il numero di sessione logica allocato quando una sessione si connette per la prima volta e un numero di commit in esecuzione che viene aggiornato ogni volta che la sessione esegue il commit o il rollback back.Foot 1 Dal punto di vista dell'applicazione, l'ID transazione logica identifica in modo univoco l'ultima transazione del database sottomessa nella sessione non riuscita.

Per ogni round trip dal client in cui viene eseguito il commit di una o più transazioni, il database memorizza un ID transazione logico. Questo ID può fornire l'idempotenza delle transazioni per le interazioni tra l'applicazione e il database per ogni round trip che esegue il commit dei dati.

Il protocollo at-most-once consente l'accesso al risultato del commit richiedendo al database di eseguire le operazioni riportate di seguito.

Durante l'esecuzione di una transazione, sia il database che il client contengono l'ID transazione logica. Il database fornisce al client un ID di transazione logico all'autenticazione, quando si prende in prestito da un connection pool e ad ogni round trip dal driver client che esegue una o più operazioni di commit.

Prima che l'applicazione possa determinare il risultato dell'ultima transazione a seguito di un errore recuperabile, l'applicazione ottiene l'ID transazione logica detenuto nel client utilizzando le API Java, OCI, OCCI o ODP.Net. L'applicazione richiama quindi la procedura PL/SQL DBMS_APP_CONT.GET_LTXID_OUTCOME con l'ID della transazione logica per determinare il risultato dell'ultima sottomissione: impegnata (true o false) e chiamata utente completata (true o false).

Quando si utilizza Transaction Guard, l'applicazione può ripetere le transazioni quando l'errore è recuperabile e non è stato eseguito il commit dell'ultima transazione nella sessione. L'applicazione può continuare quando è stato eseguito il commit dell'ultima transazione e la chiamata utente è stata completata. L'applicazione può utilizzare Transaction Guard per restituire il risultato noto al client in modo che il client possa decidere l'azione successiva da eseguire.

Vedere anche:

Transaction Guard: esempio

In questo scenario, il messaggio di commit viene perso a causa di un errore recuperabile.

Transaction Guard utilizza l'ID transazione logico per conservare il risultato dell'istruzione COMMIT, assicurando che esista un risultato noto per la transazione.

Figura 3: Controllo dello stato della transazione logica

Descrizione dell'illustrazione cncpt365.png

Nella Figura 13-3, il database informa l'applicazione se la transazione è stata sottoposta a commit e se l'ultima chiamata utente è stata completata. L'applicazione può quindi restituire il risultato all'utente finale. Le possibilità sono:

Vedi anche: Oracle AI Database Development Guide per scoprire come utilizzare Transaction Guard

Panoramica della continuità di applicazione

Continuità applicazione tenta di mascherare le indisponibilità delle applicazioni ripetendo le richieste di applicazione incomplete dopo indisponibilità non pianificate e pianificate. In questo contesto, una richiesta è un'unità di lavoro dell'applicazione.

In genere, una richiesta corrisponde alle istruzioni DML e ad altre chiamate al database di una singola richiesta Web su una singola connessione al database. In generale, una richiesta è delimitata dalle chiamate effettuate tra il check-out e il check-in di una connessione al database da un connection pool.

Questa sezione contiene gli argomenti riportati di seguito.

Vantaggi della continuità di applicazione

Un problema di base per gli sviluppatori è come mascherare una sessione di database persa dagli utenti finali.

La continuità dell'applicazione tenta di risolvere il problema della sessione persa ripristinando la sessione del database quando qualsiasi componente interrompe la conversazione tra database e client. La sessione del database ripristinata include tutti gli stati, i cursori, le variabili e la transazione più recente quando ne esiste una.

Caso d'uso per continuità applicazione

In un caso tipico, un cliente ha inviato una richiesta al database, che ha generato sia stati transazionali che non transazionali.

Lo stato del client rimane corrente, potenzialmente con i dati immessi, i dati restituiti e i dati e le variabili inseriti nella cache. Tuttavia, lo stato della sessione del database, all'interno del quale l'applicazione deve operare, viene perso.

Se la richiesta del cliente ha avviato una o più transazioni, l'applicazione deve affrontare le seguenti possibilità:

Se la ripetizione riesce, il servizio utente del database per le indisponibilità pianificate e non pianificate non viene interrotto. Se il database rileva le modifiche dei dati visualizzati e potenzialmente attivati dall'applicazione, la ripetizione viene rifiutata. La ripetizione non viene tentata quando viene superato il tempo consentito per l'avvio della ripetizione, l'applicazione utilizza una chiamata limitata oppure l'applicazione ha disabilitato in modo esplicito la ripetizione utilizzando il metodo disableReplay.

Vedere anche: Oracle Real Application Clusters Administration and Deployment Guide per ulteriori informazioni sul funzionamento di Application Continuity per le sessioni del database

Continuità di applicazione per manutenzione pianificata

La continuità di applicazione per le indisponibilità pianificate consente alle applicazioni di continuare le operazioni per le sessioni di database che possono essere drenate o migrate in modo affidabile.

La manutenzione pianificata non deve interrompere il lavoro dell'applicazione. La continuità di applicazione offre tempo di lavoro attivo da scaricare dalla posizione corrente a una nuova posizione attualmente non interessata dalla manutenzione. Alla fine dell'intervallo di rimozione, le sessioni potrebbero rimanere nell'istanza di database in cui è pianificata la manutenzione. Anziché disconnettere forzatamente queste sessioni, Application Continuity può eseguire il failover di queste sessioni in un sito rimanente e risottomettere qualsiasi transazione in esecuzione.

Con Application Continuity abilitata, il database può effettuare le operazioni riportate di seguito.

Controlla il comportamento di rimozione durante la manutenzione pianificata utilizzando gli attributi del servizio drain_timeout e stop_option della utility SRVCTL, della utility Global Data Services Control (GDSCTL) e di Oracle Data Guard Broker. Il pacchetto DBMS_SERVICE fornisce l'infrastruttura di base.

Vedere anche:

Architettura della continuità di applicazione

I componenti chiave di Application Continuity sono runtime, riconnessione e ripetizione.

Le fasi sono le seguenti:

  1. Runtime normale

    In questa fase la continuità di applicazione esegue i task indicati di seguito.

    • Identifica le richieste del database

    • Decide se le chiamate locali e del database possono essere riprodotte

    • Crea oggetti proxy per abilitare la ripetizione, se necessario, e per gestire le code

    • Contiene le chiamate originali e la convalida di queste chiamate fino a quando la fine della richiesta o della ripetizione del database non viene disabilitata

  2. Riconnessione

    Questa fase viene attivata da un errore recuperabile. La continuità di applicazione esegue le attività indicate di seguito.

    • Garantisce che la ripetizione sia abilitata per le richieste del database

    • Gestisce i timeout

    • Ottiene una nuova connessione al database, quindi convalida che si tratta di una destinazione di database valida

    • Utilizza Transaction Guard per determinare se il commit dell'ultima transazione è riuscito (le transazioni sottoposte a commit non vengono risottomesse)

  3. Ripeti

    La continuità di applicazione esegue le attività indicate di seguito.

    • Riproduce le chiamate che si trovano in coda

    • Disabilita la ripetizione se durante la ripetizione vengono visualizzate modifiche visibili all'utente nei risultati

    • Non consente un commit, ma consente all'ultimo richiamo (che ha rilevato l'errore) di eseguire il commit

Dopo una ripetizione riuscita, la richiesta continua dal punto di errore.

Vedere anche:

Panoramica delle transazioni autonome

Una transazione autonoma è una transazione indipendente che può essere chiamata da un'altra transazione, che è la transazione principale. È possibile sospendere la transazione chiamante, eseguire operazioni SQL ed eseguirne il commit o l'annullamento nella transazione autonoma, quindi riprendere la transazione chiamante.

Le transazioni autonome sono utili per le azioni che devono essere eseguite in modo indipendente, indipendentemente dal fatto che la transazione chiamante esegua il commit o il rollback. Ad esempio, in una transazione di acquisto di azioni si desidera impegnare i dati dei clienti indipendentemente dal fatto che l'acquisto complessivo di azioni avvenga o meno. Inoltre, si desidera registrare i messaggi di errore in una tabella di debug anche se viene eseguito il rollback della transazione complessiva.

Le transazioni autonome hanno le seguenti caratteristiche:

In PL/SQL, una transazione autonoma viene eseguita all'interno di un ambito autonomo, che è una routine contrassegnata dal pragma AUTONOMOUS_TRANSACTION. In questo contesto, le routine includono blocchi PL/SQL anonimi di livello superiore e sottoprogrammi e trigger PL/SQL. Una direttiva pragma indica al compilatore di eseguire un'opzione di compilazione. Il pragma AUTONOMOUS_TRANSACTION indica al database che questa procedura, se eseguita, deve essere eseguita come una nuova transazione autonoma indipendente dalla transazione padre.

Il grafico seguente mostra come il controllo scorre dalla routine principale (MT) a una routine autonoma e viceversa. La routine principale è proc1 e la routine autonoma è proc2. La routine autonoma può eseguire il commit di più transazioni (AT1 e AT2) prima che il controllo ritorni alla routine principale.

Figura 4: Flusso di controllo delle transazioni

Descrizione dell'illustrazione cncpt288.gif

Quando si entra nella sezione eseguibile di una routine autonoma, la routine principale viene sospesa. Quando si esce dalla routine autonoma, la routine principale riprende.

Nella Figura 13-4, COMMIT all'interno di proc1 rende permanente non solo il proprio lavoro, ma qualsiasi lavoro in sospeso eseguito nella sua sessione. Tuttavia, un COMMIT in proc2 rende permanente solo il lavoro eseguito nella transazione proc2. Pertanto, le istruzioni COMMIT nelle transazioni AT1 e AT2 non hanno alcun effetto sulla transazione MT.

Vedi anche: Oracle AI Database Development Guide e Oracle AI Database PL/SQL Language Reference per scoprire come utilizzare le transazioni autonome

Panoramica delle transazioni distribuite

Una transazione distribuita è una transazione che include una o più istruzioni che aggiornano i dati su due o più nodi distinti di un database distribuito, utilizzando un oggetto schema denominato database link.

Un database distribuito è un set di database in un sistema distribuito che può apparire alle applicazioni come un'unica origine dati. Un database link descrive come un'istanza di database può eseguire il login a un'altra istanza di database.

A differenza di una transazione su un database locale, una transazione distribuita altera i dati su più database. Di conseguenza, l'elaborazione delle transazioni distribuite è più complicata perché il database deve coordinare il commit o il rollback delle modifiche in una transazione come unità atomica. L'intera transazione deve eseguire il commit o il rollback. Oracle AI Database deve coordinare il controllo delle transazioni su una rete e mantenere la coerenza dei dati, anche se si verifica un errore di rete o di sistema.

Commit a due fasi

Il meccanismo di commit a due fasi garantisce che tutti i database che partecipano a una transazione distribuita eseguano il commit o annullino tutte le istruzioni nella transazione. Il meccanismo protegge anche il DML implicito eseguito da vincoli di integrità, chiamate di procedure remote e trigger.

In un commit a due fasi tra più database, un database coordina la transazione distribuita. Il nodo di avvio è denominato coordinatore globale. Il coordinatore chiede agli altri database se sono pronti a impegnarsi. Se un database risponde con un numero, viene eseguito il rollback dell'intera transazione. Se tutti i database votano sì, il coordinatore trasmette un messaggio per rendere permanente l'impegno su ciascuno dei database.

Il meccanismo di commit a due fasi è trasparente per gli utenti che emettono transazioni distribuite. In effetti, gli utenti non devono nemmeno sapere che la transazione è distribuita. Un'istruzione COMMIT che indica la fine di una transazione attiva automaticamente il meccanismo di commit a due fasi. Non è richiesta alcuna codifica o sintassi di istruzioni complesse per includere transazioni distribuite nel corpo di un'applicazione di database.

Vedere anche:

Transazioni equivoche

Una transazione distribuita dubbia si verifica quando un commit a due fasi è stato interrotto da qualsiasi tipo di errore di sistema o di rete.

Ad esempio, due database riportano al database di coordinamento che erano pronti a eseguire il commit, ma l'istanza di database di coordinamento non riesce immediatamente dopo la ricezione dei messaggi. I due database che sono pronti a eseguire il commit sono ora lasciati in sospeso mentre attendono la notifica del risultato.

Il processo in background del programma di recupero (RECO) risolve automaticamente l'esito delle transazioni distribuite insicure. Dopo la risoluzione dell'errore e il ripristino della comunicazione, il processo RECO di ogni database Oracle locale esegue automaticamente il commit o il rollback di qualsiasi transazione distribuita insicura in modo coerente su tutti i nodi coinvolti.

In caso di errore a lungo termine, Oracle AI Database consente a ciascun amministratore locale di eseguire manualmente il commit o l'annullamento di qualsiasi transazione distribuita in dubbio a causa dell'errore. Questa opzione consente all'amministratore del database locale di liberare tutte le risorse bloccate che vengono conservate a tempo indeterminato a causa di un errore a lungo termine.

Se un database deve essere recuperato in un tempo passato, le funzionalità di recupero del database consentono agli amministratori di database di altri siti di restituire i propri database al point-in-time precedente. Questa operazione garantisce che il database globale rimanga coerente.

Vedere anche:

Legenda nota a piè di pagina

Nota a piè di pagina 1:

Per Oracle Real Application Clusters (Oracle RAC), l'ID della transazione logica include come prefisso il numero dell'istanza del database.