Aller au contenu

    Configuration du nombre maximal de sessions d’une base de données Oracle pour Planisware

    Introduction

    Lorsque l’on installe un environnement Planisware Server en cluster (plusieurs Intranet Servers) connecté à un schéma de base de données Oracle il est utile de vérifier que la base Oracle est bien configurée pour ce type de fonctionnement. En particulier lorsque l’on a un nombre important d’Intranet Server démarrés il faut vérifier que le nombre maximal de sessions autorisées sur la base de données est bien paramétré.

    Services Planisware et interactions avec la base de données

    Les services Planisware communiquent vers la base de données via le module Planisware Connect. Le module Connect n’établit pas de connexion pour son compte propre mais pour celui des services applicatifs suivants :

    → Intranet Server (maître et esclave)
    → Dispatch
    → TimeCard HTML

    Estimation du nombre de sessions oracle nécessaires au fonctionnement de Planisware

    Il convient de s’interroger sur le nombre de connexions (sessions) établies par chaque processus Planisware avec la base. A titre informatif voici le nombre de sessions oracle ouvertes par type de processus Planisware sur un environnement sous Planisware 5 SP1 :

    Intranet Server

    → 1 session pour le Watchdog Intranet Server
    → 2 sessions par Intranet Server (master ou slave)

    Dispatch

    → 3 sessions pour le Dispatch

    TimeCard HTML

    → 4 sessions par TimeCard HTML (master ou slave)

    Client lourd ou batchs

    → 1 connexion par client lourd ou batch lancé

    A cela se rajouteront les connexions ponctuelles des processus forkés (à estimer en fonction de l’utilisation des forks dans votre application Planisware).

    Ainsi par exemple pour un environnement Planisware avec :

    → 1 Dispatch
    → 8 IS slaves

    Le nombre minimum de sessions oracle ouvertes par les services Planisware sera de 3 (Dispatch) + 17 (Intranet Server), soient 20 sessions hors processus forkés. Si on estime 1 fork par IS slave dans notre exemple on arrive à 28 sessions simultanées pour les processus Planisware.

    Vérification du nombre de sessions oracle ouvertes pour une application Planisware en fonctionnement

    Il est également possible de vérifier à chaud le nombre de sessions ouvertes par Planisware sur une base. Pour cela il suffira de se connecter avec un utilisateur oracle administrateur de la base (SYSTEM par exemple) et d’exécuter une requête SQL du type suivant :

    select * from v$session where MODULE like '%OPX2%';

    Cette commande est valable pour un environnement P5 SP3. Elle permettra d’afficher toutes les sessions de base de données ouvertes par les processus Planisware.

    Vérification du paramètre oracle sur le nombre maxi de sessions de BDD

    Le paramètre « *.session » initialisé au démarrage de la base indique le nombre maximal de sessions simultanées que la base de données Oracle va accepter. Au-delà toute nouvelle tentative d’accès à la base de données sera refusée.

    Attention ce paramètre est un paramètre global pour toute la base de données (non spécifique à un schéma ou un utilisateur). Ce quota est notamment partagé avec les utilisateurs SYS et SYSTEM.

    On peut vérifier la valeur du paramètre « *.session » en lisant sa valeur dans le fichier « spfile.ora » de la base.

    Ce nombre doit être supérieur au nombre de sessions simultanées estimées pour les services Planisware. Comme indiqué précédemment, comme ce paramètre est valable pour toute la base de données, on ne doit pas oublier d’inclure les connexions autres que celles de notre environnement Planisware :

    → Sessions système oracle (SYS et SYSTEM)
    → Accès à la base de données via des outils tels que SQL Developer
    → Accès direct à la base via SQLPLUS
    → Autres applications possédant un schéma sur la même base
    → …

    En cas de mauvaise estimation de cette valeur maximum de sessions autorisée sur la base de données on il y aura dysfonctionnement des processus qui tenteront de se connecter à la base (refus d’accès à la base de données).