Performance inégale des requêtes sur même environnement

[schumi101]

Bonjour,

Sous oracle 8i, hier j'ai exécuté une requête SQL à partir de l'outil business Object, cette dernière premais 15 secondes.

Aujourd'hui sur le même environnement cette requête prend plus de 30 minutes.

Quels sont les paremètres qui peuvent intervenir pour une telle différence de performance (problème de cache, surcharge sur serveur autre...)


Merci pour votre lumière, car je n'ai pas d'explication

A titre d'information voici la requête

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
 
SELECT   
  P_BAREME.FK_GBA_OPERATEUR,
  P_BAREME.BAREME,
  P_BAREME.NOM,
  to_date(to_char(P_BAREME.DATE_DEBUT,'dd/mm/yyyy'),'dd/mm/yyyy'),
  to_date(to_char(P_BAREME.DATE_FIN,'dd/mm/yyyy'),'dd/mm/yyyy'),
  P_TYPE_BAREME.TYPE_BAREME,
  P_GROUPE_BAREME.GROUPE_BAREME,
  NVL(P_BAREME_REFERENT.FK_GBA_OPERATEUR, ' '),
  NVL(P_BAREME_REFERENT.BAREME, ' '),
  to_date(to_char(P_BAREME_REFERENT.DATE_DEBUT,'dd/mm/yyyy'),'dd/mm/yyyy')
FROM
  P_BAREME,
  P_TYPE_BAREME,
  P_GROUPE_BAREME,
  P_BAREME  P_BAREME_REFERENT
WHERE
  ( P_GROUPE_BAREME.FK_TBA_OPERATEUR=P_TYPE_BAREME.FK_OPERATEUR AND P_GROUPE_BAREME.FK_TBA_TYPE_BAREME=P_TYPE_BAREME.TYPE_BAREME  )
  AND  ( P_BAREME.FK_BAR_BAREME_ALTERNATIF=P_BAREME_REFERENT.NUMERO_BAREME(+)  )
  AND  ( P_BAREME.FK_GBA_GROUPE_BAREME=P_GROUPE_BAREME.GROUPE_BAREME AND P_BAREME.FK_GBA_TYPE_BAREME=P_GROUPE_BAREME.FK_TBA_TYPE_BAREME AND P_BAREME.FK_GBA_OPERATEUR=P_GROUPE_BAREME.FK_TBA_OPERATEUR  )
  AND  (
  to_date(to_char(P_BAREME.DATE_DEBUT,'dd/mm/yyyy'),'dd/mm/yyyy')  <=  '07/11/2007'
  AND  to_date(to_char(P_BAREME.DATE_FIN,'dd/mm/yyyy'),'dd/mm/yyyy')  >=  '31/01/2000'
  AND  P_BAREME.FK_GBA_OPERATEUR  IN  ( '9T','B3G','BYT','COLT','CPTEL','CWF','FFMV2','FREE','FTF','FTLD','FTLDH','FTLDM','FTLDO','FTMRD','MFS','MONAC','OCR','OGPRS','OMMS','OMSP','ORLCF','ORORT','OVGT','OVT','OWHA','OWIFI','OZB','SFR','SIRIS','SMSC','SMSR','TD','TELE2')
  AND  P_TYPE_BAREME.TYPE_BAREME  IN  ('CNP','NNG','TBEQ')
  AND  P_GROUPE_BAREME.GROUPE_BAREME  IN  ('APN_INT','APN_NAT','CS','GBEQT','INDET','INTERNAT','MOBILES','NATIONAL','NUMSPEC')
  AND  P_BAREME.BAREME  LIKE  '%'
  AND  P_BAREME.AUT_IND  IN  @variable('A','S')
  AND  P_BAREME.BAREME  !=  ' '
  )

J'ai pensé que cela pourvait provenir du choix de l'optimizer mode vu que par défaut il est a choose. Je l'ai donc passé à first_rows mais aucune amélioration

Merci pour votre aide
cordialement

[orafrance]

les stats ont elles été recalculées cette nuit et y a-t-il eu une grosse différence de volumétrie depuis le dernier calcul de ces stats ?

[schumi101]

Cela aurait pu être une bonne raison mais ce n'est pas le cas.

De Orafrance, ce n'est pas hier, je manipule des tables avec la plus grosse qui est 9800 lignes qui est oc_bareme.

La différence comparé à hier c'est que j'utilise un alias de cette table.

[orafrance]

dans ce cas, il faut t'intéresser aux waits. Fait une trace de niveau 12 et applique un tkprof

[schumi101]

Peux tu me donner plus d'information concernant cette trace, pourquoi niveau 12? et tkprof c'est quoi??

Désolé de poser ces questions mais faut bien apprendre un jour.

NB: je ne suis pas connecté en system manager mais je suis propriétaire du schéma

[orafrance]

http://orafrance.developpez.com/dbahelp/#L3

level 8 suffit pour les waits mais level 12 permet de voir la valeur des bind variables

[13thFloor]

Une table (ou plusieurs) a t-elle été déplacée ?
D'autres traitements en cours au moment ou tu as lancé la requête (rebuild, sauvegarde, export...) ?
L'admin système a activé les caches io ?
Rien dans l'alert.log suite à un éventuel startup ?
De 15" à 30' c'est fort !

Un report de statspack permettra de voir ce qu'il se passe pendant le traitement de la requête.

[schumi101]

d'après vous ces quoi la cause principale sachant que l'environnment n'a pas évolué??

[13thFloor]

Envoyé par schumi101

d'après vous ces quoi la cause principale sachant que l'environnment n'a pas évolué??

- méga surcharge du serveur (io de folie, pagination excessive, mémoire saturée...)
- activité hyper intense sur la base
- nouveau plan d'exécution désastreux mais cela se produit sous certaines conditions : nouvelles statistiques (ou effacement), modification de paramètres, tentative de parallélisation (modification du dégré d'une des tables) etc.
- une bind variable qui fout la grouille + cursor_sharing=FORCE

[13thFloor]

Un index invalide est peut être la cause. Mais devrait-il apparaître dans le plan d'exécution alors qu'il est unusable ?

Vérifies le status des index utilisés. Si unusable => rebuild + recalcul des stats.