0

I'm running Oracle 11g on a Windows 2012R2 server. For some reason we have some code that try to restart the listener and then perform a connection. This code has been working for years on many different servers but on one particular server, the listener cannot restart.

Here is the error found in the listener.log file when the listener tries to restart:

Started with pid=5132
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(PIPENAME=\\.\pipe\EXTPROCipc)))
Error listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=thehostname)(PORT=1521)))
TNS-12542: TNS:address already in use
 TNS-12560: TNS:protocol adapter error
  TNS-00512: Address already in use
   64-bit Windows Error: 48: Unknown error
No longer listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(PIPENAME=\\.\pipe\EXTPROCipc)))

I've managed to reproduce the issue using this command:

net stop OracleOraDb11g_home1TNSListener && net start OracleOraDb11g_home1TNSListener

If I modify the command line like this:

net stop OracleOraDb11g_home1TNSListener && sleep 30 && net start OracleOraDb11g_home1TNSListener

The listener restarts correctly.

I suppose that the port 1521 is not released fast enough after stop, but I don't know how to fix it.

For information here is the content of the listener.ora file:

SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (SID_NAME = PLSExtProc)
      (ORACLE_HOME = C:\somepath\database\product\11.2.0\dbhome_1)
      (PROGRAM = extproc)
    )
    (SID_DESC =
      (GLOBAL_DBNAME = somevalue)
      (SID_NAME = somevalue)
    )
  )

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS_LIST =
        (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))
      )
      (ADDRESS_LIST =
        (ADDRESS = (PROTOCOL = TCP)(HOST = thehostname)(PORT = 1521))
      )
    )
  )

LOGGING_LISTENER=on
VALID_NODE_CHECKING_REGISTRATION_LISTENER=on
5
  • Leave the listener running, wouldn't that be an option? Sep 24, 2020 at 9:07
  • That's one of the options, but the guy who wrote this code has retired 2 years ago, I guess he had a good reason to do that, but I do not know what it was.
    – StephaneM
    Sep 24, 2020 at 9:29
  • His reason may no longer apply. The only reason why I had to stop and start the listener (after a year) was because someone forgot to hook up the battery that starts the generator. Sep 24, 2020 at 10:04
  • I've known a listener on an old Solaris, that stopped working every couple of months. A badly designed application with an onslaught of connections. My guess was some counter that reached its maximum. I had cron restart it once a month an we heard no more of it. Sep 24, 2020 at 11:27
  • @MichaelKutz Quis custodiet ipsos custodes? Sep 24, 2020 at 11:35

1 Answer 1

0

This is Working As Designed™.

TCP socket lifecycle is managed by the TCP stack outside the database process(es), asynchronously, and involves various delays when transitioning between states. It's entirely conceivable that on a fast machine the listener will terminate and start back up within few milliseconds, faster than the socket is fully released.

Since you have no control over the TCP stack logic, your only alternative solution is, in my view, to introduce a slight delay before starting the listener (as you already did). You may not need the full 30 seconds; try smaller values.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.