Pour info il avait écrit 3700 millisecondes au début !!!Envoyé par Garuda
3 700 secondes = 1 heure !
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Pour info il avait écrit 3700 millisecondes au début !!!3 700 secondes = 1 heure !
~ Lola ~
bien oui je confirme ... Et le temps de réponse est mon soucis juste en ajoutant une condition dans ma clause "where " .... je comprend pas bien pourquoi
Et c'est quoi : MATERIALIZED_VIEW
Une vue matérialisée se comporte comme une table créée par le résultat d'une requête (typiquement celle de ta vue en fait). Il faut la rafraîchir pour avoir les derniers résultats (elle ne se met pas à jour automatiquement, comme une vue). L'avantage est de pouvoir la traiter presque comme une table, l'analyser, mettre des index etc.
- Rajouter un champ dans avi_evaluation qui top si UPPER(intervenant_departement) contient la chaine FINANCE.
- Changer avi_evaluation en vue matérialisée qui se comportera plus comme une table (possibilité d'analyser et de mettre des index, comme dit par Garuda)
- Eventuellement rajouter un index sur le top pour mieux le brasser.
- So.... what exactly is preventing us from doing this?
- Geometry.
- Just ignore it !!
****
"The longer he lived, the more he realized that nothing was simple and little was true" A clash of Kings, George R. R. Martin.
***
Quand arrivera l'apocalypse, il restera deux types d'entreprise : les pompes funèbres et les cabinets d'audit. - zecreator, 21/05/2019
Arrêtez de résoudre tous les problèmes d'optimisation avec ces vue matérialisée assez intelligentes.
Avez-vous déjà essayez de faire ce que Mohamed Houri vous a proposé ?
Avez-vous compris ce qui se passe ?
Sinon pourriez-vous dropper de votre schéma la vielle table plan_table qui ne sert à rien pour avoir quelques informations de plus dans l'explain plan ?
Bonjour,
j'ai essayé les commandes décrites dans le message de Mohamed Houri sans trop comprendre le principe car je commence à atteindre les limites de mes compétences.
J'ai comme résultat :
Comme je le dis je ne suis pas DBA de ma base cela doit venir de là je suppose ....User has no SELECT privilege on V$SESSION
Et je ne sais pas ce qu'est la table plan_table mentionnée ... visiblement elle existe bien au niveau de mon schéma , je ne sais pas d'ou elle sort et si je peux la dropper sans risque ?
Merci pour votre aide....
Salut,
Tu te dis : "j'ajoute juste une clause restrictive, pourquoi ça prend plus de temps ?"
Pour choisir le bon plan, l'optimiseur doit estimer l'impact de tes prédicats sur le nombre de lignes sorties.
Le scénario probable : ta requête initiale était optimisée avec des hypothèses à peu près correctes, le prédicat ajouté dans la seconde à introduit un biais.
Seulement sur une si grosse requête, il peut y avoir des effets boule de neige, et c'est très dur à comprendre.
Ce que propose Mohammed avec son /*+ gather_plan_statistics*/, c'est de mettre face à face ce qui à été estimé, et ce qui se réalise vraiment.
Là où il y a une différence, c'est sûrement là qu'il y a le problème..
(c'est ma photo)
Paku, Paku !
Pour les jeunes incultes : non, je ne suis pas un pokémon...
Le pacblog : http://pacmann.over-blog.com/
Pour poursuivre .. je me suis décidé à dropper cette table table_plan.
j'ai relancé la requete avec la commande EXPLAIN PLAN et voici le résultat :
Par contre je veux bien essayer ces commandes , mais quels privilèges faut il sur le schéma de données ? être DBA ?
Code : Sélectionner tout - Visualiser dans une fenêtre à part
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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
j'ai à présent un acces avec un utilisateur en DBA sur ma base, j'ai pu appliquer ce que propose Mohammed avec son /*+ gather_plan_statistics*/,
et en voici le résultat sans la clause where qui fait tout ramer ... je fais la suite ... mais si quelqu'un voit déjà un truc qui cloche ..
Code : Sélectionner tout - Visualiser dans une fenêtre à part
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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
Même dans l'exécution de la requête qui répond, le CBO se vautre totalement dans l'estimation des cardinalitées (E-Rows vs A-Rows).
Regarde la colonne LAST_ANALYZED de la vue USER_TABLES pour vérifier la dernière date de calcul des statistiques.
Tu peux aussi comparer la colonne NUM_ROWS avec le vrai nombre de ligne de la table (pour les différentes tables composant la requête)
A priori les stats ne sont pas à jour, utilise DBMS_STATS.GATHER_TABLE_STAT pour les récalculer.
Une commande de base par exemple :
A affiner si nécessaire.
Code : Sélectionner tout - Visualiser dans une fenêtre à part exec DBMS_STATS.GATHER_TABLE_STAT('LE_SCHEMA','LA_TABLE',cascade=>true)
Voit avec ton DBA, le calcul des stats c'est plutôt son boulot.
Regarde dbms_xplan.display_cursor pour des infos sur la commande.
J'ai fait recalculer les statistiques et la colonne LAST_ANALYZED de la vue USER_TABLES est à la date du jour.
Cela ne change rien malheureusement.
Est ce que changer l'ordre des jointures dans les clauses where pourrait changer quelque chose ?
Il faudrait peut être faire des jointures normalisées déjà.
~ Lola ~
Il faudrait repasser le plan d'exécution de Mohamed Houri maintenant que les statistiques sont à jour.
Email : http://scr.im/waldar
heu j'ai toujours fait mes jointures comme cela .... qu'est ce que ne va pas ?
Attention ce n'est pas équivalent : le OR proposé ne ramènera que ce qui commence ou finit par FINANCE, et pas une valeur où le mot cherché serait au milieu, telle que 'DEPARTEMENT DE FINANCE STOCHASTIQUE'.
Pour Oracle c'est une connerie. Demandez à SQL PRO de prouver ses affirmations.
Merci d'avoir pris la peine de poster le plan d'exécution comme demandé. Je dois dire que c'est très intéressant et j'aimerai beaucoup que l'on trouve la raison. Voici ci-dessous mes remarques:
Le plan d'origine fait principalement ceci
Alors que le second plan fait ceci
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
c'est à dire tous les deux font une HASH JOIN entre deux VIEW intermédiaires.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
La différence provient donc principalement du pavé allant de l'opération 5 (HASH GROUP BY) jusqu'à loperation 51 dans le premier(55 dans le second) (VIEW)
Ces deux pavés sont:
dans le premier plan
et dans le second
Code : Sélectionner tout - Visualiser dans une fenêtre à part
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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
où (le second) l'on constate l'apparition d'une nouvelle operation VIEW supplémentaire
Code : Sélectionner tout - Visualiser dans une fenêtre à part
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
35
36
37
38
39
40
41
42
43
44
45
46
Dépendant de son opération fille(14 NESTED LOOPS ici), une opération VIEW doit d'abord construire totalement sa réponse avant de transmettre le résultat à son opération mère(NESTED LOOP ici aussi) ce qui veut dire que comparativement au premier plan d'execution cette opération VIEW supplémentaire peut avoir ajouter un laps de temps d'attente qui d'ailleurs vaut ici 55 secondes (y compris le temps de ses opérations filles).
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
Je remarque aussi la disparition dans le second plan des operations MERGE JOIN et SORT JOIN.
Comment ce changement est arrivé? j'avoue que je n'en ai aucune idée. Je ne peux que spéculer en comparant les différences. Par exemple la toute première opération dans le premier plan est :
Alors que dans le deuxième c'est:
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
Peut-être qu'en utilisant des hints (LEADING par exemple) conduirait le CBO à commencer par la table AGLDIMVALUE et rétablirait le bon plan. Il y aussi la possibilité de supprimer ces VIEW en utilisant le hint MERGE (quoique je n'en suis pas totalement sûr).
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
Sinon, quelques remarques au passage qui serviront peut-être ulterieurement et pas forcément cette fois-ci:
L'opération suivante fait un full table scan pour ne ramener que 4 lignes. La partie Predicate peut expliquer peut-être la non utilisation de l index si index il y a
L'opération 26 passe à son opération mère (25) 119.000 lignes sur lesquelles est appliqué un filtre pour éliminer 16.000 lignes. C'est une perte de temps et d'énergie qui peut être résolue en créant un index plus précis sur la table AEMENROLLMENT. Je suppose que l'index AIAEMENROLLMENT3 est défini sur (CLIENT,SERVICE_ID, SERVICEOFF_ID); avez vous essayé d'enrichir cet index avec la colonne STATUS?
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
Bon couragae
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
A ce niveau c'est un exemple j'ai une multitude de valeur possible et cela est au choix de l'utilisateur.
Merci à vous Mohamed.Houri, je vais regardé cela ... j'avoue cependant pas tout comprendre
je reprend les commentaires les uns après les autres et je remarque que l'index utilisé ne me semble pas judicieux et n'est pas en rapport avec ma jointure ou alors je ne comprend pas ....
Ma table a plusieurs index dont un AIAEMENROLLMENT1 qui reprend :
CLIENT, ENROLLMENT_PK
qui correspond plus à ma jointure
alors que celui qui semble utilisé est :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
AIAEMENROLLMENT3 qui reprend :
CLIENT, SERVICE_ID, SERVICEOFF_ID
qui se rapproche de cette jointure , mais qui concerne une autre table
et je vois dans le plan que pour cette table j'ai :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
alors que j'ai un index AIAEMSERVICEOFF1 qui reprend :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2TABLE ACCESS FULL | AEMSERVICEOFF
CLIENT, SERVICE_ID, SERVICEOFF_ID
j'avoue être un peu perdu
Peux tu poster le nouveau plan de la requête avec les stats.
Que donne le résultat de :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
AGRESSO, sort de ce corps !
Garuda गरूड
Brahmâ la Guerre et Vishnu la Paix
Oracle 12C R2 - Forms11GR2 - Toad 12 - sharePoint 2010
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager