Listener listens to new connections who is trying to connect to DB server. If the listener goes down, new users would not be able to connect to DB server. But still, already connected users would be able to do their work normally.
Listener waiting requests from Clients to connect to the Instance. By default, the Listener name is (amazingly enough)“Listener” (but you can call it anything you like). It listens for connection requests on aparticular port (the default port number in 8.0 and above is 1521, but once again you canset this to any valid port number if you wish). A client knows where to contact the Listener (the machine it’s running on, and the port it’s listening on) because a local configuration file, called “tnsnames.ora”, gives it the necessary information. More advanced configurations can dispense with the tnsnames.ora .
How to Register Listener In Database
1.) Static Instance Registration
2.) Dynamic Instance Registration
Lets Discuss These Method and Start With Static Instance Registration :
Its basic method , and use $ORACLE_HOME\NETWORK\ADMIN\listener.ora its look like
LISTENER =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = xx.xx.xx.xx)(PORT = 1521))
)
And When You Fire lsnrctl status , instance Name Appear with Unknown like the following :
Service “orcl” has 1 instance(s).
Instance “orcl”, status UNKNOWN, has 1 handler(s) for this service…
Service “orcl” has 1 instance(s).
Instance “orcl”, status UNKNOWN, has 1 handler(s) for this service…
The command completed successfully
The status is unknown because there is no mechanism to guarantee that the specified status even exists.Here the listener assumes that instance will be there whenever there will be any request. It donot have inforamtion about the status of the Current Instance.
Dynamic Instance Registration (service registration):
in this Way the PMON is Responsible about Register Listener ,
Benefit for this way like the following :
1.) Simplified configuration : Service registration reduces the need for the SID_LIST_listener_name parameter setting, which specifies information about the databases served by the listener, in the listener.ora file.
Note : The SID_LIST_listener_name parameter is still required if we are using Oracle Enterprise Manager to manage the database.
2.) Connect-time fail over : Because the listener always knows the state of the instances, service registration facilitates automatic fail over of the client connect request to a different instance if one instance is down.
In a static configuration model, a listener would start a dedicated server upon receiving a client request. The server would later find out that the instance is not up, causing an “Oracle not available” error message.
3.) Connection load balancing : Service registration enables the listener to forward client connect requests to the least loaded instance and dispatcher or dedicated server. Service registration balances the load across the service handlers and nodes. To ensure service registration works properly .
Services Summary…
Service “ORCL” has 1 instance(s).
Instance “ORCL”, status READY, has 1 handler(s) for this service…
Service “ORCLXDB” has 1 instance(s).
Instance “ORCL”, status READY, has 1 handler(s) for this service…
Service “ORCL2” has 1 instance(s).
Instance “ORCL2”, status READY, has 1 handler(s) for this service…
The command completed successfully
To register Database name with listener in this way you could use :
SQL> ALTER SYSTEM REGISTER;
Thank you
Osama Mustafa
Technology Geek 