[Packages]Un véritable gain de performance ?

Version imprimable

27/10/2005, 23h36
New

[Packages]Un véritable gain de performance ?

Je connais les avantages point de vue programmation de l'utilisation de packages à la place de plusieurs requetes sql mais avant de faire le pas vers l'utilisation de package, je me demande si cela va permettre de réduire l'utilisation de la mémoire d'une instance oracle ? Bref d'une manière générale si coté serveur, ça va pas plus le ralentir ?

Ceux qui ici utilisent les packages régulièrement peuvent-il me donner leur retour d'exprérience à ce sujet ?

Merci.
28/10/2005, 08h33
rouardg

Bonjour,

Citation:

Envoyé par New

Je connais les avantages point de vue programmation de l'utilisation de packages à la place de plusieurs requetes sql

C'est-à-dire ?

Citation:

Envoyé par New

je me demande si cela va permettre de réduire l'utilisation de la mémoire d'une instance oracle ? Bref d'une manière générale si coté serveur, ça va pas plus le ralentir ?

Au niveau mémoire, on pourrait dire en gros qu'un package est plus consommateur de mémoire. En effet, lors du premier appel à une procédure, ou une fonction, ou une variable de ce package, c'est tout le package qui est monté en mémoire.

Pour moi, l'avantage du package est le fait de regrouper des fonctions et des procédures communes dans un même package. L'autre avantage est qu'on peut l'utiliser pour avoir des variables globales et persistentes dans sa session, et ce pendant toute la durée de sa session.

Enfin, au niveau administration, il est possible d'épingler (certains disent pinner, d'autres disent keeper) un package dans la Shared Pool, pour qu'il reste toujours en mémoire.

Pour moi, le seul "inconvénient" des packages se situe lors de l'utilisation d'un pool de connexion, dans une architecture 3 tiers. En effet, lors des livraisons en base de production, si le code livré impacte un package et qu'il faut alors le recompiler, il est nécéssaire d'arrêter le pool de connexion. On ne peut donc pas faire de livraison à chaud et transparente sur la base de données. Mais c'est un défaut mineur.
28/10/2005, 09h34
Yorglaa

n'oublions pas non plus qu'un package est déjà compilé, donc à l'exécution tu as un gain de temps au niveau de la phase de parsing...

Citation:

Envoyé par Yorglaa

n'oublions pas non plus qu'un package est déjà compilé, donc à l'exécution tu as un gain de temps au niveau de la phase de parsing...

Bonjour ,
je vais me permettre de faire une petite remarque, si effectivement un package est monté en mémoire et que que l'on peut également le keeper en mémoire ( comme l'affirme rouardg ) je suis moins d'accord sur ce dernier point de vue.
Une procédure lorsqu'elle est appellé en mémoire est donc analysé ( ou parsé ) cependant si on appelle une autre procédure du package et que c'est la premiére fois depuis le dernier startup de la base ( et que personne d'autre ne l'a appellé ) elle serat forcément hard-parsé.

Voila un exemple qui repose sur le package DBMS_JOB, ou on va soumettre un job de prise de STATSPACK puis on va le supprimmer :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
SQL> SELECT a.name , value  FROM v$statname a , v$mystat b 
  2  WHERE a.STATISTIC#=b.STATISTIC#
  3  AND a.name LIKE '%parse count%' ;
 
NAME                                                                  VALUE
---------------------------------------------------------------- ----------
parse count (total)                                                      14
parse count (hard)                                                        1
 
SQL> DECLARE
  2  jobno number;
  3  begin
  4   dbms_job.submit(jobno, 'statspack.snap;',trunc(sysdate) + 1 + 9/24, ' trunc(sysdate) + 1 + 9/2
4');
  5  commit ;
  6  end ; 
  7  /
 
Procédure PL/SQL terminée avec succès.
 
SQL> SELECT a.name , value  FROM v$statname a , v$mystat b 
  2  WHERE a.STATISTIC#=b.STATISTIC#
  3  AND a.name LIKE '%parse count%' ;
 
NAME                                                                  VALUE
---------------------------------------------------------------- ----------
parse count (total)                                                     114
parse count (hard)                                                       12
 
SQL> SELECT a.name , value  FROM v$statname a , v$mystat b 
  2  WHERE a.STATISTIC#=b.STATISTIC#
  3  AND a.name LIKE '%parse count%' ;
 
NAME                                                                  VALUE
---------------------------------------------------------------- ----------
parse count (total)                                                     115
parse count (hard)                                                       12
 
SQL> SELECT a.name , value  FROM v$statname a , v$mystat b 
  2  WHERE a.STATISTIC#=b.STATISTIC#
  3  AND a.name LIKE '%parse count%' ;
 
NAME                                                                  VALUE
---------------------------------------------------------------- ----------
parse count (total)                                                     116
parse count (hard)                                                       12
 
SQL> r
  1  SELECT a.name , value  FROM v$statname a , v$mystat b
  2  WHERE a.STATISTIC#=b.STATISTIC#
  3* AND a.name LIKE '%parse count%'
 
NAME                                                                  VALUE
---------------------------------------------------------------- ----------
parse count (total)                                                     117
parse count (hard)                                                       12
 
SQL> 
SQL> exec DBMS_JOB.REMOVE('92') ;
 
Procédure PL/SQL terminée avec succès.
 
SQL>  SELECT a.name , value  FROM v$statname a , v$mystat b
  2   WHERE a.STATISTIC#=b.STATISTIC#
  3   AND a.name LIKE '%parse count%' ;
 
NAME                                                                  VALUE
---------------------------------------------------------------- ----------
parse count (total)                                                     124
parse count (hard)                                                       17

Et c'est même pire que ca car il suffit de changer l'heure pour qu'il y ai à nouveau un hard parse :

et c'est ainsi que :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
SQL> SELECT a.name , value  FROM v$statname a , v$mystat b 
  2  WHERE a.STATISTIC#=b.STATISTIC#
  3  AND a.name LIKE '%parse count%' ;
 
NAME                                                                  VALUE
---------------------------------------------------------------- ----------
parse count (total)                                                     146
parse count (hard)                                                       28
 
SQL> DECLARE
  2  jobno number;
  3  begin
  4   dbms_job.submit(jobno, 'statspack.snap;',trunc(sysdate) + 1 + 9/24, ' trunc(sysdate) + 1 + 9/2
4');
  5  commit ;
  6  end ; 
  7  /
 
Procédure PL/SQL terminée avec succès.
 
SQL> SELECT a.name , value  FROM v$statname a , v$mystat b 
  2  WHERE a.STATISTIC#=b.STATISTIC#
  3  AND a.name LIKE '%parse count%' ;
 
NAME                                                                  VALUE
---------------------------------------------------------------- ----------
parse count (total)                                                     151
parse count (hard)                                                       28
 
SQL> SELECT a.name , value  FROM v$statname a , v$mystat b 
  2  WHERE a.STATISTIC#=b.STATISTIC#
  3  AND a.name LIKE '%parse count%' ;
 
NAME                                                                  VALUE
---------------------------------------------------------------- ----------
parse count (total)                                                     152
parse count (hard)                                                       28
 
SQL> DECLARE
  2  jobno number;
  3  begin
  4   dbms_job.submit(jobno, 'statspack.snap;',trunc(sysdate) + 1 + 10/24, ' trunc(sysdate) + 1 + 10
/24');
  5  commit ;
  6  end ; 
  7  /
 
Procédure PL/SQL terminée avec succès.
 
SQL> SELECT a.name , value  FROM v$statname a , v$mystat b 
  2  WHERE a.STATISTIC#=b.STATISTIC#
  3  AND a.name LIKE '%parse count%' ;
 
NAME                                                                  VALUE
---------------------------------------------------------------- ----------
parse count (total)                                                     157
parse count (hard)                                                       30
 
SQL>

édifiant !!

Cependant ce probléme peut être facilement résolu en passant par les bind variables .

PS : rappellons que toute requête est parsé mais que la différence se situe entre Hard-parse et Soft parse : Plus de renseignement

Jaouad

28/10/2005, 13h49
Yorglaa

Citation:

Envoyé par Jaouad

...Cependant ce probléme peut être facilement résolu en passant par les bind variables ...

il est CLAIR qu'il faut passer par les bind variables lorsqu'on utilises des packages...

Désolé de ne pas l'avoir précisé, ça me semblait tellement évident !

Mais si on "cherche la petite bête"... il y a toujours une moyen de prendre la règle générale en défaut... ça s'appelle une exception !

Partant, faut-il conseiller de faire une application en s'appuyant sur des packages ? ou sur des scripts ?

Là je pense qu'il n'y a pas photo, les packages !! et ce quelles que soient les manips qu'on peut toujours trouver pour tomber dans ces exceptions... lorsqu'on retombe sur nos pattes (et les Best Pratices => Bind Variables) on revient quand même à la règle générale...
28/10/2005, 14h00
Jaouad

Yorglaa :fleche: ne te méprend pas sur mes intentions, ici il ne s'agit pas de mettre quelqu'un en parte a faux , et encore moins toi , je rebondissais sur ta remarque qui disait que dés que tu as un package de compilé tu gagne du temps en mémoire du à la phase de parse.

C'est juste essayer de démontrer que le fait d'avoir un package valide et déja utilisé ( procedure dbms_job.submit ) ne prévient pas un hard parse lorsque l'on réutilise le même package ( dbms_job.remove ) il ne me semble pas que cela soit une exeption ou un " cas tordu " mais plutôt la régle .

Puis par la suite j'ai continuer mon raisonnement en précisant l'utilité des Bind Variables dans les paramétres IN de la procédure : c'est une erreur largement répandu .

Ce qui est évident pour quelqu'un qui est à l'aise ( ce qui est ton cas ) ne l'ai pas pour tout le monde :wink:

Voila , j'espére n'avoir froissé personne :?
28/10/2005, 14h17
SheikYerbouti

N'oublions pas, également, que le package permet de centraliser les traitements et de s'assurer que le résultat sera rigoureusement identique quelle que soit la source d'appel (Sql*Plus, Toad, Forms, Java, etc...)

De plus, lors de la manipulation de grands volumes de données, il ne procure aucun impact réseau particulier.
28/10/2005, 14h19
Yorglaa

non, non... pas de soucis...

je ne suis pas froissé, je veux juste attirer l'attention sur le cas "d'ordre général"... :wink:

le but étant de ne pas embrouiller les autres personnes qui liraient ce Post... au delà de ça je suis toujours ouvert pour un bon petit débat sur les meilleures méthodes et leurs excetions ! :P