Delphix Products

we are moving to out of place patching and one shortcoming of the Oracle process is that we have to manually move the listener.ora file to the new home. We are also clearing tech-debt where we have old homes.

What we need to do is verify that an oracle home deinstall is not removing an active listener configuration - when we run lsnrctl status listener on a delphix host, it does NOT include the parameter file location in the information 

review of Oracle Database Service Listener Registration and Oracle Service Names (KBA5885) - Delphix seems to indicate it should be there. What we need to know if how to verify the source of the oracle listener configuration to avoid having listeners broken because we lose the config file/info.

Hi Ray.
What Oracle version are you running?
Can you provide the output of the lnsrctl command as executed by the Delphix OS user in the database host?

On a side note, if you are moving to out of place patching you may want to consider having a centralised TNS configuration and define TNS_ADMIN. This way you don't have to move your listener configuration files around after patching.
Obviously this complicates a bit the Delphix configuration but it should be a one off.

we are moving to out of place patching and one shortcoming of the Oracle process is that we have to manually move the listener.ora file to the new home. We are also clearing tech-debt where we have old homes.

What we need to do is verify that an oracle home deinstall is not removing an active listener configuration - when we run lsnrctl status listener on a delphix host, it does NOT include the parameter file location in the information 

review of Oracle Database Service Listener Registration and Oracle Service Names (KBA5885) - Delphix seems to indicate it should be there. What we need to know if how to verify the source of the oracle listener configuration to avoid having listeners broken because we lose the config file/info.

we are running 19.22 currently (waiting on 23 GA release)

I have compared the results of running lsnrctl status on both delphix and non-delphix and the big difference is that missing parameter value:

From non-delphix: 

STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 19.0.0.0.0 - Production
Start Date                21-MAY-2024 13:54:11
Uptime                    63 days 18 hr. 10 min. 15 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /opt/oracle/19_a/grid/network/admin/listener.ora
Listener Log File         /opt/oracle/base/diag/tnslsnr/...
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=LISTENER)))

From Delphix: 

Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 19.0.0.0.0 - Production
Start Date                23-JUL-2024 10:17:00
Uptime                    0 days 21 hr. 49 min. 21 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Log File         /opt/oracle/base/diag/tnslsnr/ensdxn2ah19/l....
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=...
Services Summary...

Note the second set of values does not include any parameter entry (not even a blank one). 

I did a test by renaming the only listener.ora file I found on the host (in a different home than the listener was started) and restarted lsnr - while it restarted, I could not connect, once it finished, I reconnected fine - so it seems to imply that is not the file in use BUT I still don't know where if finds the file or if it uses values from the db

Hi Ray.
What Oracle version are you running?
Can you provide the output of the lnsrctl command as executed by the Delphix OS user in the database host?

On a side note, if you are moving to out of place patching you may want to consider having a centralised TNS configuration and define TNS_ADMIN. This way you don't have to move your listener configuration files around after patching.
Obviously this complicates a bit the Delphix configuration but it should be a one off.

we are moving to out of place patching and one shortcoming of the Oracle process is that we have to manually move the listener.ora file to the new home. We are also clearing tech-debt where we have old homes.

What we need to do is verify that an oracle home deinstall is not removing an active listener configuration - when we run lsnrctl status listener on a delphix host, it does NOT include the parameter file location in the information 

review of Oracle Database Service Listener Registration and Oracle Service Names (KBA5885) - Delphix seems to indicate it should be there. What we need to know if how to verify the source of the oracle listener configuration to avoid having listeners broken because we lose the config file/info.

Hello ray.

This is not a Delphix issue, it is an Oracle expected behaviour. The Delphix database is not defined in the RAC you seem to be using for the non-Delphix database hence it will automatically register itself in the listener that is found in the Oracle Home Delphix is using to run the database. If there is no listener.ora file in the OH there is no file to reference and the database will simply register in the default listener present in the system, typically the main IP and port 1521.
If you were to add a listener.ora file in the correct Oracle home, the lsnrctl status command should show it.

we are running 19.22 currently (waiting on 23 GA release)

I have compared the results of running lsnrctl status on both delphix and non-delphix and the big difference is that missing parameter value:

From non-delphix: 

STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 19.0.0.0.0 - Production
Start Date                21-MAY-2024 13:54:11
Uptime                    63 days 18 hr. 10 min. 15 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /opt/oracle/19_a/grid/network/admin/listener.ora
Listener Log File         /opt/oracle/base/diag/tnslsnr/...
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=LISTENER)))

From Delphix: 

Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 19.0.0.0.0 - Production
Start Date                23-JUL-2024 10:17:00
Uptime                    0 days 21 hr. 49 min. 21 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Log File         /opt/oracle/base/diag/tnslsnr/ensdxn2ah19/l....
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=...
Services Summary...

Note the second set of values does not include any parameter entry (not even a blank one). 

I did a test by renaming the only listener.ora file I found on the host (in a different home than the listener was started) and restarted lsnr - while it restarted, I could not connect, once it finished, I reconnected fine - so it seems to imply that is not the file in use BUT I still don't know where if finds the file or if it uses values from the db

Hi Ray.
What Oracle version are you running?
Can you provide the output of the lnsrctl command as executed by the Delphix OS user in the database host?

On a side note, if you are moving to out of place patching you may want to consider having a centralised TNS configuration and define TNS_ADMIN. This way you don't have to move your listener configuration files around after patching.
Obviously this complicates a bit the Delphix configuration but it should be a one off.

we are moving to out of place patching and one shortcoming of the Oracle process is that we have to manually move the listener.ora file to the new home. We are also clearing tech-debt where we have old homes.

What we need to do is verify that an oracle home deinstall is not removing an active listener configuration - when we run lsnrctl status listener on a delphix host, it does NOT include the parameter file location in the information 

review of Oracle Database Service Listener Registration and Oracle Service Names (KBA5885) - Delphix seems to indicate it should be there. What we need to know if how to verify the source of the oracle listener configuration to avoid having listeners broken because we lose the config file/info.

------------------------------
ray breitenbach
Database Engineer
Paychex, Inc.
------------------------------

Hi Ray.
What Oracle version are you running?
Can you provide the output of the lnsrctl command as executed by the Delphix OS user in the database host?

On a side note, if you are moving to out of place patching you may want to consider having a centralised TNS configuration and define TNS_ADMIN. This way you don't have to move your listener configuration files around after patching.
Obviously this complicates a bit the Delphix configuration but it should be a one off.

we are moving to out of place patching and one shortcoming of the Oracle process is that we have to manually move the listener.ora file to the new home. We are also clearing tech-debt where we have old homes.

What we need to do is verify that an oracle home deinstall is not removing an active listener configuration - when we run lsnrctl status listener on a delphix host, it does NOT include the parameter file location in the information 

review of Oracle Database Service Listener Registration and Oracle Service Names (KBA5885) - Delphix seems to indicate it should be there. What we need to know if how to verify the source of the oracle listener configuration to avoid having listeners broken because we lose the config file/info.