Discussion :

[offrerem]

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

[alex.]

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.

[offrerem]

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

[alex.]

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.

[offrerem]

Je vous remericie pour toutes ces precisions .