Discussion :

[zorglob]

Bonjour,

Je rencontre depuis quelques jours des problèmes de performances aléatoire sur un projet.

Pour présenter de quoi il en retourne, je vous explique brievement ce qui se passe :

J'ai une base Oracle9i qu'on va appeler B1 et une base distante Oracle10g qu'on va appeler B2. J'ai créé un DBLink entre les 2 bases. La connection entre les 2 "reseaux" se fait via un VPN.

J'ai un package P1 dans la base B1 qui appel un Package P2 dans la base B2 via mon DBLink. (execute immediate 'P2.Mafonction@MONDB_LINK')

Dans 90% du temps, tout se passe tres bien et je constate des temps de réponse acceptable.

Dans 10% des cas, j'ai, au moment d'appeler la premiere fonction distante de P2 un retour de la fonction hyper tardif (de l'ordre de 40 secondes, voir parfois beaucoup beaucoup plus)

J'ai fais des tests dans tout les sens pour essayer de comprendre pourquoi parfois c'est lent (probleme de VPN, problème de locks, activité important de la base B1 ou B2 ...) mais rien n'explique mes problemes de lenteur qui arrivent de facon aleatoire.

J'ai constaté que le Package P2 est "gros" et j'ai decidé de le coupé en 2 pour voir si ca ne viendrait pas de la et bizarrement ca a l'air d'être mieux.

Donc j'aimerais savoir si il y a des limites de taille d'un package sur oracle ? Si oui lesquels ? Et si du coup mon probleme vient apriori de la et pas d'autre chose.

Si vous avez des idées elles sont les bienvenues.

D'avance merci.

[sgora]

Le test le plus pertinent aurait été de copier le package en local et de voir si la différence (hors gain réseau) était significative.
Le problème vient plus sûrement d'une ou plusieurs de tes requêtes de ton package qui peuvent être différemment interprétées par les optimiseurs oracle.
Les requêtes faisant intervenir des sites distants par db_link peuvent se révéler également instables, en fonction notamment du site qui va parser et exécuter la ou les requêtes considérées (le DRIVING SITE selon la terminologie Oracle).

Bref, c'est un vaste problème...

[mnitu]

Vous ne savez pas ce qui se passe. Vous avez faite une hypothèse et maintenant vous cherchez quelque un pour vous réconforter.
Alternativement, vous pouvez tracer la session SQL en mode étendue et analyser la trace d’une de vos exécutions de la procédure qui s’avère à être lente, pour comprendre où le temps passe.

[zorglob]

Je ne suis sans doute pas assez rentré dans le détail, ce qui explique sans doute vos réponses. Pour etre plus précis je vais vous detaillé un plus ce qui se passe :


Debut de B1.P1.FonctionPrincipale

- Je fais un test de pour savoir si la connection entre les bases est opérationnel (VPN monté ou autre) via un SELECT sur une table de B2

-Si le test est ok alors :

1. J'appel B2.P2.Fonction1 et je récupère le résultat
2. En fonction du résultat de Fonction1 j'appel ensuite B2.P2.Fonction2 qui renvoie également un résultat
3. En fonction du résultat de Fonction2 j'appel une fonction B2.P2.Fonction3
   ect ...

Fin de B1.P1.FonctionPrincipale


J'ai bien sure collé des logs partout et bien entendu avant et apres chaque appel de fonction pour voir ou se situe les lenteurs.
A chaque fois qu'on a constaté des lenteurs, c'etait à l'appel de la premiere fonction B2.P2.Fonction1 ( le log apres l'appel de la fonction datait de 30s, 40s voir plusieurs minutes apres le Log précedent)

J'aavais d'abord pensé à un probleme réseau, mais puisque je fais un test avant l'appel de la fonction et que ce test repond rapidement, j'ai ecarté ce probleme.

J'ai ensuite imaginé que c'etait ma premiere fonction qui posait probleme car les fonctions suivantes s'echainaient TOUJOURS rapidement. J'ai donc modifié ma fonction pour qu'elle ne fasse RIEN si ce n'est un simple RETURN d'une chaine vide.
Les lenteurs etaient toujours la, et toujours sur ce "premier appel" de fonction (les suivantes s'executant toujours normalement)


J'ai ensuite isolé la fonction 1 en la mettant dans un package seul B2.P3 et j'ai modifier mon package B1.P1 afin d'appeler cette fonction seule, puis d'appeler les autres fonctions comme avant à savoir B2.P2.Fonction2, B2.P2.Fonction3 ...
Les lenteurs etaient maintenant au niveau de l'appel de la Function B2.P2.Function2

J'en ai conclu qu'il s'agissait d'un probleme lié a mon package car je n'avais pas franchement d'autres explications (vos suggestions sont les bienvenues).

Puisque certaines fonctions de mon package P2 ne sont jamais appelées par B1.P1, j'ai décidé de découper mon package avec d'un coté les fonctions appelée par B1.P1 et de l'autre les fonctions qui était directement déclenchée par le package B2.P2
et depuis ca à l'air de répondre correctement à chaque fois.

J'en ai donc conclu qu'il pouvait peut etre s'agir d'un probleme lié a la taille de mon package car il est assez gros et parce que n'etant pas un expert oracle (je debute) je n'avais pas d'autres idées.

[sgora]

Tout dépend de ce que tu fais dans ces fonctions, tu fais référence à des objets de B2, B1, les deux ?

Comme te le conseille mnitu, le mieux est de faire une trace de ta session quand tu lances ce package.

Au fait, gros pour toi, c'est combien de lignes de code ?

[zorglob]

Chaque Base B1 ou B2 ne font jamais référence à des table de l'une ou l'autre.
J'entend par la que ce sont des bases dont les tables n'ont rien en "commun", mes packages lorsqu'ils travaillent sur les données, le font uniquement sur des tables locales.

Si vous voulez, B1 déclenche l'appel d'une fonction sur B2 qui est censé travailler localement, et me renvoyer quelque chose. Donc mis à part les paramètres des fonctions et le résultat des fonctions, rien n'est censé transiter entre les bases.

Concernant la taille de mon package, le fichier texte fait 275ko pour 6000 lignes de code.

Le problème c'est que je veux bien tracer tout ce que vous voulez mais je ne vois pas quoi tracer puisque le problème intervient de façon aléatoire et que je pourrais tout aussi bien n'appeler que ma première fonction qui je le rappel ne fait rien et ça serait toujours lent "parfois".