ORA-01555 [FAQ]

**loki8** · 06/12/2004, 15h50

Bonjour,
lors de l'execution d'une procedure PL/SQL j'ai ce message qui apparait a chaque fois:

Code :

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

1
2
3
4
ORA-01555: snapshot too old: rollback segment number 4 with name "_SYSSMU4$"
too small
ORA-06512: at "U_Z12_00.PR_CPRI_LOAD", line 211
ORA-06512: at line 1

Je ne sais pas quoi faire pour eviter ce message, j'effectue un commit toute les 1000 lignes, je ne lit pas la meme table que celle ou j'effectue mes inserts ...
Toutes suggestion serait la bienvenue.
LoKi

**lalystar** · 06/12/2004, 15h52

Poste ton bout de code, stp. Je suis sûr qu'en le réécrivant différemment et en évitant de faire des commits intermédiaires ton erreur disparaitra.

Pour plus d'infos sur cette erreur, fais une recherche sur le forum, je l'ai vu il n'y a pas très longtemps.

Laly.

**loki8** · 06/12/2004, 16h06

En quoi le fait de supprimer les commit intermidiaires peut il m'aider dans cette erreur ?
De quoi vient elle ?
D'apres ce que j'ai compris c'est le segment de rollback qui se mort la queue, pas de sous entendu

.
De toute maniere j'aurais besoin de commit intermidaire car j'insere beaucoup de lignes dans ma table.
LoKi

**lalystar** · 06/12/2004, 16h10

Quand tu fais un commit c'est comme si tu disais à Oracle qu'il peut réutiliser le rollback.

Tu dois avoir quelqu'un qui fait une requête sur les données que tu modifies. Il a besoin d'une image de la table reconstruite au moment du commencement de la requête grâce au rollback. En parallèle tu modifie ces données, les images avant modifs sont dans le rollback. Mais quand tu fais un commit, Oracle se permet de réutiliser ce rollback. Il n'est alors plus capable de fournir l'image de la table nécessaire pour la première requête qui plante alors.

<EDIT>
Voici le thread auquel je pensais : http://www.developpez.net/forums/vie...apshot+too+old
</EDIT>

Laly.

**loki8** · 06/12/2004, 16h28

Est il possible que le probleme vienne du fait que j'essaierais de lire dans une table, dont une autre procedure serait en train de faire la mise a jour ?
Ou bien est ce forcement dans l'autre sens a savoir qu'une procedure essaye de lire la table que je suis en train de mettre a jour ?

LoKi

**lalystar** · 06/12/2004, 16h34

Envoyé par loki8

Est il possible que le probleme vienne du fait que j'essaierais de lire dans une table, dont une autre procedure serait en train de faire la mise a jour ?
Ou bien est ce forcement dans l'autre sens a savoir qu'une procedure essaye de lire la table que je suis en train de mettre a jour ?

LoKi

est-ce-que ca ne revient pas au même.

Tu as une session qui lit ta table et une autre qui la modifie. Oui, ca peut être une des causes de cette erreur.

Laly.

**loki8** · 06/12/2004, 16h41

Ce n'est pas vraiment la meme chose.
En fait je pense qu'etant donne que l'ORA apparait dans ma procedure je pense que c'est la lecture d'un de mes cursors qui petent.
Et non pas la lecture de la table que je mets a jour par une autre procedure.
Apres une bref verif il ne me semble pas que ma procedure lise une table qui est en train d'etre mise a jour, ni qu'une procedure essaye de lire la table que je met a jour.
N'aurais tu pas une autre idee, stp ?
Car la moi je rame completement.
LoKi

**lalystar** · 06/12/2004, 16h43

Poste ton bout de code ou bien alors la solution classique consite à agrandir tous tes rollbacks segments ou bien si tu es sous 9i à passer en Automatic Undo Management.

Laly.

**orafrance** · 06/12/2004, 16h59

Une explication s'impose

Lorsque les données d'une table sont modifiées les données originales sont copiées dans le UNDO.

Imaginons le scénario suivant :

A 00h00 la transaction T1 update la table TOTO
A 00h15 la transaction T2 sélectionne TOTO

les données sont lu dans le UNDO
A 00h30 T1 fait un COMMIT

tous les blocs originaux sont taggés comme réutilisable
A 00h45 la transactiion T3 fait un DELETE de TATA et consomme beaucoup de UNDO

les blocs sont remplacés

T2 perd une partie des données en cours de lecture dans le UNDO

snapshot too old

Donc :

Soit le commit a libéré les blocs trop tot (trop de commit intermédiaire)
Soit le SELECT est trop long
Soit la durée de rétention des blocs dans le UNDO est insuffisante

agrandir le paramètre UNDO_RETENTION, la requête suivante peut aider :

Code :

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

select max(maxquerylen) from v$undostat;

**loki8** · 07/12/2004, 10h05

Ok, merci pour cette explication, ca commence a etre un peu plus clair dans mon petit esprit

.
En gros au lieu de valider ma transaction tout les 1000 enregistrements mieux vaut la valider tout les 5000.
Par contre pour le select je ne sais pas quoi faire, car effectivment j'ai un select qui fait un full sur une table de 740 000 enregistrements, mais je suis oblige de lire tout ces enregistrements, comment faire pour les lires en plusieurs fois ?
Sinon demander a mon dba, et oui je ne suis que le petit AP qui supplie son dba pour essayer d'avoir quelque chose

, d'augmenter le UNDO_RETENTION.
Merci pour ces infos, j'essaye de suite de mettre en pratique tes conseils.
LoKi

**orafrance** · 07/12/2004, 10h23

Pour le SELECT, tu ne t'en sortiras probablement qu'avec un index bien senti

**loki8** · 07/12/2004, 10h33

A quoi me servira l'index ?
En fait j'ai besoin de toute les lignes d'une table:

Code :

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

1
2
3
4
5
6
7
Cursor C1 is
  Select * from t1;
open C1;
loop
 fetch C1 into toto;
 -----
end loop;

Sur un cursor de ce type je ne vois pas l'interet d'un index, mais je ne demande qu'a comprendre.

LoKi

**lalystar** · 07/12/2004, 10h35

Ici c'est vrai qu'un index ne te sera pas utile. Ce qu'Orafrance sous-entendait c'est que tout ce qui pourra améliorer la performance du bout de code que tu viens de poster ira dans le sens de la résolution de ton pb.

Laly.

**orafrance** · 07/12/2004, 10h40

Effectivement, dans ce cas il n'y a rien à faire, Oracle doit ramener toutes les lignes donc il faut juste lui laisser le temps

**loki8** · 07/12/2004, 10h43

Ok, merci pour toutes vos reponses et la rapidites de celles ci.
Je fais des tests et vous tiens informes.

LoKi

**lalystar** · 07/12/2004, 10h50

Si tu as besoin d'aide, n'hésite pas à poster le bout de code qui fait l'update et celui qui fait le select.

Laly.

**loki8** · 07/12/2004, 11h16

Merci tout le monde,
ca marche le DBA a augmente le parametre UNDO_RETENTION (merci orafrance) et ma procedure tourne nikel. 8)
Encore merci pour votre aide.
LoKi

**orafrance** · 07/12/2004, 11h27

qu'il est bien ce DBA

**nuke_y** · 06/04/2006, 14h24

Salut à vous tous.

Je remonte (déterre) le sujet pour le même problème, juste pour être sûr que j'ai bien compris.

à 10h00 je sélectionne toutes les données de T1, T2 et T3 (avec des jointures entre elles).
à partir de 10h20 (le temps que la requête se termine) mon application commence à dérouler chacune des lignes de ce résultat et pour CHAQUE ligne fait un calcul puis update la ligne (grace à la clé primaire) avec le résultat.
toutes les 1000 lignes les updates sont commités. Comme les lignes sont triées lors du select et les updates basés sur les clés primaires, normalement on ne modifie que des lignes qu'on a déjà lu. Donc ça roule.
à 11h20 le traitement se termine.

Et je lance ce traitement plusieurs fois de suite (une pour chaque jour ouvré de la semaine précédente en fait).

Bon jusque là tout va bien. Mais ce matin voila ce qu'il se passe :
à 10h00 je sélectionne toutes les données de T1, T2 et T3 (avec des jointures entre elles).
à 11H30 (on remarquera le temps qu'il a fallu pour le select) j'ai droit à cette erreur là qui clot le select :

Code :

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

ORA-01555: snapshot too old: rollback segment number 2 with name "_SYSSMU2$" too small

Après analyse je me rend compte que d'AUTRES gros traitements étaient en train de tourner (je vais pister les utilisateurs qui les ont lancé et leur faire la peau

) et ont donc du pomper la place dans le UNDOTBS.

Si j'ai bien suivi l'histoire c'est que le UNDO_RETENTION est trop court. Or il est de 20h d'après les DBA (durée justifiée par le fait que nous n'avons aucun traitement qui nécessite de garder un snapshot plus de 20h pour des modifications derrière).

Donc je ne comprend pas bien... J'aurai eu une erreur du genre

Code :

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

Impossible de créer le snapshot dans UNDOTBS, pas assez de place et extension impossible

j'aurai compris, ça voulait dire que des snapshots utilisaient toute la place et qu'il n'y en avait pas assez pour moi, mais alors que mon snapshot créé il y a 1 heure se fasse écraser je ne comprend pas.

A moins... à moins que hier j'ai déjà lancé le Select (sans l'update derrière) pour vérifier les temps de requêtage et qu'Oracle en repérant que c'était la même requête ait décidé de réutiliser le snapshot d'hier qu'il n'avait pas encore effacé mais alors là

EDIT :
On est en 9.2.0.4 et de ce que me dit le DBA un patch corrige ce problème 9.2.0.5... Ca vous parle à vous ?

**orafrance** · 06/04/2006, 14h48

que donne :

Code :

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

select value from v$parameter where name = 'undo_retention'

ORA-01555 [FAQ]

Oracle

Vue hybride

Discussions similaires

Partager

Partager