Transazioni.

Presentazione sul tema: "Transazioni."— Transcript della presentazione:

1 Transazioni

2 TIPI DI TRANSAZIONI DML – Data Manipulation Language un numero di DML statement che Oracle Server tratta come una singola entità DDL – Data Definition Language una singola operazione DDL (create, alter,drop, truncate) DCL – Data Control Language una singola operazione DCL (grant, revoke)

3 TRANSAZIONI una transazione inizia quando il primo statement DML SQL viene eseguito una transazione finisce con uno dei seguenti eventi: COMMIT o ROLLBACK statement uno statement DDL o DCL viene eseguito (commit automatico) l’utente esce da iSQL*Plus la macchina vai in crash

4 VANTAGGI DI COMMIT E ROLLBACK
assicurano la consistenza permettono di vedere le modifiche apportate prima di renderle permanenti

5 CONTROLLO DI UNA TRANSAZIONE
Time COMMIT Transaction Savepoint A Savepoint B DELETE INSERT UPDATE ROLLBACK al SAVEPOINT B ROLLBACK al SAVEPOINT A INSERT ROLLBACK

6 CONTROLLO DI UNA TRANSAZIONE
Statement Descrizione COMMIT Termina la transazione rendendo permanenti le modifiche SAVEPOINT name Segna un savepoint (marca) nella transazione corrente ROLLBACK Termina la transazione cancellando le modifiche effettuate ROLLBACK TO SAVEPOINT name Effettua il rollback nella transazione corrente fino al punto savepoint specificato. Omettendo la clausola savepoint, il rollback avviene sull’intera transazione.

7 ROLLBACK TO SAVEPOINT il comando SAVEPOINT crea una “marca” nella transazione corrente in modo da dividerla in piccole sezioni ROLLBACK TO SAVEPOINT permette di effettuare un rollback fino al punto stabilito dal savepoint UPDATE … SAVEPOINT update done; Savepoint created. INSERT… ROLLBACK TO update done; Rollback complete. Creando un savepoint con lo stesso nome di uno creato precedentemente, il primo savepoint viene cancellato

8 TRANSAZIONE IMPLICITA
Avviene una transazione implicita, cioè commit automatico: quando viene eseguito uno statement DDL quando viene eseguito uno statement DCL uscendo in modo normale (non anomalo) da SQL*Plus senza specificare COMMIT o ROLLBACK Si verifica un ROLLBACK automatico uscendo in modo anormale da SQL*Plus o quando la transazione viene interrotta per un errore di sistema

9 TRANSAZIONE IMPLICITA
NOTA 1 : È possibile con SQL*Plus mettere il comando AUTOCOMMIT a ON. Questo significa che ogni statement DML verrà automaticamente committato dopo l‘esecuzione. NOTA2 : uscire in modo normale da SQL*Plus significa utilizzare il comando EXIT nel prompt. Chiudere la finestra senza uscire viene interpretato come chiudura anormale.

10 STATO DEI DATI PRIMA DI COMMIT O ROLLBACK
si può tornare allo stato precedente dei dati, ogni operazione DML non committata è solo temporanea infatti viene prima effettuata nel database buffer in modo da poter ripristinare l’utente che ha effettuato le operazioni DML può vedere il risultato con la SELECT gli altri utenti non possono vedere il risultato fino a dopo il commit le righe toccate dalle operazioni DML sono LOCCATE, gli altri utenti non possono modificare queste righe

11 STATO DEI DATI DOPO IL COMMIT
le modifiche fatte ai dati diventano permanenti nel database lo stato precedente alle modifiche viene definitivamente perso tutti gli utenti possono vedere il risultato il LOCK sulle righe modificate viene rilasciato; le righe possono essere modificate da altri utenti tutti i SAVEPOINT vengono cancellati

12 STATO DEI DATI DOPO IL ROLLBACK
le modifiche fatte vengono ripristinate viene riportato il database allo stato precedente le modifiche il LOCK sulle righe modificate viene rilasciato; le righe possono essere modificate da altri utenti

13 ROLLBACK A LIVELLO DI STATEMENT
se un singolo statement DML di una transazione fallisce durante l’esecuzione, verrà fatto il rollback solo di quello statement non viene fatto il rollback sulle modifiche fatte dai precedenti in caso si operazioni DDL, se uno statement non va a buon fine non è possibile fare rollback delle precedenti operazioni inquanto per ogni statement avviene un commit automatico

14 READ CONSISTENCY è possibile accedere al database in due modi :
- lettura (SELECT statement) - scrittura (INSERT, UPDATE, DELETE statement) viene garantita, sia in lettura che in scrittura, la consistenza dei dati le modifiche fatte da un utente non vanno in conflitto con le modifiche fatte da un altro utente in lettura non si vedono le modifiche ancora in elaborazione (non committate) Lo scopo è di assicurare che ogni utente veda i dati allo stato dell’ultimo commit.

15 IMPLEMENTAZIONE READ CONSISTENCY
Read consistency è un’implementazione automatica Quando un’operazione DML viene fatta sul database, Oracle Server mette una copia dei dati non ancora modificati sull’UNDO SEGMENT Prima che venga effettuato il commit, tutti gli utenti che entrano in lettura, ad eccezione dell’utente che ha effettuato le modifiche, vedrà uno snapshot dei dati nell’UNDO SEGMENT Questo garantisce a chi entra in lettura la consistenza dei dati Al momento del commit, i dati diventano visibili a tutti gli utenti e lo spazio occupato dai vecchi dati nell’undo segment viene liberato ed eventualmente riutilizzato Se si fa un rollback della transazione, la vecchia versione dell’undo segment viene riscritta nelle tabelle e il database tornerà, anche per l’utente che ha effettuato le modifiche, nello stato precedente la transazione