Discussion :

[maelleam]

Bonjour,

Je bosse sur un projet COBOL/CICS/DB2V9 (V10 bientôt) sur ZOS. Ma boite (SSII) a décidé de mettre en place des accesseurs DB2. Le projet compte environ 3000 pgms et 1400 tables. La mise en place sera progressive.


Je conçois bien a quel point c'est séduisant pour un chef de projet (et un commercial). Et en laissant de coté ma mauvaise fois j'arrive même a voir des avantages pour les développeur.


J'ai également lu des articles de Craigs Mullins. L'article date pas mal les machines ont évolué. Je ne sais pas si les arguments de perfs sont valides.
(http://www.craigsmullins.com/dbu_0703.htm)
Résumé rapide: Evitez les accesseurs parce que:
* Les développeurs auront tendance a ignorer la complexité de ce qu'ils demandent a DB2. Et pour cause: ils le demandent a un programme. Mieux vaut éduquer les développeurs aux bonnes pratiques SQL.
* Avec le temps les accesseurs deviennent générique. Ils fetchent beaucoup de donnée inutiles. Soit parce que l'on ajoute des colonnes dans la clause select. Soit parce que l'on filtre dans le programme au lieu de filtrer dans la requête (concept de 3rd stage predicate qu'il développe dans un autre article). De plus les développeurs risquent de mettent en place des feintes dans les requêtes pour qu'une même requête puisse servir plusieurs fois. (mettre un prédicat qui évite d'évaluer un pan de la requête ds certains cas). En résumé cela pousse a l'utilisation de mauvaise pratiques.
* Il y a plus de code cela demande plus de CPU et c'est plus complexe a maintenir.


J'aimerais avoir votre avis sur le sujet ? En tant que dev ? En tant que DBA ?
Est ce qu'au niveau perf il y a un impact perceptible ?

Merci d'avance.

[Julien Del]

Je travaille dans une banque et les accesseurs (VSAM, DB2, IDMS, SPITAB,...)sont créés par une application (maison), ce qui permet que les accesseurs soient bien fiables et qu'on puisse aussi les créer facilement, en grand nombre et pour une utilisation simple (1 READ, 1 READ-NEXT, 1 MODIFY,...).

Les accesseurs ne sont pas appelés directement par les programme, les programmes utilisent un programme "lanceur" qui lui est connecté aux accesseurs.

Au niveau compilation, c'est plus simple aussi: seuls les accesseurs sont compilé avec DB2 et sont donc à "binder".
Une fois tes accesseurs créés et bindés, tu peux faire autant de programmes que tu veux sans avoir besoin d'un DBA sous la main.


Au niveau développement, ça parait lourd au début, mais par exemple je viens de passer une appli d'IDMS en DB2, ça s'est fait presque (facilement) en changeant grosso-modo 1 accesseur IDMS par 1 accesseur DB2, ce qui n'aurait pas été possible sans accesseur.

[maelleam]

Merci pour ta réponse

C'est vrai que je n'avais pas trop pensé au facteur changement de source de données.

Pourquoi utiliser un lanceur ?

Je me demande si le fait de fetcher (probablement) plus de données depuis DB2 est sensible a grande échelle.

[Julien Del]

Le lanceur te permet de centraliser/référencer tous tes accesseurs existants.
A partir du moment où tu as plus de 3 vues/tables, je te conseille le lanceur, cela permet que cela ne devienne pas (en tout cas moins facilement) une usine à gaz sur le long terme.

Ci dessous, un extrait(10%) du code du dernier lanceur que j'ai créer, il y avait une 15aine de tables et certaines sont juste en READ, d'autres en MODIFY

Code :

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

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
 
      EVALUATE TRUE           ALSO TRUE                        
*                                                           
*            LES VUES CONCERNANT LES REMISES                  
*            -----------------------------                  
 
        WHEN AL-VUE-REME     ALSO AL-ORDACC-READ              
             MOVE 'DHDA42B0' TO WK-NMACC000                   
        WHEN AL-VUE-REME     ALSO AL-ORDACC-READN             
             MOVE 'DHDA23B0' TO WK-NMACC000                   
        WHEN AL-VUE-REMS     ALSO AL-ORDACC-READ            
             MOVE 'DHDA43B0' TO WK-NMACC000                 
        WHEN AL-VUE-REMS     ALSO AL-ORDACC-READN           
             MOVE 'DHDA33B0' TO WK-NMACC000                 
*                                                           
*            LES VUES CONCERNANT LES PARAMETRES          
*            ----------------------------------          
        WHEN AL-VUE-PARAM    ALSO AL-ORDACC-READ         
             MOVE 'DHDA20B0' TO WK-NMACC000              
        WHEN AL-VUE-PARAM    ALSO AL-ORDACC-MODIFY       
        WHEN AL-VUE-PARAM    ALSO AL-ORDACC-DELETE       
        WHEN AL-VUE-PARAM    ALSO AL-ORDACC-INSERT       
             MOVE 'DHDA21B0' TO WK-NMACC000              
        WHEN AL-VUE-PARAM    ALSO AL-ORDACC-READN        
             MOVE 'DHDA22B0' TO WK-NMACC000              *                                                           
*       WHEN AL-VUE-EVTJ                       
*            MOVE 'DHDA46B0' TO WK-NMACC000    
*       WHEN AL-VUE-GESP                       
*            MOVE 'DHDA47B0' TO WK-NMACC000    
*                                              
*-->    ERREUR LOGIQUE, CODE ACCESSEUR INCONNU 
        WHEN OTHER                             
             SET AL-CR1-ERLOGI        TO TRUE  
             SET AL-CR2-NOM-VUE-INCON TO TRUE  
             GO TO B20-FIN-EVALUATE-CATA       
 
     END-EVALUATE.

[Peut-êtreUneRéponse]

J'aimerais avoir votre avis sur le sujet ? En tant que dev ? En tant que DBA ?
Est ce qu'au niveau perf il y a un impact perceptible ?

Avec des accesseurs il est fort à parier que tu passeras par des jointures applicatives plutôt que des jointures SQL. C'est plus coûteux.

Il y a aura aussi le cas où c'est le programme appelant l'accesseur qui filtrera le résultat au lieu du prédicat SQL. Même combat que précédemment.

Enfin, mais c'est un avis personnel, mâcher le travail au développeur avec une couche d'abstraction c'est l'empêcher de se poser les bonnes questions, réfléchir et progresser, bref l'infantiliser.

[maelleam]

Merci pour la précision sur le programme.

"Peut-êtreUneRéponse": Merci pour ta contribution. Oui ça a été ma première réaction quand j'ai vu la proposition d'utiliser des accesseurs.

Le problème c'est que les tests vont être fait à tellement petite échelle et avec des accesseurs tout neuf (et donc adapté aux demandes fonctionnelles) que l'impact au niveau perf ne sera pas perceptible.

Il me viens une autre question : Les Binds packages.

Nos programmes sont bindés an reopt none (les access path sont calculé au moment du bind). Si tous les programmes accèdent aux mêmes accesseurs, les binds seront renouvelés régulièrement, ce qui est loin d'être le cas actuellement. Je ne sais pas trop si c'est une bonne chose. En théorie, je suppose que oui. Si tout es fait a l'arrache je suppose que c'est a double tranchant.

Nous avons eu un problème récemment. Un programme qui utilisait des requêtes avec beaucoup de host (même pour des constantes) a été mis en prod et a vu ses performances chuter grandement. La seule solution a été de rebinder en reopt always (ou once plus trop sur) pour que le recalcul des access path se fasse a l'exécution du statement (ou du programme pr once) ce qui permettait de ne pas utiliser les "defaut filter factors". Et je me dis que vu que les accesseurs serviront en batch et tp on perd cette flexibilité car je ne pense pas que l'on fera un reopt always/once pour du transactionnel.

Dans votre expérience ce genre de problème est il fréquent ?
Est ce que les paramètres du bind plan permettent de contourner le problème ?

[Julien Del]

Peut-êtreUneRéponse> Ta réflexion est tout à fait juste, il manque juste le composant principal: des développeurs instruits.

Perso j'ai été jeté dans le grand bain du MVS (en 1998 à 25 ans) après 3 semaines de cours COBOL, avec aucune notion de SQL, de DB2 ou autre.

Aucune formation technique donnée dans mes différents boites, j'ai tout appris (le peu que je sais) sur le tas et je suis tout à fait heureux que les accesseurs existent: j'aurais bien été en peine d'en créer.
(Par exemple je n'ai pratiquement rien compris au dernier message de maellam)

[maelleam]

Julien Del: même parcours

[Pico-----]

Il est difficile de dire que les accesseurs sont bien ou pas : tout dépend de l'architecture avant même les compétences des développeurs...
Donc là, sans connaissance du site, je n’émettrai aucun avis sur la pertinence des accesseurs.

Ensuite concernant les binds, se basant sur les statistiques, la pertinence du recalcul des access path dépend du contenu de la base de données.
Pour des traitements accédant à des tables dont le contenu ne change que très peu au fil de l'eau, pas besoin de le faire souvent, alors que si le contenu est très mouvant : il faut le faire régulièrement.

La plupart des sites où je suis passé avaient tous une politique assez proche concernant les 3R (Reorg, Runstats, Rebind) : un passage complet en hebdo, un passage en quotidien pour les chaines de mouvements quotidiens, et un passage en début des jobs pour lesquels le gain étaient pertinent (ce qui est très subjectif car déjà les 3R sont couteux).

[maelleam]

On est loins des 3R sur notre projet.
Je vais demander à l'infogérant comment c'est organisé.

Merci pour ton aide

[Luc Orient]

...
Je bosse sur un projet COBOL/CICS/DB2V9 (V10 bientôt) sur ZOS. Ma boite (SSII) a décidé de mettre en place des accesseurs DB2. Le projet compte environ 3000 pgms et 1400 tables. La mise en place sera progressive.

Mais il y aura un accesseur par table ?

[maelleam]

Luc Orient: Non probablement pas. Ils prévoient d'utiliser un accesseur par fonction. Je donnais des chiffres histoire de dimensionner un peu le projet.

[bernard59139]

Nous avons eu un problème récemment. Un programme qui utilisait des requêtes avec beaucoup de host (même pour des constantes) a été mis en prod et a vu ses performances chuter grandement. La seule solution a été de rebinder en reopt always (ou once plus trop sur) ?

je vois 2 pistes
Soit un problème de stats.
soit un problème de requête SQL (la présence de OR mal maitrisé provoque des dégats sur les perf).

Chez mon client actuel, les accesseurs sont utilisés, surtout en inter-application (par ex: entre les commandes et la facturation) et sont développés par les propriétaires de l'application.
Il n'y a pas de problème de perf.

[fsmrel]

Bonsoir,

Avec des accesseurs il est fort à parier que tu passeras par des jointures applicatives plutôt que des jointures SQL. C'est plus coûteux.
Il y a aura aussi le cas où c'est le programme appelant l'accesseur qui filtrera le résultat au lieu du prédicat SQL. Même combat que précédemment.

Bien parlé.

Il est difficile de dire que les accesseurs sont bien ou pas : tout dépend de l'architecture avant même les compétences des développeurs...

Bien parlé aussi. La performance de la base de données doit être connue avant même que ne commencent les développements : une fois définie l'architecture de la base de données, prototyper les perfs, et encore les prototyper...

On est loins des 3R sur notre projet.
Je vais demander à l'infogérant comment c'est organisé.

J'ai lâché DB2 il y a 10 ans. A l'époque le coup des 3R (REORG, RUNSTATS, REBIND) était évidemment de mise (sinon c’était direction la sortie !) sans oublier les EXPLAIN. Mais surtout, on ne pouvait se dispenser d'un outil de surveillance et de réglage du genre Platinum Detector (ou équivalent) permettant d'y voir clair et de prendre les mesures qui s'imposent en termes d'index et tout ça. Qu'en est-il chez vous ?

[Luc Orient]

Concernant les fameux 3R (REORG, RUNSTATS, REBIND) ces derniers se résument souvent à deux maintenant car les versions modernes des utilitaires DB2 for z/OS incluent souvent la prise de statistiques lors de la phase de réorganisation ... c'est toujours ça de gagné ... mais bon le principe demeure ...

[maelleam]

@fsmrel et @Peut-êtreUneRéponse: ça a été ma première pensée (fetch excessifs et jointures logicielle). On m'a répondu: "On ne fera jamais ça. Bien entendu, nous allons mettre en place des normes". Je ne me fais pas trop d'illusions.

@fsmrel: Je ne sais pas trop ce que l'infogéreur de notre client utilise.

De notre coté, nous avons accès a Platinium et Mainview.
Nous faisons des explains pour toutes les requêtes.

L'exploit exploite mais je ne pense pas qu'il fasse d'optimisation.

J'ai regardé :
* dans sysibm.systables, systablespace, sysindexes 1/10 des objets ont un statstime datant de cette année.
* dans sysibm.systablespace aucun ts n'a un alteredts datant de cet année (en dehors des tables montées en prod ou modifiées).
* pour les binds c'est pareil dans syspackage.

Nos environnements de dev on de meilleures stats. lol

[maelleam]

Je pense que nous avons grosso modo fait le tour de la question.
Merci pour vos interventions.

[fsmrel]

Bonne route maelleam,

N'hésitez pas à nous tenir au courant.