J'ai un problème de performance avec une requête SQL.
Je dispose du cas concret suivant :
 
- Sur un serveur de développement, une requête met 5 mn.
(date d'achat du serveur : décembre 2003)
 
- Sur un serveur de production, cette même requête met 45 mn.  
(date d'achat du serveur : juin 2002)
 
La capacité en RAM est identique (1 GO)
Le CPU et les disques sont plus performants.
 
 
Comment "tester" les performances d'un serveur Oracle, ainsi que les flux d'entrée-sortie ?
Je suppose en effet qu'un serveur plus performant permet d'améliorer les temps d'exécution d'une requête, mais ici on a un facteur 9 (on passe de 5 mn.... à 45 mn).
 
C'est la première chose que je voulais tester, avant les paramètres Oracle.
 
 
Merci d'avance.

tu peux detailler tes configs stp ?
 
il fait autre chose que de l'oracle ton serveur de prod ?
 
tu tournes en quel version d'oracle ?
 
de 5 a 45 ça fait facteur 9

T'as vérifié que t'avais bien des index correctement créés et à jour ?
 
Deplus, c'est quoi la charge et la volumétrie ? Parceque si c'est pas identique, c'est normal que tu aies des différences.
 
Peux-tu poster ta requête qu'on voit à quoi elle ressemble ? Parceque pour que ce soit aussi lent, soit tu tapes dans 500 tables de 100 Go chacune, soit elle est écrite comme un sagouin... (soit t'as pas d'index évidement)

J'utilise Oracle 8.1.7.
 
Les données de dev et de prod sont les mêmes.
 
Mes serveurs sont des serveurs servant uniquement pour Oracle.
 
Les index sont correctement creés et à jour.
 
La requête est composée de 2 parties : les 2 parties prises indépendemment sont rapides, mais j'ai un NOT IN (2 sous-requêtes donc), qui consomme énormément de CPU.

ton CBO est a jour sur les 2 ?

Comment voir si le cost based optimizer est à jour ?

on veut voir les requetes et des infos sur la charge et la volumétrie. parce que 45minutes, c'est une sacré pause café

Sinon, je le dirai jamais assez mais... Si y'a moyen d'éviter le NOT IN, bah... Voilà

 
+1

J'ai eu une idée :  
les 2 sous-requêtes sont vraiment merdiques.
Je vais mettre leur contenu dans des tables, et faire un select sur ces tables.

tu peux poster ta requête qu'on voit ça ?

J'ai déjà fait un post presque similaire, mais je la remets :
 
(Oracle a des problèmes avec le plan d'exécution)
 
SELECT DISTINCT adhe_no_bull, Cour_dat_eff,
Cour_nom_adhes,cour_cod_prod,cour_cod_part,  
cour_cod_aven, DOCUMENTS.*
FROM   COURRIERS, DOCUMENTS, Adhesions, adherents
WHERE  DOCU_CODE = COUR_COD_AVEN
AND    DOCU_TYPE = COUR_COD_PROD
AND    COUR_COD_PROD =72
AND    COUR_COD_AVEN ='GAIN'
and    ADHE_NO_ADHES = COUR_NO_ADHES
and    adhe_no_adher = adhr_no_adher
and    adhr_dat_deces is null
and    (adhe_dat_cpta is not Null)
and    ((adhe_flg_transfert = 0 ) or (adhe_flg_transfert = 1 and adhe_cont_recep is not null))
and adhe_no_bull NOT IN ( select adhe_no_bull from adhesions, evenements
                          where adhe_cod_prod = even_cod_prod
                          and adhe_no_adhes = even_no_adhes
                          and adhe_cod_prod =72
                          and ( (adhe_dat_cpta is Null )
                                or (adhe_flg_transfert = 1 and adhe_cont_recep is null)
                                or even_dat_val is null)
                          and (adhe_cod_etat is null or not adhe_cod_etat in ('AL','A3'))
                          )

c'est pas le post où je t'avais réécrit la requête sans le not in ? il me semble la reconnaître

parceque pour info, t'as deux trucs affreux dans ta requête, qui expliquent les mauvaises perfs :
-> NOT IN (surtout qu'il est superflu, avec un not exists mieu écrit, tu gagnes à la fois parceque not exists est plus rapide et parceque la sous-requête que je t'ai filé est mieu écrite)
-> DISTINCT qui est une usine à gaz dès que tu as pas mal de colonnes (ce qui est le cas) et beaucoup de ligne (ça je sais pas)

C'était celle là en effet !
 
Bon je la réécris.... mais j'avais eu du mal avec l'explication du post précédent.