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 où 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
→ Piste 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 >}} SQL> 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.
