L’optimisation des applications
Historique de l’optimiseur d’Oracle. L’optimisateur syntaxique
Avant la version 7.0, l’optimiseur syntaxique (rule-based optimizer) se contentait d’optimiser le code en utilisant un ensemble de règles internes fixes et en les appliquant à partir d’une analyse syntaxique du code : • Règle n° 1 : Lecture des lignes isolées à l’aide du ROWID. (Cette règle posait problème lorsque les tables étaient réorganisées ou lorsque la base était portée sous Oracle8, impliquant un changement de format du ROWID). …………. Règle n° 8 : Accès par l’intermédiaire d’un index composite avec toutes les clés contenues dans la clause where. Règle n° 9 : Accès par l’intermédiaire d’un index sur une colonne. Règle n° 10 : Accès par l’intermédiaire d’un index composite, avec préfixes de clés contenus dans la clause where. …………. Règle n° 15 : Balayage complet de la table.

• • • • • •

Dans le principe, pour traiter une instruction, l’optimiseur commençait à la fin de la liste, par exemple la règle n° 15, puis il remontait dans la liste. S’il trouvait un index, il décidait d’appliquer la règle n° 8 ou n° 9, etc.… L’hypothèse de base était la suivante : à partir du moment où une instruction SQL validait une règle, et que le numéro de la règle diminuait, le plan d’exécution était réputé meilleur. C’est à ce niveau que l’optimiseur syntaxique atteignait ses limites, incapable de déterminer la méthode la moins coûteuse, dans la mesure où il ne faisait usage d’aucun type de fonction de coût ou de statistiques. Cependant, il avait été initialement conçu pour les BDD transactionnelles, car les Datawarehouses n’existaient pas encore.

L’optimiseur statistique
Il apparaît avec la version 7.0 d’Oracle, dans le but de permettre l’utilisation d’un plus grand nombre d’options lors de la construction des plans d’exécution du code SQL, mais il lui aura fallu sept ans pour atteindre un niveau de maturité satisfaisant. Dès Oracle 7.3, l’optimiseur avait la possibilité de