Pb de performances sous Oracle 10g

**kamalito** · 25/10/2005, 14h34

Bonjour,
Nous rencontrons un pb qui nous (DBA et développeur) étonne. Nous avons développé plusieurs packages qui ont pour fonctionnalité de charger un schéma d'une BD à partir d'un schéma de migration sur la même BD. C'est une appli qui tourne depuis plusieurs années (8i 9i ) et maintenant en 10g R2 sous AIX.
Depuis peu on a de très gros pb de performances
Principe:
On lit un fichier qu'on charge dans un schéma de migration, on fait nos p'tits traitements qui vont bien et on réplique en production. (PL/SQL)
Tous les fichiers ont la même taille et de même structure. Les lenteurs sont rencontrées lors de la phase de réplication donc rien à voir avec les fichiers. Dans les précédentes versions on désactivait les stats on a super bien optimisé nos requêtes.
Petite préciion qui nous sidère: les 4 ou 5 premières réplications vont de manière croissante et ensuite à partir de la 5ième réplication jusque la dernière et il en y a une dizaine, cela va super vite. On passe de 2h à 15' de traitement.
Autre précision : on a également désactivé les stats bien que nous soyons en 10g.

A votre avis Où peut on regarder ?

Merci d'avance

**Jaouad** · 25/10/2005, 14h38

Excusez moi mais je ne comprends pas quel est le probléme ??

ou alors j'ai mail lu

**orafrance** · 25/10/2005, 14h42

commence par réactiver les stats

Est-ce qu'il y a des materialized view log ? est-ce que c'est bien les materialized view qui sont utilisées ?

**kamalito** · 25/10/2005, 14h46

Envoyé par Jaouad

Excusez moi mais je ne comprends pas quel est le probléme ??

ou alors j'ai mail lu

J'esayais d'expliquer en quelques lignes que nous avons des pb de perfs. Exemple normal:
Première phase : ==> Un fichier est d'abord (PL/SQL) et le temps de traitement dure en moyenne 15min
Seconde phase : ==> Un traitement migre les données dans des tables de migration (PL/SQL) et le temps de traitement dure en moyenne 10min
dernière phase : ==> Un traitement de réplication prend les données des tables e migration vers un autre schéma de production (PL/SQL) et le temps de traitement dure en moyenne 7min.
Il y a environ 10 voire 15 fichiers d'environ 30MO à traiter (suivant la volumétrie du client).
Dans notre cas les deux premières phases restent constantes durant tous le processus et tout va bien. C'est la troisième phase qui ne va plus bien. Elle commence par mettre 7min, puis, 30min, puis 1h15, puis 2h , pour enfin revenir à 7min dès le 5ième fichier.
C'est etonnant non !

**Jaouad** · 25/10/2005, 14h49

Ok ,

Il vaut mieux comme le dit Fred calculer les stats dés que les données ont été insérés

Est ce que tu peux voir les explan plan des requêtes ?

Jaouad

**PpPool** · 25/10/2005, 14h53

Bonjour

la réplication se fait-elle sur un même serveur ou 2 serveurs distants ?

**kamalito** · 25/10/2005, 14h55

Oui on a fait du TKPROF et on a eu l'occasion de regarder les plans d'exécution, il sont parfaits simplement pour quelques requêtes pas très compliqées on a des temps affreux avec un plan d'exécution parfait.

Cela voudrait dire qu'il faudrait prévoir dans notre traitement entre chaque réplic. le calcul des stats ? C'est pas trop lour cette histoire ?

**orafrance** · 25/10/2005, 14h55

quel mécanisme de réplication est mis en oeuvre et quelle version d'Oracle (version compléte) ?

**kamalito** · 25/10/2005, 14h56

Envoyé par PpPool

Bonjour

la réplication se fait-elle sur un même serveur ou 2 serveurs distants ?

Oui sur un même serveur et la même instance.

**orafrance** · 25/10/2005, 14h57

Envoyé par kamalito

Oui on a fait du TKPROF et on a eu l'occasion de regarder les plans d'exécution, il sont parfaits simplement pour quelques requêtes pas très compliqées on a des temps affreux avec un plan d'exécution parfait.

si les plans sont bons c'est pas ça qu'il faut regarder dans Tkprof, c'est les événements d'attente et les phases qui posent problème ?

**kamalito** · 25/10/2005, 14h57

Envoyé par Fred_D

commence par réactiver les stats

Est-ce qu'il y a des materialized view log ? est-ce que c'est bien les materialized view qui sont utilisées ?

Non pas de materialized view.

Donc d'après toi il faudrait que je lance les stats entre chaque répliq ?

**kamalito** · 25/10/2005, 15h01

Envoyé par Fred_D

quel mécanisme de réplication est mis en oeuvre et quelle version d'Oracle (version compléte) ?

C'est du PL/SQL qui répliq. d'un schéma vers un autre.
C'est une version 10g R2 complète.

Oui effectivement on voit des dans la zone QUERY des chiffres affolant. mais là je sais pas quoi faire.
Il doit y avoir de la contention mais comment faire et voir quoi ?

**orafrance** · 25/10/2005, 15h09

Envoyé par kamalito

C'est du PL/SQL qui répliq. d'un schéma vers un autre.
C'est une version 10g R2 complète.

c'est clair comme de l'eau de boudin

Comment ? DBLink ? magie noire ? vaudou ? Lance pierre ?

que donne :

Code :

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

select * from v$version;

**bouyao** · 25/10/2005, 15h11

La meilleur solution est de lancer un statspack.

**Jaouad** · 25/10/2005, 15h11

Envoyé par Fred_D

Envoyé par kamalito

Oui on a fait du TKPROF et on a eu l'occasion de regarder les plans d'exécution, il sont parfaits simplement pour quelques requêtes pas très compliqées on a des temps affreux avec un plan d'exécution parfait.

si les plans sont bons c'est pas ça qu'il faut regarder dans Tkprof, c'est les événements d'attente et les phases qui posent problème ?

tu peux formatter ta trace avec waits=y

pour avoir les événnements d'attentes

Jaouad