IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

z/OS Discussion :

question sur db2 batch


Sujet :

z/OS

  1. #1
    Membre du Club
    Inscrit en
    Mai 2008
    Messages
    58
    Détails du profil
    Informations forums :
    Inscription : Mai 2008
    Messages : 58
    Points : 45
    Points
    45
    Par défaut question sur db2 batch
    bonjour

    quelle est la difference entre un quiesce et un commit ?

    de plus lors d'un load d'une table quelle difference entre log yes et log no ?

    merci

  2. #2
    Membre habitué
    Profil pro
    Inscrit en
    Septembre 2004
    Messages
    123
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2004
    Messages : 123
    Points : 146
    Points
    146
    Par défaut
    L'utilitaire quiesce établit un point de cohérence qui est enregistré dans la SYSCOPY de DB2. Un point de cohérence est un RBA/LRSN qui assure que si restauration, les données restaurées seront commitées. Typiquement, on utilise des quiesces avant un batch en mise à jour pour revenir à ce point si problème.

    L'ordre SQL commit termine une unité logique de recovery d'un programme en flushant les buffers de log dans les logs sur disque (write ahead). Les logs contiennent alors les mises à jour effectuées dans le programme. A noter qu'un quiesce ne peut passer sur un tablespace que si toutes les URs en cours sur ce tablespace ont commitées.

    Un load log yes loggue les données insérées dans la table dans les logs. A l'issue du load log yes, le tablespace contenant la table est disponible. Le load log no ne loggue pas les données insérées dans les logs ce qui est plus rapide mais nécessite une image copy (ou un repair nocopypend) à la suite ou en même temps pour que le tablespace soit disponible en maj. On utilise le load log no pour les grosses volumétries.

  3. #3
    Membre du Club
    Inscrit en
    Mai 2008
    Messages
    58
    Détails du profil
    Informations forums :
    Inscription : Mai 2008
    Messages : 58
    Points : 45
    Points
    45
    Par défaut
    l'utilitaire quiesce fonctionne par rapport à une logue ?

    mais je n'ai pas tres bien compris la difference en quiese et commit, ce sont tous les 2 des points de sauvegardes non ?

    Merci

  4. #4
    Membre habitué
    Profil pro
    Inscrit en
    Septembre 2004
    Messages
    123
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2004
    Messages : 123
    Points : 146
    Points
    146
    Par défaut
    Le commit peut être vu (mais pas seulement) comme un "point de sauvegarde applicatif " pour une application donnée. Par exemple, si un application débite un compte et crédite un autre avec l'argent du premier, on pourrait mettre un commit à la suite de ces 2 mouvements logiquement liées dans la même opération. Ce commit force l'écriture des données maj par cette application sur les logs et rajoute dans les logs un indicateur pour dire que cette unité de travail (ou de recovery) correspondant à cette application est compléte.

    Si cette application traite 1000 débit/crédit, commite toutes les 10 opérations mais malheureusement plante, DB2 rollback les majs faites par ce batch jusqu'au dernier commit. Si le programme sait gérer le restart en sachant se repositionner par rapport aux informations enregistrées lors du dernier commit, on peut repartir à partir du dernier point de commit. Mais toute cette mécanique hormis le rollback est à la charge du développeur (sauvegarde des infos nécessaires au restart, repositionnement sur les fichiers en entrée, réouverture et repositionnement sur les curseurs DB2 etc..) même s'il existe des produits non-db2 qui peuvent faire le boulot.

    Maintenant, rien n'empêche que dans le même temps un autre batch passe et fasse des majs. Ce qui voudrait dire que si l'on restaurait les données au temps du dernier commit du premier batch, on aurait des données logiquement cohérentes issu du batch 1 et incohérentes à cause du batch 2, le temps du commit du batch 1 pouvant être différent du temps du commit du batch 2.

    Pour éviter ce cas de figure en cas de restauration, on fait un quiesce sur la table qui ne prendra un point de cohérence que si tous les batchs accédant à la table en maj ont commités. Ce qui veut dire qu'il attend la fin des unités de travail en cours et peut le cas échéant time-outer si une application ne commite pas assez vite, qu'il bloque les applis qui voudraient accèder en écriture à la table. Le quiesce enregistre ce point dans la syscopy, ce point correspondant à une adresse dans la log. Si restauration à ce point, on appliquera les données dans les logs sur la table restaurée jusqu'à ce point.

    Je ne sais pas si je suis clair donc si certains veulent préciser d'autres points qu'ils ne se privent pas.

  5. #5
    Membre du Club
    Inscrit en
    Mai 2008
    Messages
    58
    Détails du profil
    Informations forums :
    Inscription : Mai 2008
    Messages : 58
    Points : 45
    Points
    45
    Par défaut
    Je vous remericie pour toutes ces precisions .


Discussions similaires

  1. Réponses: 0
    Dernier message: 15/09/2008, 11h03
  2. Question sur index DB2 400
    Par Jibon dans le forum DB2
    Réponses: 4
    Dernier message: 19/08/2007, 17h58
  3. Question sur IBM DB2
    Par SQLpro dans le forum DB2
    Réponses: 3
    Dernier message: 12/06/2007, 15h57
  4. [DB2] Question sur les index et les vues
    Par ahoyeau dans le forum DB2
    Réponses: 1
    Dernier message: 14/03/2005, 09h30
  5. Question sur les batchs files (.bat)
    Par ptitbonum dans le forum Scripts/Batch
    Réponses: 4
    Dernier message: 09/04/2004, 00h02

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo