Discussion :

[StringBuilder]

Bonjour,

J'ai une requête (qui était déjà pas bien rapide) qui est devenue totalement inutilisable.

J'ai identifié quelle partie coince :

Tables impliquées :
EVE
=> INDEX UNIQUE sur (CODSOC, ACHVTE, TYPEVE, NUMEVE)

EVL
=> INDEX UNIQUE sur (CODSOC, ACHVTE, TYPEVE, NUMEVE, NUMPOS, NUMLIG)

PRO
=> INDEX UNIQUE SUR (CODSOC, CODPRO)

Code sql :

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

1
2
3
4
5
6
7
8
 
select *
from eve
inner join evl on evl.codsoc = eve.codsoc and evl.achvte = eve.achvte and evl.typeve = eve.typeve and evl.numeve = eve.numeve
inner join pro on pro.codsoc = 1 and pro.codpro = evl.codpro
where eve.codsoc = 8001
and eve.achvte = 'A'
and eve.typeve = 'PLA'

Sur le serveur de DEV, cette requête fait un RANGE SCAN sur les index uniques de EVE et EVL, et un UNIQUE SCAN sur PRO, pour un coût de 167. La requête est instantanée (moins de 0,1 seconde)

Sur le serveur de REC, cette requête fait un RANGE SCAN sur les index uniques de EVE et EVL, mais un FAST FULL SCAN sur PRO, pour un coût de plus de 90000. J'ai stoppé la requête au bout de 5 minutes.

Les index sont les mêmes sur les deux serveurs, même version (c'est deux instance sur un même serveur).

La volumétrie est cependant passablement différente :

DEV :
- EVE : 30 383
- EVL : 67 970
- PRO : 136 419

REC :
- EVE : 25 015 883
- EVL : 84 233 838
- PRO : 428 292

Ok, des rapports de 1 pour 1000, c'est loin d'être anodin.
Mais pourquoi passer d'un UNIQUE SCAN à un FAST FULL SCAN ?
Si j'enlève la jointure sur PRO, la requête est immédiate. La requête retourne alors moins de 50 lignes. Comment 50 lectures sur PRO, en se basant sur un INDEX UNIQUE peuvent être aussi lentes ?

[Linkin]

Soit la requête est fausse (codsoc =1 et codsoc=8001), soit elle fait un produit cartesien avec PRO, dans ce cas, vu la volumétrie de la table, les temps de réponses ne m'étonnent pas.

[escartefigue]

Combien y a -t- il de valeurs distinctes pour vos colonnes index sur la table PRO, si très peu, votre index n'est pas éligible

[mnitu]

Se qui evp dans

Code :

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

1
2
and pro.codpro = evp.codpro

Postez la bonne requête ainsi que les informations du plan d'exécution réel si possible sinon on perte notre temps.

[StringBuilder]

Excusez-moi, c'est pas EVL, mais EVL qu'il faut lire dans la jointure de PRO.

Le modèle des données ne contient pas de PK ni de clé étrangères.

Et la colonne "CODSOC" permet d'avoir un niveau de gestion (société) différent d'une entité à l'autre (table).

Ici, les produit (PRO) sont gérés dans la société 1 (groupe), et les événements (EVE, EVP, EVL, EVT) sont gérés en société juridique (8001 dans l'exemple).

J'ai simplifié le code en mettant ces valeurs en dur. Il y a une table MEV qui permet de faire la jointure "proprement" (autant faire se peut). Mais qu'elle soit présente ou non, ne change rien.

Quant à la question sur l'éligibilité de l'index sur PRO, je comprends pas la question : les index que j'ai indiqué sont des index UNIQUES, donc il y a 428 292 lignes dans la table PRO, et 428 292 valeurs uniques dans l'index (même si presque toutes les lignes ont le même CODSOC).

Sinon, les performances n'ont rien de normal, avant passage à Oracle 11, c'était la même base, un serveur vieillissant moindrement configuré, et on n'avait pas du tout de problème avec cette table. Je le répète, historiquement, ce type de jointure ne change pas un millième de seconde en temps normal.

Il n'y a qu'une seule ligne PRO par EVL, donc avec la jointure sans PRO, on a 50 lignes, c'est pas comme si on ramenait des millions de lignes.

EVE : Commandes
EVL : Ligne de cadencement de la commande (un produit/un dépot de livraison/une date de livraison/un lot/un emplacement)
PRO : Produit

On a donc N cadencements pour une commande. Mais 1 produit pour un cadencement.

Les index uniques que j'ai indiqué sont l'équivalent des clés primaires (qui n'existent pas dans la base). Donc vu la nature des jointures, il ne peut pas y avoir de meilleur candidat.

[escartefigue]

Quant à la question sur l'éligibilité de l'index sur PRO, je comprends pas la question : les index que j'ai indiqué sont des index UNIQUES, donc il y a 428 292 lignes dans la table PRO, et 428 292 valeurs uniques dans l'index (même si presque toutes les lignes ont le même CODSOC).

OK en ce cas on oublie la question