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 :
1 |
ORA-12514: TNS:listener does not currently know of service requested in connect descriptor |
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 :
1 2 3 4 5 6 7 8 9 10 11 12 13 |
INSTANCE_TEST = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS=(PROTOCOL=TCP)(HOST=test-server.example.com)(PORT=1529)) ) ) SID_LIST_INSTANCE_TEST = (SID_LIST = (SID_DESC =</span> (SID_NAME = TEST) (ORACLE_HOME = /oracle/product/db_1) ) ) |
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 :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
ORACLE:/home/oracle $ lsnrctl status INSTANCE_TEST LSNRCTL for Linux: Version 11.2.0.3.0 - Production on 02-APR-2013 09:17:58 Copyright (c) 1991, 2011, Oracle. All rights reserved. Connecting to (DESCRIPTION=(address=(protocol=tcp)(host=test-server.example.com)(port=1529))) STATUS of the LISTENER ------------------------ Alias INSTANCE_TEST Version TNSLSNR for Linux: Version 11.2.0.3.0 - Production Start Date 02-APR-2015 09:02:55 Uptime 0 days 0 hr. 15 min. 2 sec Trace Level off Security ON: Local OS Authentication SNMP OFF Listener Parameter File /oracle/product/db_1/network/admin/listener.ora Listener Log File /oracle/diag/tnslsnr/db-test-r1/INSTANCE_TEST/alert/log.xml Listening Endpoints Summary... (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=test-server.example.com)(PORT=1529))) Services Summary... Service "TEST" has 1 instance(s). Instance "TEST", status UNKNOWN, has 1 handler(s) for this service... The command completed successfully |
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 :
1 2 3 4 5 6 |
(DESCRIPTION = (ENABLE = BROKEN) (LOAD_BALANCE = YES) (ADDRESS = (PROTOCOL = TCP) (HOST = test-server.exemple.com) (PORT = 1529)) (CONNECT_DATA = (SID = TEST)) ) |
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 :
1 2 3 4 5 6 |
(DESCRIPTION = (ENABLE = BROKEN) (LOAD_BALANCE = YES) (ADDRESS = (PROTOCOL = TCP) (HOST = test-server.exemple.com) (PORT = 1529)) (CONNECT_DATA = (SERVICE_NAME = TEST_DG)) ) |
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.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
INSTANCE_TEST = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS=(PROTOCOL=TCP)(HOST=test-server.example.com)(PORT=1529)) ) ) SID_LIST_INSTANCE_TEST = (SID_LIST = (SID_DESC = (SID_NAME = TEST) (ORACLE_HOME = /oracle/product/db_1) ) (SID_DESC = (GLOBAL_NAME = TEST_DG) (ORACLE_HOME = /oracle/product/db_1) ) ) |
Suite à cette configuration et au redémarrage du listener, nous devrions avoir le résultat suivant :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
ORACLE:/home/oracle $ lsnrctl status INSTANCE_TEST LSNRCTL for Linux: Version 11.2.0.3.0 - Production on 02-APR-2013 09:17:58 Copyright (c) 1991, 2011, Oracle. All rights reserved. Connecting to (DESCRIPTION=(address=(protocol=tcp)(host=test-server.example.com)(port=1529))) STATUS of the LISTENER ------------------------ Alias INSTANCE_TEST Version TNSLSNR for Linux: Version 11.2.0.3.0 - Production Start Date 02-APR-2015 09:02:55 Uptime 0 days 0 hr. 15 min. 2 sec Trace Level off Security ON: Local OS Authentication SNMP OFF Listener Parameter File /oracle/product/db_1/network/admin/listener.ora Listener Log File /oracle/diag/tnslsnr/db-test-r1/INSTANCE_TEST/alert/log.xml Listening Endpoints Summary... (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=test-server.example.com)(PORT=1529))) Services Summary... Service "TEST_DG" has 1 instance(s). Instance "TEST", status UNKNOWN, has 1 handler(s) for this service... Service "TEST" has 1 instance(s). Instance "TEST", status UNKNOWN, has 1 handler(s) for this service... The command completed successfully |
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 :
1 |
ORA-12514: TNS:listener does not currently know of service requested in connect descriptor |
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.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
ORACLE:/home/oracle $ lsnrctl status INSTANCE_TEST LSNRCTL for Linux: Version 11.2.0.3.0 - Production on 02-APR-2013 09:17:58 Copyright (c) 1991, 2011, Oracle. All rights reserved. Connecting to (DESCRIPTION=(address=(protocol=tcp)(host=test-server.example.com)(port=1529))) STATUS of the LISTENER ------------------------ Alias INSTANCE_TEST Version TNSLSNR for Linux: Version 11.2.0.3.0 - Production Start Date 02-APR-2015 09:02:55 Uptime 0 days 0 hr. 15 min. 2 sec Trace Level off Security ON: Local OS Authentication SNMP OFF Listener Parameter File /oracle/product/db_1/network/admin/listener.ora Listener Log File /oracle/diag/tnslsnr/db-test-r1/INSTANCE_TEST/alert/log.xml Listening Endpoints Summary... (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=test-server.example.com)(PORT=1529))) The listener supports no services The command completed successfully |
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 :
1 |
SQL> ATLER SYSTEM REGISTER |
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.
Très bon article merci à vous