GotoDBA How Things Work Listener Registration Explained

Listener Registration Explained

Why do We Need Listener Registration?

In Oracle environment, we have a special component that listens to network requests to connect and pass them on to the instance. This is the listener, of course. We need to remember that a single listener can serve several instances, and a single instance can be served by several listeners. So in order to do its job, the listener needs to know all the instances it serves.
The information the listener needs is the SID and ORACLE_HOME of the instance. With this information we can connect users to the instance and create server processes if needed.
The process in which the listener gets to know the instance is called registration. If you know the concept of services in Oracle, it is also related, but that is a different story.
If we try to connect to an instance, which the listener does not know, we will get the following error:
ORA-12514: TNS:listener does not currently know of service requested in connect descriptor.
There are 2 ways to perform the registration process:

  1. Static registration – this is the older way, but it is still in use.
  2. Dynamic registration – a newer way and much more versatile.

Static Registration

Using this method, we manually configure to the listener which instances it serves. The static configuration is done in the listener.ora which is under the ORACLE_HOME/network/admin directory. This file has 2 parts, one starts with the listener name and has information about the addresses that listener listens on. The other starts with SID_LIST_<listener_name> (where <listener_name> is the name of the listener), and it includes information about the static registration.
Example:

LISTENER =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = server)(PORT = 1521))
  )
SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (ORACLE_HOME = C:\oracle\product\10.2.0\db_1)
      (SID_NAME = db10)
    )
  )

From this listener.ora file we can see that we have one listener, it listens on all IP addresses of the server at port 1521. Also, the listener knows of (statically) an instance names db10 whose ORACLE_HOME is C:\oracle\product\10.2.0\db_1.

Dynamic Registration

Using this method, running instances perform the registration automatically, without any listener.ora configuration. The process responsible for the registration is PMON, it contacts the listener and updates it with the instance name, ORACLE_HOME and status.
By default, the PMON contact the listener on the local server as the instance at port 1521 to perform the registration. If we wish the instance to register on a different listener (e.g. listener running on a different port), we’ll have to change the LOCAL_LISTENER parameter in the init.ora or spfile of the instance. The parameter should include a reference to the desired listener in one of 2 ways:

  • Full details, e.g. (ADDRESS=(PROTOCOL=TCP)(HOST=hostname)(PORT=1530))
  • ora entry, e.g. listener_1530 while the tnsnames.ora has an entry called listener_1530 which directs to the correct listener

The parameter is dynamic, so you can change it on the fly by the “alter system” command. PMON will de-register from the old listener and register to the new one.

When do We Need to Set Non-default Dynamic Registration?

The 2 most common scenarios are:

  1. We changed the listener port as part of hardening or anything else.
  2. We have several listeners on the server and we need to set which instance will be registered to which listener. If we use static listeners for that, it will work, except that all instances will be registering to the default listener as well (if there is such). In order to solve this we’ll have to change their dynamic registration.

Pros and Cons

In practice, both methods are simple to implement and works just fine. However, there are several differences:

  • With dynamic registration, PMON is the one who register the instance. So if the instance is down, no registration will be made. Even when the instance is in nomount, the listener will block access to it. If we need the ability to remotely connect to the instance when it’s down or in nomount in order to start it or maintain it, we will have to add static registration.
  • With dynamic registration, PMON is periodically updating the listener with its registration status. The advantage here is that we can add data such as workload. This is irrelevant for a single instance, but in RAC it is very important and used by the listener for load balancing.
  • To work with services we need to use dynamic registration.

Summary

There are 2 methods to register an instance in the listener, static registration and dynamic registration. We can work with one of them or both of them combined. Remember that in order to work with static registration we need to edit and maintain the listener.ora file, and in order to work with dynamic registration we need to set the LOCAL_LISTENER parameter. Another thing to remember is that the default for dynamic registration is to register to the listener running on the local host, listening on port 1521.
Hope you enjoyed.
Liron

1 thought on “Listener Registration Explained”

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Post