Access to Network Services in Oracle Database - Oracle DBA

What is a listener?
Listener is a process that resides on the Oracle server whose responsibility is to listen for incoming client connection requests and manage the traffic to the server.

- By default, the listener name is (amazingly enough) “listener” (but you can call it anything you like). It listens for connection requests on a particular port (the default port number in 8.0 and above is 1521, but once again, you can set 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 (for example, you can opt to install a “names server”, which does the same job of telling the client where to find the listener).

- Upon receiving a connection request from a client, the listener can do one of two things. Either it will spawn a new server process, and redirect the client to talk directly to that server process… at which point, the listener drops out of the picture altogether, and continues to listen for connection requests from other clients. This is known as ‘bequeathing’ the server process to the client, in the sense of ‘making a gift’ –and the client is then said to have a bequeath session.

- Or it will inform the client of the network address of a server process which has already been created when the instance was started (a “pre-spawned server process), and the client is then able to make direct contact with that server process. Note again, however, that once the connection is established between the client and the server process, the listener simply continues to listen for new connection requests. This is known as ‘redirecting’ the client to the server process, and hence the client is said to have a redirect session. The only real difference between bequeath and redirect sessions is that, in theory, it takes longer to set up a bequeath session (the server process has to be created from scratch, for a start). However, the drawback with redirect sessions is that you have to pre-spawn a bunch of server process and hope that enough clients want to connect to make them useful… overdo it, and you just have a lot of processes chewing up memory and CPU cycles for no particular reason.

- Whatever type of session you end up with, though, it’s important to realise that the Listener is merely instrumental in establishing the connection; once established, the listener plays no further part in client-server communications. It is, therefore, possible to kill a listener, and no existing user would be any the wiser.

- The above description applies only to dedicated server configurations, where each user is connected directly to one server process that does nothing but service that user’s requests. It is also possible, however, to configure Oracle in what is known as multi-threaded server configuration (now known in 9i, more accurately, as “shared server configuration”). The only real difference this makes to the listener is that, upon receiving a client connection request, the listener redirects the connection to a dispatcher process, several of which are pre-spawned at instance startup. Yet again, however, once the client connection is established, the listener plays no further role in the communications process and continues to listen for new requests

- A single listener process can listen out for client connection requests on a variety of different networking protocols (such as tcp/ip, ipx/spx, Appletalk and so on). A single listener can also listen out on multiple ports for a single protocol (for example, port 1521 for tcp/ipan d port 1526 for tcp/ip) –but there are additional configuration issues when you use anything other than the default port of 1521 for tcp/ip connections (the short story is that local_listener must be set in the init.ora of the instance using the non- default port address).