Mode RULE et CHOOSE.

Bonjour les forumistes...

J'ai 3 traitements qui tournent beaucoup mieux en mode 'RULE' qu'en mode 'CHOOSE' (gain de près d'une heure pour 2 et très rapide pour le 3em), avec des statistiques fraîches => OK :lol:

Quand je retire les stats (alors que je suis en mode 'RULE'), les traitements sont beaucoup plus lents (50 % du temps en plus pour les 2 premiers), voire complètement dans les choux (pour le 3em)..

Comment expliquez-vous qu'il faille effectuer des stat fraîches pour que le mode RULE fonctionne correctement (alors que normalement, le mode RULE ne prends pas en compte les stats !)

Merci pour votre réponse...

PS : Ne me répondez pas qu'il faut que je passe en mode CHOOSE car ce n'est pas le but de ma question

Ca laisse à penser que vous croyez être en mode RULE, mais que vous ne l'êtes pas ! Comment le vérifiez-vous ?

Et la version de la base, au fait ?

Bonjour à tous
Excusez la lenteur de ma réponse... je vérifie que je suis en mode 'RULE' avec un :

Citation:

---

SQL> show parameter optimizer_mode

---

qui me rend la réponse suivante...

Citation:

---

NAME-------------------------TYPE-----VALUE
optimizer_mode--------------- string-----RULE

---

Et je suis bien en mode 'RULE' car nous avons effectué la modif sur le init.ora et fait l'arrêt/relance de l'instance..

Mystère ?

On n'a toujours pas la version de la base :roll:

Désolé...

L'instance est une Oracle9i (9.2.0.5.0) sur UNIX AIX 5...

les stats ont été effectuées par des FND_STATS.GATHER_SCHEMA_STATISTICS, car nous sommes dans un univers Oracle Appli e-business 11i...

Merci pour vos eclaircissements...

8O 11i en mode RULE... spa bien :roll:

Si tu as des dévs qui vont mieux en mode RULE alors faut faire un ALTER SESSION plutôt que de changer l'optimizer. Sinon il me semble que les stats passent le CBO en CHOOSE même si tu es en RULE... mais j'suis pas sûr que ce soit documenté d'une part et vrai d'autre part :mouarf:

Citation:

---

Envoyé par genio

Et je suis bien en mode 'RULE' car nous avons effectué la modif sur le init.ora et fait l'arrêt/relance de l'instance..

---

Ca ne permet pas d'être très affirmatif.
Tout ce qu'on peut dire, c'est que vous serez par défaut en mode RULE.
Cette valeur par défaut peut être outrepassée au niveau session, voire au niveau requête.

Il n'y a guère que les plans d'exécution qui vous renseigneront sur le mode effectif pour une requête donnée.

Bonjour...

Citation:

---

Si tu as des dévs qui vont mieux en mode RULE alors faut faire un ALTER SESSION plutôt que de changer l'optimizer.

---

De quel ALTER SESSION parles-tu ?

par exemple :

Code:

---

ALTER SESSION SET OPTIMIZER_MODE=RULE

---

Merci pour vos réponses...

Pour Pomalaix : Mes plans d'exécution indiquent bien que je suis en mode RULE...

J'en conclue que le mode RULE doit quand même utiliser les statistiques (même si c'est minime) pour déterminer son plan d'accès... je ne vois pas d'autres explications ...

Et vous ?

Si on en croie Donald K. Burleson (C'est un pilier de la connaissance Oracle) il semblerait que les modes RULE, FIRST_ROWS & ALL_ROWS peuvent être influencés par l'ordre dans lequel apparaissent le tables dans la clause FROM.

Il conseille en mode RBO (RULE) de lister les tables de la plus grosse à la plus petite. Inversement en mode CBO (FIRST & ALL) il semble falloir faire l'inverse et donc lister les tables de la plus petite à la plus grosse.

Pour un peu plus d'infos (Qui mènent à l'achat de l'un de ses livres) : http://www.remote-dba.cc/Oracle_tips_SQL_Optimizer.htm

Le fait que la présence ou non de statistiques en mode RULE change le plan d'exécution peut être quelque part corrélé avec ton observation. Il spécifie bien qu'en mode RULE le moteur s'appuie sur le dictionnaire mais ne dit pas qu'il n'utilise pas un peu les statistiques...

Citation:

---

Envoyé par philcero

Si on en croie Donald K. Burleson (C'est un pilier de la connaissance Oracle)

---

Attention, il peut raconter de grosse bêtise... il n'est d'ailleurs pas très apprécié de Tom Kyte notamment quand il parle perf.

Exemple :

Citation:

---

Envoyé par philcero

Inversement en mode CBO (FIRST & ALL) il semble falloir faire l'inverse et donc lister les tables de la plus petite à la plus grosse.

---

l'ordre des tables n'influence pas le CBO, tout au plus cela peut changer l'ordre de traitement des plans possible qui associé à optimizer_max_permutation peut donner l'impression que l'ordre des tables influent.

Merci pour l'info, je ferais plus attention à l'avenir sur ses écrits...

;)

Pour ma part en tout cas, loin de vouloir prendre sa défense, j'ai pas eu à me plaindre de ses écrits jusqu'à aujourd'hui. Ils m'ont beaucoup amené et je n'ai pas encore rencontré d'illogisme...

N'y aurait-il pas derrière cela une guerre semi-ouverte visant à qui sera le numéro un ?

Guerre menée sur de multiples champs de batailles amenant tour à tour puissance, reconnaissance et autres joies attendues de toute partie visant la reconnaissance suprême...

:mrgreen:

En tout cas cela n'explique pas le problème initialement constaté.

je ne sais pas mais en tout cas Kyte a toujours parfaitement argumenté ses remarques ;)

Citation:

---

je ne sais pas mais en tout cas Kyte a toujours parfaitement argumenté ses remarques

---

Pas comme Génio :D !

Merci pour vos réponses... je ferme le post !