Discussion :

[seb_asm]

J'ai besion de faire une jointure entre deux tables, où l'une représente une entête et l'autre les détails.

Je veux faire une jointure sur ces deux tables pour qu'à chaque entête soit associé ces lignes détails.

La clé primaire de l'entête es sur plusieurs champs et la clé primaire de détail est la même avec un champ en plus représentant le numéro de ligne.

Pour optimiser la jointure j'ai créé un index de type normal sur la table détail qui est l'équivalent de la clé primaire de la table entête.

Je voudrais savoir si c'est ce qu'il faut faire , car c'est la première fois que je fais ca, et en plus comment savoir si Oracle utilise bien mon index.

Merci

[SheikYerbouti]

Pour optimiser la jointure j'ai créé un index de type normal sur la table détail qui est l'équivalent de la clé primaire de la table entête.

c'est parfait.

[seb_asm]

Merci de répondre aussi vite.

Comment je fais pour savoir si Oracle utilise cette index.

J'ai entendu parler d'un plan d'exécution mais je connais pas.

[SheikYerbouti]

Vous affichez le plan d'exécution de votre requête

voyez l'article : http://sheikyerbouti.developpez.com/...timisation.pdf

[seb_asm]

Voilà le plan d'exécution :

Code :

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

1
2
3
4
5
 
SELECT STATEMENT, GOAL = CHOOSE			2	1	96
 NESTED LOOPS			2	1	96
  INDEX FULL SCAN	ODS_OWNER	PK_ESPDECAT		1	58
  INDEX UNIQUE SCAN	ODS_OWNER	PK_ESPDECET	1	2127884	80859592

ESPDECAT = Détail
ESPDECET = Entête

[SheikYerbouti]

Vos index sont donc bien utilisés.

[seb_asm]

Encore une petite question.

INDEX FULL SCAN signifie qu'il va utiliser l'index mais est qu'il va utiliser le bon?

Car il y a l'index sur la clé primaire qui s'appelle PK_ESPDECAT, alors que le 2ème index qui correspond à celui que j'ai créé pour correspondre s'appelle AK_ESPDECAT.

Et dans le plan d'exécution le object name est PK_ESPDECAT.

[SheikYerbouti]

A priori, les colonnes de votre PK sur la table détail suffisent à établir la correspondance. votre deuxième index semble donc redondant.

[seb_asm]

J'ai donc aucun moyen d'accélérer ma requête qui tourne depuis pratiquement 24h maintenant.

La différence étant que lorsque je l'ai lancé je n'avais pas encore fait l'index qui apparament sert à rien.

Par contre il y a un champ qui est toujours à la même valeur que je n'ai pas mis dans la jointure mais qui par contre est dans la clé et sonc voici la plan de celle lancée depuis 24h.

Code :

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

1
2
3
4
5
6
 
SELECT STATEMENT, GOAL = CHOOSE			426	2127884	191509560
 FILTER					
  NESTED LOOPS OUTER					
   INDEX FAST FULL SCAN	ODS_OWNER	PK_ESPDECET	426	2127884	74475940
   INDEX FULL SCAN	ODS_OWNER	PK_ESPDECAT		1	55

Est ce qu'en mettant la colonne correspondant au dernier champ de la clé et ainsi en obtenant ce plan :

Code :

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

1
2
3
4
5
 
SELECT STATEMENT, GOAL = CHOOSE			2	1	96
 NESTED LOOPS			2	1	96
  INDEX FULL SCAN	ODS_OWNER	PK_ESPDECAT		1	58
  INDEX UNIQUE SCAN	ODS_OWNER	PK_ESPDECET	1	2127884	80859592

J'irais un peu plus vite?

Entête environ 2 800 000 lignes.
Détail environ 3 800 000 lignes.

En fait decompte faire un index ou j'eleve juste une colonne par rapport à l'index de la clé primaire de la seconde table ne sert à rien.

[orafrance]

Entête environ 2 800 000 lignes.
Détail environ 3 800 000 lignes.

la volumétrie est quand même assez importante mais 24h ça parait long

Pourriez-vous fournir la requête est là où sont les indexes pour voir si il n'y a pas un probléme ?

Vous pouvez aussi regarder du coté des indexes partitionnés

[seb_asm]

Voilà ma requête :

Code :

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

1
2
3
4
5
6
7
 
select DEEADH,DEERNG,DEEDAT,DEENUM,DEEUTI,DETLIG 
from ods_owner.espdecet esp, ods_owner.espdecat cat
where CAT.DETADH(+) = ESP.DEEADH AND CAT.DETRNG(+) = ESP.DEERNG
AND CAT.DETDAT(+) = ESP.DEEDAT AND CAT.DETNUM(+) = ESP.DEENUM
AND CAT.DETUTI(+) = ESP.DEEUTI
AND CAT.Detlig is null

la PK de ESPDECET est : DEESIT, DEEADH, DEERNG, DEEDAT, DEEUTI, DEENUM.
Et la
PK pour ESPDECAT est : DETSIT, DETADH, DETRNG, DETDAT, DETUTI, DETNUM, DETLIG.

J'ai donc ces deux indexes créé par oracle et j'ai rajouté l'indexe dans ESPDECAT qui correspond exactement à la PK de ESPDECET.

Cependant j'ai fait ça après avoir exécuté la requête et je voulais savoir si ça allait accélérer la requête avant de l'arréter pour rien.

[thomasjcj]

Code :

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

1
2
3
4
5
6
7
 
select DEEADH,DEERNG,DEEDAT,DEENUM,DEEUTI,DETLIG 
from ods_owner.espdecet esp, ods_owner.espdecat cat
where CAT.DETADH(+) = ESP.DEEADH AND CAT.DETRNG(+) = ESP.DEERNG
AND CAT.DETDAT(+) = ESP.DEEDAT AND CAT.DETNUM(+) = ESP.DEENUM
AND CAT.DETUTI(+) = ESP.DEEUTI
AND CAT.Detlig is null

Les colonnes DETUTI et DEEUTI sont elle indexées ?

[orafrance]

ouh laaaaaaa... 2 PK avec les mêmes colonnes et constituer de 7 colonnes ça va pas du tout

Remplace la PK de la table mettre par un ID et ne mets que la colonne ID dans la table fille en FK avec un index, ça ira déjà beaucoup mieux

Ensuite, les jointures externes sont très consommatrices si bcp de lignes sont dans une table et pas dans l'autre, est-ce qu'il n'y a pas de critères discriminant possibles ?

Là il faut revoir le modéle à mon avis

[childeric]

le plan d'execution est caluclé au moment du lancement de la requette, donc ta création d'index n'est pas utilisée.

Si tu veux vraiement améliorer tes temps de réponse tu peux :

- Remplacer ta clé primaire par une clé unique
- inserer une colonne numérique qui te servira de clé primaire ( tu l'alimentes avec une séquence et un trigger)
-mettre cette colonne dans ta table détails en clé étrangère
- Crée un index sur cette colonne dans ta table détail

Ta jointure se faisiant sur une colonne unique de type numérique,tes temps de réponses seront fortement améliorer

[seb_asm]

Je veux bien recréer une clé primaire mais mon problème vient du fait de la mettre en clé étrangère dans le deuxième, car pour ça je vais bien être obligé de faire ma jointure?

De plus ces tables me serviront qu'une seule fois car c'est une reprise pour mettre dans une troisième table qui sera définitive.
Est ce que ça vaut le coup de les préparer autant pour une seule fois :

[orafrance]

- Remplacer ta clé primaire par une clé unique
- inserer une colonne numérique qui te servira de clé primaire ( tu l'alimentes avec une séquence et un trigger)

la clé unique à la place de la PK n'a d'intérêt que pour les update/insert mais pas le SELECT et que la PK soit en numérique ne change pas grand chose, c'est surtout de faire une PK sur une colonne au lieu de 6 qui sera intéressant

[seb_asm]

Je sais pas si vous avez vu ce message?

Ancien Message

[orafrance]

oui ça vaut le coup

[seb_asm]

La je viens d'alluciner

J'ai refait ma clé primaire en enlevant le champ qui était toujours identique et donc refait les deux clés primaires et les trois indexes.

En plus j'ai restructuré ma requête de cette manière :

Code :

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

1
2
3
4
5
6
7
8
9
 
select DEEADH,DEERNG,DEEDAT,DEENUM,DEEUTI,DETLIG 
from ods_owner.espdecet esp, ods_owner.espdecat cat 
where ESP.DEEADH = CAT.DETADH(+)
AND ESP.DEERNG  = CAT.DETRNG(+) 
AND ESP.DEEDAT = CAT.DETDAT(+)   
AND ESP.DEENUM = CAT.DETNUM(+) 
AND ESP.DEEUTI = CAT.DETUTI(+)
AND CAT.Detlig is null

E j'ai relancé la requête.
En moins de deux minutes il m'a trouvé toutes les lignes, c'est à dire environ 44000, alors qu'avant en 24h il avait trouvé 2000 lignes et avait donc même pas fini.

Pourquoi autant de différence

[SheikYerbouti]

Ramener une requête de 24h00 à 2 minutes, chapeau !!!