Version imprimable
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
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.
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.
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 ;)Citation:
Envoyé par philcero
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 !Citation:
Attention, en mode MANUAL l'ORA-1555 est un grand classique causé par un nombre insuffisant de segments de rollback.
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.Citation:
Avec le UNDO en effet, c'est souvent plus un problème de perf mais pas forcément non plus.
;)
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 :arrow: ORA-1555Citation:
Envoyé par philcero
http://download-west.oracle.com/docs...nsis.htm#17882
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 :mouarf:Citation:
Envoyé par philcero
le plus simple est encore de lire la doc détaillée à ce sujet : ORA-01555 "Snapshot too old" - Detailed Explanation
Je vois que le sujet fait débat, je vais apporter quelques précisions :
Au niveau des rollbacks (je suis encore en 8i donc pas de undo) la base distante (responsable des ORA-01555) il n'y a pas de contention particulière, pour preuve la somme du HWMSIZE ne dépasse pas 60% de la taille du TS RBS.
Je pense donc plus à un problème applicatif qu'à un problème sur les RBS proprement dit.
Ce que j'ai du mal à percevoir c'est pourquoi mon ORA-01555 n'apparait pas dans l'alert.log de la base distante alors que ce sont bien les RBS de cette base (distante) qui supporte la transaction.
Merci pour vos analyses.
Cdt,
A.Personnat
parce que c'est pas le RBS qui déclenche la 1555 mais la transaction qui s'est vautré à cause de la 1555.
As tu des commits dans ton traitement ?
Je pense qu'il doit y avoir des commits intermédiaires dans le traitement responsables de cette erreur (il faut que je vérifie).
En revanche je ne comprends toujours pas pourquoi l'ORA-01555 n'est pas tracée dans l'alert.log de l'instance supportant le traitement.
Désolé, je suis parfois un peu long à la détente :oops:
Cdt,
A.Personnat
Tu ouvres une session distante pour récupérer les données mais la transaction est locale et pas distante... c'est tout.