Lors de ces transactions, nous voyons nos données modifiées ... mais pas d’une autre session (principe d’isolation). La validation de la transaction sera appliquée, et donc visible par d’autres sessions, lors du COMMIT.
Exemple :
| Session N°1 | Session N°2 |
SQL> select * from myids;ID ------- 1 2 3 4 | SQL> select * from myids;ID ------- 1 2 3 4 |
SQL> insert into myids values(5);1 row created. SQL> select * from myids; ID ------- 1 2 3 4 5 | SQL> select * from myids;ID ------- 1 2 3 4 |
COMMIT; | |
SQL> select * from myids;ID ------- 1 2 3 4 5 | SQL> select * from myids;ID ------- 1 2 3 4 5 |
On voit bien dans cet exemple que la transaction n’est pas visible pour tout le monde. Et bien, on a là, tout le mécanisme des annulations.
Les transactions qui ne sont pas enregistrées durablement dans la base sont contenues dans des segments spécifiques appelés segments d’annulation.
Ces segments permettent d’etablir un ordre ROLLBACK et de retrouver un état en début de transaction.
Enfin, les annulations sont également très utiles après un crash d’instance. Si il y avait eu un crash d’instance après mon ordre INSERT, toutes les transactions non validées auraient été annulés lors du redémarrage de l’instance (par SMON). Si un administrateur avait tué ma session, le mécanisme aurait été identique (annulation effectuées par PMON).
et réellement ?
Et bien réellement, il existe des segments spéciaux appelés RollBack Segments (RBS).
Ces segments spéciaux sont en fait des segments circulaires (un segment étant composé d’extensions, elles-mêmes composées de Blocs Oracle), dans lequel toutes les anciennes valeurs seront enregistrées. A ce point, deux scenarii :
- un COMMIT valide la transaction alors :
- la valeur du SCN est incrémentée
- le segment d’annulation est libéré pour d’autres opérations (par incrément du SCN courant)
- les données modifiées sont inscrites durablement dans la base (dans les redo log).
- un ROLLBACK invalide la transaction alors :
- les données contenues dans le RBS sont remises en place dans le segment de données
- les données d’annulations sont invalidées et le segment peut-être utilisé pour d’autres annulations.
Fonctionnement de l’annulation
NB : Si ces segments sont circulaires, cela signifie qu’ils seront limités dans le volume de la transaction pouvant être enregistrée. Un UPDATE volumineux nécessitera un RBS assez volumineux, si on désire l’annuler.
Pourquoi est ce mieux depuis la 9i ?
Avant la 9i, les RBS étaient généralement stockés dans un tablespace pour lequel il fallait gérer les paramètres de stockage (comme tous les tablespaces).
Mais en plus, il fallait régler le nombre de ces RBS, les règles de stockage de chacun de ses RBS, la taille de ceux-ci devait également être soigneusement étudiée, notamment sur des batch qui, généralement, demandaient de larges espaces d’annulations... bref, il fallait être aux petits soins de ces RBS.
A partir de la 9i, oracle a simplifié la gestion des annulations (tout en conservant le fonctionnement "Old-Fashion" des RBS). La gestion automatique des annulations se résume maintenant à :
un tablespace dit d’annulation ou UNDO TABLESPACE (avec le paramètrage que cela implique). Ce tablespace contient des RBS (mais ils ne sont plus géré par l’humain). un paramètre de temps conservation des données ou UNDO RETENTION.L’UNDO management
La gestion des annulations automatiques (AUTOMATIC UNDO MANAGEMENT en opposition au MANUAL ie. gestion des RBS), se fait en plusieurs étapes.
La première consiste à créer un tablespace d’annulation. Par exemple, pour un tablespace UNDOTBS01 géré localement :
CREATE UNDO TABLESPACE undotbs01 DATAFILE '/u02/orcl/undotbs01.dbf' size 500M REUSE
AUTOEXTEND OFF
/
Puis, il nous faut modifier le paramètrage de notre base. Dans un premier temps il faut stipuler le fait que l’on va travailler en automatique avec notre tablespace UNDOTBS01 (si on travaille avec un SPFILE, voila ce que cela donnera) :
ALTER SYSTEM SET UNDO_MANAGEMENT=auto SCOPE=SPFILE;
ALTER SYSTEM SET UNDO_TABLESPACE=undotbs01 SCOPE=SPFILE;
Il nous faut ensuite déterminer le temps de conservation de nos données. En gros, on va dire au système combien de secondes on désire conserver nos données pour annulation. Ce paramètre se nomme UNDO_RETENTION.
Si par exemple, on règle ce paramètre à 10 minutes (soit 600 secondes), alors on considère que toutes nos données d’annulations pourront être conservées pendant 10minutes ... au delà, une erreur caractéristique se produira ... l’ORA-01555 (voir plus bas).
ALTER SYSTEM SET UNDO_RETENTION=600 ;
ORA-01555 ??
Nous l’avons vu plus haut, cette erreur est générée lorsqu’une transaction s’est éxecutée pendant plus de temps que n’est configuré le paramètre UNDO_RETENTION et qu’une autre session a tenté d’accéder aux données modifiées par cette transaction.
En effet, lorsque des blocs de données sont modifiés, nous avons vu qu’ils était mis dans un rollback segment, et la nouvelle image des données mis à jour dans le segment de données.
Lorsqu’une autre session tente d’accéder à cette table, elle doit voir les anciennes données (image avant). Les données sont donc récupérées dans le segment d’annulation et dans la table pour fournir une lecture cohérente. L’erreur ORA-01555 est renvoyée lorsque la session concurrente (pas celle qui modifie les données) tente de lire des données dans le segment d’annulation et que ces données ne s’y trouvent plus (dépassement du temps de rétention.)
Lorsqu’une erreur de ce type apparait, il est conseillé d’augmenter le paramètres d’UNDO_RETENTION, et donc en conséquence, de surveiller l’occupation du tablespace d’annulation.
Gestion des performances
Les informations de performances des annulations se trouvent la vue V$UNDOSTAT.
D’autres vues systèmes (DBA_ROLLBACK_SEGS, V$TRANSACTION, V$ROLLSTAT, V$ROLLNAME, V$SESSION) peuvent être mises en jointures avec pour obtenir des informations sur les segments d’annulation.
Source http://laurent.leturgez.free.fr/
Aucun commentaire:
Enregistrer un commentaire