Retrouver les DDL de création d'une table

La chaine RBF permet de générer les DDL de création des tables HR Access en se basant sur la description des objets "Information". Le programme utilise aussi des résultats intermédiaires de génération : les "macros information" des tables GE1*. Ces macros ne sont présentes que sur les environnements de type "Développement" (générables).

Quand il n'est pas possible de créer ces DDL avec la chaîne RBF, le SGBD permet en général de retrouver l'ordre de création (exemple avec la table TP13) :

• sous Oracle, via SQLPlus :

SET LONG 2000000 PAGESIZE 0 
SELECT dbms_metadata.get_ddl('TABLE','TP13','HR') FROM DUAL;

DBMS_METADATA.GET_DDL('TABLE','TP13','HR')
--------------------------------------------------------------------------------

  CREATE TABLE "HR"."TP13"
   (    "IDPOPL" CHAR(4) NOT NULL ENABLE,
        "TEVERR" CHAR(1) NOT NULL ENABLE,
        "TIPOPL" DATE NOT NULL ENABLE,
         CONSTRAINT "IXTP13" PRIMARY KEY ("IDPOPL")
  USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255
  STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
  PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
  TABLESPACE "HRXT"  ENABLE
   ) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
  STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
  PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
  TABLESPACE "HRTT"

• sous DB2, via Unix :

db2look -d $DB2DBDFT -e -u $LOGNAME -tw "TP13"

------------------------------------------------
-- DDL Statements for table "HR      "."TP13"
------------------------------------------------

CREATE TABLE "HR      "."TP13"  (
                  "IDPOPL" CHAR(4) NOT NULL ,
                  "TEVERR" CHAR(1) NOT NULL ,
                  "TIPOPL" TIMESTAMP NOT NULL )
                 IN "USERSPACE1" ;

-- DDL Statements for primary key on Table "HR      "."TP13"

ALTER TABLE "HR      "."TP13"
        ADD PRIMARY KEY
                ("IDPOPL");

COMMIT WORK;
CONNECT RESET;
TERMINATE;

Utilitaire db2top : suivre l'activité d'une base DB2

DB2 fournit sous Unix une interface permettant de suivre l'activité de la base : db2top
Ci joint un lien vers un manuel assez pratique, avec des cas d'usage.





Pour avoir le rendu en couleurs, faire un :
export TERM=xterm

Puis appeler l'exécutable :
db2top

La vue dynamic SQL accessible par "D" permet de consulter les ordres SQL dynamiques en cours.
A noter : 

• on n'y trouve pas les requêtes statiques (sans champs variabilisés - stockées dans des bibliothèques DB2 lors du BIND),
• Pour changer le tri , faire "z" ou "Z",
• Pour voir l'ordre complet, faire "L" puis indiquer l'identifiant "HashValue" de la requête,
• L'option -V permet de spécifier le schéma par défaut - ce qui peut être utile à db2expln et db2exfmt (option "e" et "x" pour l'analyse du plan d'accès de la requête).
• Pour rafraichir les données (purger le tampon) des "dynamic sql", faire "R".

Il y a d'autres vues, comme "T" pour les tables accédées ou "U" pour les verrous actifs.

Des options par défaut peuvent être spécifiées dans $HOME/.db2toprc.

Vous pouvez collecter les données en batch - ici pendant 5 minute avec un intervalle de 30 secondes :
db2top -C -d hradev -b m -m 5 -i 30 -f $TMP/db2top.file

[14:41:32] Starting DB2 snapshot data collector, collection every 30 second(s), max duration 5 minute(s), max file growth/hour 100.0M, hit <CTRL+C> to cancel...
[14:41:32] Overridding previous occurence of '/hradev/hraccess/txt/tmp/db2top.file'
[14:42:02] 1.4M written, time 30.112, 173.8M/hour
...
[14:46:33] 8.5M written, time 300.962, 103.0M/hour
[14:47:03] Max duration reached, 8.5M bytes, time was 331.062...
[14:47:03] Snapshot data collection stored in '/hradev/txt/tmp/db2top.file'
Exiting...

Puis extraire les données du fichier :

db2top -d hradev -b l -f $TMP/db2top.file
Time;Application_Handle(Stat);Cpu%_Total;IO%_Total;Mem%_Total;Application_Status;Application_Name;Delta_RowsRead/s;Delta_RowsWritten/s;Delta_IOReads/s;Delta_IOWrites/s;Delta_TQr+w/s;Sess_Memory;Assoc._Agents;Paral._Degree;Lockwait_(sec);Locks_Held;Sorts_(sec);Log_Used;Delta_RowsSelect/s;Fetch_Count(Stmt);Dynamic_SQL;Static_SQL;#of_XQueries;Os_User;DB_User;Client_NetName;Client_Platform;Status_ChTime;Time_InStatus;IoType_(Data/Index/Temp);Sorts_Overflows;Hash_Join_Overflows;Client_Pid;Node_Number;Last_Operation;TimeTo_Connect;Session_Cpu;Statement_Cpu;Max Cost_Estimate;Wkd_Id;Recent_Cpu[1]
14:43:33;18528;0.00%;2.08%;4.76%;UOW Waiting in the application;db2jcc_applicat;43;20;713;0;0;262144;1;1;0;0;0;0;25;0;3613;354;0;DIGIX;DIGIX;digix;ABCD;14:43:04;28.081875;ddddddddddddddddddd;0;0;0;0;Static Commit;1.340;0.240599;0.000008;0;1;0.000
14:44:33;18528;0.00%;30.77%;4.40%;UOW Waiting in the application;db2jcc_applicat;0;0;16;0;0;262144;1;1;0;0;0;0;0;0;3639;362;0;DIGIX;DIGIX;digix;ABCD;14:44:04;29.102762;ddddddddddddddddddd;0;0;0;0;Static Commit;1.340;0.245410;0.000012;0;1;0.000
...
  

Avec l'option -A on a un résumé orienté performance par application.

 Rank Application_Handle(Stat)        Percentage fromTime toTime                   sum(Cpu%_Total)
----- ------------------------------ ----------- -------- --------- ------------------------------
    1 18528                             50.0000% 14:44:33 14:46:03                          100000
    2 5288                              50.0000% 14:44:33 14:46:03                          100000
    3 20799                              0.0000% 14:44:33 14:46:03                               0

Merci à Michel pour le tuyau.

Mettre a jour les séquences d'attribution du NUDOSS

Depuis HRv7 les NUDOSS sont ne sont plus calculés sur la base de l'horodatage système, mais attribués par une séquence Oracle ou DB2 nommée SEQU{SD}.

Si vous devez purger ou livrer des dossiers par un outil du SGBD (imp, load), ces séquences ne seront pas mises à jour, ce qui peut être source d'erreurs de type "clef en double" lors des futures créations de dossiers :

• sous Oracle : code erreur SQL 1
• sous DB2 : code erreur SQL 803

Exemple d'erreur induite :

• Avec NOZ : 

BQL-BBAD0015-ERREUR D'ACCES (TABLE RELATIONNELLE) : S1/EXECUTE/10/PK/000000000000001
BQL-BBAD0015-ERREUR D'ACCES (TABLE RELATIONNELLE) : S1/EXECUTE/10/PK/000000000000803

• Avec NRB :  

Zone libre : BML40DD-000000001 / BML40DD-000000803
et message BME-BBAM0016-ERREUR GRAVE DURANT LA MISE A JOUR 

Pour mettre à niveau une séquence, dans un premier temps sélectionnez le plus grand NUDOSS (exemple pour ZY) :
SQL> select max(NUDOSS) from ZY00;
126

Sous DB2 mettez a jour la séquence par un ALTER :
DB2> alter sequence SEQUZY restart with 127

Sous Oracle vous devrez détruire et recréer la séquence :
SQL> drop sequence SEQUZY;
SQL> create sequence SEQUZY start with 127;

Calculer le nombre de jours (hors WE) dans l'année

Ci joint une fonction DB2 trouvée sur le forum de http://www.tek-tips.com. Elle vous permet de calculer le nombre de jours ouvrables (lundi, mardi ... vendredi - sans considération de jours fériés) entre deux dates.

exemple : script DDL PSBBGJ_BUSINESSDAYS.sql

CREATE FUNCTION business_days (low_date DATE, high_date DATE)
RETURNS INTEGER
BEGIN ATOMIC
   DECLARE bus_days INTEGER DEFAULT 0;
   DECLARE cur_date DATE;
   SET cur_date = low_date;
   WHILE cur_date < high_date DO
      IF DAYOFWEEK(cur_date) IN (2,3,4,5,6) THEN
         SET bus_days = bus_days + 1;
      END IF;
      SET cur_date = cur_date + 1 DAY;
   END WHILE;
   RETURN bus_days;
END!
COMMIT!

création de la fonction :
cat PSBBGJ_BUSINESSDAYS.sql | db2 -vtd\!

utilisation de la fonction :
select HR.business_days(DATE ('2012-01-01'),DATE ('2013-01-01')) from sysibm.sysdummy1
-----------
        261

Formater sous DB2 un nombre avec signe et zero non significatifs

Ci joint un exemple d'ordre SQL pour formater sous DB2 un nombre avec signe et zéros non significatifs (par exemple pour les bordereaux NRB)

•  "CASE" pour l'affichage systématique du signe
•  "CHAR" pour les zeros non significatifs et le séparateur des décimales
•  "DECIMAL" pour spécifier le nombre de chiffres dont le nombre de décimales

select CASE WHEN a.BASCT > 0 THEN '+' ELSE '-' END|| CHAR(DECIMAL(a.BASCT,15,2),',') from  HR.ZYVL a, HR.ZY00 b, HR.ZYES c
where a.nudoss=b.nudoss and a.nudoss=c.nudoss
and a.dteffe between c.datent and c.datsor and a.datfin not between c.datent and c.datsor
and b.matcle='A123456'
------------------
+0000000123400,00

ERREUR D'ACCES (TABLE RELATIONNELLE) : PP10/SELECT/9X/DF/000000000000805

Ce genre de message (erreur SQL 805) se produit sous DB2 quand le "Bind" de certains Cobols n'a pas été joué.

SQL0805N Package "<package-name>" was not found

• Si l'environnement était propre jusqu'alors, on pourra se contenter de refaire le bind du programme concerné.
• Si le contexte est défavorable (environnement instable), il vaut mieux rejouer la totalité des binds de la totalité des programmes. Cela rendra la situation plus claire.

Re-Exécution des Bind pour les programmes référencés en table PG15

db2 -x "select pkgname from syscat.packages, ${HRSCHEMA}.pg15 where pkgschema='${HRSCHEMA}' and pkgname=rtrim(rdprog)||cdprog" | while read BND
do
   [ ! -f $SIGACS/prod/bnd/${BND}.bnd ] && echo "<W> Fichier ${BND}.bnd inexistant" && continue
   if ! db2 "bind $SIGACS/prod/bnd/${BND}.bnd collection ${HRSCHEMA} datetime iso isolation UR qualifier ${HRSCHEMA}" ; then
      echo "<W> Bind Ko pour ${BND}.bnd"
   else
      echo "<I> Bind Ok pour ${BND}.bnd"
   fi
done > ${LOG}/ReBind.log 2>&1

Exécution du Bind pour les programmes présents dans $SIGACS/prod/bnd mais absents en base de données

ls $SIGACS/prod/bnd | grep '\.bnd$' | while read F
do
   BND=$(basename $F .bnd)
   EXIST=$(db2 -x "select count(*) from syscat.packages where pkgschema='${HRSCHEMA}' and pkgname='${BND}'")
   if [ ${EXIST} -eq 0 ]; then
     if ! db2 "bind $SIGACS/prod/bnd/${BND}.bnd collection ${HRSCHEMA} datetime iso isolation UR qualifier ${HRSCHEMA}" ; then
      echo "<W> Bind Ko pour ${BND}.bnd"
     else
      echo "<I> Bind Ok pour ${BND}.bnd"
     fi
   fi
done > ${LOG}/NewBind.log 2>&1

FYI : la liste des packages générés par DB2 lors d'un bind est accessible à travers la vue "syscat.packages".

Résoudre un verrouillage sur DB2

1 - Bilan

  db2pd -wlocks -db $DB2DBDFT

Cette commande liste les "applications DB2" (champ AppHandl) à la source d'un verrouillage et celles en attente de la levée du verrou. Si la commande n'affiche qu'une ligne avec l'heure - il n'y a pas de verrou - l'éventuel blocage n'est pas dû à DB2.

Message d'erreur "98 RS BNA 9N CG TD11 00000000000818"

Sous DB2 l'erreur SQL 818 signifie qu'il existe un déphasage entre l'exécutable et sa bibliothèque de définition des accès SQL stockée en base. Ce déphasage a plusieurs causes possibles :

Des exécutables ont été copiés à partir d'un autre environnement, mais le bind n'a pas été fait (ou inversement) :

Suite à une livraison imparfaite, exécutable et bind sont déphasés.
Vérifiez que l'horodatage des fichiers ".so" et ".bnd" sont en phase, et cohérents avec ceux de l'environnement source.
Il suffit alors de faire la mise à jour de la bibliothèque de définition des accès SQL ("bind") par prise en compte du fichier *.bnd :

bind RRRRRPPP.bnd collection $HRSCHEMA  datetime iso qualifier $HRSCHEMA

Avec RRRRRPPP radical et code du programme.

La dernière génération s'est terminée en fin anormale :

Il est possible de se trouver dans le cas de figure ou le "bind" a été fait mais la compilation est sortie en erreur. Ce déphasage se résout en corrigeant la source du problème de compilation et en relançant la génération de l'exécutable.

Les chaines de génération physique réalisent dans l'ordre :

• L'écriture du source Cobol
• La pré-compilation DB2 du source contenant du SQL (création du *.bnd)
• Mise à jour de la bibliothèque de définition des accès SQL ("bind" par prise en compte du fichier *.bnd)
• La compilation du Cobol (fichiers *.so)
• Le stockage des générés dans $SIGACS/prod (gnt et bnd)

Lorsqu'une étape sort en erreur, le stockage des *.so et *.bnd correspondants n'est pas réalisé.

Observer la correspondance de l'horodatage des fichiers *.bnd et *.so n'est donc pas pertinent.
Mieux vaut comparer l'horodatage du bind (LAST_BIND_TIME de SYSCAT.PACKAGES) avec celui de l'exécutable (TICOMP de PG15).

Une version obsolète de l'exécutable est encore active :

Avec les versions Web de HR Access, les BHR montés en mémoire sont partagés entre les différents utilisateurs de l'application. Un BHR peut ainsi rester plusieurs heures en ligne si l'activité TP est incessante.

Si une génération a lieu entre temps, la nouvelle version des exécutables n'est alors pas prise en compte. Néanmoins, le bind de la nouvelle version des programmes ayant été fait, les BHR actifs utilisent des exécutables BNA, BNK ... déphasés.

Pour limiter cette rémanence des programmes, il convient :

• De réduire le temps de latence des BHR au minimum (working time out dans dispatcher.ini ou dispatcher.properties),
• On s'arrangera pour que les BHR soient spécialisés par processus HR (reuse_cobol_runtimes à false dans dispatcher.ini ou dispatcher.properties),

• En dernier recours on éliminera les processus unix BHR obsolètes (kill).

Exemple : un processus BHR a démarré à 11h21 mais certains programmes ont été regénérés à 11h52.

hrppr@hra:/hraccess5/hrppr/txt/log> ps -ef | grep BHR

hrppr     6604 22369  1 11:21 ?        00:00:14 /hraccess5/hrppr/bin/RTSDGN TYBXBHR WZ005BNM0000000000000001 192.168.64.11 58282 logdir=/hraccess5/hrppr/openhr/logs,trace=true,debug=true,chrono=false,client=*

hrppr@hra:/hraccess5/hrppr/prod/gnt> ltt

-rwxrwxr-x  1 hrppr v5ppr  402219 jun 28 11:52 WZ005BNA.so

-rwxrwxr-x  1 hrppr v5ppr  402219 jun 28 11:53 WZ005BJA.so

-rwxrwxr-x  1 hrppr v5ppr  402219 jun 28 11:53 WZ005BNK.so

-rwxrwxr-x  1 hrppr v5ppr  402219 jun 28 11:54 WZ005BNL.so