Le RBO est mort depuis longtemps et pourtant, tous les jours j’entends ou je lis les pires des raccourcis à propos de l’optimiseur SQL d’Oracle. Si j’adore ça, c’est justement parce que le tuning est parfois un puzzle ; il s’appuie sur un modèle statistique puissant et il n’obéit surtout pas à des règles. Alors, vous aussi, à chaque fois que vous lisez des règles à propos du moteur SQL d’Oracle, pensez plutôt :

• Il n’y a pas de règles ; il n’y a que des exceptions
• Ça dépend (Tom Kyte)
• Arrêtez de croire ce qu’on vous dit ou les évidences (BAAG by Alex G.)
• Faites vous une opinion par vous-même
• Remettez toujours en doute vos certitudes (si c’est vrai aujourd’hui, rien ne dit qu’avec le prochain patch)

Et… Arrêtez de penser :

• qu’il ne faut pas utiliser pas de valeurs littérales dans les systèmes transactionnels, 
• que pour qu’un index soit efficace, il faut qu’il ramène moins de 5, 10 ou 15% des données d’une table (et même si c’est écrit dans la doc), 
• que rien ne sert d’indexer les colonnes qui ne sont pas dans les clauses WHERE, 
• qu’il faut mettre les colonnes les plus sélectives en début d’un index,
• que le plan choisi est celui qui a le coût le plus faible, que le plan d’un ordre SQL est celui affiché par la commande explain plan, 
• que le tuning SQL est un art 
• ou n’importe quel propos qui pourrait vous donner le sentiment que vous maitrisez ^(*) le CBO.

A propos des index, créez le modèle ci-dessous :

create table gark(col1 number, col2 number, col3 varchar2(4000));

insert into gark
       select mod(rownum, 5), mod(rownum, 29), rpad('X',1000, 'X')
         from dual 
      connect by level <= 1500000;

commit;

exec dbms_stats.gather_table_stats('GARK')

Puis exécutez cette requête qui ramène 20% des lignes de la table :

• Sans Index
• Avec un index sur (col1, col2)
• Avec un index sur col1 uniquement

set timing on

select sum(col2)
  from gark
 where col1 1;

Vérifiez  le plan ; Toujours convaincu que pour qu’un index soit utile il faut que ses colonnes soient dans la clause WHERE ou que sa sélectivité doit être importante ?

J’enfonce des portes ouvertes ? Restez critiques quand vous lisez des articles à propos du SQL et d’Oracle, il y a des conneries partout, y compris dans les miens… Et n’hésitez pas à commenter les articles !

^(*)Mark Townsend a dit un jour d’Exadata, je pense en ne plaisantant qu’à moitié, que si ça marche aussi bien, c’est que le CBO peut se tromper puisque les TABLE ACCESS FULL ont des performances fulgurantes !