Dépassement UNDO oracle

Bonjour,

j'ai un dépassement de UNDO, comment ça se passe ? Si je fais pleins d'insert/update/delete dans une session oracle peut le remplir avant un commit ou rollback ?

Oui : C'est exactement cela.
Quand on fait des modifs sur des tables oracle (donc Insert/update/Delete), Oracle modifie les tables, mais il écrit dans le tablespace Undo la version d'origine... ou en tout cas les informations nécessaires pour reconstituer la version d'origine.
Et ça peut prendre beaucoup de place !

Tu peux nous donner le message d'erreur?

Bah en fait je crois qu'on a 16go d'alloue au undo le lancement d'un traitement fait que pour les perds ils l'ont doublé sur 32go mais d'après eux avec 16go on devrait avoir assez.

On traite pas mal de données le traitement fait pas mal de maj de plusieurs tables je pourrais pas dire combien mais beaucoup.

Je vois pas trop quoi faire pour régler le soucis si j'ai 1 million dinsert a faire je vois pas comment je peux faire autrement ..

C'est beaucoup de merge inserts update et des délete where

Je ne suis pas un spécialiste de l'Undo mais, 32 Go 8O8O8O8O8O c'est ENORME! Je ne pense pas qu'il faille augmenter cette taille indéfiniment, le problème me semble ailleurs.

Que donne la commande suivante?

Code:

---

1 2 3 4 5 6 7 8

SQL> show parameter undo   NAME TYPE VALUE ------------------------------------ ----------- ------ temp_undo_enabled boolean FALSE undo_management string AUTO undo_retention integer 900 undo_tablespace string UNDOTBS2

---

Une solution, mais certains vont hurler, serait de casser ta grosse transaction en transactions plus petites SI et uniquement SI c'est possible!

Par exemple si la transaction suivante consomme 25Go:
INSERT 1 000 000 de lignes
UPDATE 10 000 000 de lignes
COMMIT

est-il possible de faire à la place deux transactions pour gérer moins de Undo?
INSERT 1 000 000 de lignes
COMMIT
UPDATE 10 000 000 de lignes
COMMIT

ça met :

Code:

---

1 2 3 4 5 6 7

NAME TYPE VALUE -------------------------------------------------- ----------- ---------------------------------------------------------------------------------------------------- undo_management string AUTO undo_retention integer 900 undo_tablespace string UNDOTBS1

---

Ouais, rien d'extraordinaire.

Essaye de voir avec les développeurs le point que je t'ai expliqué précédemment, à savoir couper la grosse transaction en N plus petites, du moins si fonctionnellement c'est faisable.

Bonjour,

Un petit renseignement supplémentaire, pour savoir si la rétention est garantie ou non (par défaut elle ne l'est pas, mais sait-on jamais) :

select retention from dba_tablespaces where tablespace_name='UNDOTBS1';

ça me rend NOGUARANTEE


@Ikebukuro je suis le dev ^^ je vais voir avec mon chef ce qu'il décide c'est pas de mon ressort ma boite tend à virer le max de commit /rollback dans le code d'un traitement en cours d'exec ...


Imaginons que la réponse soit non quelles solutions sont possibles ?

Je vais répondre un peu à côté, mais pas complètement.
Update sur 10 Millions de ligne, c'est à éviter. Update est très lent ( et si Update est très lent, Update est probablement gros consommateur d'espace Undo).
Remplacer un Update par un Insert est souvent possible.

Et je maîtrise moins, mais remplacer un Update par un Merge est certainement possible. Il me semble que souvent, ça accélère les traitements ; reste à voir si c'est moins consommateur en espace Undo.

le traitement qui prend des plombes déjà on insert 62 109 198 enregs dans une table temporaire ..

ensuite on fait 12 234 508 merge update ...

Encore un traitement à la "con" :aie:

Je vois que la question est résolue : quelle solution a été retenue?

Pour l'instant diminuer les insert dans la table temporaire en gros on pouvait faire un group by sur le select pour diminuer énormément cet insert.

A voir si c'est concluant en prod