oracle foreign key primary key constraints performance tuning MTS IOT 9i block size backup rman corrupted column drop rename recovery controlfile backup clone architecture database archives export dump dmp duplicate rows extents segments fragmentation hot cold blobs migration tablespace locally managed redo undo new features rollback ora-1555 shrink free space user password link TNS tnsnames.ora listener java shutdown sequence

1. 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 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
Copyright © Howard Rogers 2002 3/4/2002 Page 1 of 2

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 non-
default 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 don’t need three different Listeners. On the other hand, it’s 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
can’t 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 it’s 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