The Listener

Networking Tips

What is a Listener?
The Listener is a named process which runs on the Oracle Server, awaiting 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 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 its running on, and the port its 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, its 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 Users 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
Copyright Howard Rogers 2002 3/4/2002 Page 1 of 2

The Listener

Networking Tips

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/IP and 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 nondefault port address). A single Listener process is also perfectly capable of listening for connection requests to any number of Instances. In other words, if your machine happens to be hosting 3 instances, you dont need three different Listeners. On the other hand, its legitimate to create additional Listeners if the number of client requests to your various Instances is so high that you are at risk from Listener contention problems (where a single Listener just cant keep up with the rate of connection requests). Listeners are created and configured using a text file, called listener.ora, details of which are included in my tip How do I create a Listener?. This file can be edited at any time, but changes you make to it have no effect until the Listener is stopped and re-started. Starting and stopping the Listener is most easily done by using a command-line utility, called LSNRCTL (Listener Control) - and again, further details are included in the tip What tools do I use to manage a Listener. I should perhaps mention that it is possible to connect to an Instance without a Listener running at all but it requires you to be making the connection directly on the machine hosting the Instance. By setting the ORACLE_SID environment variable, and then simply issuing a connect username/password request (i.e., a connection string with no Instance name specified), you are able to make a direct connection to the Instance using what is known as the IPC (Inter-Process Communication) protocol. This is a valid approach for Database Administrators, but its not exactly useful for ordinary users: remote connections across a network must always go via a Listener.

Copyright Howard Rogers 2002

3/4/2002

Page 2 of 2