Featured Database Articles

Static Registration and the Oracle 12.2 Listener

By David Fitzjarrell

In earlier versions of the Listener, Oracle has been more forgiving with static registrations; with 12.2 that seems to have changed as static registrations, if not configured completely, can cause the listener to dump a core file in the directory where the listener process was started. What can make this even more confusing is that dynamic registrations are not affected. And to add to all of this, having databases down when starting the listener doesn't 'fix' the problem because the listener isn't connecting to a running database, it's trying to resolve library paths for static declarations. Let's look at how static registrations can be written to avoid this.

Static registrations for TCP connections are the 'problem' with the 12.2 listener (from personal experience) when they stop short of configuring the library path for the given database and home. A typical static TCP registration can look like this:

Even up to release 12.1.0.2 the listener would appear to 'pick up' the necessary environment settings and find the associated libraries in the given ORACLE_HOME; in 12.2.0.1 this seems to have changed, which causes the core file to be generated for Oracle databases not using the same home as the running listener. This can be a problem if your site has a dedicated home for the listener to run from since no databases will be running from that home. And not knowing that static registrations are at fault the core file generation will be a mystery.

The solution to this is fairly simple and has been available in listener configurations for many releases. Taking the configuration shown above it can be modified to provide the 'missing' information the listener needs by adding the ENVS configuration parameter for each static database registration:

Related Articles

A simple change but it may be unfamiliar to some DBAs who have never configured a listener outside of NETCA. Of course, simply changing the listener.ora doesn't fix anything in a currently running listener as it will need to be reloaded to make the changes effective:

If your listener is named LISTENER (the default naming provided by NETCA) then a simple:

lsnrctl reload

is all that's necessary. It is good practice, however, to supply the listener name every time one performs maintenance on a listener, so the correct listener is affected. Not doing so may result in no actual reload taking place as the current lsnrctl executable won't 'know' which LISTENER to reload on systems where multiple Oracle installations exist. In situations where LISTENER is not the name of the running listener (it may be LISTENER_BOB, LISTENER_TURNIP or even LISTENER_POODLE) there won't be any listener to act upon.

Every static registration can have its own ENVS setting; in installations involving multiple Oracle versions all using a single listener it's perfectly legal to have each ENVS entry specify a different lib location:

[This may not be obvious to DBAs not familiar with static configurations created by writing or editing a listener.ora file.]

Sometimes the most confusing issues can have the simplest of solutions; fortunately for listener static configurations this is the case as it only requires the addition of the ENVS parameter to provide the information the listener process was missing. This is of course, covered in the Oracle on-line documentation (for several releases) which makes a good reason to have such documentation bookmarked in the browser.