La disponibilité de la base de données a été revue en V5R30.
 
 1/ la sauvegarde de fichiers en cours d'activité (paramètre SAVACT)
      peut se faire meme en cas de transaction.
 
 2/ la réorganisaiton des fichiers :
 
      a/ peut etre interrompue
 
      b/ peut éventuellement se faire sans verrouillage fort
 
 Rappel sur le paramètre SAVACT.
 
   cela permet de faire une sauvegarde d'une base en activité.
 
     il reste cependant le problème des objets base de données en cours
      de transaction (sous commitment control)
 
     on peut sauvegarder des fichiers en cours de mise à jour simple, mais
      pas sous COMMIT/ROLLBACK
 

  Exemple :
 
  Soit un fichier avec un enregistrement verrouillé par un pgm sans COMMIT.
   DB2 va poser un verrouillage *SHRUPD sur le membre (les données)
 
   SAVLIB ==> la sauvegarde prévient d'un objet NON sauvegardé
 
   SAVLIB SAVACT(*LIB) ==> la sauvegarde est effectué normalement (complète)
   [ SAVLIB SAVACT(*SYNCLIB) si vous avez plusieurs bibliothèques ]
 
   ......................................................................
   : L'intégrité de la base en cas de restauration est à votre charge,  :
   :   vous venez peut-etre de sauvegarder une piece comptable          :
   :   incomplète (non équilibrée), par exemple.                        :
   :                                                                    :
   : La fonction journal peut vous y aider (APYJRNCHG / RMVJRNCHG).     :
   :....................................................................:
 
   le paramètre SAVACTWAIT(120) permet d'indiquer le temps d'attente pour
    la disponibilité des objets et la fin d'une transaction.
 
 

 
  Mais, imaginons un fichier en cours d'utilisation sous commitment control
   (DB2 pose alors un verrou *SHRRD sur l'objet)
 
   SAVLIB ==> la sauvegarde prévient d'un objet NON sauvegardé
 
   SAVLIB SAVACT(*LIB) ==> Erreur CPF377F, la sauvegarde n'a pas lieu
 
   ....................................................................
   :   La disponibilité des objets est testée AVANT la sauvegarde !   :
   :..................................................................:
 
   SAVLIB SAVACT(*LIB) SAVACTWAIT(120 *NOCMTBDY ) nouveau paramètre en 5.30
   ........................................................................
   : le paramètre SAVACTWAIT accèpte trois valeurs :                      :
   :  1/ attente pour la disponibilité des objets                         :
   :  2/ attente pour la disponibilité des enregistrements en transaction :
   :  3/ attente pour les autres transactions (création de table, ...)    :
   :......................................................................:
 
    la sauvegarde a lieu, complète, avec un message d'information CPI3731
      par fichier en transaction, dans la JOBLOG du travail.

 
Détail du message CPI3731
 
                     Complément d'informations sur message 
 
 ID message . . . . . . :   CPI3731
 Date d'envoi . . . . . :   29/11/04      Heure d'envoi  . . . . :   17:34:2
 
 Message . . . . :   Objet FICH1P1 (type *FILE) enregistré avec une transaction
   partielle.
 
 Cause . . . . . : L'objet FICH1P1 de type *FILE de la bibliothèque AF4SRCT
   été sauvegardé avec une ou plusieurs transactions partielles. Si cet objet
   est un fichier base de données, le nom du membre est FICH1P1.
 Que faire . . . :
     -- S'il s'agit d'une opération de restauration, vous ne pouvez utiliser
   cet objet avant d'appliquer ou de supprimer les modifications journalisées
   (commande APYJRNCHG ou RMVJRNCHG) pour atteindre les limites de validation
   Pour appliquer ou supprimer les modifications, vous aurez besoin du journal
   QSQJRN de la bibliothèque AF4SRCT et de la chaîne des destinataires du
   journal commençant par JRNRCV0001 dans la bibliothèque AF4SRCT de l'unité
   ASP *SYSBAS.

 
 ATTENTION, le message indique bien que le fichier a été sauvegardé
  lors d'une transaction incomplète , il n'est donc pas intègre.
 
 SI VOUS LE RESTAUREZ :
 
  vous aurez un message CPI3731 (toujours de type *INFO) dans la JOBLOG.
 
 et le fichier sera considéré comme inutilisable. 
 
  DSPFD montre cela, un OPEN sur le fichier engendre CPF428D
 
  et vous devez :
 
   i/   avoir ou restaurer le récepteur avec la transaction terminée, puis
         passer l'une des commandes suivantes : APYJRNCHG ou RMVJRNCHG
 
   ii/  restaurer une version avec transaction complète du fichier
 
   iii/ passer la commande CHGJRNOBJA ATR(*PTLTNS) PTLTNS(*ALLUSE)
         pour autoriser l'utilisation de cette version non intègre.
         (reprise "à la main" de l'intégrité du fichier)

 
 A noter qu'un ROLLBACK peut maintenant être annulé.
 
     1/ passez la commande WRKCMTDFN JOB(*ALL)
     2/ faites F11 pour regarder l'état de la transaction
 
 
Si vous avez les droits *ALLOBJ, vous pouvez passer l'option 20 qui annule
 le ROLLBACK, le fichier devient alors dans le même état qu'un fichier
 restauré suite à une sauvegarde pendant transaction.
 
Il est donc, lui aussi inutilisable, sauf à
 
     a/ terminer la transaction
 
     b/ passer la commande CHGJRNOBJA
 
 
Il est enfin possible d'empécher cette fonction, même à un utilisateur
 ayant des droits en créant une DATA AREA QGPL/QTNNOENDRB.
 
 

 
 Autre nouveauté concernant la disponibilté de la base de données, la
  réorganisation de fichier, plus souple qu'avant.
 
 Elle peut maintenant etre interrompue (Appel/sys 2 ou ENDJOB)
  (Iseries navigator vous propose un dialogue spécifique et très pratique)
 
  RGZPFM ... ALWCANCEL(*YES)
 
  Avant, (ou sans ce paramètre)  quand vous lancez RGZPFM, le système :
 
   1/ invalide tous les index.
 
   2/ fabrique une copie du fichier qui deviendra l'original à la fin.
 
   3/ reconstruit ensuite les index (sauf celui utilisé en référence)
 
 Si on interrompt la réorganisation, on retouve le fichier physique dans
  son état d'origine, et le système se met à reconstruire tous les index !
 
 Ce qui rend l'interruption très délicate, les applications étant en
   attente de la disponibilité des index associés.

 si vous précisez ALWCANCEL(*YES)
 
   - le système ne travaille pas sur une copie du fichier
       ==> le fichier doit etre journalisé !
 
   - la réorganisation est un peu plus longue.
 
   - vous pouvez indiquer KEYFILE(*RPLDLTRCD) qui place les enregistrements
      de fin du fichier, à la place des enregistrements supprimés.
 
   - vous pouvez demander une maintenance des index en temps réel, afin
      d'assurer une disponibilité immédiate de la base, en cas d'arret.
 
        RBDACCPTH(*YES) les chemins d'accès sont maintenu de manière
                         asynchrone, en fin d'opération (comme avant)
 
        RBDACCPTH(*OPTIMIZE) le système choisi, soit une maintenance pendant
                             la réoganisaiton, soit une maintenance
                              asynchrone, en fin de traitement.
 
        RBDACCPTH(*NO)  les chemins d'accès sont maintenus PENDANT la
                         réoganisation [ALWCANCEL(*YES) obligatoire]

 
   Dans ce dernier cas, RBDACCPTH(*NO), vous pouvez autoriser l'accès
    au fichier pendant la réogranisation, avec le paramètre LOCK.
 
 
     LOCK(*EXCL)     le système pose un verrou exclusif rendant l'accès
                      au fichier impossible.
 
     LOCK(*EXCLRD)   le système pose un verrou exclusif avec lecture,
                      rendant la consultation possible, mais la mise à jour
                      impossible.
 
     LOCK(*SHRUPD)   le système pose un verrou en mode partagé, la mise à
                      jour du fichier par d'autres traitements est permise.
 
                     ATTENTION, la réorganisaiton du fichier suivant un
                      critère de clef précis [paramètre KEYFILE], n'est
                      plus garantie, des enregistrements pouvant etre
                      insérés (par exemple) pendant le traitement.
 
    Ce dernier paramètre, rend, lui aussi la réorganisaiton plus longue.
 

 Détails :
 
  Le système créé un fichier de travail dans QRECOVERY portant le nom SQL
    QDBRGZ_BIBLIOTHEQUE_FICHIER, et le détruit en fin de traitement.
 
  L'annulation d'une demande s'affiche comme cela dans l'historique
 
  .......................................................................
  : Dernière demande au niveau 2 interrompue.                           :
  : Traitement de l'instruction SQL arrêté. Code raison : 3. (SQL0952)  :
  :.....................................................................:
 
  Si le fichier de QRECOVERY existe déja, le système tente une reprise,
   si les paamètres de la commande sont les meme.
 
  Voici ce que peut afficher la LOG
 
   QDBRGZ_AF4W_HTTPLOG_HTTPLOG de type *FILE existe déjà dans QRECOVERY.
   Non continuation de l'opération de réorganisation annulée sur le fichier
     HTTPLOG_I2 de la bibliothèque HTTPLOG_I2, membre AF4W.
 
 

 
 Si vous demandez de l'Aide, il ya trois codes possibles :
 
  1 -- Les paramètres indiqués lors de la réorganisation en cours (RGZPFM
 FILE(AF4W/HTTPLOG) MBR(HTTPLOG) KEYFILE(AF4W/HTTPLOG_I2 HTTPLOG_I2)
 RCDFMT(*ONLY) RBDACCPTH(*YES) ALWCANCEL(*YES) LOCK(*EXCL)) ne correspondent
 pas exactement aux paramètres de la réorganisation annulée (RGZPFM
 FILE(AF4W/HTTPLOG) MBR(HTTPLOG) KEYFILE(AF4W/HTTPLOG_I2 HTTPLOG_I2)
 RCDFMT(*ONLY) RBDACCPTH(*YES) ALWCANCEL(*YES) LOCK(*SHRUPD)).
 
 le code raison 2 indique que le fichier contient trop de différences
 
         - restauration du fichier, depuis.
         - changement de nom (fichier ou membre)
         - déplacement (bibliothèque)
         - effacement du membre (CLRPFM)
         - ALTER TABLE
 
 le code 3 que le fichier dans QRECOVERY n'existe pas ou est endommagé.
 
 
 Voyez aussi les nouveautés Iseries Navigator sur ce sujet.