Dès qu’une mise
à jour est effectuée, des verrous sont positionnés implicitement.
La fin d’une transaction libère tous les verrous !Une transaction est un ensemble cohérent de modifications apportées
aux données.
Elle est soit totalement écrite soit totalement annulée.Une transaction
débute soit à la connexion, soit lors de la fin de la transaction
précédente.
Il est possible de définir des sous-transactions et de faire des annulations
partielles de transaction jusqu’à une étiquette préalablement
définie, grace a la commande SQL savepoint :
SQL> UPDATE EMP SET SAL=...
SQL> SAVEPOINT S1
SQL> UPDATE EMP SET COMM=...
SQL> ROLLBACK TO S1
Dès qu’une mise
à jour est effectuée, des verrous sont positionnés implicitement.
La fin d’une transaction libère tous les verrous !
L’ordre SQL COMMIT termine et valide (écrit) la transaction.
L’ordre SQL ROLLBACK termine et annule la transaction. Ce retour en arrière
se fait par l'intermédiaire des ROLLBACK SEGMENTS.
Commit implicite
Certains ordres SQL COMMITent automatiquement notamment tous ceux qui ne portent
pas directement sur le contenu des données : CREATE, DROP, ALTER,
GRANT, REVOKE, TRUNCATE, etc.
Dans certains environnements (sous SQL+ par exemple) on peut également
forcer un commit implicite après tous les ordres SQL :
SQL> SET AUTOCOMMIT ON
SQL> DELETE FROM EMP;
;-( trop tard on ne peut + revenir en arrière...
Rollback implicite
Un mécanisme de sécurité et d’intégrité basique d’Oracle fait qu’une transaction est automatiquement annulée en cas de défaillance soit du poste client, soit du serveur, voire du réseau. (CTRL + ALT + DEL du PC client par exemple)
en résumé :
| validation de transaction | annulation de transaction |
| COMMIT | ROLLBACK |
| ordres SQL : CREATE, DROP, ALTER, RENAME, TRUNCATE |
interruption : CTRL ALT DEL, RESET, ON/OFF  |
| ordre SQL*Plus : EXIT, QUIT, CONNECT, DISCONNECT |
erreur d'execution Oracle |
Un rollback segment est un segment particulier qui sert à stocker l'image avant modification des données. En d'autres termes dès qu'une modification est demandée par l'utilisateur (UPDATE, INSERT ou DELETE) avant d'être réalisée une image des données initiale est sauvegardée dans les RBS.
Dès que la transaction est terminée (explicitement ou implicitement) les RBS sont libérés (extents désalloués)
Il existe un Rollback segment par défaut obligatoire, et se trouve dans
le tablespace SYSTEM.
Une description complète des RBS est disponible dans la vue DBA_ROLLBACK_SEGS
du dictionnaire de données...
De la même façon qu'il est judicieux d'avoir plusieurs tablespaces
pour des raisons de répartitions de charge, il est vivement conseillé
d'avoir plusieurs RBS dans des tablespaces différents (jusqu'à
qq dizaines). Ils seront en général de tailles équivallentes.
Ici on crée 4 RBS répartis dans 2 tablespaces (et donc 2 fichiers)
différents.
SQL> CREATE ROLLBACK_SEGMENT RBS1 tablespace TBS_RBS1;
SQL> CREATE ROLLBACK_SEGMENT RBS2 tablespace TBS_RBS1;
SQL> CREATE ROLLBACK_SEGMENT RBS3 tablespace TBS_RBS2;
SQL> CREATE ROLLBACK_SEGMENT RBS4 tablespace TBS_RBS2;
La liste des RBS en ligne (sauf SYSTEM qui est obligatoire et par défaut) est en général spécifiée dans le fichier de démarrage init.ora.
Cette affectation se fait quasiment de manière aléatoire, en fait une nouvelle transaction alloue un extent dans un nouveau RBS (le suivant dans la liste des RBS en lignes). Une fois le dernier RBS utilisé on reboucle de manière sur le premier. Ainsi si on a 4 RBS, la cinquième transaction (d'un point de vue chronologique) ira s'inscrire à la suite de la première dans le premier RBS.
Il
est possible de forcer une transaction à utiliser un RBS ! et
affecter un gros rollback segment à une grosse transaction . Au début
de la transaction (apres commit, rollback ou connect) on écrit :
SQL> set transaction use rollback segment rbsdd;
|
|
