Discussion :

[LoveOracle]

Bonjour,

J'ai une application qui tourne sur Oracle 9i avec le paramètre [optimiser_mode] positionné à [RULE] et je dois migrer cette application sur Oracle 10g.

Je pensais que ce paramètre n'était plus supporté en Oracle 10g alors j'ai changé le paramètre [optimiser_mode] à [CHOOSE].

=> Résultat, un de mes traitements est passé de 20' à 8h !!!

J'ai tenté de changer en passant à [ALL_ROWS], même résultat.
J'ai tenté de changer en passant à [FISRT_ROWS], même résultat.

Du coup, je suis revenu en mode [RULE] (qui finalement est encore supporté mais déconseillé car n'évolue plus depuis 1994).

Mes questions sont donc :
1 - Que signifie le mode RULE ?
2 - Pourquoi et comment peut-il être aussi performant par rapport au nouveaux modes CBO (Cost Based Optimiser) ?
3 - Si je devais migrer vers un mode CBO, j'ai cru comprendre qu'il fallait recalculer les statistiques... : comment faire ? Est-ce un paramètre à ajouter dans le PFILE ?

Merci pour vos réponses à toutes ou une de mes questions.

[orafrance]

Le mode CHOOSE s'appuie sur la volumétrie de la base pour choisir le chemin d'accés au donnée (explain plan) le plus adapté contrairement au mode RULE qui ne repose que sur des règles strictes.

La volumétrie ne peut être connue que si les statistiques sont calculées régulièrement, la 10g crée un job en ce sens en principe. Sinon, recherche dans le forum pour voir comment t'y prendre (ou la doc : DBMS_STATS)

Pour finir, il n'y a rien d'étonnant à avoir une baisse de perfs, certaines applis sont développées spécifiquement pour le mode RULE et ne supporte pas le mode CHOOSE. Il convient donc de réécrire les requêtes à problème ou adapter les plans d'indexation

[LoveOracle]

Merci pour ces précisions.

Sinon, j'ai le paramètre [timed_statistics] positionné à [false].
Cela peut-il être la cause d'un non calcul de statistiques ?

[orafrance]

non mais à des fins de monitoring ça peut-être intéressant de le passer à TRUE sachant que l'overhead que cela génère est négligeable