Vous êtes dans une architecture multi-tiers Sage X3 U8 à V12, virtualisée ou non et la base de données est installée sur le même serveur que le couple Application / Runtime X3, et un ou plusieurs serveurs de traitements additionnels sont configurés

Symptômes du problème rencontré

Les sessions utilisant un des serveurs de traitements additionnels sont très lentes par rapport aux sessions utilisant le serveur de traitements principal (celui hébergé dans le serveur contenant la Base de données Oracle 11gR2 ou 12c et le serveur d’application Sage X3).



Le programme de stress (ZX3IOBENCH v2.4 ou AIOBENCH) rapporte un différentiel de performance pouvant aller jusqu’à un facteur 10.

Constat

lorsqu’on lance une session X3 en utilisant le serveur de traitements additionnel :

• Le processus adonix (exécution du code L4G) est bien lancé sur le serveur runtime additionnel ;

• Le processus sadfsq associé à la session est bien lancé sur le serveur runtime principal (ce processus est le « broker » d’objets qui fournit l’accès à adonix sur le runtime additionnel à l’arborescence des dossiers sur le serveur d’application)

• Par contre, le processus sadora qui est le « middleware » accédant à la base de données Oracle, qui normalement doit s’exécuter dans le même serveur que le processus adonix se retrouve fonctionner sur le serveur d’Application / Traitement principal

On a donc un chemin de données incorrect entre le processus adonix du serveur de traitements secondaire et la base de données Oracle, correspondant à un mode « dégradé » .

Explication

• La variable d’environnement runtime CONNECTSTR qui contient les caractéristiques de la connexion distante au serveur de base de données est manquante sur le serveur de traitement principal.

Solution à mettre en place

Il suffit de procéder à l’ajout du paramètre manquant sur le serveur de Traitements principal, à savoir déclarer une variable CONNECTSTR avec la bonne valeur (celle que la Console Safe X3 a bien mis sur le serveur de traitement additionnel, mais où elle est ignorée).



Cas d'une configuration sous unix:

• Sur le serveur de traitements principal, sous le répertoire où est installé le runtime :
  
  
  • Créer un fichier .local_profile (ce fichier sera chargé par le .profile standard)
  
  
  • Dans ce fichier, ajouter la définition de la variable d’environnement CONNECTSTR et l’exporter:
  
  
  

• hostname_oracle Est le hostname du serveur Oracle, qui est dans ce cas de figure le hostname du serveur Application X3 / Traitement principal.
  
  
  • port_listener Est le numéro de port du listener Oracle, normalement 1521
  
  
  • nom_service_oracle Est le nom du service de listener pour se connecter à la base Oracle, normalement la même valeur que ORACLE_SID
  
  
  

• Exemple de fichier ".local_profile

• Attendre la fin d’exploitation interactive (plus d’utilisateurs interactifs, plus de Web Services actifs), ou la forcer (il ne doit rester AUCUNE session X3 active, même celles lancées sur les runtimes additionnels).

• Arrêter le serveur de batches (pas obligatoire, mais recommandé)

• Arrêter le service d’écoute du runtime principal, puis le redémarrer, normalement par les commandes suivantes (XXXXX à adapter selon votre cas) :

systemctl stop x3-XXXXX-adxd

systemctl start x3-XXXXX-adxd

Attention: le “start” ne fonctionnera pas s’il restait des sessions ouvertes

• Sur le(s) serveur(s) de runtime additionnels :
  
  
  • Rien à faire a priori, toutes les nouvelles sessions profiteront automatiquement du nouveau paramétrage du serveur principal
  
  
  

Dans le cas d'une solution X3 sous Windows, la résolution se fait dans la REGISTRY, dans la section correspondant au runtime principal; on peut ègalement rajouter la variable CONNECTSTR dans le fichier env.bat ou local_env.bat; ne pas oublier de redémarrer le service Windows du runtime principal.

NULL