While working on an 11gR1 database server today, I fat-fingered the name of a secondary listener (you know, practicing my stock-trading skills), and in the process I noticed something that I hadn't considered before. Here's the setup:
[oracle@11gr1srv ~]$ cd $DIAG_DIR/tnslsnr/11gr1srv [oracle@11gr1srv 11gr1srv]$ ls listener listener_old [oracle@11gr1srv 11gr1srv]$ lsnrctl start LISTENER_ODL LSNRCTL for Linux: Version 11.1.0.7.0 - Production on 16-MAY-2010 13:09:10 Copyright (c) 1991, 2008, Oracle. All rights reserved. Starting /opt/oracle/app/oracle/product/11.1.0/dbhome_1/bin/tnslsnr: please wait... TNSLSNR for Linux: Version 11.1.0.7.0 - Production System parameter file is /opt/oracle/app/oracle/product/11.1.0/dbhome_1/network/admin/listener.ora Log messages written to /opt/oracle/app/oracle/diag/tnslsnr/11gr1srv/listener_odl/alert/log.xml TNS-01151: Missing listener name, LISTENER_ODL, in LISTENER.ORA Listener failed to start. See the error message(s) above...
It looks like there are more consequences than brief embarrassment for that typo, though. My failed attempt to start the listener created a full Automatic Diagnostic Repository (ADR) directory structure for the non-existent listener:
[oracle@11gr1srv 11gr1srv]$ ls listener listener_odl listener_old [oracle@11gr1srv 11gr1srv]$ ls -R listener_odl listener_odl: alert cdump incident incpkg lck metadata stage sweep trace listener_odl/alert: log.xml listener_odl/cdump: listener_odl/incident: listener_odl/incpkg: listener_odl/lck: AM_1096102193_3488045378.lck AM_1744845641_3861997533.lck AM_1096102262_3454819329.lck AM_3216668543_3129272988.lck listener_odl/metadata: ADR_CONTROL.ams INC_METER_IMPT_DEF.ams ADR_INVALIDATION.ams INC_METER_PK_IMPTS.ams listener_odl/stage: listener_odl/sweep: listener_odl/trace: listener_odl.log
I looked through the Net Services docs, but wasn't able to find a way to disable this behavior, and my Google-fu failed me as well. This only seems to be happening for the 'start' command; other lsnrctl commands (reload, status, stop, etc) just return the expected "TNS-01101: Could not find service name" response.
This sort of thing happens in 10g, too (and probably in older versions, I'm just too lazy to fire up my 9i test system), but the impact is much smaller: a single log file, not all of the ADR stuff that comes with 11g. Even in 11g, it's not a big deal; this just generates some light housecleaning work. At the extreme, I suppose it could be possible to launch the lamest DOS attack ever by chewing up lots of inodes, but there have to be more entertaining (and faster) ways to do that.
