Oracle Net Service : est un ensemble de logiciels qui permettent aux applications cliente

d’établir une connexion ( un connexion est une session ou un canal do communication entre le
processus utilisateur et le processus serveur , via ce canal on va émettre nos requêtes )
Dans les nouvelle version on ne travail pas avec le SID mais avec le SERVICE_NAME
 Description de la connexion

Protocol

Host

Port

Connect system@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521))
(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=orcl))
Pratiquement :
Comme on voit cette méthode est très lente , en pratique en migre ces paramètre vers un
fichier de configuration qui sera consulter à chaque fois on souhaite établir la connexion.
Pourquoi la résolution des noms :
La résolution de noms (naming resolution) est un processus essentiel pour permettre aux
applications et aux services de localiser et de se connecter à des ressources réseau, telles que
des bases de données, des serveurs et d'autres services. Dans le contexte des bases de
données Oracle et de la connexion, la résolution de noms est utilisée pour déterminer
comment localiser et se connecter à une base de données spécifique.

Dans le cas d'Oracle et de sa technologie Net Services (TNS - Transparent Network Substrate),
la résolution de noms est utilisée pour déterminer :
1. Où se trouve la base de données : La résolution de noms permet de savoir où est
hébergée la base de données à laquelle vous souhaitez vous connecter. Cela peut être
sur la même machine (localhost) ou sur une machine distante avec un nom d'hôte
spécifique.
2. Le port à utiliser : Chaque service Oracle fonctionne sur un port spécifique. La résolution
de noms détermine quel port utiliser pour établir la connexion.
3. Le nom de service ou le SID : Oracle utilise des noms de service ou des SIDs (System
Identifiers) pour identifier les bases de données. La résolution de noms permet de faire
correspondre un nom de service ou un SID avec une adresse IP et un port.
4. D'autres paramètres de connexion : En plus de l'adresse IP et du port, la résolution de
noms peut également inclure des informations de configuration supplémentaires, telles
que le mode de connexion (dédié ou partagé) et d'autres paramètres spécifiques.

Les fichier responsable de la connexion réseau se trouve dans le path : C:\NewFolder\homes\

OraDB21Home1\network\admin
Pour établir une méthode de résolution de nom on consulte le fichier « sqlnet.ora »

On spécifie les méthodes de résolution de noms

  Easy Connect (EZCONNECT) :

Exemple :

Machine local : connect system/Ysne2468@Glioual-SIL/orcl

Remarque :
- Dans cette méthode comme on a dit elle nécessite pas de fichier de
configuration mais on précise tous nos paramètre de connexion dans le
commande line
- Si le fichier n’existe pas il faut utiliser l’utilitaire : Assistant Configuration
Oracle Net

Cette configuration va garder un copie de la version actuelle de fichier actuelle puis remplacer
le fichier par le nouveau fichier .
  TNSNAMES :

Ce fichier va nous aider à se connecter avec des diffèrent base de données , à

chaque fois on ajoute un nouvelle base de données il faut ajouter aussi dans ce fichier.
Pour pouvoir se connecter il faut la commande :
Connect system/mdp_lors_d’instalation_d’oracle@nom_d’alisas
Exemple :
Connect system/Ysne2468@orcl

Si ce fichier n’existe pas on procède de la même manière avec assistant

Résumé :
Les processus de connexion :

1. Mode de connexion dédié :

Le fichier Listener n’est fonctionnel que pendant la demande de connexion entre le processus
utilisateur et le serveur, une fois vous mettez en communication avec les processus serveur qui
va vous prendre en charge pour lui sont travail est terminé(il va rester à l’ écoute d’autre
demande de connexion).
pour chaque utilisateur , un processus
serveur qui va le prendre en charge , c’est le
mode dédié , ce mode là est configuré dans
le fichier tnsnames.ora avec le paramètre
SERVER = DEDICATE. (default mode)
càd à chaque fois une personne est
connecté à la base , il aura un processus
serveur qui va le prendre en charge , et qui
dit un processus serveur di une mémoire
PGA ( 1000users => 1000 mémoire PGA =>
gaspillage de mémoire => ce mode est que
pour la maintenance ou les opération de
récupération ) .

2. Mode de connexion partagé :

 dans ce cas là un nombre de client peuvent se connecter mais pas directement , mais
plutôt il doivent passer par un DISPATCHER = un répartiteur de processus qui va diriger les
demande de connexion ou bien de session vers un file d’attente. On va choisir ce qu’on appelle
un pool partagé de SP (server process) qui va s’occuper d’un ensemble de demande de
connexion.
Donc on une file d’attente de demandes , et chaque processus serveur libre va prendre
en charge une demande avec le principe FIFO et ainsi de suite
1. File d'attente de demande (Request Queue) :
 Lorsqu'un client Oracle se connecte en mode serveur partagé, sa demande de
connexion est placée dans la file d'attente de demande.
 La file d'attente de demande est gérée par un composant appelé "Dispatcher" (ou
"Shared Server Dispatcher"). Le dispatcher est responsable de l'acceptation des
demandes de connexion des clients et de leur placement dans la file d'attente.
2. Dispatcher :
 Le dispatcher est un processus Oracle spécialisé qui fonctionne en mode serveur
partagé. Il est responsable de la gestion des connexions entrantes des clients.
 Lorsqu'un client se connecte, le dispatcher prend en charge sa demande de connexion
en la récupérant depuis la file d'attente de demande.
 Le dispatcher traite ensuite la demande en allouant une session partagée disponible
pour le client à partir du pool de sessions partagées. Une session partagée est associée
à un thread de processus serveur partagé.
 Le dispatcher gère également les tâches de communication avec le client, telles que la
réception des requêtes SQL et l'envoi des résultats.
3. File d'attente de réponse (Response Queue) :
  Une fois qu'une session partagée a terminé de traiter les requêtes d'un client, les
résultats sont placés dans la file d'attente de réponse.
 La file d'attente de réponse est également gérée par le dispatcher.
4. Retour des résultats au client :
 Le dispatcher récupère les résultats depuis la file d'attente de réponse et les envoie au
client approprié.
5. Libération des ressources :
 Après que le client a reçu les résultats et que la session a été utilisée, les ressources
associées à la session partagée sont libérées.
 Le thread de processus serveur partagé peut être réutilisé pour gérer les futures
demandes de connexion d'autres clients.

Configuration du mode partagé :

le paramètre obligatoire est le SHARED_SERVERS qui doit avoir une valeur > 0 (si sa valeur est
égale à 0 , cela veut dire que vous avez désactiver le mode partagé )
1. SHARED_SERVERS :
 Le paramètre "SHARED_SERVERS" spécifie le nombre maximal de processus serveur
partagés qui peuvent être créés pour gérer les connexions clientes dans le mode serveur
partagé.
 Chaque processus serveur partagé peut gérer plusieurs sessions clientes simultanément,
ce qui permet de partager efficacement les ressources du système entre les connexions.
 La valeur de ce paramètre doit être définie en fonction de la charge prévue de la base
de données et de la capacité du système. Une valeur trop basse peut entraîner des
attentes pour les connexions, tandis qu'une valeur trop élevée peut consommer
inutilement des ressources système.
 Par exemple, si "SHARED_SERVERS" est défini sur 20, cela signifie qu'il peut y avoir
jusqu'à 20 processus serveur partagés en cours d'exécution pour gérer les connexions.
2. SHARED_SERVER_SESSIONS :
 Le paramètre "SHARED_SERVER_SESSIONS" spécifie le nombre maximal de sessions
clientes pouvant être associées à un processus serveur partagé dans le mode serveur
partagé.
 Une session cliente est associée à un thread de traitement dans un processus serveur
partagé. Ce paramètre contrôle donc le nombre maximal de threads de traitement
pouvant être créés dans chaque processus serveur partagé.
 La valeur de ce paramètre est généralement définie en fonction de la charge et des
besoins de l'application. Si la valeur est trop basse, cela peut entraîner une utilisation
inefficace des ressources du processus serveur partagé, tandis qu'une valeur trop élevée
peut entraîner une utilisation excessive de la mémoire.
 Par exemple, si "SHARED_SERVER_SESSIONS" est défini sur 10, cela signifie qu'un
processus serveur partagé peut gérer jusqu'à 10 sessions clientes simultanément.

1000 agents
1 agent 10% utilisation de la db
 Quelle est le nombre de serveur partagé à établir ?
Pour 1000 agents  10% * 1000 = 100 serveurs

Un "serveur partagé", dans le contexte de l'administration de bases de

données ou d'autres systèmes informatiques, fait référence à une
configuration où plusieurs clients ou utilisateurs partagent les ressources
d'un seul serveur. Plutôt que d'avoir un serveur dédié pour chaque utilisateur
ou application, les ressources de calcul, de mémoire, de stockage et de
réseau sont partagées entre plusieurs utilisateurs ou processus.
Explication d’exercice :
Dans le contexte spécifique des bases de données Oracle, la terminologie
"serveurs partagés" peut faire référence aux processus serveurs qui sont
utilisés pour gérer les connexions et les demandes des utilisateurs ou des
applications dans une instance de base de données Oracle.

Lorsque vous utilisez Oracle Database, il existe un processus central appelé

"instance de base de données" qui gère l'accès aux données et exécute les
requêtes. Cette instance de base de données peut avoir plusieurs processus
serveurs pour gérer les demandes. Ces processus serveurs sont partagés
entre les utilisateurs et les connexions.

Dans le contexte d'une instance Oracle avec "serveurs partagés", cela signifie
que les processus serveurs gèrent les connexions et les requêtes de plusieurs
utilisateurs simultanément. Les ressources du serveur (CPU, mémoire, etc.)
sont partagées entre ces connexions. Oracle utilise un modèle d'architecture
multithread pour gérer efficacement les connexions multiples.

Lorsque vous configurez Oracle avec des "serveurs partagés", cela signifie
que vous configurez l'instance Oracle pour gérer les connexions entrantes en
utilisant un pool de processus serveurs partagés. Cela peut aider à gérer
efficacement les connexions et à répondre aux demandes des utilisateurs.

Pour revenir à votre exercice, si l'exercice parle de "100 serveurs partagés"

dans le contexte d'Oracle, il pourrait faire référence à la configuration d'une
instance Oracle avec un pool de 100 processus serveurs partagés pour gérer
les connexions et les requêtes. Cela permettrait de fournir des services de
base de données à un grand nombre d'utilisateurs en partageant les
ressources des serveurs.
Gestion de pool de processus serveurs partagés :
Voici comment fonctionne concrètement un "pool de processus serveurs partagés" dans le
contexte d'Oracle Database :

1. Création du Pool : Lorsque vous configurez une instance Oracle pour utiliser un pool de
processus serveurs partagés, vous spécifiez le nombre initial de processus serveurs qui
seront créés dans le pool au démarrage de l'instance. Par exemple, si vous définissez le
pool pour avoir 100 processus, cela signifie que 100 processus serveurs sont créés au
démarrage de la base de données.
2. Connexions Utilisateurs : Lorsqu'un utilisateur ou une application se connecte à la base
de données, une session utilisateur est créée. Cette session nécessite un processus
serveur pour gérer les demandes de cette session.
3. Allocation de Processus : Lorsqu'une nouvelle connexion arrive et nécessite un processus
serveur, le système vérifie s'il y a un processus disponible dans le pool. Si un processus
est disponible, il est alloué à la nouvelle connexion. Si le pool est vide, un nouveau
processus peut être créé pour cette connexion, jusqu'à ce que le nombre maximum
spécifié soit atteint.
4. Réutilisation des Processus : Une fois qu'une session utilisateur a terminé son
traitement, le processus serveur est libéré. Au lieu d'être détruit, ce processus est remis
dans le pool. Il peut ensuite être réutilisé pour gérer d'autres connexions ultérieures.
Cela évite la création et la destruction constantes de processus, ce qui économise des
ressources.
 5. Gestion des Pools : La base de données gère de manière intelligente le nombre de
processus dans le pool en fonction de la charge. Si la charge augmente et que le pool est
vide, de nouveaux processus peuvent être créés pour répondre à la demande. Si la
charge diminue, les processus inutilisés peuvent être remis dans le pool.
6. Paramètres de Configuration : La configuration du pool de processus serveurs partagés
peut être ajustée en fonction des besoins de l'application. Les paramètres incluent le
nombre initial de processus, le nombre maximal de processus, et d'autres options de
gestion.
7. Avantages : L'utilisation d'un pool de processus serveurs partagés permet de gérer
efficacement la charge, d'économiser les ressources du système et de fournir une
meilleure évolutivité, car les processus sont réutilisés au lieu d'être constamment créés
et détruits.
En résumé, un pool de processus serveurs partagés permet à plusieurs connexions et sessions
d'utilisateurs de partager un ensemble de processus serveurs. Les processus sont alloués
dynamiquement en fonction de la demande, et une fois libérés, ils sont remis dans le pool
pour être réutilisés. Cela permet une gestion plus efficace des ressources et une meilleure
capacité à gérer les pics de charge.
Pratique :
 Affichage des dispatchers :

 Activation du mode partagé :

Alter system set shared_serveur = 1

 Affichage de shared_serveurs :

Le paramètre shared_servers indique le nombre minimal de processus

serveurs partagés qui seront créés dans le pool. Pour activer ou désactiver les
processus serveurs partagés, vous devez utiliser le paramètre dispatchers.
Pour activer les processus serveurs partagés, vous pouvez utiliser la commande
suivante :
ALTER SYSTEM SET DISPATCHERS="(PROTOCOL=TCP) (SERVICE=shared)
(DISPATCHERS=1)" SCOPE=BOTH;
Cela permettra à votre instance Oracle de configurer un dispatcher pour gérer
les connexions entrantes avec des processus serveurs partagés.
Pour désactiver les processus serveurs partagés, vous pouvez utiliser la
commande suivante :
ALTER SYSTEM SET DISPATCHERS="" SCOPE=BOTH;
 Changer le mode dédié vers partagé :
ALTER SYSTEM SET DISPATCHERS="(PROTOCOL=TCP) (SERVICE=shared)
(DISPATCHERS=n)" SCOPE=BOTH;
 Remplacez "n" par le nombre de processus serveurs partagés que vous
souhaitez configurer.
ALTER SYSTEM SET DISPATCHERS="(PROTOCOL=TCP) (SERVICE=shared)
(DISPATCHERS=3)" SCOPE=BOTH;

 Pour désactiver les processus serveurs partagés, vous pouvez utiliser la

commande suivante :
ALTER SYSTEM SET DISPATCHERS="" SCOPE=BOTH;
Le processus Listener :

Nom des Base de données

À chaque fois ou on ajoute une base de données dans notre serveur il faut l’ajouter ici

Se connecter en tant qu’administrateur