Optimisation de requête

Citation:

---

Envoyé par cedrich

Déjà merci à tous,

Le temps doit être le plus bas possible car cette vue entre dans processus de calcul. Ce processus actuellement prend 1h pour générer une 100 de facture d'une centaine de ligne ce qui tout simplement innacpetable pour le client.

J'ai également lancé une trace Oracle pour voir qu'elles seraient les requêtes qui pourraient poser problème. De là, j'en ai tiré un index qui manquait, malgré cela, c'est toujours trop lent.
...

---

Désolé, mais « le temps doit être le plus bas possible » n'est pas une cible d'optimisation. Il est toujours possible d'améliorer encore, pourvu que les ressources nécessaires soient disponibles. Tu dois optimiser les requêtes qui utilise la vue et non pas la création de la vue. Donc utilise la trace pour identifier les requêtes qui consomme trop de temps et ensuite essaie de les optimiser.

@orafrance ok, merci!:oops:

@mnitu Alors le seul vrai consommateur est cette partie là :

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 32 33 34

SELECT LEVEL, ID, SEQ_TRI FROM DB_CHAPITRE_STRUCTURE STRUCT START WITH ID = :b1 CONNECT BY PRIOR DB_CHAPITRE_STR_PARENT_ID = ID   call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 0 0.00 0.00 0 0 0 0 Execute 114140 1.98 1.91 0 0 0 0 Fetch 342420 5.81 5.98 0 684840 0 228280 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 456560 7.79 7.89 0 684840 0 228280   Misses in library cache during parse: 0 Optimizer goal: CHOOSE Parsing user id: 23 (IDINFO) (recursive depth: 1)   Rows Execution Plan ------- --------------------------------------------------- 0 SELECT STATEMENT GOAL: CHOOSE 0 CONNECT BY (WITH FILTERING) 0 TABLE ACCESS GOAL: ANALYZED (BY INDEX ROWID) OF 'DB_CHAPITRE_STRUCTURE' 0 INDEX GOAL: ANALYZED (UNIQUE SCAN) OF 'DB_CHAPSTR_PK' (UNIQUE) 0 NESTED LOOPS 0 BUFFER (SORT) 0 CONNECT BY PUMP 0 TABLE ACCESS GOAL: ANALYZED (BY INDEX ROWID) OF 'DB_CHAPITRE_STRUCTURE' 0 INDEX GOAL: ANALYZED (UNIQUE SCAN) OF 'DB_CHAPSTR_PK' (UNIQUE) 0 TABLE ACCESS GOAL: ANALYZED (FULL) OF 'DB_CHAPITRE_STRUCTURE'

---

En ajoutant un indexe sur le colonne "DB_CHAPITRE_STR_PARENT_ID", c'est encore un peu plus lent. Donc je l'ai supprimé.

Je suis en train de regarder pour insérer cette valeur dans une table afin de ne pas le recalculer dans la vue pour chaque ligne.

J’aime pas trop la trace parce que la colonne rows ne montre pas les infos utilises à la compression du plan.
On constate que tu a exécute 114140 fois la requête et que chaque fois tu a fait 3 fetch (342420 = 114140 * 3) pour ramener chaque fois 2 lignes (114140 * 2 = 228280) et tout ça a pris 8 secondes. Est-ce que c’était à chaque fois les mêmes valeurs ? Si tu avait exécuté une seul fois la requête les temps cpu aurait être 0.00 (inférieur à la granularité de mesure). Trop d’inconnue pour pouvoir cibler le problème.
N'ajoute pas des index. Commence par chercher et comprendre le problème. Seulement après tu peux parler des solutions.

Voilà, j'ai résolu mon problème.

J'ai crée une nouvelle table qui contient la hierarchie qui était calculé dans la vue (Elle sera alimenté via un trigger). Le temps de calcul pour une facture est passé de ~27s à < 5s, ce qui est très satifaisant pour le moment.

Le problème est liée au connect by prior qui changait pour chaque ligne de ma vue. En le stockant dans une table, je m'évite ce calcul couteux et le temps devient à nouveau acceptable.

Merci à tous de votre aide.

plutôt qu'une table, tu aurais également pu créer une vue matérialisée ;)