close
Unix, Linux & Tips

Les tribulations d'un admin sys

Travail

Enregistrement du listener

Image par joffi de Pixabay

Dans cet article, nous allons nous intéresser à la gestion du listener Oracle et notamment aux différents modes d’enregistrement de celui-ci, ainsi que sur leurs significations. Nous verrons également comment résoudre les erreurs liées à celui-ci.

Définition

Le listener est un processus à part entière qui s’exécute sur le serveur de base de données. Celui-ci s’occupe de recevoir la connexion cliente et d’effectuer la connexion à la base de données; une fois que cette connexion a eu lieue, le listener n’est plus utilisé pour communiquer avec cette connexion.

La question soulevée est donc la suivante :
Comment le listener sait sur quelle instance (que ce soit par nom ou service) il doit transférer la connexion cliente?

Nous analyserons également les problèmes de listener qui proviennent généralement de l’erreur suivante :

Nous détaillerons donc, les deux modes de fonctionnement de cet outillage, ainsi que leurs configurations et mise en place respectives, à savoir :

  • Enregistrement Statique
  • Enregistrement Dynamique

Enregistrement Statique

  • Par l’instance :

L’enregistrement statique s’effectue en incluant la section SID_LIST dans le fichier de configuration listener.ora.

Prenons par exemple, le fichier de configuration suivant :

Comme on peut le voir, nous avons ici une section qui se nomme SID_LIST_INSTANCE_TEST qui dit au listener que le nom de la base de données (SID_NAME) est “TEST“. Si nous regardons maintenant le status du listener, nous verrons le résultat suivant :

Le résultat de la commande entraînant “Instance “TEST”, status UNKNOWN” signifie bien que l’instance TEST est bien enregistrée sur le listener INSTANCE_TEST.

Essayons maintenant de comprendre pourquoi le statut est en “UNKNOWN“. Tout simplement, car le listener n’est pas capable de savoir si la base de données est ouverte et exploitable ou non. Il n’existe pas de moyen qui permette de garantir si l’instance est bien existante. Le listener va donc partir du principe que la base de données est présente et fonctionnelle quand une connexion client sera effectuée.

Voici un extrait de mon fichier tnsnames.ora :

Nous voyons que nous avons “SID=TEST” dans notre chaîne de connexion. Et, puisque mon SID/instance est enregistrée avec mon listener, mes connexions sont possibles avec la base de données (bien sûr, pour cela il faut utiliser le bon nom d’hôte et de numéro de port).

  • Par le service :

Dans le cas où nous voudrions utiliser un service, voici un extrait du fichier tnsnames.ora :

Si l’on veut se connecteur à la base de données en utilisant la définition vu ci-dessus (SERVICE_NAME), il est obligatoire que le service soit enregistré dans le listener. La méthode pour effectuer cette configuration de manière statique est la suivante, il faut utiliser le paramètre “GLOBAL_DBNAME=<SERVICE_NAME>” dans le fichier listener.ora et ainsi relancer le service.

Suite à cette configuration et au redémarrage du listener, nous devrions avoir le résultat suivant :

Souvenez-vous que dans une configuration statique, vous devez avoir un nom d’instance dans la section SID_LIST du fichier listener.ora spécifiée par SID_NAME=TEST. Si, vous décidez d’utiliser un SERVICE_NAME configuré en tant qu’alias TNS (fichier tnsnames.ora ou autre), il faut vous assurer qu’en cas d’enregistrement statique ces service_names sont bien intégrés dans le fichier listener.ora spécifiés par GLOBAL_DBNAME=TEST_DG.

Remarque :
Si nous supprimons la section SID_LIST de notre fichier listener.ora, le listener continuera de fonctionner. Toutefois, lorsque nous effectuerons une vérification, le message suivant apparaîtra : “The listener supports no services“. Si vous essayez de vous connecter à votre base de données, l’erreur suivante surviendra :

Cette erreur est présente car, l’instance n’est pas enregistrée avec le listener. Donc, “TEST” n’est qu’un processus standalone qui s’exécute sur la machine hôte avec aucune instance enregistrée, il ne peut donc transférer aucune connexion à la base de données. Aucune connexion n’est alors possible.

Enregistrement Dynamique

  • Par l’instance :

La question que l’on peut légitimement se poser est la suivante : A-t-on besoin d’avoir une section SID_LIST dans notre fichier listener.ora? Et bien, la réponse est non. Ce pré-requis n’est plus obligatoire depuis Oracle 9i et la mise en place de l’enregistrement dynamique. Avec ce mode de fonctionnement, la base de données enregistre automatiquement les instances et services sur les ports du listener.

Si nous utilisons le port par défaut du listener (1521), la base de données enregistrera automatiquement l’instance avec le listener.

Lors de l’exemple ci-dessus, nous remarquons que le listener n’est pas enregistré sur la base de données. Pour se faire, il faut redémarrer la base de données, car lors du démarrage de celle-ci, un enregistrement sera fait sur le listener par défaut.

Toutefois, même si un arrêt / relance peut résoudre ce problème, une autre commande peut permettre d’effectuer cette opération sans pour autant arrêter la base de données. Il s’agit de la commande suivante :

Suite à cette commande, le processus PMON est capable de mettre en contact le listener et l’enregistrer sur l’instance.

Conclusion

Nous avons vu au cours de cet article comment vérifier si une base de données et son listener sont correctement configurés. Toutefois, nous n’avons pas expliqué les principes liés au paramétrage du local_listener (sur l’enregistrement dynamique). Ce qui fera l’objet d’un autre article (lié notamment au DG_BROKER). Nous conseillons dans tous les cas, de bien renseigner le fichier listener.ora, ce qui entraînera beaucoup moins d’erreurs aussi bien dans le cas d’un enregistrement statique, que d’un enregistrement dynamique.

Tags : databasedbalisteneroraclesql
Emmanuel V.

The author Emmanuel V.

Un commentaire

Leave a Response

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.