Au niveau architecture système, il existe essentiellement 2 architectures :
- l’une dédiée (dedicated)
- l’autre partagée (shared ou multithreaded)
Par défaut Oracle fonctionne dans le premier mode.
Le choix du mode de fonctionnement impactera fortement la charge du système en terme de nombre de processus.
Serveurs dédiés (Oracle dedicated server)
En architecture standard Oracle, un process serveur (shadow process) est dédié à chaque session cliente.
En clair il ya autant de process sur le serveurs que de client connectés.
On peut lister ces process sur le serveur en sachant qu’ils ont un attribut ‘LOCAL=NO’
$> ps -ef|grep LOCAL
oracle 270380 1 0 Mar 03 - 10:05 oracleTEST (LOCAL=NO)
oracle 995516 4636838 0 13:42:07 pts/6 0:00 grep LOCAL
oracle 1024208 1 0 10:17:01 - 0:08 oracleTEST (LOCAL=NO)
oracle 4419740 1 0 11:38:21 - 0:00 oracleTEST (LOCAL=NO)
oracle 4468764 1 0 11:24:12 - 1:13 oracleTEST (LOCAL=NO)
oracle 4481238 1 0 10:15:28 - 0:07 oracleTEST (LOCAL=NO)
C’est donc le mode par défaut. Il est satisfaisant dans la plupart des cas, hormis lorsque le nombre d’utilisateurs connéctés simultanément ’sessions) est très important. Dans ce cas il sera peut-être intéressant de passer en architecture partagée pour diminuer le nombre de processus sur le serveur…
Serveurs partagés (Shared Server)
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 connexions simultanées, sans augmenter linéairement le nombre de process serveurs.
arhitecture 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”
Les process en architecture serveurs partagés
Il faut au minimum 3 process pour que ça marche :
- un listener , (LISTENER) process réseau qui attend les demandes 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é disponible 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.
On peut voir sur le listing suivant, outre les process de fond du serveur, les process dispatcher et shared
$ > ps -ef|grep PPRUN
oracle 291042 1 49 Mar 03 - 53:21 ora_d003_PPRUN
oracle 315414 1 0 Mar 03 - 71:35 ora_d002_PPRUN
oracle 327688 1 0 Mar 03 - 112:29 ora_d001_PPRUN
oracle 368882 1 0 Mar 03 - 0:05 ora_qmnc_PPRUN
oracle 381180 1 2 Mar 03 - 51:42 ora_d000_PPRUN
oracle 385276 1 0 Mar 03 - 15:00 ora_mmnl_PPRUN
oracle 389214 1 76 13:41:14 - 0:22 ora_s001_PPRUN
oracle 663766 1 0 Mar 03 - 2:04 ora_pmon_PPRUN
oracle 819304 1 0 Mar 03 - 0:54 ora_mmon_PPRUN
oracle 843914 1 0 Mar 03 - 2:25 ora_smon_PPRUN
oracle 848122 1 0 Mar 03 - 6:08 ora_ckpt_PPRUN
oracle 925788 1 0 Mar 03 - 1:10 ora_psp0_PPRUN
oracle 930042 1 0 Mar 03 - 9:19 ora_lgwr_PPRUN
oracle 934012 1 2 Mar 03 - 5:55 ora_dbw0_PPRUN
oracle 938124 1 0 Mar 03 - 0:16 ora_mman_PPRUN
oracle 942294 1 0 Mar 03 - 0:00 ora_reco_PPRUN
oracle 954520 4636838 0 13:43:57 pts/6 0:00 grep PPRUN
oracle 962780 1 0 Mar 03 - 0:02 ora_q000_PPRUN
oracle 970974 1 0 Mar 03 - 0:04 ora_q001_PPRUN
oracle 4501582 1 0 13:38:20 - 0:49 ora_s000_PPRUN
rem : 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.
rem : 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 paramétrage
SQL> show parameter shared_server
NAME TYPE VALUE ------------------ ------ ----- max_shared_servers integer 40 shared_server_sessions integer shared_servers integer 10
SHARED_SERVERS
——————–
SHARED_SERVERS spécifie le nb de process lancés systématiquement au démarrage de l’instance. En cas de montée en charge, ce nombre pourra augmenter, mais ne descendra jamais en dessous de cette limite dans le cas inverse.
MAX_SHARED_SERVERS
——————-
MAX_SHARED_SERVERS spécifie le nb maximum de process qui peuvent tourner simultanément.
Il est compris entre SHARED_SERVER et PROCESSES.
Imposer cette limite permet de laisser des ’slots’ libres pour d’autre process comme les proces dédiés par exemple.
si MAX_SHARED_SERVERS n’est pas spécifié, un SHARED SERVER sera déclenché tant que le nb de ’slots’ de libre est > a 1/8 max(nb max process)
ou 2 si PROCESSES < 24.
