Discussion :

[skaloup]

Bonjour,

Sur une base de donnée oracle 9, j ai l'erreur suivante qui est générée malgré l'augmentation du roolback segment :
ORA-01555: snapshot too old: rollback segment number 1 with name "_SYSSMU1$" too small

Je pense qu une application ne commit pas sa transaction après avoir effectuer des insert/update ou un select sur un dblink.
Comment identifier la taille du roolback segment utilisé pas chaques sessions et ainsi trouver quel application gère mal les transactions ?

[louping]

En version 9i, rechercher la valeur du paramètre undo_retention, la valeur par défaut est 900 (en secondes)
SQL> show parameter undo_retentio

Relever la valeur MAXQUERYLEN
SQL> select to_char(end_time,'YYYY-MM-DD:HH24:MM:SS'), maxquerylen from v$undostat where maxquerylen =(select max(maxquerylen) from v$undostat);

Modifier la valeur du undo_retension en fonction de MAXQUERYLEN, dans la mesure du raisonnable.
SQL> alter system set undo_retention=1800 ;

Modifier le fichier d’initialisation avec la nouvelle valeur
undo_retention=1800

[skaloup]

Merci pour cette reponse rapide.

J ai deja un site intéraissant :
http://www.akadia.com/services/ora_optimize_undo.html


Mais ce que j aimerrai c'est de savoir quel sont les sessions qui consomme beaucoup de place dans le roolback segement.

[pifor]

Pour avoir la taille de l'undo généré par une transaction, on peut regarder la vue V$TRANSACTION:

USED_UBLK: Number of undo blocks used

USED_UREC: Number of undo records used.

Ces données existent uniquement tant que la transaction n'est pas terminée. Je ne crois pas qu'on peut retrouver la taille de l'undo généré par une session donnée depuis son démarrage.

Noter qu'une session donnée n'utilise pas forcément le même rollback segment; en fait c'est la transaction qui utilise directement un rollback segment. En mode manuel, une transaction utilise toujours le même rollback segment (en mode automatique, je ne sais pas).

Si une transaction n'est pas terminée au bout d'un temps raisonnable, elle va rester dans V$TRANSACTION et vous pouvez utiliser la colonne:

START_TIME VARCHAR2(20) Start time (wall clock)

pour savoir quand elle a démarré.

On peut relier la transaction à sa session avec:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

v$transaction.addr = v$session.taddr

[skaloup]

Il y a sauf erreur des sessions sans transaction (select, dblink, ..) qui peuvent utiliser le roolback segement.

Peut t'on voir cela quelque part ?

Note that only transactions are assigned to rollback segments and non-distributed transactions involve a DML operation: insert, update, or delete. So sessions that have issued only normal queries do not show up as being assigned to rollback segments since these sessions will access rollback segments only to read data from them. And if a session needs to read data changed by another session that data can be in any segment.

[orafrance]

Mais ce que j aimerrai c'est de savoir quel sont les sessions qui consomme beaucoup de place dans le roolback segement.

c'est pas forcément un problème de place. Un bloc du UNDO peut passé EXPIRED dés que le undo_retention est passé. Auquel cas ce bloc peut être réutilisé et du coup la transaction suivante peut l'écraser même si c'est une toute petite transaction. Dans ce cas, si un curseur était ouvert en utilisant ce bloc et bien la session correspondante tombera en snapshot too old.

Il y a sauf erreur des sessions sans transaction (select, dblink, ..) qui peuvent utiliser le roolback segement.

en lecture uniquement. Quand un bloc est modifié, l'original est copié dans le UNDO. Du coup si un SELECT arrive alors qu'une autre transaction modifie les données, le SELECT lira les blocs du UNDO et non du tablespace.

[skaloup]

Merci de vos réponses. Je deverrai pouvoir avoir l information recherchée