AXOPEN

Planisware : le client lourd reste bloqué au début du chargement

Description du problème

On tente de démarrer le client lourd mais après la mire d’authentification le client lourd reste bloqué sans message d’erreur dans sa procédure de chargement.

Identification de la cause du problème

Pour vérifier à quel endroit précis le client lourd reste bloqué il peut être utile de passer les logs en mode débug pour les échanges avec la base de données en rajoutant l’instruction suivante dans le fichier opx2.ini :

(setq db-driver::*debug-driver* t)

On aura ainsi dans les logs la requête sur laquelle le client lourd reste bloqué.

Cas ou le problème vient de la requête de purge de la table des transactions 

Identification de la transaction

Si le client lourd reste bloqué sur une transaction du type suivant :

delete from TRANSACTION_LOG where TRN_NUMBER < 
(select max(TRN_NUMBER) from TRANSACTION_LOG 
where MODIFY_VERSION is not null 
and MODIFY_VERSION > 0 and MODIFY_VERSION <= 
(select min(ONB) from OPX2_TRANSACTION where OPX2_DATE > 
to_date('2013/06/10 09:45:22','YYYY/MM/DD HH24:MI:SS')));

Cela signifie que le client lourd reste bloqué sur la suppression des transactions inutiles. Cela arrive lorsque le nombre de transactions de la table TRANSACTION_LOG est très important (plusieurs millions d’entrées). En effet l’exécution de cette requête va alors nécessiter beaucoup de ressources de la base de données (notamment la table UNDO pour les SGBD sous ORACLE).

Origine du problème

Ce remplissage important de la table peut avoir plusieurs origines :
•    Batch ayant généré un nombre important de transactions
•    Absence de purge des transactions inutiles

Pistes de résolution

Pour débloquer la situation on a 2 solutions :
•    Exécuter la requête en plusieurs fois (en jouant sur la date que l’on prend pour référence) si les transactions sont relativement espacées dans le temps.
•    Faire un truncate de la table : 

SQL> truncate table TRANSACTION_LOG

Remarques importantes

•    Pour exécuter la requête il sera sans doute nécessaire d’augmenter la taille du tablespace UNDO de votre base. Dans tous les cas il faut monitorer son remplissage car s’il est saturé pas l’exécution de la commande de suppression la requête n’aboutira pas.
•    Le truncate est à réaliser en dernier recours car il induira une perte d’informations techniques (pas fonctionnelles) notamment sur la date de dernière modification des objets Planisware. Cependant c’est la méthode la plus rapide pour débloquer la situation.