Discussion :

[marsup077]

Bonjour à tous,

Et un nouveau mystère à élucider.
J'ai depuis quelques jours un problème sur une base 9.2.0.6 (serveur AIX 5.3) lors de son export full nocturne.
Celui-ci indique beaucoup de messages comme celui-ci :


ORA-04030: mémoire de traitement manquante lors d'affectation de 135192 octets (session heap,kllcqgf:kllsltba)


La ligne de commande d'export full est la suivante :

Code :

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

1
2
 
exp xxx/yyy DIRECT=Y FULL=Y CONSISTENT=Y recordlength=65535 buffer=2000000 FILE=zzz.dmp

Parmi les tentatives déjà faites :
- augmenter le paramètre stack de ulimit pour le user Oracle à unlimited -> sans effet
- augmenter la pga_aggregate_target de l'instance jusqu'à 600M -> sans effet
- augmenter la sort_area_size de l'instance -> sans effet.

De plus, j'ai remarqué que les erreurs disparaissent quand on réalise l'export full en passant par Sql*Net, c'est-à-dire avec une ligne de commande comme :

Code :

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

1
2
 
exp xxx/yyy@monAlias DIRECT=Y FULL=Y CONSISTENT=Y recordlength=65535 buffer=2000000 FILE=zzz.dmp

Il va sans dire que cela a fonctionné sans souci pendant des années et que rien n'a été modifié récemment sur cette base.

Merci d'avance pour vos idées.

[Pomalaix]

Il y a des notes dédiées à cette erreur sur Metalink, notamment 399497.1 et 233869.1. Vous y trouverez peut-être des pistes si vous ne les avez pas encore consultées.

Je pense que le fait que ça marche en passant par le listener, et pas en direct, est un symptôme important (sous réserve que cette différence soit systématique).
Si ça se trouve, vous passez par un serveur dédié dans un cas et pas dans l'autre.

Par ailleurs, le compte Unix qui fait tourner le listener est-il le même que celui qui fait tourner l'instance ?

[marsup077]

Bonjour,

Le compte unix pour faire tourner le listener et pour effectuer l'export sont bien les mêmes (oracle, en l'occurrence).

J'ai déjà un peu épuisé les notes Metalink, sans grand succès...

Et ça continue...

Depuis hier il y a eu un autre phénomène encore plus curieux : l'instance qui posait problème fonctionne maintenant parfaitement (l'export se déroule à présent sans problème), mais UNE AUTRE INSTANCE Oracle 9i présente sur ce même serveur rencontre à présent les symptômes lors de son export (ORA-04030).
ET CE, SANS QUE JE CHANGE QUOI QUE CE SOIT...

Etrange, n'est-ce pas ?

[marsup077]

Bon, ben j'ai réussi à me dépanner. Mais le remède m'étonne encore plus que le problème lui-même...

J'ai ajouté le paramètre d'initialisation

Code :

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

1
2
 
db_files=50

Sa valeur par défaut est 200. Il précise le nombre maxi de datafiles que la base peut posséder, 50 étant bien suffisant pour les bases de ce serveur.

Du coup tout se passe bien lors de l'export (et autres opérations qui plantaient avec le même ORA-04030, je m'en suis aperçu petit à petit).

Maintenant je pars à la recherche de l'explication...

[Pomalaix]

Ah oui, c'est la note Metalink 612418.1 : réduire le paramètre DB_FILES tout en sifflant "le pont de la rivière Kwai".

Blague à part, en admettant que cette manip soit réellement la source de l'amélioration, comment l'idée vous en est-elle venue ??

[marsup077]

Pour être sûr que je ne rêvais pas, j'ai refait le test plusieurs fois, avec et sans le paramètre db_files=50, suivi d'un A/R de la base. Y'a pas de doute, c'est bien ça...

L'idée m'est venue de la manière suivante... quitte à affronter un problème bizarre, autant lui soumettre une solution bizarre.
Puisque d'autres bases 9i sur ce même serveur n'étaient pas sujettes au problème, j'ai pris l'init.ora de l'une d'entre elles, j'y ai changé le SID, les chemins, etc., j'ai redémarré la base à problèmes avec ce nouveau init.ora, et j'ai tenté un export full... qui a marché.

Puis j'ai comparé l'ancien init.ora avec le nouveau, et j'ai testé un par un tous les paramètres qui étaient différents, avec à chaque fois A/R de la base et tentative d'export full. Jusqu'à ce que je tombe sur db_files (non précisé dans l'ancien init.ora, et positionné à 50 dans le nouveau).

Pour terminer, j'ai repris l'ancien init.ora, j'ai démarré la base avec, et tenté un export -> NOK, comme avant.
Puis j'y ai ajouté uniquement db_files=50, j'ai démarré la base avec, et etnté un export -> OK.

Mais ça me laisse perplexe...

[Pomalaix]

Merci pour le détail, et bravo pour avoir trouvé un contournement !
En souhaitant qu'il soit durable, ce qui n'est pas acquis.

Je pense que vous avez trouvé un levier parmi d'autres pour faire baisser un peu la consommation mémoire, mais que DB_FILES en tant que tel n'est pas plus coupable qu'autre chose.
Spontanément, j'ai du mal à faire le lien entre DB_FILES et la PGA, mais il y a sans doute plein de subtilités que j'ignore sur le sujet.
Mais surtout, si DB_FILES était véritablement en cause, vous n'auriez pas pu faire vos exports depuis des années, et ça n'aurait pas non plus marché dans votre test à travers le listener.

Sauf hypothèse de bug, il est probable que la vraie raison soit un paramétrage OS insuffisant par rapport au besoin actuel de votre base en PGA, ce besoin ayant parfaitement pu augmenter au fil du temps, alors que le paramétrage n'a pas bougé.