Bonjour les forumnautes...
quelle est la vraie fonctionnalité du undo_supress_error ?
Merci pour vos réponses..
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
fonction du undo_suppress_error
Bonjour les forumnautes...
quelle est la vraie fonctionnalité du undo_supress_error ?
Merci pour vos réponses..
c'est UNDO_SUPPRESS_ERRORS : http://download.oracle.com/docs/cd/B...htm#REFRN10226
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 ?
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...
c'est ça, c'est pour assurer la compatibilité ascendante
Cela veut-il dire que mon UNDO_RETENTION n'est jamais pris en compte ?c'est ça, c'est pour assurer la compatibilité ascendante
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
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...
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
un insert c'est pas une mise à jour de la table ?Envoyé par genio
J'entendais par 'mise à jour', une modification de son état...
Je me suis mal exprimé !
INSERT -> UNDO... si t'as des insert tu consommes de l'undo...
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 ?
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:
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 !
très étrange
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 !)
J'avais pas lu ton dernier courrier orafrance...
Voici la def. de mon UNDO...
Merci pour tes réponses...CREATE UNDO
TABLESPACE "UNDOTBS1"
DATAFILE '/toto/undot.dbf' SIZE 1195M
REUSE AUTOEXTEND
ON NEXT 5120K MAXSIZE 32767M
PS : Que veut dire 'ASSM' ?
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.
Non l'application effectue :
un 'Insert' normal en somme !INSERT INTO Table
( Col1, col2 ...etc )
VALUES ( val1, val2 ... etc);
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 ?
Répondre avec citation
Partager