20 juillet 2016

Partitionnement Oracle "By reference" - Effets d'un DROP/CREATE sur l'ordre des partitions


Dans le cas d'un partitionnement "BY REFERENCE", on va partitionner la table ZX00 sur le critère de la période de paie (PERPAI) et les autres tables ZX** sur la base de la clef étrangère (utilisant le numéro de dossier NUDOSS).

Par exemple : 
CREATE TABLE       HR.ZX00                                   
        (      NUDOSS       NUMBER(38)                        NOT NULL ,
               SOCDOS       CHAR                    (0003)    NOT NULL ,
               PGPDOS       NUMBER(38)                        NOT NULL ,
               IDGPRG       NUMBER(38)                        NOT NULL ,
               SOCCLE       CHAR                    (0003)    NOT NULL ,
               MATRIC       CHAR                    (0012)    NOT NULL ,
               NUDOSP       NUMBER                  (0003, 0) NOT NULL ,
               IDSITU       CHAR                    (0002)    NOT NULL ,
               PERPAI       CHAR                    (0008)    NOT NULL ,

               FLGNTG       CHAR                    (0001)    NOT NULL )
                                  
 PARTITION BY LIST(PERPAI)                                    

 (PARTITION MT201401 VALUES ('MT201401') TABLESPACE HRZX_MT201401);                                           

ALTER TABLE       HR.ZX00                                    -- global
 ADD  CONSTRAINT PKZX00                                       
        PRIMARY KEY (NUDOSS)                                 
            USING INDEX TABLESPACE HRZXI                     
;                                                            
ALTER TABLE       HR.ZX00                                     
 ADD  CONSTRAINT X2ZX00              UNIQUE
          (
           SOCCLE               ,                            
           PERPAI               ,      
           ...
           TIMEST               ) 
USING INDEX                              
LOCAL (PARTITION MT201401 TABLESPACE HRZXI_MT201401)
;                                                            
CREATE            INDEX       HR.X4ZX00        ON       HR.ZX00
          (NUGEST               ,                             
           NUDOSP               )                            
 LOCAL (PARTITION MT201401 TABLESPACE HRZXI_MT201401)
; CREATE TABLE       HR.ZXTA                              
        (      NUDOSS       NUMBER(38)                       NOT NULL ,
               NULIGN       NUMBER(38)                       NOT NULL ,
               SOCDOS       CHAR                    (0003)   NOT NULL ,

               PERPAI       CHAR                    (0008)   NOT NULL ,
               USAGEP       CHAR                    (0001)   NOT NULL ,
               NUMTRT       CHAR                    (0001)   NOT NULL ,
               NUMBUL       CHAR                    (0002)   NOT NULL ,
               TIMEST       DATE                             NOT NULL ,
CONSTRAINT FKZXTA
        FOREIGN KEY (NUDOSS     ) REFERENCES       HR.ZX00
              ON DELETE CASCADE )
PARTITION BY REFERENCE (FKZXTA)                         
;                                                           
ALTER TABLE       HR.ZXTA
 ADD  CONSTRAINT X1ZXTA             UNIQUE
          (NUDOSS               ,
           NULIGN               )                            

USING INDEX 

LOCAL (PARTITION MT201401 TABLESPACE HRZXI_MT201401) ;


L'avantage avec un partitionnement « BY REFERENCE » c'est que l'absence de champ PERPAI dans la table ZX** n’est pas impactante, et que la création des partitions de toutes les tables filles (et des index) se fait automatiquement suivant celles de la ZX00.

5 juillet 2016

hr-rich-client ERROR - HRWEB3016 Invalid node name



Au cours de la vie d’un de mes projets, l’environnement de PRD a été initialisé par duplication d’un environnement QUA.

Puis une fois le démarrage réalisé, les livraisons en PRD ont été réalisées à partir d’un environnement INT.

Problème : 
Suite à la copie du ZIP de l’arbre Web de INT sur PRD, l'utilisateur rencontre des « pages blanches »...

Il se trouve qu'entre QUA et INT ... HRStudio a nommé différemment les LFA
/hraqua/tomcat/hr-rich-client/protected/TA0FR/F/FRP/TA0FR0DN/auevaa01.html <- QUA != INT
/hraint/tomcat/hr-rich-client/protected/TA0FR/F/FRP/TA0FR0DN/au0dsn03.html
/hraprd/tomcat/hr-rich-client/protected/TA0FR/F/FRP/TA0FR0DN/au0dsn03.html <- PRD == INT

Par acquis de conscience le ZIP et l’objet « arbre de publication » TA0FR ont été relivrés (export en mode complexe de INT sur PRD - le fichier contient bien les 501 objets "LY" associés aux LFA).

Dans le /hraprd/tomcat/hr-rich-client/protected/TA0FR/lfas.xml on retrouve
<LFA deployPlatform="CDPLPINT" deployTime="2016-05-25-17.14.29" deployUser="DIGIX" name="TA0FR0DN" synchObject="Yes" version="004"><LANG Code="F"><VOC Code="FRP"/></LANG></LFA>
Donc le fichier des LFA vient bien de INT

Dans le /hraprd/tomcat/hr-rich-client/protected/TA0FR/navigation_F_FRP.xml on retrouve
<HRNODE BorderName="ASB00001" Confid="" HelpId="FCW0AK01" Id="TA0FR0DN_AU0DSN03" Lfa="TA0FR0DN" Locations="FR" Modules="PAD" PresentationType="" ProcessName="FD0PA" SPCA="PADEVT02" TreeNodeName="AU0DSN03" ValidityState="1">
Ce qui est cohérent avec INT et avec l’arborescence des fichiers de PRD

Pourtant – après arrêt/démarrage - l'utilisateur rencontre toujours des pages blanches, et dans la log de production on trouve encore :
GET /hr-rich-client/operation.jsp?TREE=TA0FR&LANG=F&NODE=TA0FR0DN_AUEVAA01&VOC=FRP&LOADNODE=false

En fait, l’association LFA (action fonctionnelle localisée) - Page web est stockée dans l’objet Scope ...

Si l'on exporte et décode l’objet AR INST en PRD on y retrouve :
<node name="TA0FR_TA0FR0DN_AUEVAA01" node_id="AUEVAA01" type="NN" functional-action="CSTMCY22" index="0" modules="ANA,ASM,BEN,CMP,CPT,DIV,DUC,EVD,FDP,GHR,GTA,HWH,ITS,…"><loc value="FR"/>


Conclusion :

  • Ne pas changer d’environnement « source » pour les livraison en production d’arbre web,
  • Ou, si cela est nécessaire, relivrer systématiquement le scope avec le zip de l’arbre

6 juin 2016

AIXTHREAD_SCOPE - Thread Tuning pour Oracle

Suite à l'analyse d'un administateur AIX, il apparaît que le paramètre suivant peut valoir d'être adapté : IBM recommande de positionner cette valeur à "S" notamment en AIX 7.1

<<AIXTHREAD_SCOPE - Thread Tuning
· Oracle requires AIXTHREAD_SCOPE=S (sytem wide)
· AIX 7.1 uses the M:N model for user threads as the default. It is recommended for an Oracle environment to specify AIXTHREAD_SCOPE=S (1:1). The default of M:N permit several user threads to share virtual processor or the same pool of VPs and the kernel thread is mapped to eight user threads.

if you set systemwide contention scope, then significantly less memory is allocated to each Oracle process.>>


Dans le cas où un compte Unix dédié à oracle démarre les bases de données, il est préconisé de valoriser ce paramètre dans le .profile.

Si c’est un compte unix HRAccess qui démarre la base données, valoriser ce paramètre dans le script de démarrage la base de données - afin que seuls les process Oracle en bénéficie (il n'est peut-être pas judicieux pour les autres types de programmes (java, cobol …)).

25 mai 2016

BOV-BBAO0020-ERREUR MODULE JAVA JAVAPRESELECTION TYPE CONNECTION

Depuis HRv5 la plupart des chaines batch HR Access possèdent une étape de pré-sélection de la population à traiter. Elle peut prendre la forme d'un ordre SELECT ou d'un appel à un Query Population (information ZO5T).

select * from ZO5T where nudoss = 8590;

    NUDOSS SOC     PGPDOS T CDQURY
---------- --- ---------- - --------
      8590 INT          0 Q VBSOCPER


Cette pré-sélection passe donc par le serveur HRQuery.
  • Un java est exécuté 
  • Il reçoit le NUDOSS du dossier de Travail via la socket IP libellée "TCPPort"dans la Topologie HRS. 
  • En retour - si la présélection prend la forme d'un Query Population - HRQuery alimente la ZO5W du travail avec l'ordre SQL correspondant au query passé en paramètre.

if
  [ $MAX_RETOUR -le 4 ]
  then
echo "*-------------------------- STEP105N ----------------*"
echo "*          Execution module JAVA                    *"
echo "*---------------------------------------------------*"
   cd $SIGACS/openhr/lib
   java -jar preselection.jar \
   filein=$TMP/T100C1."$nupro"\
   fileout=$TMP/T105JV."$nupro"
   cd $TMP
    CODE_RETOUR=$?
if
  [ $CODE_RETOUR -gt $MAX_RETOUR ]
  then
      MAX_RETOUR=$CODE_RETOUR
fi
echo "\n"
fi


Dans le fichier en entrée, on trouvera les paramètres d'accès au serveur de Query et le numéro de dossier du travail :

[CONNECTION]
HOST=myhrserver
PORT=1234
[GENERAL]
ACTION=1
NUDOSS=000008590
LANG=F



Le log de la chaine indique :

*-------------------------- STEP105N ----------------*
*          Execution module JAVA                    *
*---------------------------------------------------*
Filein: /hraqua/txt/tmp/T100C1.4105
Fileout: /hraqua/txt/tmp/T105JV.4105
Reading INI file /hraqua/txt/tmp/T100C1.4105 ...
Action: 1
Host:
myhrserver
Port: 1234
Dossier ID: 000008590
Language: F
Opening socket to myhrserver:1234 ...
Writing request ...
Wrote request. Reading response ...
Read response: OK
Closing socket ...
Socket closed
Writing response to file /hraqua/txt/tmp/T105JV.4105 ...
Wrote response to file /hraqua/txt/tmp/T105JV.4105


Le log de HRQuery

2016-05-25 08:56:10,500 [PopulationConnector] INFO  - HRJS1031 Proxy created
2016-05-25 08:56:10,501 [Thread-70] INFO  - HRJS1033 Proxy started
2016-05-25 08:56:10,502 [Blank][Thread-70] INFO  - QRSRV1004 Start of preselection query execution 2016-05-25.08.56.10
2016-05-25 08:56:10,563 [Blank][Thread-70] INFO  - SQLNG1014 Creating query from xml
2016-05-25 08:56:10,565 [Blank][Thread-70] INFO  - SQLNG1020 Generating SQL ...
2016-05-25 08:56:10,608 [Blank][Thread-70] INFO  - QRSRV1005 End of batch preselection execution 2016-05-25.08.56.10
2016-05-25 08:56:10,608 [Blank][Thread-70] INFO  - HRJS1032 Proxy closed


Dans le fichier retour :
JAVAPRESELECTION
OK


Le serveur HRQuery va modifier le dossier de travail pour alimenter dans une occurrence de ZO5W l'ordre SELECT de creation de population (cf ligne 9000 pour JQP)

select * from ZO2P where nudoss = 8590;

    NUDOSS     NULIGN SOC     PGPDOS TIMDEB              TIMFIN              CDP ZOSOUM CD
---------- ---------- --- ---------- ------------------- ------------------- --- ------ --
      8590          1 INT          0 2016-05-25-08.56.10 2016-05-25-08.56.10 BOU        01
      8590          2 INT          0 2016-05-25-08.56.10 2016-05-25-08.56.10 BOV        00
      8590          3 INT          0 2016-05-25-08.56.10 2016-05-25-08.56.10 DC6        12
      8590          4 INT          0 2016-05-25-08.56.10 2016-05-25-08.56.10 BE9        00
      8590          5 INT          0 2016-05-25-08.56.11 2016-05-25-08.56.11 BLZ        00
      8590       9000 INT          0 2016-05-25-08.56.10 2016-05-25-08.56.10 JQP        00

6 rows selected.

hr@APCV9QUA@frsopslappv26> select * from ZO5W where nudoss = 8590;

    NUDOSS SOC     PGPDOS CDIDEN
---------- --- ---------- --------
ZOREQU
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
      8590 INT          0
SELECT DISTINCT   T1.NUDOSS    FROM ZX00 T1,ZX6B T2  WHERE   T1.NUDOSS  = T2.NUDOSS   AND   T1.PERPAI = 'MT201606' AND T2.CODSOC = '001'


En cas d'erreur c'est BOV qui signale l'incident
AD800BOV-BBAO0020-ERREUR MODULE JAVA JAVAPRESELECTION TYPE CONNECTION
sans fournir aucun détails ...

Il pourrait s'agir d'un serveur de Query fermé,

Dans mon exemple, la demande ZO fait référence à un Query Population qui n'a pas été déployé.

select * from ZO00 where TYTMPL='T' and CDELMT='VBSOCPER';
no rows selected



9 mars 2016

Erreur fatale dans HRaSpace - Message DNA4


A la connexion, l'application HRaSpace affiche :
<< L'application suivante n'est pas disponible : HR Configuration Tool V2 >>

Dans hr-configuration-tool-web-smartgwt.log on note un message d'erreur abscons concernant BNP et le module DNA4 :

2016-03-09 06:22:57,110 [localhost-startStop-1] ERROR com.hraccess.log.ophrc.msgDesc - OPHRC3101 Error while reading server response. Result message description :
RESPONSE <- R_EXTRACT_DATA of '0' rows(s)
2016-03-09 06:22:57,110 [localhost-startStop-1] ERROR com.hraccess.log.ophrc - OPHRC3010 *** System error occured while getting message <REQUEST -> S_EXTRACT_DATA> : <RESPONSE <- R_SYSTEM_ERROR, TYERRE= R, TYORDR= P, CDPROG= BNP, CDFONC= 62, CDSFTC= HQ, ZOERR1= DNA4, ZOERR2= 000000000000999, ZOERR3= , ZOERR4= , ZOERR5= , MSG= Error on record>
2016-03-09 06:22:57,111 [localhost-startStop-1] FATAL com.hraccess.webapp.fatalerror.HRStartupFatalErrorBuilder - Error
java.lang.RuntimeException: com.hraccess.openhr.exception.HRResultSYSTEMERRORException: HRAccess system error [TYERRE='R',TYORDR='P',CDPROG='BNP',CDFONC='62',CDSFTC='HQ',ZOERR1='DNA4',ZOERR2='000000000000999',ZOERR3='',ZOERR4='',ZOERR5='',MSG='Error on record']


DNA4 est un module C existant depuis HRv9. Le guide technique indique : module Unix/ Oracle << spécifique aux plates-formes dotées d'un processeur 64 bits sur lesquelles le Pro COBOL ne permet pas le SQL dynamique de niveau 4>>

En cas d'erreur l'exécutable rédige un fichier DNA4.err
    GETLOGDIR(sPath);
    strcat(sPath,"DNA4.err");
 
Dans le répertoire openhr/logs on trouve un fichier DNA4.err dont l'horodatage correspond. Son contenu est explicite :

|DNA4-ERR|32202|318|2016-03-09 06:22:57,066959008|---------6---------7---------8
12345678901234567890123456789012345678901234567890123456789012345678901234567890
SELECT DISTINCT ZD00.NUDOSS, ZD00.CDREGL, ZD00.CDSTCO, ZD00.CDCODE FROM HR.ZD7T
ZD7T, HR.ZD00 ZD00 WHERE ( ZD00.NUDOSS = ZD7T.NUDOSS AND ZD7T.NATU23 = 'R' AND Z
D00.CDSTCO = 'HMD') ORDER BY ZD00.CDREGL ASC, ZD00.CDSTCO ASC, ZD00.CDCODE ASC;
ORA-MSG:ORA-00942: table or view does not exist
12345678901234567890123456789012345678901234567890123456789012345678901234567890

SQL> desc ZD7T
ERROR:
ORA-04043: object ZD7T does not exist
 
L'application cherche à accéder à une table ... inexistante.
La créer, stopper HRaSpace et redémarrer.

9 novembre 2015

Oracle - statistics_level = TYPICAL / ALL

De la part de Michel,

La base de données Oracle dispose d'un paramètre "statistics_level" par défaut à TYPICAL
select value from  v$system_parameter where name='statistics_level';
-------
TYPICAL
 
Sur certaines de ses bases le paramètre était valorisé à ALL.

L'effet sur les performances de HR Access s'est avéré parfois extrêmement pénalisant (surtout lorsqu'un batch exécute des milliers de petites requêtes). Replacer le statistics_level à TYPICAL a eu un effet immédiat.

Ce paramètre est en lien avec le "cardinality feedback" et le "adaptive cursor sharing".
Quelques infos sur ce post...

A priori le "statistics_level" = ALL est plutôt à réserver au debug, quand on suspecte un problème (cf ce post) :



There is very little overhead for collecting typical statistics but there will be extra overhead for collecting the OS and plan execution statistics, and statistics_level=all should only be used when troubleshooting a performance problem

23 juillet 2015

Oracle - Effets du "cardinality feedback"

Chez un collègue les performances de certaines requête Oracle se dégradaient lorsqu’elles étaient lancées plus d’une fois.

<< Depuis la version 11.2.0.1 de oracle, lorsqu’une requête est exécutée de façon répétitive, l’optimiseur tente d’améliorer son plan d’exécution après chaque passage.
Pour atteindre cet objectif, il utilise la technique de "cardinality feedback" pour s’informer sur les mauvaises estimations qu’il vient de faire pendant la génération de l’actuel plan d’exécution. Au passage suivant, il essaye de générer un nouveau plan d’exécution en se basant sur les informations précédentes.
Hélas, le nouveau plan n’est pas toujours optimal, ce qui peut contribuer à dégrader la performance de la requête à partir de la deuxième exécution

Pour savoir si le Cardinality Feedback est utilisée, se reférer à la partie Note du plan d’exécution où il est indiqué :  "Cardinality Feedback used for this statement" - ou bien interroger la colonne USE_FEEDBACK_STATS de la vue dynamique V$SQL_SHARED_CURSOR. Cette colonne doit être initialisée à ‘Y’ >>


Note de Oracle :
Cardinality feedback. This feature, enabled by default in 11.2, is intended to improve plans for repeated executions. See Support note 1344937.1 and documentation for additional info.
You can be disable cardinality feedback with an underscore parameter which can be set at session or instance level. Usual caveats on setting underscore parameters apply:
alter session set "_OPTIMIZER_USE_FEEDBACK"=FALSE;
This can also be done with a hint, therefore at statement level, using the opt_param syntax: /*+ opt_param('_OPTIMIZER_USE_FEEDBACK','FALSE') */

5 mars 2015

HRaSpace : "Erreur au chargement, essayez de vous reconnecter" si connexions multiples

Dans certains cas une connexion à un second environnement HRaSpace "écrase" la première.
 

Pour y remédier, vous devez vous arranger pour que l'entête des URL (nom du serveur) soit différent pour chacun de vos environnements.

Cela peut se faire via le fichier hosts de votre PC (répertoire C:\windows\system32\drivers\etc - à ouvrir si besoin en tant qu'administrateur).

Si votre serveur a pour adresse IP : 1.2.3.4 et qu'il héberge deux environnements REF et DEV, ajoutez une ligne pour lui associer des "noms" de machine distincts :

# mon.hraspace
1.2.3.4 monhraspace.ref mon.hraspace.dev

Et dans vos favoris (IE, Firefox) changez vos IP par les noms.
Par exemple :
http://1.2.3.4:5678/hraspace/portal
http://1.2.3.4:5679/hraspace/portal
deviendra :
http://mon.hraspace.ref:5678/hraspace/portal
http://mon.hraspace.dev:5679/hraspace/portal