Architectures client / serveur d'Oracle

Serveur dédié et serveur partagé

En architecture standard Oracle, un process serveur (shadow process) est dédié à chaque session cliente.

L'architecture clients / serveurs partagés (shared servers), baptisée 'MultiThread' dans les précédentes versions d'Oracle permet de ne pas dédier un process serveur à chaque demande d'ouverture de session d'un client.
Un ou plusieurs process partagés pourront ainsi supporter un grand nombre de connections simultanées, sans augmenter linéairement le nombre de process serveurs.

architecture client-serveur dédié

architecture client-serveur partagé

un "listener" SQL*Net est obligatoire, même si le client est situé sur la même machine que le serveur. On sera alors en pseudo accès distant, en "Loopback"

Serveurs partagés : les process

Il faut au minimum 3 process pour que ca marche :

un listener , (LISTENER) process réseau qui attend les demande de connexion utilisateur, et connecte le process utilisateur à un serveur partagé (ou à un serveur dédié en cas de demande expresse)
un dispatcher (ora_D00n) , qui place la requête dans une file d'attente (request queue) où le premier serveur partagé diponible se servira
le nombre initial de dispatchers est donné par le paramètre DISPATCHERS de l'init.ora
un serveur partagé (ora_S00n) , qui traite effectivement la requête, accède au SGBD et met le résultat dans la file d'attente de réponse (response queue) du dispatcher demandeur.
Il y a entre SHARED_SERVERS and MAX_SHARED_SERVERS (paramètres de l'ini.ora) qui peuvent être créés.

la zone mémoire utilisateur standard (PGA), dans ce type d'architecture, ne contient qu'une pile et les informations vraiment spécifiques du process user. Les autres informations normalement contenues en PGA sont déportées en SGA.

en architecture serveur partagée, la taille de la SGA doit être revue sensiblement à la hausse du fait de l'incorporation des infos des PGAs utilisateur. Le montant de RAM maxi alloué pour une session dans la SGA peut être limitée par le paramètre d'initialisation (init.ora) PRIVATE_SGA

Configuration des paramètres utiles de l'instance

le paramétrage (nom et valeur des paramètres de l'instance est très différent suivant la version de SQL*Net utilisée : Net8 (serveur V7, V8.0 ou 8i) ou Netservice (serveur 9i)

Paramêtres version NET8

nom du paramètre ou sous paramètre	type	description	exemples
MTS_DISPATCHERS ADDRESS DESCRIPTION PROTOCOL CONNECTION DISPATCHER LISTENER	paramètre dynamique sous paramètres sous paramètres optionnels	donne le nombre et les caractéristiques des dispatchers adresse de la machine (nom hote, protocole, port) description le protocole réseau utilisé le nb max de connexions pour chaque dispatcher le nb initial de dispatchers lancés (defaut = 1 description du listener	mts_dispatchers = "(protocol=tcp) (dispatchers=5)" MTS_DISPATCHERS= "(ADDRESS= (PROTOCOL=tcp) (HOST=144.25.16.201) (PORT=5000)) (DISPATCHERS=1) LISTENER= (address=(protocol=tcp) (port=1521) (host=machine1))"
MTS_LISTENER-ADDRESS	obsolete	voir "LISTENER" de MTS_DISPATCHERS	MTS_LISTENER-ADDRESS = "(ADDRESS= (PROTOCOL=tcp) (HOST=toto) (PORT=5000))"
MTS_SERVERS	dynamique	le nombre de process serveur créés au démarrage
MTS_MAX_SERVERS	statique	nb de process simultanés max
MTS_MAX_DISPATCHERS	statique	nb de process dispatcher simultanés max

remarque : le sous paramêtre "LISTENER" DE MTS_DISPATCHERS remplace "LOCAL_LISTENER" et MTS_L.ISTENER_ADDRESS maintenus pour des raisons de compatibilité.

Pour qu'une modification de ces paramètres soit prise en compte, il faudra arrêter et redémarrer l'instance si les paramêtres sont statique ou faire un 'ALTER SYSTEM..." s'ils sont dynamiques

Un exemple en production (version Net8)

Observons la base 'PROT' en production sur une machine Unix, et notamment les serveurs partagés et dispatchers actifs :

$> ps -ef|grep ora_s00
oracle 24024 1 0 06:00:49 - 0:00 ora_s004_PROT
oracle 25290 1 0 06:00:49 - 0:00 ora_s007_PROT
oracle 25548 1 0 06:00:49 - 0:00 ora_s002_PROT
oracle 26064 1 0 06:00:49 - 0:00 ora_s008_PROT
oracle 26580 1 0 06:00:49 - 0:00 ora_s003_PROT
oracle 46440 1 0 06:00:49 - 0:00 ora_s009_PROT
oracle 52430 1 0 06:00:49 - 0:00 ora_s005_PROT
oracle 89848 1 0 06:00:49 - 0:09 ora_s001_PROT
oracle 121224 1 0 06:00:49 - 0:00 ora_s006_PROT
oracle 140000 1 12 06:00:49 - 1:21 ora_s000_PROT
$>
$> ps -ef|grep ora_d00
oracle 27022 1 0 06:00:49 - 0:00 ora_d002_PROT
oracle 37266 1 0 06:00:49 - 0:00 ora_d004_PROT
oracle 53290 1 0 06:00:49 - 0:00 ora_d000_PROT
oracle 73030 1 0 06:00:49 - 0:01 ora_d003_PROT
oracle 88368 1 0 06:00:49 - 0:00 ora_d001_PROT
$>

Il y a donc 10 process server partagés, vérifions combien de sessions sont connectées et utilisent ces serveurs partagés (ou en d'autres termes n'utilisent pas de serveurs 'dédiés'). On va pour se faire faire, consulter la table des sessions du dictionnaire (v$session) :

SQL> connect SYSTEM@PROT
SQL> select count(server) from v$session
where SERVER='NONE';

COUNT(SERVER)
-------------
74

On s'apercoit que 74 sessions sont connectées, en utilisant seulement 10 process serveurs (et 5 dispatchers)

Les paramètres correspondant de l'instance PROT (fichier init.ora) sont les suivants :

## initPROT.ora
...
mts_listener_address = "(address=(protocol=tcp)(port=1521)(host=machine1))"
mts_service = PROT
mts_dispatchers = "(protocol=tcp)(dispatchers=5)"
mts_max_dispatchers = 20
mts_servers = 10
mts_max_servers = 30

modifié
le 20/11/2006