!
!
Info TAFORA
!
Méthodes Conseil
!
Mon credo Oracle
!
Nouveautés
!
Expertise technique
!
Fiches Techniques
!
Séminaires
Technique
FAQ
Domaines
DBA
Tuning
PL/SQL
Divers
Varia
Liens
Contact
TAFORA
Radu
Mail
White Paper
CBO/RBO

Quelques précisions concernant les optimisations Oracle

Depuis des années (depuis l’adolescence de Oracle 7 en fait), une guerre fratricide oppose les adeptes du CBO (cost based optimizer, né en v7) et de RBO (né en V6).
  • L’optimiseur base sur des règles (RBO) utilise des règles syntaxiques pour évaluer les différents chemins d’accès aux données.
  • L’optimiseur base sur les coûts utilise des statistiques sur les tables, colonnes, index pour évaluer les différents chemins d’accès aux données (nombre de lignes, distribution des données, plages de valeurs, etc). Son avantage primordial réside dans le fait qu’il peut déterminer un chemin d’accès aux données différent en fonction de la distribution et la volumétrie de celles-ci, en diminuant l’effort du programmeur pour trouver le bon chemin ‘théorique’ d’accès aux données.
Le type d’optimisation est choisi avec optimizer_mode dans init.ora ou optimizer_goal dans alter session (pas de détails ici ;-), par défaut il est a choose depuis v7.
Note importante, le développement du RBO (au sein des équipes Oracle) est arrêté. Il est pratiquement sur qu’un jour il ne sera plus disponible. Déjà depuis 8.1, Oracle met a la disposition des DBAs des outils pour fliquer le comportement du RBO pour l’imposer à CBO.

Pour rappel, en mode choose, si une seule table participante à une requête est analysée, le CBO sera utilisée, ce qui peut s’avérer catastrophique. Je crois que les détracteurs du CBO ont ici un bon point d’accusation, mais je rappelle que même dans les plus difficiles cas (volumétrie gigantesque, etc), les analyses des tables peuvent être correctement effectuées.
  1. N’oublions pas que le CBO est amélioré sans cesse, il est le choix de l’avenir (malgré les bugs rencontrés du temps à l’autre)
  2. Dans les versions modernes d’Oracle, certaines actions nécessitent des données analysées : parallel query, fine grained access control, fast full index scans, etc.
  3. J’ai vu beaucoup de boites noires améliorer leurs performances lors du passage au RBO.
  4. J’ai vu également, notamment lors des migrations, des performances divisées par 10 si l’utilisation du CBO était imposée (bug 1318267) (résolu avec SQLEXEC_PROGRESSION_COST=0 dans init.ora)
J’ai vu dans un vieux document Oracle qui circule sur le WEB l’assertion qu’il y a plus des bases en CBO qu’en RBO. Je ne suis pas statisticien, mais je n’ai qu’un seul client qui est obligé d’employer le RBO (et qui va passer en CBO illico). Le document est relativement vieux, j’imagine qu’il s’agisse d’un document issu pendant le vieillissement de la V7 ou l’enfance de la V8.
Mes conclusions (Radu Caulea, TAFORA ;-))
  • Le RBO est mature, mais il est voué à une lente obsolescence pour des bases modernes.
  • Dans les rares cas de disfonctionnement du CBO, des hints peuvent être employés pour mettre le moteur sur le chemin estimé plus performant.
  • Les applications autour du noyau Oracle savent de plus en plus tirer profit du CBO. En faite, elles sont obligées pour être en pas avec les développements fonctionnels des noyaux modernes.
  • Chaque nouvelle version, même mineure apporte des améliorations ET des nouvelles applications pour le CBO.
Tout ceci devrait déterminer pour toute base supérieure à la V8.0 l’utilisation du CBO.
Bien sur que l’utilisation du CBO impose l’analyse des tables et index associés, ce qui peut etrte contraignant, mais j’insiste, ceci peut être systématiquement effectué sans impiétér sur le deroulement de la production (Je rappelle que l’analyse des grosses tables peut durer des heures).
Ce petit document n’exclut pas la bonne écriture des ordres SQL !

N’oubliez pas de tracer vos ordres SQL : vous serez surpris !
Copyright © 1998-2002 Radu Caulea, TAFORA MAJ 06/11/2006 !
Commentaires et suggestions radu[CHEZ]tafora.fr