::: Alain DEREN, Consultant --=-- Certified Oracle DBA (OCP).

  Accueil  Blog  Nouvelles  Télécharger  Liens  FAQ  Livre d'or 

PL-SQL parallel execution

Rubrique : ORACLE-SweetDreams - par webMaster_alaindereninfo

Oracle - Sweet Dreams  PL-SQL parallel execution

Note: "Sweet Dreams are made of this..."
Un article "Sweet Dreams" parle une amélioration, une nouvelle fonctionnalitée, que je voudrai voir apparaitre dans une prochaine version d'Oracle.


Oracle est capable de lancer des SELECT en exécution parallèles. De même pour les créations d'Index ou autres.
Cela existe depuis longtemps, mais rien n'existe dans le PL/SQL.

Sur les serveurs, on est depuis longtemps en multi-processeurs, mais pour les traitements en PL/SQL on travaille presque toujours sur un seul processeur à la fois.

Une solution de contournement est possible avec DBMS_SCHEDULER (ou l'ancien DBMS_JOB). Mais ca peut devenir pénible à écrire et maintenir ce genre de Job.

Une autre solution de contournement  existe pour "TABLE PARALLEL EXECUTION" en 11gR2 avec le package "DBMS_PARALLEL_EXECUTE".
C'est parfait, par exemple, pour exécuter des UPDATE en parallel sur la même table. Mais pour des actions indépendantes, c'est inutile.
Jetez un oeil sur cet excellent article: http://www.oracle.com/technetwork/issue-archive/2010/10-may/o30plsql-086044.html


Soit un PL/SQL (block, procedure/fonction d'un package ou indépendant).
a) Je cherche dans TABLE1, le nombre de lignes qui répondent à un certain critère.
b) Je cherche dans TABLE2, le nombre de lignes qui répondent à un autre critère.
c) Je cherche dans TABLE3, le nombre de lignes qui répondent à un autre critère.
d) Je compare le résultat de a) b) et c). Et selon les cas (égalité, null d'un coté ou l'autre, supérieur, inférieur, ...), je décide de faire tel ou tel traitement.

Dans un PL/SQL classique, les opérations sont serialisés: D'abord a), puis b) puis c) puis d).
Mais a) b) et c) sont indépendants, mais en PL/SQL je n'ai pas le choix de les exécuter en parallèles.


Bien sur, il est possible de choisir une solution de contournement décrite plus haut. Mais c'est lourd à écrire, et pas toujours à la portée du programmeur Oracle "standard", et cela perd en portabililté.


Donc voici mon rève d'extension du PL/SQL:

DECLARE
  l_result1 NUMBER ;
  l_result2 NUMBER ;
  l_result3 NUMBER ;
BEGIN
...
  BEGIN PARALLEL
    SELECT COUNT(*)  INTO l_result1 FROM table1  WHERE ... ;
    SELECT COUNT(*)  INTO l_result2 FROM table2  WHERE ... ;
    SELECT COUNT(*)  INTO l_result3 FROM table3  WHERE ... ;
  END PARALLEL ;
--
  IF ( l_result1 IS NULL )
  THEN
...
  ELSE
    IF ( l_result1 = ( l_result2 + l_result3 ) )
    THEN
    ELSE
      IF ( l_result1 > ( l_result2 + l_result3 ) )
      THEN
        ..
      ELSE
        ..
      END IF ;
    END IF ;
  END IF ;
...
EXCEPTION
...
END ;


Explications:

(1)  BEGIN PARALLEL
(2)    SELECT COUNT(*)  INTO l_result1 FROM table1  WHERE ... ;
(3)    SELECT COUNT(*)  INTO l_result2 FROM table1  WHERE ... ;
(4)    SELECT COUNT(*)  INTO l_result3 FROM table3  WHERE ... ;
(5)  END PARALLEL ;


(1) prepare le block en parallel execution.
(2), (3), (4) sont des declarations de traitements, tant que l'on ne rencontre pas le (5), elles sont déclarés mais non exécutés.
(5) clos les déclarations de traitements, et lance l'exécution en parallel de (2), (3) et (4) dans des processus différents. On ne sort de (5) que lorsque toutes les exécutions sont terminées.


Limitations:

1) Pour éviter de lancer trop de processus en parallèles, on pourrait imaginer d'avoir un paramètre d'instance du type MAX_PARALLEL_PLSQL_EXECUTION. Ce paramètre serait égal par défaut au nombre de processeurs divisé par 2. Ainsi sur un système sur 8 processeurs, la valeur serait de 4 par défaut. Si un PL/SQL demande demande l'exécution de 5 processus en parallele, seul les 4 premiers vont démarrer, et le 5ième ne va démarrer que lorsque l'un des 4 premiers sera terminé.

2) Un block parallele à la fois: Pas d'imbrication de block parallele à l'intérieur d'un block déjà déclaré comme parallele.

Date de création : 07/07/2011 : 17:53
Page lue 389311 fois
Haut

© 2004-2025

Document généré en 1.44 secondes