Discussion :

[arezki76]

Bonjour

Voila j'ai lancer un bloc PL/SQL, et il marchait convenablement.

Aprés, j'ai reçu ce message :

ORA-01555 : Snapshot tros vieux : rollback segment no "", nommé "_SYS.." trop petit.

Que signifie et pq c'est arrivé ?

Merci à vous

[orafrance]

Par ailleurs, merci de mettre un titre plus explicite sans oublier les régles fondamentales du forum

[rouardg]

Bonjour,

Quelle version d'Oracle ?

En tout cas, cela signifie qu'Oracle est incapable de te retourner un jeu de données cohérents, car les valeurs modifiées ont été supprimées des RBS (Rollback Segments), certainement à cause des COMMIT intermédiaires.

Pour être plus clair :
Je suis sur que, dans ton code, tu parcours des données via un curseur sur lequel tu fetches (donc une boucle), et qu'ensuite tu modifies ces données.

Lorsque tu modifies les données, les anciennes valeurs sont conservées dans le RBS qui gère ta transaction. Et lors du prochain fetch sur ton curseur, comme ces données ont été modifiées, et qu'Oracle te donne toujours un jeu de données cohérentes, il a besoin d'aller chercher ces données dans le RBS.

Or si jamais tu commites dans ta boucle, ces anciennes données peuvent être effacées par d'autres mises à jour. Or lors du fetch, Oracle en avait besoin.

Moralité : ne commite qu'à la fin de ton traitement, pas dans ta boucle.

[orafrance]

Il est également possible d'augmenter le UNDO_RETENTION si c'est plutôt un problème de performance du traitement

[arezki76]

vous avez raison,
je fait des insertions dans une table et je commit chaque 500 dans le curseur.

[arezki76]

Bonjour

Existes t-il un moyen pour contourner ce pb ?

Vu que j'ai un nombre important de données à insérer, et je commit à chaque 100 records insérés.

Merci à vous d'avance

[plabrevo]

La note Metalink 40689.1 decrit en detail les raisons du pourquoi, ainsi que les possibles solutions, dont celles deja evoquees dans ce post.

[Thierry&Manon]

Bonjour,

Si vous voulez verifier que le parametrage du undo rentention est correct! Allez voir dans la table v$undostat. La requete ci-dessous vous donne la durée de la requete la plus longue.

Elle est MAJ toutes les 10Min et initialisé toutes les 24H.

select max(maxquerylen) from v$undostat;

[dedalios]

Bonjour

je reviens sur cette question :
j'ai sur une requête d'extraction qui dans l'esprit ces cette opération

Code :

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

1
2
3
4
5
6
7
8
with Lisrentrant as ( distinct select a.IDentrant1 as IDentrant1, b.c3 as c3 from entrant_a inner join  entrant_b
                                   on inner join a.IDentrant1 =b.IDentrant1  )
,
     lotretour as   ( select a.IDentrant1 as IDentrant1, b.c3 as c3 from sortant_a inner join  sortant_a
                                   on inner join a.IDentrant1 =b.IDentrant1  )
select * from Lisrentrant  left outer join  lotretour 
       on Lisrentrant.IDentrant1 = lotretour.IDentrant1 
where lotretour.c3 is null

j'obtient

ORA-01555: clichés trop vieux : rollback segment no 19,...
*Cause: rollback records needed by a reader for consistent read are
overwritten by other writers

ICi il n'y a aucune mise à jour directe effectué dans le select .

toutefois la base est vivante , il peut donc exister des update de celle-ci qui modifie les données

Est-ce que la volumétrie de la base , et donc le temps de réponse de chaque sous requête peut entrainer ce problème (notamment la première avec l'opération select distinct ????

il n y a pas d'update donc pourquoi avons nous un référence à une opération de roolback?

[skuatamad]

Est-ce que la volumétrie de la base , et donc le temps de réponse de chaque sous requête peut entrainer ce problème (notamment la première avec l'opération select distinct ????

Potentiellement, vérifiez le paramètre UNDO RETENTION à comparer au temps d'exécution de la requête.

il n y a pas d'update donc pourquoi avons nous un référence à une opération de roolback?

Read Consistency