Requête avec une performance minable

**nuke_y** · 13/12/2006, 17h30

Super. Tu pourrais nous donner les 2 plans d'exécution maintenant ?

En tous cas vu le faible volume, je confirme qu'on devrait avoir des résultats plus rapides.

**Oz-WereWolf** · 13/12/2006, 18h00

Pour le plan d'exécution, je ne sais pas.

Le problème a été reproduit chez un client, pas chez nous.

Sur nos différentes bases de test, nous n'avons que 10 % de ce volume (oui, je sais

).

Un plan d'exécution fait chez nous irait aussi ou non ?

**nuke_y** · 13/12/2006, 18h05

Ben malheureusement non, il nous faudrait celui de chez le client pour voir quel est le problème.

Mais je trouve ça bizarre que tu n'ais pas d'index sur immat.ETC_ID ni sur etatcivilp1_.ETC_ID. D'ailleurs tu n'en as aucun sur EC_ETATCIVIL ?

**Oz-WereWolf** · 13/12/2006, 18h09

Envoyé par nuke_y

Ben malheureusement non, il nous faudrait celui de chez le client pour voir quel est le problème.

Alors là, c'est rapé.

Envoyé par nuke_y

Mais je trouve ça bizarre que tu n'ais pas d'index sur immat.ETC_ID

En fait, il y a une contrainte FK vu que ETC_ID est l'identifiant de etatcivil.

Envoyé par nuke_y

ni sur etatcivilp1_.ETC_ID. D'ailleurs tu n'en as aucun sur EC_ETATCIVIL ?

Je l'avais oublié parce que pour moi il est implicite. Dans etatcivil, l'index sur ETC_ID est la clé primaire unique.

**orafrance** · 13/12/2006, 18h47

Envoyé par Oz-WereWolf

Un plan d'exécution fait chez nous irait aussi ou non ?

Oui à condition d'importer les stats du client... sinon, je ne vois pas comment tu pourrais travailler sur les perfs sans l'environnement cible

Au pire envoie nous les plans de ton environnement

**nuke_y** · 13/12/2006, 19h56

Mouaih, disons qu'au moins on verra si les plans ressemblentà quelquechose, même avec 10% du volume.

**remi4444** · 13/12/2006, 22h33

Franchement, ce ne sont pas des volumes ennormes, il y a des index correctement placés, la requête est simple (j'aime pas le distinct mais bon tant pis...) y'a aucune raison de galérer longtemps sur ce type de requête...

Il faut juste trouver le hic... à ta place, en premier lieux je demanderais au client:
- Combien de lignes ramène cette requête ?
- de vérifier qu'il y a bien tous les indexs que tu nous a donnés (clef-primaire et contraintes uniques équivalent à un index, pas une FK)
- de passer les stats.

si la requête ramène peu de lignes et que les 2 autres critères sont respectés, elle ne doit pas mettre plus d'une demi-seconde....

Je peux pas m'empecher, je vais quand meme revenir sur le distinct... (désolé une vielle alergie

)... Qu'est-ce qui justifie d'en mettre un vu que EC_ID est unique et que je suppose (peut etre mal?) que IMM_NUM est unique pour ta table IM_IMMATRICULATION ?

J'ai l'impression que le distinct est là pour masquer les doublons provoqués par la jointure avec ta table d'historique immservi2, or cette jointure ne se justifie pas puisque tu ne ramène aucune des colonnes de cette dernière table dans ton select. Comme cette table ne sert que de filtre, alors il faut utiliser l'instruction sql de filtrage qu'est EXIST.

Dans un modèle de données propre, le distinct ne se justifie quasiment jamais et je suis prêt à argumenter longtemps pour le prouver

. Son utilisation est certes pratique mais très dangeureuse car elle peut masquer des grosses erreurs d'écritures de requêtes.

En dehors des points que je t'ai signalé (qui devrait déja résoudre) je te propose de réécrire la requête de manière plus pure par rapport à ton besoin:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
SELECT /* PAS DISTINCT ;) */ immat.IMM_NUM AS col_0_0_,
		      immat.IMM_DAT_DEPART AS col_1_0_,
		      immat.IMM_ID AS col_2_0_,
		      etatcivilp1_.ETC_NOMUSU AS col_3_0_,
		      etatcivilp1_.ETC_NOMPAT AS col_4_0_,
		      etatcivilp1_.ETC_PSEUDO AS col_5_0_,
		      etatcivilp1_.ETC_PRENOM AS col_6_0_,
		      etatcivilp1_.ETC_DAT_NAISSANCE AS col_7_0_
FROM IM_IMMATRICULATION immat,
	EC_ETATCIVIL etatcivilp1_
 WHERE immat.ETC_ID=etatcivilp1_.ETC_ID
   AND immat.ETS_COD='LYON'
   AND immat.IMM_NUM='100755'
   AND (immat.IMM_DAT_DEPART IS NULL OR   immat.IMM_DAT_DEPART>=SYSDATE)
AND EXISTS (
 SELECT 1 FROM IM_SERVICE immservi2_ 
   WHERE  immservi2_.IMS_FLG_NEUTRE=0
    AND immservi2_.IMM_ID=immat.IMM_ID
    AND immservi2_.ETS_COD=immat.ETS_COD )
ORDER BY immat.IMM_NUM ASC

Si avec tout ça, tu n'a pas une réponse instantanée, je veux bien rentrer au couvent...

**nuke_y** · 13/12/2006, 23h19

Tu t'appelleras soeur Marie-Thérèse.ora ?

**Oz-WereWolf** · 14/12/2006, 00h00

Alors...

La table des services peut contenir plusieurs enregistrements en cours à une date données.

Pourquoi cette jointure ?

Alors là, on rentre dans un système nébuleux d'habilitations : l'utilisateur peut avoir le droit de voir un service et pas d'autres.

Ce que je ne comprends pas (je ne connais pas cette partie du code), c'est que dans mon log hibernate, je ne vois jamais la table des habilitations. Donc, je ne sais pas comment c'est calculé.

**orafrance** · 14/12/2006, 07h58

ON VEUT LE PLAN D'EXECUTION

**Oz-WereWolf** · 14/12/2006, 09h28

Ouais, ben un moment parce que là, c'est chaud au taf.

On me reproche de vouloir améliorer les performances au lieu de développer...

**nuke_y** · 14/12/2006, 10h03

Oui ça m'arrive tous les jours ce genre de choses. M'enfin c'est comme ça qu'un projet à plusieurs millions d'euros a finalement été abandonné parce qu'il avait toutes les fonctionnalités qu'il fallait mais qu'il fallait attendre 20s à chaque clic...

**orafrance** · 14/12/2006, 10h13

Envoyé par Oz-WereWolf

Ouais, ben un moment parce que là, c'est chaud au taf.

On me reproche de vouloir améliorer les performances au lieu de développer...

aucun problème, tu auras remarqué le smilie

Bon courage et on attend la suite

**remi4444** · 14/12/2006, 11h38

Envoyé par Oz-WereWolf

Alors...

La table des services peut contenir plusieurs enregistrements en cours à une date données.

Pourquoi cette jointure ?

Alors là, on rentre dans un système nébuleux d'habilitations : l'utilisateur peut avoir le droit de voir un service et pas d'autres.
....

Je ne remets pas du tout en cause le fait de croiser avec la table des services (c'est du metier je me permetrais pas....) simplement, vu qu'aucune de ses colonnes n'est ramenée dans le select, c'est donc qu'elle ne sert qu'a faire du filtrage. Et donc la methode prévue pour ça, c'est EXISTS et non la jointure conventionnelle.
C'est une erreur classique, on apprend le sql en commençant par les jointures, du coup, on ne voit plus l'utilité d'aprendre le filtrage étant donné qu'on s'en sort fonctionnellement avec des DISTINCT. Mais c'est vraiment pas optimum, car dans un premier temps on demande à oracle de croiser et ramener potentiellement beaucoup de données (imagine qu'il y ait 10 000 correspondances avec ta table de service) puis dans un 2ieme temps on lui demande de dédoublonner (donc de trier). Donc sans le voir, il peut y avoir un rapatriement de 10 000 lignes en mémoire, puis un tri de 10 000 lignes pour un resultat final d'une seule ligne. Alors qu'avec le EXISTS, oracle va arrêter sa recherche à la premiere ligne trouvée et ensuite il n'aura rien a dédoublonner...

**Oz-WereWolf** · 13/08/2007, 23h36

Bonjour,

Content de voir que ce fil continue de vivre.

Pour donner quelques nouvelles de la requête initiale : rien n'a changé à part le fait que j'ai quitté cette société depuis début mars.

Visiblement, depuis, les méthodes de développement n'ont pas changé et mes collègues survivants cherchent désespéremment à fuir.

Bonne soirée.

Requête avec une performance minable

Oracle

Discussions similaires

Partager

Partager