fonction du undo_suppress_error

[genio]

Bonjour les forumnautes...
quelle est la vraie fonctionnalité du undo_supress_error ?

Merci pour vos réponses..

[orafrance]

c'est UNDO_SUPPRESS_ERRORS : http://download.oracle.com/docs/cd/B...htm#REFRN10226

[genio]

Merci...
si j'ai bien compris c'est pour qu'une ancienne appli V8, migrée vers Orace9i, puisse 'fonctionner' avec les UNDO sans qu'il y ait d'erreur...
Me trompe-je ?

[genio]

Autre question...
Nous avons une appli de mise à jour 9i qui tourne avec :
Undo_management = auto
Undo_suppress_error = TRUE...
Mon UNDO_RETENTION est à 3600 (1 heure)...
Hors mon TS UNDO grossit démeusurément (il est en AUTOEXTEND !) au fur et à mesure des m.a.j sans tenir compte du UNDO_RETENTION (il en est actuellement à 6 Gigas pour 3000 mvts)...

Est-il possible que les paramètres Undo_management et undo_suppress_error pignorent le UNDO_RETENTION ?

Merci pour vos réponses...

[orafrance]

c'est ça, c'est pour assurer la compatibilité ascendante

[genio]

c'est ça, c'est pour assurer la compatibilité ascendante

Cela veut-il dire que mon UNDO_RETENTION n'est jamais pris en compte ?

[orafrance]

tu ferais mieux de relire la doc du UNDO parce que visiblement tu n'as pas compris comme ça fonctionne

Le UNDO_RETENTION permet de garder les blocs plus longtemps dans le UNDO. Un bloc passe au status EXPIRED (= peut être recyclé pour les modifs suivantes) si l'espace du UNDO est insuffisant (ce qui ne peut pas arriver en AUTOEXTEND no limit) ou quand après UNDO_RETENTION secondes.

Donc avec un UNDO_RETENTION à une heure et un UNDO de 6Go, si tu modifies 2 fois 6 Go en moins d'une heure tu consommes 12Go de UNDO.

Le undo_suppress_errors n'a absolumment aucune incidence sur l'espace utilisé, c'est juste une suppression d'alerte

[genio]

Merci pour tes réponses...
Nous avons en fait, un cas bizarre... nous avons un traitement d'insert qui semble-t-il boucle, qui n'écrit pas sur les fichiers en sortie, mais qui grossit l'UNDO...
D'après vous, comment cela peut-il être possible de grossir l'UNDO sans effectuer de msies à jour de tables ?...
Merci encore pour vos réponses...

[pifor]

Oracle utilise l'undo chaque fois qu'une transaction écrit des données dans une table et/ou un index: cela concerne les 3 instructions SQL suivantes:

• INSERT
• UPDATE
• DELETE

[orafrance]

Envoyé par genio

Merci pour tes réponses...
Nous avons en fait, un cas bizarre... nous avons un traitement d'insert qui semble-t-il boucle, qui n'écrit pas sur les fichiers en sortie, mais qui grossit l'UNDO...
D'après vous, comment cela peut-il être possible de grossir l'UNDO sans effectuer de msies à jour de tables ?...
Merci encore pour vos réponses...

un insert c'est pas une mise à jour de la table ?

[genio]

J'entendais par 'mise à jour', une modification de son état...

Je me suis mal exprimé !

[orafrance]

INSERT -> UNDO... si t'as des insert tu consommes de l'undo...

[genio]

Voici le problème...

Nous avons 5 traitements d'à peu près 15.000 Mvts d'insert chacun (65.000 en tout) qui passent bien (1 commit tous 50 000 lignes, donc jamais de commit vu que les vacations sont de 15.000) => Ok

Le sixième (4000 mvts d'insert (donc ridicule par rapport aux autres vacations) rame à n'en plus savoir pourquoi, ne s'arrête pas et quadruple l'UNDO_TABLESPACE le positionnant à 19 Gigas (alors que le UNDO_RETENTION est à 3600)...

Nous avons 8 environnements identiques et dans les 7 autres, ça se passe bien...

D'ou peut provenir le problèlme ?
1°) Les stats qui ne sont pas assez fraîches.
2°) Arrivé à un certain seuil, l'undo est trop fragmenté et ralentit les traitements...
3°) Les index sont désorganisés...
4°) un peu des trois ?

J'avoue que je suis un peu sec... peux-tu m'aider ?

[orafrance]

il suffit d'un seul mouvement de 19Go pour mettre la grouille... certains mouvements présentent peut-être des données qui générent des traitements complémentaires... là faut suivre les sessions pour voir qui consomme du UNDO et ce qu'il fait :neutre:

[genio]

Non, il n'y a pas de traitement comlémentaires... 1 seul est même désespéré traitement...
En fait, sur OEM, c'était TOUJOURS le même insert qui consommait de l'UNDO... il restait affiché dans la fenêtre... et mon UNDO qui grandissait à vue d'oeil !
L'insert est celui qui fonctionne très bien dans les autres vacations... bizarre hein ?

Est-il possible d'avoir un dump de l'UNDO.. de voir ce qu'il a fait dans le traitement... et les lignes mises à jour ?

Merci encore pour ta patience !

[orafrance]

très étrange Tu as fait une migration de ta base ? Tu n'es pas en ASSM en AUTOALLOCATE sur le UNDO par hasard... t'atteint peut-être des tailles d'extents trop grand. Essaye de le recréer éventuellement avec une extention uniforme de 100Mo par exemple.

[genio]

Nous avons trouvé la solution mais je m'interroge...

Nous avons refait les statistiques, et les traitements sont passés à Vitesse Grand V... (en fait ma caisse avait été IMPORTEE par un dump d'une très grosse caisse et ensuite avait été mise à jour de différentes façons, par des insert et deletes applicatifs) .. donc ma nouvelle caisse comportait les stats de la 'source' qui n'étaient pas du tout représentatives de ma caisse 'cible' ... Donc, après les nouvelles stats, ok !

Ce que je ne comprends pas c'est le lien entre les stats et l'UNDO qui grossissait (il est passé de 3 à 19 Gigas pour 4000 insert ! donc obligé de canceler le traitement)...

Si vous avez une explication entre le'UNDO qui grossit démesurément et les stats, je suis preneur !

Merci pour vos réponses...

PS : J'ai oublié de vous dire que le traitement d'Insert ne committait jamais (mais pour 4000 insert, ce n'est pas grave hein !)

[genio]

J'avais pas lu ton dernier courrier orafrance...

Voici la def. de mon UNDO...

CREATE UNDO
TABLESPACE "UNDOTBS1"
DATAFILE '/toto/undot.dbf' SIZE 1195M
REUSE AUTOEXTEND
ON NEXT 5120K MAXSIZE 32767M

Merci pour tes réponses...

PS : Que veut dire 'ASSM' ?

[orafrance]

ASSM = Automatic Segment Space Managment, c'est l'option AUTO dans OEM.

On peut imaginer que sans stats tu faisais un FULL SCAN (tu fais bien un INSERT AS SELECT ?) et que du coup du mettait énormément de bloc dans le UNDO.

[genio]

Non l'application effectue :

INSERT INTO Table
( Col1, col2 ...etc )
VALUES ( val1, val2 ... etc);

un 'Insert' normal en somme !

Tu sembles dire qu'avant d'effectuer l'Insert, il met dans l'UNDO tout le scan de la table lu avant l'insertion...

En effet ça expliquerai mon énorme UNDO mais j'en reste pantois !
Une telle chose peut-elle se produire ?