Go Back > Common DBA Misconceptions

User login

Frontpage Sponsor


As a Customer What would do to keep your ERP Implementation intact
Proactively define Business Process-- Take the Project Ownership
Handover everything to System Integrator from drawing BP till implementation of ERP
Hire more inhouse skilled & capable IT Resource to work directly with SI
Rely on SI Architects/Consultants
Total votes: 4

Baanboard at LinkedIn

Reference Content

Book Navigation

General Practices: Listeners must be started before the instance
By patvdv at 23 Feb 2008 - 22:10

The idea that the instance and the listeners must be started in a certain order probably stems from the way that PMON registers MTS dispatchers with listeners. When an instance is started, at the time that the database is opened, PMON attempts to register the MTS dispatchers with any listener on the localhost's port 1521, and/or any listeners specified in the MTS initialization parameters. If a listener is not started, then there is nothing for PMON to register the dispatchers with.


The common misconception is that the only time dispatcher registration can occur is at database open time. In fact, after the database is open, PMON attempts to register dispatchers, or perform a service update, periodically. This means that if the listener is started after the instance, PMON will soon perform a service update and registration will be successful. This behavior can be observed by looking for the service update string in the listener logs. These messages will appear every minute or so when PMON is idle, and less frequently when PMON is busy.


In many environments, DBAs prefer to start listeners after the database instance because their applications bombard the listeners with large numbers of connections, and compete for system resources during database startups. Unfortunately, if such systems rely on MTS to prevent excessive resource consumption during normal operation, they become flooded with dedicated server connection until PMON can get around to performing dispatcher registration. There are several satisfactory solutions to this problem. Net8 allows the use of a SERVER=SHARED attribute in the client's tnsnames.ora, which will force connections to establish only if an MTS service handler is available on the listener. With this parameter enabled, the listener will not attempt to establish dedicated server processes for all these incoming connections. From the point of view of the client applications, the database service becomes available only when the dispatchers have been registered with the listeners.


An alternative to using SERVER=SHARED is to start the listeners when the database is in mount mode. If a startup script first starts the database up MOUNT, then starts the listeners, then opens the database, the instance startup won�t have to compete with the listeners for resources as large numbers of shared servers and job queue processes are being forked.


Finally, a new feature introduced in Oracle9i allows on-demand registration of the dispatchers with the listener. This also provides better support for brief listener restarts during normal operations. Because a listener reload is insufficient to make a variety of changes, it is sometimes necessary to fully restart the listener. It is highly preferable to be able to make such a change without causing undue interruption in service. With on-demand dispatcher registration, it is no longer necessary to wait around for PMON to register dispatchers after a listener restart. The lack of such a feature in earlier versions of Oracle has resulted in no small amount of frustration while clients fail on connect to a database whose PMON can't seem to get around to doing the next service update.


No votes yet

All times are GMT +2. The time now is 16:10.

©2001-2018 - -