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

Le 09/07/2013 Par Thibault Goninopx2p5client-lourdchargementbloquédebug driverinutileplansiwaretransactiontransaction_logundo

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 :

{{< highlight java >}} (setq db-driver::debug-driver t){{< /highlight >}}

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 :

{{< highlight java >}} 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'))); {{< /highlight >}}

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 : 

{{< highlight java >}} SQLLangage permettant de communiquer avec une base de données.> truncate table TRANSACTION_LOG{{< /highlight >}}

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.

Sommaire

  •         fleche vers la droite Description du problème
  •         fleche vers la droite Identification de la cause du problème
  •         fleche vers la droite Cas ou le problème vient de la requête de purge de la table des transactions 

À voir aussi

Tous les articles