Discussion :

[nuke_y]

Code :

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

1
2
3
VALUE
-----
72000

[orafrance]

c'est donc bien 20h... ce qui m'ennuie c'est que j'ai du mal à imaginer que 20 peuvent tenir dans les UNDO... à moins qu'ils soient énormes

[orafrance]

pour info : http://www.ixora.com.au/tips/admin/ora-1555.htm

[nuke_y]

ben 6 giga de UNDO et on n'a jamais de transaction qui dure plus de 6h donc c'est normal... Et en plus je me suis déjà fais jeter par un

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

en tentant un update sur une grosse table pendant que de gros traitements tournaient sur une autre.

Je regarde ton lien.

[nuke_y]

Bon le lien explique bien le problème en général mais je ne vois pas en quoi il s'applique à mon cas... Comment se fait-ce que mon snapshot ait été supprimé avant la durée des 20h...

[bouyao]

Trop de commit dans les boucles.

Introduire des validations supplémentaires peut créer d'autres problèmes, parmi eux, la fameuse ORA-01555: l'erreur snapshot too old, car l'annulation (ou undo) des données peuvent être sur écrites. Une fréquence de commit trop élevé augmente aussi le temps système qui est associé avec le démarrage et la fin des transactions. Au début de chaque transaction, Oracle assigne un segment d'annulation (appelé segment d'annulation imposé) et mets à jours la table de transaction dans l'entête du segment d'annulation. La table de transaction doit être aussi mise à jours à la fin de chaque transaction, suivi par une validation de l'activité de nettoyage. Mettre à jours l'entête du segment d'annulation doit aussi être enregistré dans le log buffer car le bloc à été modifié. Pourtant, le fait de valider à la fin d'une unité de travail résoudra le problème. Le commit dans un loop à besoin d'être enlevé de telle façon que le commit d'un travail se fasse à la fin.

[nuke_y]

Mail du DBA :

Le traitement d’aujourd’hui a été rejeté pour un problème de ressource dans le UNDO tablespace.

Les causes sont:

+ Taille de undo_retention trop grande 20 heures, obligeant oracle à garder 20 heures d’information Roll-back dans le UNDO

+ Il y a eu un concours de circonstance faisant que les dernières 20 heures les activités (insert/update/delete) sur la base on été multipliés par 3


Solutions :

+ diminuer le UNDO_RETENTION qui doit avoir comme valeur la durée en seconde du temp de traitement le plus long

+ Augmenter encore le UNDO tablespace, mais il est dèjà à 6 Go

+ mettre en place un traitement quotidien qui vide le UNDO tablespace ! c’est une solution de contournement discutable !

+ Il faut absolument patcher la version Oracle 9.2.0.4 que nous avons avec le pach 5, qui permet de fixer quelques Bugs liés à la gestion automatique des UNDO. opération à planifier entre notre équipe et la votre

+ Oracle recommande de passer à version 10g qui a une option permettant de garantir la non écriture sur des undo non expirés (nouvelle clause « RETENTION GUARANTEE »)

Je ne suis d'accord ni avec l'explication du problème ni avec la solution proposée (diminution du UNDO_RETENTION) parce que je ne vois pas comment ça peut empêcher un snapshot too old de mettre la durée de retention plus petite...

[nuke_y]

Excuse moi bouyao mais là je ne t'ai pas bien compris

Autant je comprend bien le problème des commits dans les boucles pour certains problèmes autant là je ne comprend pas très bien

Et ça ne m'explique pas pourquoi mon snapshot n'a pas été conservé 20h...

[bouyao]

snapshot n'a pas été conservé 20h

Tout simplement je ne suis pas d'accord avec ton DBA , Car UNDO_RETENTION n'est pas honoré s'il n y a pas assez d'espace dans la tablespace UNDO.

[nuke_y]

MERCI BOUYAO !!!!

C'est EXACTEMENT ce que je voulais entendre !!! VOILA !! C'est pour ça. c'est ce que je soupçonnais mais je me demandais si c'étais possible.

Ok donc je comprend tout, tout s'explique et voila pourquoi il ne faudrait faire des commits qu'à la fin.

Le problème c'est que SI je ne le fais qu'à la fin je me mange un not enough space sur le UNDO_TBS (si je suis en concurrence avec d'autres traitement évidemment) et SI je le fais de temps en temps je risque le too old.

Dur dur...

[bouyao]

Voici un article plein de fautes que je n'ai pas encore finis : http://mbouayoun.developpez.com/reglredo/

Parmi les causes de l'attente log file sync est la fréquence très élevée des validations (commit). Il faut trouver si la session qui passe plus de temps dans l'événement log file sync appartient à un batch ou à un processe OLTP ou si c'est un middle-tier (comme Tuxedo, Weblogics, etc.)

Si la session appartient à un process batch, il doit être validé à chaque modification de la base à l'intérieur d'un loop. Découvrir le nom du module et demander au développeur de revoir dans leurs codes si les nombres de commit peut être diminués. C'est un problème d'applications, et la solution est simplement d'éliminer les validations non nécessaires et réduire la fréquence des validations.

Certains développeurs d'applications ont appris que s'ils valident rarement, les jobs devrait s'échouer suite au manque d'espace dans les segments d'annulations. La bonne chose à faire est de valider à la fin de chacune des transactions. Une transaction est une unité de travail. Une unité de travail devrait réussir ou échouer dans son entité. La place convenable pour une validation ou annulation est à la fin de chaque unité de travail. Ne pas ajouter des validations supplémentaires aux bénéfices des espaces d'annulations ou des deadlocks. Il traite le symptôme mais ne résout pas le problème. (Si vous utilisez AUM, alors allouer plus d'espace au tablespace undo et mettre le temps de rétention undo approprié.)

Introduire des validations supplémentaires peut créer d'autres problèmes, parmi eux, la fameuse ORA-01555: l'erreur snapshot too old car l'annulation (ou undo) des données peuvent être sur écrites. Une fréquence de commit trop élevé augmente aussi le temps système qui est associé avec le démarrage et la fin des transactions. Au début de chaque transaction, Oracle assigne un segment d'annulation (appelé segment d'annulation imposé) et mets à jours la table de transaction dans l'entête du segment d'annulation. La table de transaction doit être aussi mise à jours à la fin de chaque transaction, suivi par une validation de l'activité de nettoyage. Mettre à jours l'entête du segment d'annulation doit aussi être enregistré dans le log buffer car le bloc à été modifié. Pourtant, le fait de valider à la fin d'une unité de travail résoudra le problème. Le commit dans un loop à besoin d'être enlevé de telle façon que le commit d'un travail se fasse à la fin.

Si la session qui passe beaucoup de temps dans l'événement log file sync est une connexion persistance d'une couche middle-tier, alors c'est un cas difficile car il servit plusieurs utilisateurs frontaux. On doit tracer la session avec l'événement 10046 et observer le comportement de l'application. Chercher l'événement log file sync dans le fichier trace. Ils nous donneront une idée sur la fréquence des validations. Alternativement, on peut creuser les fichiers redo par le Logminer. Cela montrera le comportement des validations dans le système.

Dans une base OLTP, on observe normalement, un temps d'attente élevé du log file sync au niveau système (V$SYSTEM_EVENT) mais pas au niveau session. Le temps d'attente élevé au niveau système doit être mené par des petites transactions des sessions OLTP qui sont se connecte et se déconnecte activement dans la base. Si c'est notre scénario, le seule chose que nous pourrons faire est d'assurer un circuit stable d'E/S pour le process LGWR. Cela inclus l'utilisation les E/S/ asynchrones et mettre les fichiers redo dans des périphériques RAW ou un équivalent, comme Veritas Quick I/O, cela est servi par des contrôleurs E/S dédié ou mieux encore, utiliser des disques performants pour les fichiers redo.

pour ton dba Metalink note : 269814.1

The UNDO_RETENTION parameter is only honored if the current undo tablespace has
enough space. If an active transaction requires undo space and the undo tablespace
does not have available space, then the system starts reusing unexpired undo space.
This can cause some queries to fail with ORA-01555(snapshot too old) message.

[nuke_y]

Intéressant.

3 fautes cependant :

...une connexion persistance...
...car il servit ...
...sont se connecte et se déconnecte activement ...