Utilisation de HINT PARALLEL

Version imprimable

08/02/2013, 02h21
tropiko

Utilisation de HINT PARALLEL

Bonjour,
Je souhaite étudier l’impact de l’utilisation du hint PARALLEL sur une requête SQL 10gR2.
Le hint PARALLEL 4 m’a permis de passer de 30 min à 12 min.
Le problème c’est que quand cette requête est lancé par 3 utilisateurs en même temps, le temps est quasi le même ( 30 min ) , voir plus pour le 3eme utilisateur !
Comment remédier à cela ? Quelles paramètres de la base 10gr2 et/ou OS AIX 6 à configurer pour assurer un accès simultané via le hint PARALLEL ?

Enfin, dans quel cas le hint PARALLEL est recommandé ?
quel est le degré DOP optimal ?

merci
08/02/2013, 09h21
Rei Ichido

Parallel fait que plusieurs processeurs sont utilisés pour la requête. Ce n'est pas toujours utile, selon la requête, mais forcément ça peut aider. Par contre, si vous avez 4 processeurs disponibles, et qu'un seul utilisateur fait la requête : il peut tout utiliser. Mais si vous avez 4 utilisateurs, il va y avoir conflit ! Et sans compter qu'il faut aussi coordonner les 4 processeurs, et que cela prend du temps, d'où la potentielle dégradation.

Le mieux serait certainement, avant d'en arriver au hint parallel, d'essayer d'optimiser la requête ?
08/02/2013, 09h31
mnitu

L’exécution parallèle est l’opposé de la montée en échèle. Un utilisateur exécutant une requête en parallèle c’est super si le système a des ressources disponibles. N utilisateur exécutant la même requête en parallèle peut être un désastre parce qu’en plus du travail de la requête Oracle doit gérer la coordination de l’exécution parallèle. De plus l’optimisation des requêtes en parallèle est différente de celle de l’exécution normale.
Essayez d’optimiser la requête sans exécution parallèle si elle doit être exécutée par plusieurs utilisateurs simultanément.
08/02/2013, 13h26
pachot

Bonjour,

Il y a un certain nombre de paramètres qui gèrent ça:

Code:

show parameter parallel

Il se peut que lorsque vous avec les 3 requêtes, Oracle n'ait pas assez de process (parallel_max_servers) et que le degré soit dégradé.

Un DOP de 4 peut avoir besoin de 8 process.

Citation:

Le hint PARALLEL 4 m’a permis de passer de 30 min à 12 min.

Utiliser 4 fois plus de ressources (ou même peut-être 8) pour diviser le temps par seulement 2.5 ce n'est peut-être pas si judicieux...

Cordialement,
Franck.
09/02/2013, 01h46
tropiko

Bonjour ,

Dois-je augmenter parallel_max_servers ? si oui quelle valeur ?
Actuellement il est à la valeur 40 ?
et en 11g existe-il des nouveautés permettant d'utiliser le PARALLEL sans risques ?
Aujourd'hui quand j'ai une requête SELECT qui rame et que je ne peux pas la réécrire , si plan d'exécution montre du full scan sur des tables , j'utilise PARALLEL comme hint pour chacune de ces tables de la requête et cela fait booster l'exécution :)

Votre avis ?
09/02/2013, 11h46
pachot

Bonjour,

Il faut prendre l'exécution parallèle comme un moyen d'utiliser toutes les ressources de la machine.
Par exemple, un batch qui tourne tout seul sur une machine qui a 8 CPU, si on n'est pas en parallèle, n'utilisera jamais plus d'une CPU. On peut donc augmenter le degré de parallélisme jusqu'à utilisation maximale de la machine.

mais lorsqu'on a plusieurs utilisateurs, on ne peut pas donner toutes les ressources de la machine à chacun des utilisateurs.

Si parallel_max_servers=40 il ne devrait pas y avoir de dégradation du degré de parallélisme avec 3 utilisateurs. Par contre, combien y a-t-il de CPU (nb de cores) ? Par exemple, s'il y a 4 cores il y a probablement contention savec 3 x 4 (et peut être x2 en fonction du plan d'exécution) processus d'exécutant en parallèle. Et pour les accès disques, c'est pareil. Il y a une limite.

Citation:

quand j'ai une requête SELECT qui rame et que je ne peux pas la réécrire , si plan d'exécution montre du full scan sur des tables

Il y a d'autres choses à voir: compression, partitionnement, ...

Citation:

en 11g existe-il des nouveautés permettant d'utiliser le PARALLEL sans risques ?

Il y a moyen de laisser Oracle adapter le DOP en fonction de la charge.

Cordialement,
Franck.
10/02/2013, 20h33
tropiko

Bonjour ,

Citation:

Envoyé par pachot

Si parallel_max_servers=40 il ne devrait pas y avoir de dégradation du degré de parallélisme avec 3 utilisateurs. Par contre, combien y a-t-il de CPU (nb de cores) ?

Je n'ai pas compris le terme "Dégradation de DOP ?"
Nous avons 10 CPU dual-coeurs , donc 20 cores au total.
Combien de requêtes sérialisées et // puis-je lancer en même temps sachant que max_parallel_servers = 40 ?

Citation:

Il y a d'autres choses à voir: compression, partitionnement, ...

Le partitionnement est déjà utilisé mais la compression NON.
S'agit-il de compresser systématiquement les données de chaque table accédée par FULL SCAN ? compression basique ou FOR OLTP ?
Dans tous les cas il faut compresser les données dont la mise à jour n'est pas fréquente ?

Merci.
11/02/2013, 09h03
Rei Ichido

Citation:

Envoyé par tropiko

Aujourd'hui quand j'ai une requête SELECT qui rame et que je ne peux pas la réécrire , si plan d'exécution montre du full scan sur des tables , j'utilise PARALLEL comme hint pour chacune de ces tables de la requête et cela fait booster l'exécution :)

Outre ré-écrire la requête, si le plan montre un full scan, il est potentiellement possible de poser un/des index. Bien sûr, comme toute pose d'index, cela a un coût tant en espace disque qu'en terme d'IO dans les insertions/éditions ; mais ça peut changer radicalement les performances.
11/02/2013, 09h37
pachot

Bonjour,

Citation:

Je n'ai pas compris le terme "Dégradation de DOP ?"

En fait, lorsque Oracle n'a plus assez de parallel servers pour le DOP demandé, il va réduire le DOP, voir exécuter la requête sans parallel.
Suivant la config, adaptive multi-user peut dégrader le DOP avant même d'atteindre le maximum.

Citation:

Nous avons 10 CPU dual-coeurs , donc 20 cores au total.
Combien de requêtes sérialisées et // puis-je lancer en même temps sachant que max_parallel_servers = 40 ?

Donc 20 cores, à supposer qu'il n'y a rien d'autre qui tourne sur le serveur, peut faire tourner jusqu'à 20 processus. Donc 5 requêtes en DOP 4 si elles sont à fond en CPU. Mais elles font aussi des i/o. Et il peut y a voir 2 process pour un DOP (un producteur et un consommateur...)

Citation:

S'agit-il de compresser systématiquement les données de chaque table accédée par FULL SCAN ?

Non ! Il n'y a rien de systématique !

Le mieux est de voir où est la contention (Statspack, AWR, etc.)

Cordialement,
Franck.
11/02/2013, 10h25
Rams7s

Citation:

Envoyé par pachot

Donc 20 cores, à supposer qu'il n'y a rien d'autre qui tourne sur le serveur, peut faire tourner jusqu'à 20 processus. Donc 5 requêtes en DOP 4 si elles sont à fond en CPU. Mais elles font aussi des i/o. Et il peut y a voir 2 process pour un DOP (un producteur et un consommateur...)

Un peu plus que 5 requetes, ou en parallèle 8 voir plus selon où est le goulot d'étranglement.
Un des intêrets du parallèle, c'est que le temps que le block physique soit lu, on puisse avoir un autre process qui travaille sur CPU. Après, le degré de parallelisme va pouvoir être adapté en fonction de la baie de disque. Si c'est 2ms de temps d'accès on aura besoin de moins processus que si c'est 8ms pour être à 100% de CPU et donc aller le plus vite possible.