Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.



Published on

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

  • Be the first to comment

  • Be the first to like this


  1. 1. The Listener Networking TipsWhat is a Listener?The Listener is a named process which runs on the Oracle Server, awaiting requests fromClients 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 theListener (the machine it’s running on, and the port it’s listening on) because a localconfiguration file, called “tnsnames.ora”, gives it the necessary information. Moreadvanced configurations can dispense with the tnsnames.ora (for example, you can opt toinstall a “Names Server”, which does the same job of telling the client where to find theListener).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 thatServer Process… at which point, the Listener drops out of the picture altogether, andcontinues 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 theclient is then said to have a Bequeath Session.Or it will inform the client of the network address of a Server Process which has alreadybeen created when the Instance was started (a “pre-spawned Server Process), and theclient 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, theListener 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 aRedirect Session.The only real difference between Bequeath and Redirect sessions is that, in theory, ittakes longer to set up a Bequeath session (the Server Process has to be created fromscratch, for a start). However, the drawback with Redirect Sessions is that you have topre-spawn a bunch of Server Process and hope that enough clients want to connect tomake them useful… overdo it, and you just have a lot of processes chewing up memory andCPU cycles for no particular reason.Whatever type of session you end up with, though, it’s important to realise that theListener is merely instrumental in establishing the connection; once established, theListener plays no further part in client-server communications. It is therefore possible tokill a Listener, and no existing User would be any the wiser.The above description applies only to Dedicated Server configurations, where each User isconnected 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 ServerConfiguration (now known in 9i, more accurately, as “Shared Server Configuration”). TheCopyright © Howard Rogers 2002 3/4/2002 Page 1 of 2
  2. 2. The Listener Networking Tipsonly real difference this makes to the Listener is that, upon receiving a client connectionrequest, the Listener redirects the connection to a Dispatcher Process, several of whichare pre-spawned at Instance Startup. Yet again, however, once the client connection isestablished, the Listener plays no further role in the communications process, andcontinues to listen for new requests.A single Listener process can listen out for client connection requests on a variety ofdifferent networking protocols (such as TCP/IP, IPX/SPX, Appletalk and so on). A singleListener can also listen out on multiple ports for a single protocol (for example, port 1521for TCP/IP and port 1526 for TCP/IP) –but there are additional configuration issues whenyou use anything other than the default port of 1521 for TCP/IP connections (the shortstory 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 toany number of Instances. In other words, if your machine happens to be hosting 3instances, you don’t need three different Listeners. On the other hand, it’s legitimate tocreate additional Listeners if the number of client requests to your various Instances is sohigh that you are at risk from ‘Listener contention’ problems (where a single Listener justcan’t keep up with the rate of connection requests).Listeners are created and configured using a text file, called listener.ora, details of whichare 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 Listenerrunning at all… but it requires you to be making the connection directly on the machinehosting the Instance. By setting the ORACLE_SID environment variable, and then simplyissuing a ‘connect username/password’ request (i.e., a connection string with no Instancename specified), you are able to make a direct connection to the Instance using what isknown as the IPC (Inter-Process Communication) protocol. This is a valid approach forDatabase Administrators, but it’s not exactly useful for ordinary users: remote connectionsacross a network must always go via a Listener.Copyright © Howard Rogers 2002 3/4/2002 Page 2 of 2