Sorry really bad pun there...
This is some info about how we went from multiple listeners to just one per box and how we got cloud control to recognise this new single listener.
For a while now we've had 1 listener per database, this seems to have been setup historically as some kind of 'logical separation' or supposed security enhancement but has become an admin nightmare. When you have up to 10 listeners per box working out which ones should be running and which ones belong to which database is painful. Box reboots especially so as we have no oracle restart and no automated listener/database start in place (we're looking at oracle restart at the moment as this should improve it - and before you say its deprecated it's not. They deprecated the deprecation - seriously....)
Anyway back to the listeners, each listener was on a separate port with it's own lines of config in the listener.ora. What we did was convert to a single listener (called listener) which is listening on all the ports configured for the databases. So one listener can serve all the database and respond on all ports that are opened through the firewall. This makes admin and maintenance much easier.
So rather than having
LISTENER1 =
(DESCRIPTION_LIST = (DESCRIPTION =(ADDRESS = (PROTOCOL = TCP)(HOST = host)(PORT = 1521))
)
)
LISTENER2 =
(DESCRIPTION_LIST = (DESCRIPTION =(ADDRESS = (PROTOCOL = TCP)(HOST = host)(PORT = 1522))
)
)
LISTENER3 =
(DESCRIPTION_LIST = (DESCRIPTION =(ADDRESS = (PROTOCOL = TCP)(HOST = host)(PORT = 1523))
)
)
LISTENER4 =
(DESCRIPTION_LIST = (DESCRIPTION =(ADDRESS = (PROTOCOL = TCP)(HOST = host)(PORT = 1524))
)
)
We have
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = host)(PORT = 1521))
)
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = host)(PORT = 1522))
)
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = host)(PORT = 1523))
)
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = host)(PORT = 1534))
)
)
So now to stop and start listening for the whole box we just say
lsnrctl stop / lsnrctl start
rather than
lsnrctl stop listener1 /lsnrctl start listener1
etc......
That all went find and we seamlessly switched the listeners over. Switching the listeners does not drop any existing connections (unless you used shared servers) it just stops new connections while the switch is being done.
OK so now we made this transformation we need to update cloud control to just have one listener. However one other thing we changed proved to make things a little difficult as you will see (that 'thing' was to move the listener.ora file to /etc it's not tied to any one oracle home)
Anyway - here is what we did to try and discover the listener via the normal process through cloud control.
First of all go to setup -> add target -> configure auto discovery
don't fall in to the trap of thinking you want to select 'Oracle database,listener and ASM' as there is not a lot you can do after clicking the spanner icon (seemingly only specify a clusterware home)
What you actually need to select is the spanner at the end of all discovery modules -shown below
Here highlight the host you want to force discovery on (auto discovery runs once per day)
once it's run then click run discovery now to get it to check for the new single listener.
setup -> add target ->auto discovery results
And it's just found the original listeners again (we didn't remove the config files from the oracle homes) but no sign of the new one. (only 2 listed in the pic above though it had found all 4).
So what's gone wrong - why didn't it find it?
The autodiscovery output is logged in the emagent_perl.trc in the sysman/log directory on the agent directoryof the host. Lets see what is mentioned there. There are a few lines related to the discovery but no error and no mention of the config file in /etc.
Lets try increasing the log level and see if that tells us any more
cd $ORACLE_HOME/sysman/config
vi emd.properties
Now add the lines shown below (comment out any other trace level for this component)
############################################################################
########################### Modifiable Properties ##########################
############################################################################
#
#
#### Tracing related properties
#
#
# emagent perl tracing levels
# supported levels: DEBUG, INFO, WARN, ERROR
# default level is WARN
#
EMAGENT_PERL_TRACE_LEVEL=DEBUG
EMAGENT_PERL_TRACE_FILESIZE=5120
Now get the agent to re-read the config (no restart required)
emctl reload agent
OK lets now check that log again. There is more info but still no mention of the reason for it missing the error.
Hmmmm
From the debug log i can see that the script the agent is running is called oracledb.pl
Lets find that and see what it is actually doing
A quick find from the agent home and we can find the file (choose the one for the plugin you are using)
In my case thats:
$AGENT_HOME/plugins/oracle.sysman.db.discovery.plugin_12.1.0.5.0/discover/oracledb.pl
Looking into this file (and my perl is not brilliant) I stumble across this section
#If there are no TNS errors and listener is running
#using the passed tnsAdminDir, check the log and trace directory for OH
if ($result !~ /^.*TNS-[0-9]*/i && isThisListenerRunning($result,$tnsAdminDir,$name))
{
EMD_PERL_DEBUG("$LOG_CATEGORY $name is running from $tnsAdminDir");
my @resultArray = split /\n/, $result;
Aha!
So it seems TNS_ADMIN might be required - lets give that a try...
export TNS_ADMIN=/etc
emctl stop agent
emctl start agent
Now lets run that forced discovery again and see what happens...
And it finds it!
we then click promote and we can see it is the correct one
However there is something now changed on this screen to when I've done this previously - see the zoomed in section below - some global properties are now mandatory...
I can only assume this has become mandatory as i created some 'Administration groups' which make use of some of these properties - but that's for another post as I'm still investigating it.
Anyway - i fill in some values and now the listener is correctly added - job done!
Comments
Post a Comment