Discussion :

[tropiko]

bonjour ,
Je souhaite paralléliser un batch qui dure 3h en mettant le paramètre PARALLE_DEGREE_POLICY à AUTO (nouveauté 11g).
J'ai suffisamment de ressources CPU et mémoire pour paralléliser des requêtes.
Que pensez-vous de cette technique ? danger ?
merci

[pachot]

Bonjour,

PARALLEL_DEGREE_POLICY=AUTO est facile à essayer, mais comme tout paramètre automatique, difficile à contrôler.
Il active plusieurs fonctionnalités (statement queuing et in-memory parallel execution).
Ce n'est pas seulement une question de mémoire et ressources CPU. Parallel query va aussi faire plus d'i/o vers les tempfiles.

Une autre approche serait de voir les requêtes qui prennent beaucoup de temps, et individuellement de voir ce qu'apporte Parallel Query.
Peut-être voir si le partitionnement est ok avant.

Cordialement,
Franck.

[tropiko]

Bonjour .
Merci Franck
Si les stats ne sont pas a jour Oracle risque t il de mal paralleliser ?
Si oui comment ?
quel est le lien entre les stats et la gestion automatique de la parallelisation par Oracle ?
merci

[tropiko]

Enfin comment je peux verifier qu au niveau OS(AIX) s il existe des limitations ou contraintes techniques qui pourraient empecher la parallelisation oracle ?

[pachot]

Bonjour,

Si les stats ne sont pas a jour Oracle risque t il de mal paralleliser ?

Si les stats sont fausses, tous les choix du CBO risquent d'être mauvais... parallelisation inclus.

quel est le lien entre les stats et la gestion automatique de la parallelisation par Oracle ?

Les stats servent à calculer les coûts des différents choix possibles. Et les décisions de parallélisation se basent sur les coûts.

Enfin comment je peux verifier qu au niveau OS(AIX) s il existe des limitations ou contraintes techniques qui pourraient empecher la parallelisation oracle ?

Je ne vois pas ce qui pourrait empêcher la parallélisation par Oracle. Du moment que Oracle peut créer plusieurs process il peut paralléliser. Après c'est une estimation de coût.

[tropiko]

Bonjour
Est ce que PARALLE_DEGREE_POLICY=AUTO gere automatiquement la parallelisation au niveau SELECT ou aussi les DML ?
Avec ce mecanisme mes insert update delete sont aussi parallelisees ?
Merci

[pachot]

Parallel DML n'est pas activé par défaut. Il faut faire ALTER SESSION ENABLE PARALLEL DML.

[tropiko]

Bonjour Franck
quand un dml est executé en parallel sur une table T il faut parfois commiter avant de pouvoir consulter cette table sinon un erreur ORA- ....
Est-ce normal ? comment contourner ce pb dans mon cas :
parallelisation automatique des select et des DML sans rien toucher au code.
merci

[pachot]

Oui c'est normal. Parallel DML écrit directement dans les fichiers en bypassant le buffer cache. Il faut terminer la transaction avant de pouvoir faire une autre opération sur la table.

[tropiko]

bonjour
le bach de 3 heures tourne sans erreurs en mode serialisé.
il tourne sans erreurs en 2h30 en mode parallel_degree_policy=AUTO
MAIS des erreurs apparaissent des que je rajoute

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

alter session force parallel dml

erreur genre colonne n accepte pas la valeur nulle ....
j'étais persuadé que la parallelisation n'impacte pas les traitements et leur sémantiques mais là ce n'est pas le cas ?

[pachot]

Bonjour,

j'étais persuadé que la parallelisation n'impacte pas les traitements et leur sémantiques mais là ce n'est pas le cas ?

Si, et c'est probablement la raison pour laquelle ce n'est pas par défaut...

Il y a de nombreuses restriction de l'insert en direct-path
http://docs.oracle.com/cd/E11882_01/...3.htm#CACEJACE

Cordialement,
Franck.

[tropiko]

bonjour
merci pour la doc.
pas facile la mise en oeuvre de cette nouvelle option 11g et surtout sa maitrise par la suite....
je vais creuser la piste du parallel au niveau des tables les plus volumineuses ?
[sql]alter table toto parallel 10;[/sql]

[pachot]

Oui. Le parallel DML, c'est pas un truc magique qui fait tout aller plus vite. C'est au cas par quoi qu'il faut voir à l'utiliser (à mon avis).
J'ai déjà vu des bases qui faisaient un FORCE PARALLEL DML dans un logon trigger - pour tous les users. Avec des effets plutôt inattendus...

[tropiko]

Bonjour Franck ,
J'ai utilisé FORCE PARALLEL QUERY au niveau de la procédure initiale du traitement et j'ai eu un gain de 10% en temps de traitement
(Le FORCE PARALLEL DML génère des erreurs au niveau du traitement , j'ai donc laisser tomber pour l'instant).

Le DOP calculé par Oracle dans mon cas = cpu_count * Nbre de threads par cpu.

Par contre le paramètre 11g parallel_degree_policy je l'ai laissé à sa valeur par défaut (MANUAL).

J'ai rencontré un souci :
J'ai lancé le traitement n fois mais 2 fois il ne veut pas se lancer en // (uniquement en sérialisé) ...
En vérifiant au niveau session j'ai trouvé un "résidus" de processus PX inactifs !!!
J'étais contraint de redémarrer la base pour ne plus les avoir ...
Est-ce normal ?
Votre avis ? Puis-je faire mieux ?
merci

[pachot]

Bonjour,

J'ai lancé le traitement n fois mais 2 fois il ne veut pas se lancer en // (uniquement en sérialisé) ...

Il faudrait en chercher la raison dans les stats (Parallel operations downgraded), le plan d'exécution,...
Si Tuning Pack, les rapports SQL Monitoring sont excellents pour ça.

C'est normal que les process parallèles restent.

Cordialement,
Franck.

[tropiko]

Bonjour Franck ,
Merci pour votre aide !
Sinon en lançant un traitement en parallel , comment je pourrais vérifier la consommation CPU et la consommation en RAM.

L'objectif est de vérifier que mon traitement parallélisé ne risque pas de faire tomber mon serveur IBM AIX.

merci encore une fois

[pachot]

Bonjour,

L'objectif est de vérifier que mon traitement parallélisé ne risque pas de faire tomber mon serveur IBM AIX.

C'est au niveau AIX qu'il faut vérifier: CPU usage, Load average,...
Cordialement,
Franck.