Discussion :

[apersonnat]

Bonjour,

J'observe de temps en temps un msg type ORA-01555 dans l'alert.log d'une base effectuant un refresh de vue matérialisée au travers d'un db link.

Le RBS appartient à la base distante, pourtant lorsque j'interroge la V$rollstat je constate que le RB ne s'est pas étendu (il y a pourtant de la place sur le TS), de plus je n'ai aucun msg ORA-01555 dans l'alert.log de la base distante.

Or c'est elle qui supporte la transaction non ?

Cdt,
A.Personnat

[orafrance]

Tu es en rollback segment manuel ou auto (avec un UNDO). En manuel tu devrais essayer de créer de nouveaux segments de rollback.

L'idéal étant de migrer vers l'auto si ce n'est pas le cas.

[philcero]

La tansaction a bien des effets sur les blocs de données de la base locale et non la distante donc il est normal que ce soit elle qui est l'erreur.

Le SNAPSHOT TOO OLD est le vilain canard, faut juste tuner un peu la requête qui te permet de créer/mette à jour ta vue matérialisée. Si tuner la requête ne suffit pas, passe par un code PL/SQL qui ferra le boulot de façon segmentée.

Généralement augmenter la taille des UNDO ou ROLLBACK est un palliatif au problème rien de plus, il ne faut pas se laisser avoir. Sauf bien évidement si tes UNDO ou ROLLBACK sont au ras de paquerettes auquel cas il faut pas hésiter à leur donner de l'espace.

[orafrance]

Généralement augmenter la taille des UNDO ou ROLLBACK est un palliatif au problème rien de plus, il ne faut pas se laisser avoir. Sauf bien évidement si tes UNDO ou ROLLBACK sont au ras de paquerettes auquel cas il faut pas hésiter à leur donner de l'espace.

Attention, en mode MANUAL l'ORA-1555 est un grand classique causé par un nombre insuffisant de segments de rollback, là les perfs n'y sont pas pour grand chose. Avec le UNDO en effet, c'est souvent plus un problème de perf mais pas forcément non plus

[philcero]

Attention, en mode MANUAL l'ORA-1555 est un grand classique causé par un nombre insuffisant de segments de rollback.

De mon point de vue, en mode MANUAL, l'erreur ORA-01555 est plus liée à un phénomène de sessions qui se chevauchent sur un même ensemble de données. Les champions sont les client qui ouvrent une session à 08h00 du matin et qui attendent que l'utilisateur ferme le logiciel pour commiter !

Avec le UNDO en effet, c'est souvent plus un problème de perf mais pas forcément non plus.

Si il est en mode UNDO, y a qu'à aller chercher dans les vues adéquates les informations de rétention (V$UNDOSTAT.MAXQUERYLEN) pour obtenir une valeur minimale pour le paramétrage de la rétention.

[orafrance]

De mon point de vue, en mode MANUAL, l'erreur ORA-01555 est plus liée à un phénomène de sessions qui se chevauchent sur un même ensemble de données. Les champions sont les client qui ouvrent une session à 08h00 du matin et qui attendent que l'utilisateur ferme le logiciel pour commiter !

Bien sûr mais il y a aussi un défaut de conception corrigé avec le UNDO. Il pouvait arriver que le nombre de blocs modifiés soit tellement grand qu'il soit plus grand que le nombre de segment, dans ce cas Oracle réutiliser le 1er segment (c'était cyclique) et donc supprimé les blocs lus ORA-1555

http://download-west.oracle.com/docs...nsis.htm#17882

Si il est en mode UNDO, y a qu'à aller chercher dans les vues adéquates les informations de rétention (V$UNDOSTAT.MAXQUERYLEN) pour obtenir une valeur minimale pour le paramétrage de la rétention.

en effet, mais augmenter la rétention ne suffit pas, il faut aussi augmenter la taille du UNDO et évidemment ça ne suffit souvent encore pas