Oracle listener does not restart because port 1521 is not released fast enough after stop

Question

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

Answer 1

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.