Discussion :

[fouad_wsf]

Je suis un responsable étude et développement et j’ai une équipe de sept développeurs qui développent en PL/SQL des procédures qui font la plupart du temps des extractions à partir d’ERP (base oracle 10g, taille 3 teraoctets).

Lorsque mon équipe de DEV met en PROD l’une des procédures développées, on reçoit toujours des réclamations de la part de notre équipe de DBA qui nous réclame que notre procédure n’est pas optimisée, et ceci parce que la procédure a mis plus que 12h de traitement ou plus bref…

Le problème c’est qu’ils ne nous fournissent aucun élément à part que le programme n’est pas optimisé et que lors de son lancement les performances de la base de la PROD ont chuté.

Mes questions sont les suivantes :

1. Comment je peux être sûr qu'effectivement les performances de la base ont chuté à cause de la nouvelle procédure qui vient d’être développée et mise en prod ?
2. Comment je peux savoir si ma procédure est optimisée on non ?
3. Qu’est ce qu’on peut exiger au DBA comme élément pour qu’il nous prouve la non-optimisation de la procédure ?
4. Est ce que vous trouvez normal que les performances d’une base de données chutent d’une manière brutale à cause d’un programme (admettons) non optimisé ?

Je vous serais très reconnaissant si vous pouvez nous donner quelques idées sur le sujet.

Merci d’avance.

[Invité]

1- si la procédure est mal écrite, elle peut être très consommatrice de ressource, au détriment des autres utilisateurs.
2- Le métier et une bonne compréhension du fonctionnement. Des tests sérieux de validations.
3- effectivement, c'est plus sérieux de le prouver. Mais si la bd est bloquée par une nouvelle procédure, il n'y a pas à chercher midi à quatorze heure.
4- Ça se voit très régulièrement. Est-ce normal? Non.
Comment se fait-il que des programmeurs bidouillent un programme sur des tables énormes sans avoir une vague notion des concepts de bases de données et d'optimisation? C'est ça que je ne trouve pas normal.
D'autant plus que j'en ai pondu du code pourri non optimal au possible avant d'être former DBA.

[Waldar]

Vous pouvez demander à votre équipe DBA une trace étendue de l'exécution du code des procédure pour voir où ça coince exactement.

Si votre volumétrie en DEV est très différente de celle de PROD, vous pouvez modifier les statistiques afin de les faire correspondre, ce qui vous permet d'analyser les plans d'exécution.

[fouad_wsf]

Vous pouvez demander à votre équipe DBA une trace étendue de l'exécution du code des procédure pour voir où ça coince exactement.

Si votre volumétrie en DEV est très différente de celle de PROD, vous pouvez modifier les statistiques afin de les faire correspondre, ce qui vous permet d'analyser les plans d'exécution.

merci bcp pour la réponse.
vous dite que je peux changer les statistiques qui sont calcules par ORACLE dans
mon environnement de DEV .
est ce que c'est possible que j'insert dans les tables du SYS ?

[Waldar]

Oui, regardez dans le package DBMS_STATS, il y a tout ce qu'il faut pour définir des statistiques.

[fouad_wsf]

Oui, regardez dans le package DBMS_STATS, il y a tout ce qu'il faut pour définir des statistiques.

ok je vais voir et je vous tiendrais au courant si ça marche

merci