Catégorie: Plan d'exécution

En général lorsqu'il y a plusieurs indexes qui peuvent répondre aux prédicats d'une requête, Oracle va choisir l'index le plus selectif, et les autres conditions seront vérifiées au moment d'aller lire l'enregistrement complet dans la table.
Ceci peut nous amener à créer un index concaténé, en combinant toutes les colonnes sur lesquelles il y a des prédicats, afin que l'index soit plus sélectif.

Mais ajouter un index a un coût et va pénaliser les insert/deletes ainsi que les updates qui touchent aux colonnes indexées.

Il y a cependant des cas où Oracle peut combiner deux indexes.
C'est le cas par exemple des indexes bitmap. On peut avoir un index bitmap sur chaque colonne, et Oracle va combiner les bitmaps avant d'aller voir la table (en utilisant des opérateurs binaire AND et OR sur les bitmaps). Mais ce n'est pas le sujet de cet article.

Il y a aussi un cas particulier avec les indexes 'normaux': c'est le chemin d'accès 'INDEX JOIN': les 2 indexes sont lus, et sont réunis, comme si l'on faisait une jointure sur le rowid, et la sortie de cette opération est équivalente à un index qui contiendrait toutes les colonnes.

Voici un exemple de cette opération 'index join', le but de cet exemple était de répondre à la question suivante, sur le forum dba-village: 'Que signifient les indexes index$_join$_9 et index$_join$_8' dans un plan d'exécution, et 'comment les remplacer par mes propres indexes ?'

» Lire la suite!

Cet article est la traduction d'un article de Jonathan Lewis. L'article original en anglais se trouve ici. J'ai cependant traduit l'exemple de requête dans une syntaxe Oracle, et l'idée d'index cluster de SQL Server correspond à celle d'IOT sous Oracle.
Jonathan Lewis décrit ici une démarche visuelle pour comprendre une requête SQL en faisant un schéma des tables impliquées.

C'est parfois intéressant de s'éloigner du clavier lorsqu'on se bat avec une requête peu performante et assez complexe, et de prendre un papier et un crayon à la place. En faisant un schéma qui montre les tables impliquées, les jointures, les volumes de données manipulées, et les indexes, vous pourrez comparer plus facilement l'efficacité des différents chemins d'exécution que la requête peut prendre pour passer d'une table à une autre.

» Lire la suite!