When running Oracle Database on a server, the Oracle Net Listener is a vital component.

Let’s discuss how you can patch it.

The Basics

Normally, on a server, you have:

• One listener
• One or many database instances

That one listener handles new connections to all database instances. You patch the listener simply by starting it in the new Oracle home.

You can have multiple listeners and use remote listeners, but if you do that, you’re smart and probably won’t need the advice in this blog post.

How to Patch the Listener

1. Copy listener.ora from the old Oracle home to the new Oracle home.

   export OLD_ORACLE_HOME=/u01/app/oracle/product/19.26.0/dbhome_1
   export NEW_ORACLE_HOME=/u01/app/oracle/product/19.27.0/dbhome_1
   cp $OLD_ORACLE_HOME/network/admin/listener.ora $NEW_ORACLE_HOME/network/admin
   

   • You can avoid this step by redirecting the location of your network files using the TNS_ADMIN environment variable.
   • If you have a completely default installation with no listener configuration, you don’t have a listener.ora file and can skip this step.
   • In an advanced configuration you might have references to the listener Oracle home. Those you must update. But don’t confuse the listener Oracle home, with the Oracle homes of the databases with static registration. Those you update, when you patch the matching database.
2. Restart the listener in the new Oracle home:

   export ORACLE_HOME=$OLD_ORACLE_HOME
   $OLD_ORACLE_HOME/bin/lsnrctl stop
   export ORACLE_HOME=$NEW_ORACLE_HOME
   $NEW_ORACLE_HOME/bin/lsnrctl start 
   

   • If you use Oracle Grid Infrastructure or Oracle Restart, they manage the listener. You automatically restart, and thus patch, the listener when you patch those components.
3. If you use the dbstart script to start the listener, update it with the new Oracle home.
   • On Windows, you must delete the matching Windows service when you stop the listener. The lsnrctl start command should create a new listener. Be sure to set it to start automatically.

The Outage

• When you restart the listener, there’s a short period where there’s no listener. It takes a second or so for the new listener to start. In that period, any new connection attempt fails:

  ORA-12541: TNS:no listener
  

  This affects new connections only. Existing connections continue to work unaffected.

• As soon as the listener starts, it’ll read listener.ora and go through the static listener registrations defined by the SID_LIST. Connections to those databases are ready immediately.

• For optimal flexibility, however, it’s better to use dynamic listener registration, where the database instance automatically registers with the listener. When you restart the listener, it doesn’t know of all the dynamic registrations and will have to wait until the database registers (up to 60 seconds).

  • You can force a database to register with the listener:

    SQL> alter system register;
    

  • It’s a good idea to run through all of your databases after the listener restart and force a listener registration with the above command.
  • Until the dynamic registration completes, any new connection to the database will fail:

    ORA-12514: TNS:listener does not currently know of service requested in connect descriptor
    

• You can hide the short outage from the client by using RETRY_COUNT and RETRY_DELAY in your connect strings. Allow the client to retry for a short period before throwing the above errors.

• You can avoid the outage completely by using multiple listeners and patching them separately. Your connect strings should have an ADDRESS_LIST containing both listeners.

Do I Need to Patch the Listener and Database At the Same Time?

No, that’s up to you. If you want just one interruption, then do it all at once. Otherwise, you can do it in separate maintenance windows.

What About AutoUpgrade?

At the moment, AutoUpgrade doesn’t patch the listener. But it’s on the backlog.

Happy patching!