Debugage serveur dédié, conseils et astuces

Oracle Database crée des processus de serveur pour traiter les demandes des processus utilisateur connectés à une instance. Un processus serveur peut être l’un des éléments suivants :

Un processus de serveur dédié, qui ne dessert qu’un seul processus utilisateur.

Votre base de données est toujours activée pour permettre les processus de serveur dédié, mais vous devez configurer et activer spécifiquement le serveur partagé en définissant un ou plusieurs paramètres d’initialisation.

Processus de serveur dédié

Dans le jargon utilisé pour le dépannage serveur dédié , “Oracle Database Dedicated Server Processes”, illustre le fonctionnement des processus de serveur dédié. Dans ce schéma, deux processus utilisateur sont connectés à la base de données par le biais de processus de serveur dédié. En général, il est préférable d’être connecté via un répartiteur et d’utiliser un processus de serveur partagé. Ceci est conduit au  “Processus de serveur partagé de la base de données Oracle”. Un processus de serveur partagé peut être plus efficace car il maintient le nombre de processus requis pour l’instance en cours d’exécution à un faible niveau.

À propos des processus de serveur dédiés et partagés

Toutefois, dans les situations suivantes, les utilisateurs et les administrateurs doivent se connecter explicitement à une instance en utilisant un processus de serveur dédié : Pour soumettre un travail par lot (par exemple, lorsqu’un travail peut permettre peu ou pas de temps d’inactivité pour le processus serveur). Pour utiliser Recovery Manager (RMAN) pour sauvegarder, restaurer ou récupérer une base de données. Pour demander une connexion à un serveur dédié lorsque la base de données Oracle est configurée pour un serveur partagé, les utilisateurs doivent se connecter en utilisant un nom de service net qui est configuré pour utiliser un serveur dédié. Plus précisément, la valeur du nom de service net doit inclure la clause SERVER=DEDICATED dans le descripteur de connexion.

Processus de serveurs partagés

Prenons l’exemple d’un système de saisie des commandes avec des processus de serveur dédié. Un client téléphone au bureau des commandes et passe une commande, et l’employé qui prend l’appel entre la commande dans la base de données. Pendant la majeure partie de la transaction, l’employé est au téléphone et parle au client. Un processus serveur n’est pas nécessaire pendant cette période, et le processus serveur dédié au processus utilisateur de l’employé reste inactif. Le système est plus lent pour les autres employés qui entrent des commandes, car le processus serveur inactif accapare les ressources du système. Dans une configuration de serveur partagé, les processus utilisateurs clients se connectent à un répartiteur. Le répartiteur peut prendre en charge plusieurs connexions client simultanément. Chaque connexion client est liée à un circuit virtuel, qui est un morceau de mémoire partagée utilisé par le répartiteur pour les demandes de connexion à la base de données client et les réponses. Le répartiteur place un circuit virtuel dans une file d’attente commune lorsqu’une demande arrive.

Un processus serveur partagé inactif récupère le circuit virtuel dans la file d’attente commune, répond à la demande et renonce au circuit virtuel avant de tenter de récupérer un autre circuit virtuel dans la file d’attente commune. Cette approche permet à un petit groupe de processus de serveur de servir un grand nombre de clients. Un avantage important de l’architecture de serveur partagé par rapport au modèle de serveur dédié est la réduction des ressources du système, ce qui permet de prendre en charge un nombre accru d’utilisateurs.

Pour une gestion encore plus efficace des ressources, le serveur partagé peut être configuré pour la mise en commun des connexions. La mise en commun des connexions permet à un répartiteur de prendre en charge un plus grand nombre d’utilisateurs en permettant au serveur de base de données de temporiser les connexions au protocole et d’utiliser ces connexions pour servir une session active. En outre, le serveur partagé peut être configuré pour le multiplexage de session, qui combine plusieurs sessions pour la transmission sur une seule connexion réseau afin de conserver les ressources du système d’exploitation. L’architecture de serveur partagé nécessite Oracle Net Services. Les processus utilisateur ciblant le serveur partagé doivent se connecter via Oracle Net Services, même s’ils se trouvent sur le même système que l’instance de la base de données Oracle.

À propos du Database Resident Connection Pooling

Database Resident Connection Pooling (DRCP) fournit un pool de connexions dans le serveur de base de données pour les scénarios d’utilisation typiques des applications Web dans lesquels l’application acquiert une connexion à la base de données, l’utilise pendant une durée relativement courte, puis la libère. DRCP met en commun des serveurs “dédiés”. Un serveur mutualisé est l’équivalent d’un processus de premier plan du serveur et d’une session de base de données combinés.

DRCP complète les pools de connexion de middle-tier qui partagent les connexions entre les threads d’un processus de middle-tier. En outre, DRCP permet le partage des connexions de base de données entre les processus middle-tier sur le même hôte middle-tier et même entre les hôtes middle-tier. Il en résulte une réduction significative des ressources clés de la base de données nécessaires à la prise en charge d’un grand nombre de connexions client, ce qui réduit l’empreinte mémoire de la couche de base de données et améliore l’évolutivité des couches intermédiaire et de base de données. Le fait de disposer d’un pool de serveurs facilement disponibles présente également l’avantage de réduire les coûts de création et de suppression des connexions client. Voir https://geneve.news/category/informatique/ pour en savoir plus !

 

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.

*

code