Publicité
+ Répondre à la discussion
Affichage des résultats 1 à 18 sur 18
  1. #1
    Invité de passage
    Homme Profil pro
    Inscrit en
    juin 2012
    Messages
    8
    Détails du profil
    Informations personnelles :
    Sexe : Homme

    Informations forums :
    Inscription : juin 2012
    Messages : 8
    Points : 1
    Points
    1

    Par défaut Accesseur DB2 en COBOL

    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.

  2. #2
    Nouveau Membre du Club
    Profil pro
    Développeur COBOL
    Inscrit en
    mai 2009
    Messages
    30
    Détails du profil
    Informations personnelles :
    Âge : 40
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur COBOL
    Secteur : Finance

    Informations forums :
    Inscription : mai 2009
    Messages : 30
    Points : 29
    Points
    29

    Par défaut Complètement pour les accesseurs

    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.

  3. #3
    Invité de passage
    Homme Profil pro
    Inscrit en
    juin 2012
    Messages
    8
    Détails du profil
    Informations personnelles :
    Sexe : Homme

    Informations forums :
    Inscription : juin 2012
    Messages : 8
    Points : 1
    Points
    1

    Par défaut

    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.

  4. #4
    Nouveau Membre du Club
    Profil pro
    Développeur COBOL
    Inscrit en
    mai 2009
    Messages
    30
    Détails du profil
    Informations personnelles :
    Âge : 40
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur COBOL
    Secteur : Finance

    Informations forums :
    Inscription : mai 2009
    Messages : 30
    Points : 29
    Points
    29

    Par défaut

    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 :
    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.

  5. #5
    Membre chevronné Avatar de Peut-êtreUneRéponse
    Homme Profil pro Guillaume VENTRE
    z/OS Senior Technical Leader
    Inscrit en
    décembre 2006
    Messages
    538
    Détails du profil
    Informations personnelles :
    Nom : Homme Guillaume VENTRE
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : z/OS Senior Technical Leader
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : décembre 2006
    Messages : 538
    Points : 712
    Points
    712

    Par défaut

    Citation Envoyé par maelleam Voir le message
    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.

  6. #6
    Invité de passage
    Homme Profil pro
    Inscrit en
    juin 2012
    Messages
    8
    Détails du profil
    Informations personnelles :
    Sexe : Homme

    Informations forums :
    Inscription : juin 2012
    Messages : 8
    Points : 1
    Points
    1

    Par défaut

    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 ?

  7. #7
    Nouveau Membre du Club
    Profil pro
    Développeur COBOL
    Inscrit en
    mai 2009
    Messages
    30
    Détails du profil
    Informations personnelles :
    Âge : 40
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur COBOL
    Secteur : Finance

    Informations forums :
    Inscription : mai 2009
    Messages : 30
    Points : 29
    Points
    29

    Par défaut

    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)

  8. #8
    Invité de passage
    Homme Profil pro
    Inscrit en
    juin 2012
    Messages
    8
    Détails du profil
    Informations personnelles :
    Sexe : Homme

    Informations forums :
    Inscription : juin 2012
    Messages : 8
    Points : 1
    Points
    1

    Par défaut

    Julien Del: même parcours

  9. #9
    Membre actif
    Inscrit en
    juin 2008
    Messages
    125
    Détails du profil
    Informations forums :
    Inscription : juin 2008
    Messages : 125
    Points : 195
    Points
    195

    Par défaut

    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).

  10. #10
    Invité de passage
    Homme Profil pro
    Inscrit en
    juin 2012
    Messages
    8
    Détails du profil
    Informations personnelles :
    Sexe : Homme

    Informations forums :
    Inscription : juin 2012
    Messages : 8
    Points : 1
    Points
    1

    Par défaut

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

    Merci pour ton aide

  11. #11
    Membre Expert

    Homme Profil pro François Durand
    Spécialiste Delivery Mainframe IBM
    Inscrit en
    octobre 2005
    Messages
    1 198
    Détails du profil
    Informations personnelles :
    Nom : Homme François Durand
    Âge : 55
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Spécialiste Delivery Mainframe IBM
    Secteur : Finance

    Informations forums :
    Inscription : octobre 2005
    Messages : 1 198
    Points : 2 151
    Points
    2 151

    Par défaut

    Citation Envoyé par maelleam Voir le message
    ...
    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 ?

  12. #12
    Invité de passage
    Homme Profil pro
    Inscrit en
    juin 2012
    Messages
    8
    Détails du profil
    Informations personnelles :
    Sexe : Homme

    Informations forums :
    Inscription : juin 2012
    Messages : 8
    Points : 1
    Points
    1

    Par défaut

    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.

  13. #13
    Membre Expert Avatar de bernard59139
    Profil pro
    Administrateur de base de données
    Inscrit en
    octobre 2006
    Messages
    697
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : octobre 2006
    Messages : 697
    Points : 1 230
    Points
    1 230

    Par défaut

    Citation Envoyé par maelleam Voir le message
    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.

  14. #14
    Expert Confirmé Sénior
    Avatar de fsmrel
    Homme Profil pro François de Sainte Marie
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    4 398
    Détails du profil
    Informations personnelles :
    Nom : Homme François de Sainte Marie
    Localisation : Autre

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 4 398
    Points : 11 850
    Points
    11 850

    Par défaut

    Bonsoir,


    Citation Envoyé par Peut-êtreUneRéponse Voir le message
    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é.


    Citation Envoyé par Pico----- Voir le message
    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...


    Citation Envoyé par maelleam Voir le message
    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 ?
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)


    De grâce, pas de questions techniques par MP, ma boîte de réception explose !
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale (Bonne lecture !)

  15. #15
    Membre Expert

    Homme Profil pro François Durand
    Spécialiste Delivery Mainframe IBM
    Inscrit en
    octobre 2005
    Messages
    1 198
    Détails du profil
    Informations personnelles :
    Nom : Homme François Durand
    Âge : 55
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Spécialiste Delivery Mainframe IBM
    Secteur : Finance

    Informations forums :
    Inscription : octobre 2005
    Messages : 1 198
    Points : 2 151
    Points
    2 151

    Par défaut

    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 ...

  16. #16
    Invité de passage
    Homme Profil pro
    Inscrit en
    juin 2012
    Messages
    8
    Détails du profil
    Informations personnelles :
    Sexe : Homme

    Informations forums :
    Inscription : juin 2012
    Messages : 8
    Points : 1
    Points
    1

    Par défaut

    @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

  17. #17
    Invité de passage
    Homme Profil pro
    Inscrit en
    juin 2012
    Messages
    8
    Détails du profil
    Informations personnelles :
    Sexe : Homme

    Informations forums :
    Inscription : juin 2012
    Messages : 8
    Points : 1
    Points
    1

    Par défaut

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

  18. #18
    Expert Confirmé Sénior
    Avatar de fsmrel
    Homme Profil pro François de Sainte Marie
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    4 398
    Détails du profil
    Informations personnelles :
    Nom : Homme François de Sainte Marie
    Localisation : Autre

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 4 398
    Points : 11 850
    Points
    11 850

    Par défaut

    Bonne route maelleam,

    N'hésitez pas à nous tenir au courant.
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)


    De grâce, pas de questions techniques par MP, ma boîte de réception explose !
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale (Bonne lecture !)

+ Répondre à la discussion
Cette discussion est résolue.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •