Introduction

« Index », voilà un mot utilisé par tout le monde sans vraiment savoir comment ça fonctionne et pourquoi on l’utilise. On voit partout la remarque « Ca marche mieux avec », oui mais pourquoi ça marche « mieux » ? Y a t-il vraiment qu’un seul type d’index ? Vous pensez pas qu’un index contient des options spécifiques ? Autant de réponses auxquelles je vais essayer de répondre dans cet article.

Pourquoi utiliser un index ?

Par analogie, un index est une liste des termes utilisées dans un ouvrage et les numéros de pages qui y réfèrent. Un index dans une base de données aura globalement le même fonctionnement mais à l’échelle d’une colonne de table et ses valeurs.

Lorsque vous allez rechercher un terme dans une colonne, Oracle va regarder dans les indexs s’il ne trouve pas ce mot et le « numéro de page » de la table où il y a cette valeur.

Par exemple, vous avez une requête « SELECT * FROM customers WHERE customer_id=352 . Dans ce cas là, Oracle va regarder si il existe un index sur la colonne customer_id et s’il existe, va regarder dans l’index s’il trouve la valeur 352. S’il trouve cette valeur, il regarde l’emplacement indiqué par l’index.

Les indexs permet à Oracle de ne pas parcourir les tables entièrement à chaque requête SQL pour trouver des valeurs spécifiques. Cela améliore donc nettement la rapidité de vos requêtes. Cependant, nous allons voir plus tard qu’il ne faut trop en abuser non plus

J’en mets sur quelles colonnes alors les indexs ?

C’est simple, vous allez positionner des indexs sur les colonnes où vous allez avoir besoin de rechercher des valeurs. Par exemple, si vous êtes souvent amené à faire des recherches sur les emails de vos employées (colonne email de la table employees) avec une requête du type SELECT user_id FROM users WHERE email LIKE ‘guireg%’, il serait judicieux de positionner un index sur la colonne email pour qu’Oracle puisse retrouver très rapidement la valeur du bloc où se trouve toutes les adresses email commençant par « guireg ».

Il est donc très conseillé de mettre des indexs sur les colonnes que vous utilisez souvent dans la clause WHERE de vos requêtes.

Les deux types d’index

Les index B*Tree

Lorsque vous créez un index sans vous souciez de son type, Oracle vous crée par défaut un index de type B*Tree. Comme son nom l’indique, c’est un arbre. Le « B » veut dire Balanced et non pas Binary comme le pense beaucoup de gens.

Imaginons, par exemple une table USERS contenant 200 lignes, 3 colonnes (id de 1 à 300,name,password) et un index B*Tree sur la colonne id.

L’index B*Tree ressemblera à un arbre de ce type :

Il faut savoir que les index B*Tree n’indexent pas les valeurs NULL.

Les index B*Tree sont très efficaces lorsque la cardinalité (Le nombre de valeurs différentes)  est forte – très forte , que le nombre de lignes est très importante et bien sûr que la colonne soit utilisée dans des clauses WHERE ou JOIN.

Ils sont souvent très utilisés dans les bases de données de type OLTP (Transactionnel) contrairement à son rival l’index BITMAP.

Les index Bitmap

L’index Bitmap est un index très spécifique souvent utilisé en Datawarehousing et BI. Et pour cause, ce dernier est très coûteux à mettre à jour, ce qui rend son utilisation dans des environnements OLTP vraiment limité.

Comme son nom l’indique, les index Bitmap sont faits de bits. Ils prennent toutes les valeurs différentes d’une colonne et ensuite transforment en bits leurs dispositions.

Par exemple, une table USERS contenant un champ usergroups disposant de 3 valeurs différentes : Administrateurs, Modérateurs, Utilisateurs et contenant 5 lignes avec les valeurs : 1.Administrateurs, 2. Administrateurs 3.Utilisateurs, 4. Modérateurs 5.Utilisateurs

L’index Bitmap correspondant ressemblerait à ceci :

Administrateurs : 11000

Modérateurs : 00010

Utilisateurs : 00101

Dans ce cas là, vous pouvez imaginer qu’une clause AND ou OR entre deux colonnes  indexées est redoutablement efficaces car il suffit de faire un AND ou OR des bits correspondant à ces deux colonnes, ce qu’un ordinateur fait très rapidement.

De plus, le fait d’indexer toutes les valeurs possibles dans une colonne, les indexs Bitmap sont très performants lorsqu’une colonne a une sélectivité faible. C’est exactement là où les index B*Tree pêchaient.

Enfin, les indexs Bitmap indexent les valeurs NULL.

Les indexs Bitmap sont donc conseillés lorsque vos tables remplissent toutes ces conditions :

• La cardinalité des colonnes est faible (Très peu de valeurs différentes)
• Il  y a beaucoup de lignes dans votre table
• Lorsqu’il y a quasiment uniquement des activités de lecture sur la table

Les options des indexs

Unique

Encore une fois, comme son nom l’indique, cet index permet de ne pas avoir de valeurs dupliquées dans une colonne.

Composite

Un index composite est un index qui est sur plusieurs colonnes de votre table. Si par exemple, vos requêtes SQL interrogent souvent deux colonnes à la fois dans une table (WHERE usergroup= »blabla » AND name= »haha » par exemple) , il serait judicieux de mettre un index composite sur les colonnes usergroup et name.

Attention : Oracle utilisera l’index que si vos requêtes SQL respecte l’ordre des colonnes que vous avez donné sinon il fera un Skip Scan de votre table qui est beaucoup moins efficace.

Clé inversé (Reversed Key)

Cette option permet d’inverser l’ordre des valeurs indexés. Par exemple, « guireg » deviendra « geriug » lorsqu’il sera indexé par un index Reversed Key.

Cela permet d’être très efficace lorsque vous avez des requêtes avec des clauses WHERE du type LIKE ‘%eg’.

Compressé

Par défaut, Oracle crééera une entrée pour chaque valeurs avec son ROWID correspondant même s’il existe deux valeurs identiques. Cette option permettra de regrouper tous les ROWIDs des valeurs identiques ensemble. Cela peut-être efficace dans le cas de tables fréquemment mises à jour mais qui ont une colonne à cardinalité faible.

Function based

Lorsque vous intégrez une fonction à vos noms de colonnes dans vos requêtes (Par exemple : WHERE SUBSTR(username,0,5) =’BLABLA’, Oracle décidera de parcourir entièrement la table plutôt que de passer par votre index.

Pour remédier à ceci, vous pouvez mettre en place des indexs Function Based qui indexeront les valeurs précédemment passées par votre fonction (ici SUBSTR).

Ascendant ou Descendant

Cette option permet de régler l’ordre par défaut des lignes retournées dans les indexs. Par défaut, les indexs sont de type Ascendant mais si vous utilisez fréquemment un ORDER BY Desc, vous pouvez régler vos index en Descendant et enlever la clause ORDER BY.

Ceci peut apporter de très bons résultats en terme de performance car le tri est la bête noire de Oracle.

Dans quel cas ne pas utiliser d’index ?

Dans tous ces cas, il est déconseillé de poser des indexs :

• Majorité des requêtes ramènent plus de 5% des lignes d’une table
• Enormément de mise à jour par rapport au nombre de lecture
• Colonne pas utilisée dans les clauses WHERE des requêtes et dans les JOINS
• Un nombre de lignes faible dans votre table

Aussi, veillez à ne pas mettre trop d’indexs par table. Ceci peut être très fortement pénalisant lors des mises à jours de votre table.

Pour terminer, l’art de poser est un index n’est pas une science universelle. Chaque cas est une tâche unique à traiter singulièrement et pas à la légère. Il faut savoir bien dosé entre le coût de lecture et d’écriture,  la structure des données, le nombre de lignes etc… etc…

Introduction

L’Optimizer est la partie la plus importante d’une instance Oracle. C’est lui qui choisit quelle chemin il va prendre pour prendre/modifier les données que vous lui ordonnez. Toutes les étapes qu’il va prendre s’appelle le plan d’exécution.

Exemple de plan d’exécution généré via SQL*Plus :

Plan d'exécution
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=143 Card=1438 Bytes=503300)
   1    0   TABLE ACCESS (FULL) OF 'PS_PERSONAL_DATA' (Cost=143 Card=1438 Bytes=503300)

Sur celui-ci par exemple, on observe que l’Optimizer a choisi de scanner complètement la table PS_PERSONAL_DATA , qu’il a parcouru 1438 lignes soit 503,300 kiloBytes de données et que la requête a un coût estimé à 143.

Je paris que vous avez un certain nombre de questions qui vous viennent à la tête tout de suite :

Comment il choisit son « chemin » ce fameux Optimizer ?

Alors, il choisit en fonction de ce qu’on appelle « le coût ». Le coût est un indice qu’Oracle donne à certaines étapes du plan d’exécution. Plus le coût est grand, plus l’action est consommatrice de ressources/temps (dans l’idéal d’Oracle parce que ça se passe pas tout le temps comme ça). Par exemple, un balayage complet d’une table aura un coût plus élevé qu’une sélection partielle de lignes.

Comment elle calcule le coût notre base de données ?

Ca, c’est le jardin secret d’Oracle. C’est un algorithme que seules quelques personnes connaissent dans le monde entier. Pour avoir une migration d’Oracle 8i vers 10G,  le fait que ce soit secret est la principale cause des déboires des Administrateurs de bases de données lors des changements de version d’Oracle. On ne sait jamais vraiment si les performances seront très dégradées/améliorées lorsqu’on migre une application sur une nouvelle version d’Oracle.

Peut-on influencer les choix de l’Optimizer ?

Bien sûr qu’on peut ! C’est d’ailleurs le sujet de cet article. Influencer l’Optimizer est une des principales pistes de Tuning que vous devez explorer sur votre base de données.

Y a-t-il eu des changements importants dans l’Optimizer ces dernières versions ?

Beaucoup de changements. Depuis la version 10G, Oracle a « abandonné » (plutôt déprécié) les modes Rule et Choose et a tout misé sur le mode Cost-based. Vous pouvez choisir entre le mode ALL_ROWS qui privilégie le débit et le mode FIRST_ROWS(n) qui privilégie le temps pour les « n » premiers résultats. Bien sûr, vous pouvez toujours choisir le mode RULE mais l’Optimizer ne tiendra pas compte de ce mode et passera en mode Cost-Based si il juge que c’est mieux pour certaines requêtes.

Finis les questions ? On passe à la liste des paramètres ! Si vous avez d’autres questions, postez les en commentaire. J’ajouterai les réponses à la liste des questions ci-dessus.

OPTIMIZER_MODE

C’est le mode de fonctionnement de l’Optimizer. 4 valeurs sont possibles : CHOOSE, RULE, ALL_ROWS, FIRST_ROWS. Le premier paramètre laisse l’Optimizer choisir entre le mode RULE et COST BASED. Le deuxième paramètre force le mode RULE . Les deux derniers paramètres forcent le mode COST BASED mais avec deux approches différentes :

• ALL_ROWS permet de privilégier le débit global

• FIRST_ROWS permet de privilégier le débit des premiers résultats sortis par une requête

Note : Le mode Rule est devenu obsolète en 10G

Rang de valeurs : RULE, ALL_ROWS, FIRST_ROWS, CHOOSE

Valeur par défaut : ALL_ROWS en 10G, CHOOSE en 8i

Valeur Recommandée pour l’OLTP : CHOOSE

OPTIMIZER_DYNAMIC_SAMPLING

Contrôle le niveau de dynamic sampling, qui permet de calculer les statistiques automatiquement. Plus la valeur est grande, plus le « Dynamic Sampling » est agressif. A 0, le Dynamic Sampling est désactivé.

Note : Existe seulement en 10G

Rang de valeur : 0-10

Valeur par défaut : 2

Valeur recommandée pour l’OLTP : Ca dépend de la quantité de donnée mise à jour/insérées durant une journée. Si vous modifiez/ajoutez plus de 10% de vos données actuelles dans vos tables, Oracle conseille de mettre une valeur grande. Sinon, une valeur de 2 suffira.

OPTIMIZER_INDEX_CACHING

Détermine en pourcentage de nombre de blocs d’index auxquels l’Optimizer peut s’attendre dans le cache.

Rang de valeur : 0 – 100

Valeur par défaut : 0

Valeur recommandée pour l’OLTP : 0

OPTIMIZER_SECURE_VIEW_MERGING

Existe seulement en 10G

Permet d’autoriser ou pas l’Optimizer à vérifier si la vue viole des règles de sécurité.

Rang de valeur : True, False

Valeur par défaut : True

Valeur recommandée pour l’OLTP : False

OPTIMIZER_INDEX_COST_ADJ

Ajuste le coût de parcours d’un index contre un Full Scan. Plus la valeur est petite, plus l’optimiseur est enclin à choisir un index dans le plan d’exécution.

Rang de valeur : 1 – 10 000

Valeur par défaut : 100

Valeur recommandée pour l’OLTP : 100

OPTIMIZER_FEATURES_ENABLE

Permet de forcer l’exécution du noyau comme il était dans une certaine version d’Oracle. Par exemple, si ce paramètre vaut 8.0.6, l’optimizer exécutera la requête comme sur une instance Oracle 8.0.6.

Rang de valeur : Tous les numéros de versions Oracle

Valeur par défaut : Numéro de version d’Oracle

Valeur recommandée pour l’OLTP : Valeur par défaut

OPTIMIZER_PERCENT_PARALLEL

Obsolète en 10G.

Plus la valeur est grande, plus l’Optimizer sera enclin à exécuter en parallèle des requêtes. Ce qui permet d’améliorer significativement les gros traitements, surtout les FULL TABLE SCAN. La valeur de 100 force l’Optimizer à exécuter constamment les requêtes en parallèles. Ce paramètre est surtout utile pour le datawarehousing. Il est plutôt conseillé de passer par des indexs en OLTP.

Rang de valeur : 0 – 100

Valeur par défaut : 0

Valeur recommandée pour l’OLTP : 100 / Nombre d’utilisateurs simultanés

OPTIMIZER_MAX_PERMUTATIONS

Seulement en 8i. Paramètre caché en 10G.

Restreint le nombre de permutations de tables que l’Optimizer va prendre en compte dans les requêtes avec des jointures.

Rang de valeur : 4 – 80 000

Valeur par défaut : 80 000

Valeur recommandée pour l’OLTP : < 1000