Introduction au parallélisme d’Oracle

Cet article est une introduction à une série d’article à venir sur le parallélisme d’Oracle.

Principe :

Par défaut lorsque vous exécutez une requête celle-ci s’exécute de manière séquentielle c’est à dire que vous n’avez qu’un seul process server qui travaille pour vous. Donc même si vous avez plusieurs CPU, le process server ne pourra en utiliser qu’un seul.

Le but du parallélisme dans une base Oracle est de répartir sur plusieurs process esclaves ("slave process") une tâche adressée initialement à un process server. La coordination de ces process est géré par le process server lui-même qu’on appelle dans ce cas le « Query Coordinator » L’avantage c’est que chacun de ces process esclaves pourra utiliser un CPU différent. On profite ainsi pleinement des ressources disponibles sur le serveur (CPU, RAM, I/O).

Un parallélisme approprié peut faire passer une requête de plusieurs heures à quelques minutes seulement, mais attention, un parallélisme inappropriée peut avoir l’effet inverse.

Analogie :

Le parallélisme utilisé par Oracle ressemble à ce que tout le monde fait dans la vie de tous les jours. Imaginons que vous souhaitez rénover votre appartement. Si vous êtes tout seul à travailler vous devrez repeindre chacune de vos pièces les unes après les autres. Vous travaillerez alors en mode séquentiel. Par contre si vous êtes 4 amis à travailler vous pouvez vous partager les tâches. Chacun par exemple pourra s’occuper de repeindre une pièce. Vous travaillerez donc en mode parallèle. Vous perdrez juste un peu de temps pour vous coordonner mais au final vous serez plus efficaces.

Maintenant imaginons que vous n’ayez qu’un mur à repeindre. Vous perdrez plus de temps en vous mettant à plusieurs qu’en le faisant tout seul (je suis en plein chantier peinture en ce moment chez moi c'est pour ça que cet exemple m'est venu à l'esprit).

Le parallélisme d’Oracle fonctionne selon le même principe. Si vous avez de grosses requêtes qui mettent du temps à s’exécuter et dont les opérations sont facilement divisibles en sous-tâches (ex : parcours de plusieurs partitions d’une table) alors vous y gagneriez en parallélisant. Par contre si vous décidez de paralléliser un select retournant qu’une ligne via un index unique alors votre requête sera moins performante car la gestion des process « slaves » sera plus coûteuse que l’exécution de la requête elle-même.

Quand utiliser le parallélisme :

Le parallélisme est approprié lorsque :
- Vous avez plusieurs CPU disponibles
- Les données sont réparties sur plusieurs disques (stripping)
- L’instruction SQL met du temps à s’exécuter car consomme beaucoup de ressources (ex : Full Table Scan sur une grosse table avec une clause ORDER BY).
- Votre requête ne s’exécute pas dans un environnement hyper concurrentiel (base OLTP)

Le parallélisme peut être utilisé en générale dans les instructions suivantes:
- Un select massif effectuant de l’accès multiblocks (Full Table Scan ou Fast Full Index Scan). On parle de « Parallel Query ».
- Un update/delete/insert massif. On parle de « Parallel DML ».
- Pour les rebuilds d’index ou les CTAS (Create Table As Select). On parle de « Parallel DDL ».


Degrée de parallélisme (DOP) :

Le degré de parallélisme correspond au nombre de process esclaves utilisé pour une instruction en mode parallèle.
Par exemple la commande ci-dessous crée une table TOTO en mode parallèle avec un DOP de 8. Cela veut dire que 8 process « slaves » (donc 8 CPU) seront utilisées pour les requêtes effectuées sur cette table :

CREATE TABLE TOTO (c1 NUMBER, c2 VARCHAR2(100)) PARALLEL 8 ;

Vous pouvez vérifier qu’une table est définie en mode parallèle ou pas en interrogeant la colonne DEGREE de la vue USER_TABLES :

SQL> select table_name,degree from user_tables where table_name='TOTO';

TABLE_NAME                     DEGREE
------------------------------ ----------
TOTO                                    8

Si la clause PARALLEL est utilisée sans spécifier le degré de parallélisme, le DOP utilisée sera alors le résultat de la multiplication suivante :

CPU_COUNT * PARALLEL_THREAD_PER_CPU

CPU_COUNT est le paramètre d’initialisation de la base indiquant le nombre de CPU disponibles et PARALLEL_THREAD_PER_CPU est le paramètre indiquant le nombre de process « slaves » possibles pour un CPU.

Lorsque vous utilisez le parallélisme je recommande de ne pas définir la table en mode parallèle mais plutôt d’utiliser le hint PARALLEL pour les requêtes que vous voulez vraiment paralléliser.

Chaque type d’instructions SQL parallélisable fera l’objet d’un post prochainement :
- Les SELECT en mode parallèle (Parallel Query)
- Les DML en mode parallèle (PDML ou Parallel DML)
- Les DDL en mode parallèle (PDDL ou Parallel DDL)