Discussion :

[Golgotha]

Bonjour,

Je mets mon problème ici, je vais commencer moi même à travailler dessus mais on ne sait jamais, si quelqu'un voit tout de suite de quoi il s'agit, avec un peu de chance..

Donc, le problème vient d'une belle requête poilue qui pique les yeux mais bon, c'est comme ça, ce n'est pas moi qui l'ai écrite ^^ et pour l'instant je dois faire avec, la voici :

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
21
22
23
select distinct Get_Sectionlib(g.GRILLE_TARIF_ID) sectiongrille,
                to_char(DATE_DEB, 'YYYY') ANNEE,
                DATE_FIN,
                GTG_LIBELLE || ' (' || unitval_id || ')' ||
                case g.gtg_minimum_taxable
                  when 0 then
                   ''
                  else
                   ' Min. taxable ' || to_char(g.gtg_minimum_taxable)
                end LIB,
                g.active,
                clt_tiers_id,
                [...]
                g.gtg_minimum_taxable
  from gtg g, tiers ti, gtg_t t, SECTION s
 where clt_tiers_id = 53885
   and g.DATE_FIN >= date_inf('26/11/2012')
   and g.DATE_DEB <= date_inf('26/11/2012')
   and g.GTG_TYPE = 'CLIENT'
   and g.clt_tiers_id = ti.tiers_id
   and g.grille_tarif_id = t.grille_tarif_id
   and g.section_id = s.section_id(+)
 order by 1, lib, GTG_LIBELLE, unitval_id, TRANCHEINF

Et le problème, que je rencontre et qui est assez cocasse, c'est que le résultat de cette aimable requête renvoie un résultat A lors de la première exécution et un résultat B lors des exécutions suivantes.

Comme le montre le screen suivant :



Le problème se situe sur le min. taxable, qui change.

Plusieurs point pour commencer :

• la base ne change pas d'un pouce entre les exécutions.
• la requête ne change pas d'un poil entre les exécutions.
• le changement est surtout effectif entre la première exécution et les suivantes, mais pas entre l’exécution 2 et n.

N'étant pas expert Oracle (enfin là ça me dépasse), quelles sont les possibilités pour qu'une requête change de résultats entre deux exécutions sur une base Oracle ?

Voilà, celui qui trouve la réponse aura gagné mon respect

[Mohamed.Houri]

Si

(a) la base ne change pas d'un pouce entre les exécutions.
(b) la requête ne change pas d'un poile entre les exécutions.
(c) le changement est surtout effectif entre la première exécution et les suivantes, mais pas entre l’exécution 2 et n.

et si

(d) vous utilisez la version 11gR2

Je peux supposer que c'est l'effet de "Cardinality Feedback" qui s'est mis en route à la suite de la deuxième exécution générant un nouveau plan d'exécution comportant un bug.

Ce qu'il faut faire dans un premier temps c'est de voir le premier et surtout le deuxième plan d'exécution et voir si à la fin de ce plan il existe une note concernant la cardinality feedback.

[Golgotha]

Mohamed,

Tout d'abord, merci pour votre aide.

Effectivement, nous utilisons la 11gR2.

La solution serait de mettre /*+ opt_param('_optimizer_use_feedback' 'false') */ dans la requête ?

Je n'arrive pas à reproduire le premier cas quand je le désire, ce cas survient si j'exécute la requête un jour ou deux par exemple après la dernière exécution de la requête. Avez vous une idée pour reproduire les conditions du premier cas ?

[skuatamad]

Que fait la fonction date_inf ?

[Golgotha]

Que fait la fonction date_inf ?

Date_inf renvoie une date à minuit :

'26/11/2012' => '26/11/2012 00:00:00'

et Date_sup :

'26/11/2012' => '26/11/2012 23:59:59'

[Rei Ichido]

A priori gtg doit être une vue ? Sinon je ne vois pas comment le résultat peut changer. Et du coup il faudrait voir le corps de gtg, je suppose qu'il y a une sélection de minimum fait sur un critère qui a en fait des ex-eaquo (et du coup le SGBD peut choisir une ligne ou une autre).

[Mohamed.Houri]

Pour l'instant la "Cardinality feedback " n'est qu'une supposition car vous n'avez pas encore un plan d'exécution avec la partie Note qui le prouve.

Lorsque vous aurez la preuve alors oui l'utilisation du hint

Code :

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

1
2
 
/*+ opt_param('_optimizer_use_feedback','false') */

peut alors vous aider.

Ce qu'il faut savoir c'est que le CBO (l'optimisateur) se lance éventuellement dans l'utilisation de la Cardinality feedback lorsqu'il se rend compte grâce à la première exécution de la requête que les estimations sur lesquelles il s'est basé ne sont pas bonnes; il remémore alors cette information et lors de la deuxième exécution il essaie d'avoir une meilleure estimation pour produire un bon plan d'exécution. Malheureusement, cette fonctionnalité cause plus de problèmes qu'elle n'apporte de solution.

Il se peut que votre problème n'ait rien à voir avec la Cardinality feedback et dans ce cas ces explications serviront tout de même pour une bonne compréhension de cette option du CBO.

Afin de connaitre les sql_id de votre base de données qui ont été soumis à la cardinality feedback vous pouvez utiliser la requête suivante:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
select
  sc.sql_id,
  sc.child_number,
  sc.use_feedback_stats,
  s.sql_fulltext 
from
  v$sql_shared_cursor sc,
  v$sql s
where
  sc.use_feedback_stats='Y'
  and sc.sql_id=s.sql_id
  and sc.child_number=s.child_number

Il faut juste noter que la colonne use_feedback_stats n'est pas fiable à 100% car il arrive que des curseur enfants (child cursor) soient passés par la moulinette "cardinality feedback" alors que leur colonne use_feedback_stats n'est pas mise à 'Y'.