Tracing listener dynamic service registration

Service registration with Oracle listener allows processes to identify their available services to the listener, which then acts as a port mapper for those services. The listener uses the dynamic service information about the database and instance received through service registration.

Dynamic service registration is configured in the database initialization file. It does not require any configuration in the listener.ora file. However, listener configuration must be set to listen on the ports named in the database initialization file, and must not have parameters set that prevent automatic registration, such as COST (a class of secure transports) parameters (for example, DYNAMIC_REGISTRATION_listener_name set to ‘off’ in listener.ora file will disable dynamic service registration)

The class of secure transports (COST) parameters (optional) specify a list of transports that are considered secure for administration and registration of a particular listener. The COST parameters identify which transports are considered secure for that installation and whether the administration of a listener requires secure transports.

  • SECURE_REGISTER_listener_name
  • DYNAMIC_REGISTRATION_listener_name
  • SECURE_PROTOCOL_listener_name
  • SECURE_CONTROL_listener_name

I wrote another post that one possible reason for dynamic service registration could fail if IPC protocol is used, but different keys are defined in the listener.ora file and in the database parameter local_listener. Even with other protocols like TCP, settings (e.g, port used 1521 by default) needs to be matched between the file listener.ora and parameter local_listener (for local registration) .

Some times if you cannot find the reason causing failure of dynamic registration, you can still register it manually:

SQL> alter system register;

System altered.

Before 12c, dynamic registration is done by PMON. Since 12c, there is a new process LREG which is responsible for this.

[oracle@joetest admin]$ ps -ef|grep -i lreg
oracle     39549       1  0 08:53 ?        00:00:00 ora_lreg_PROD

You can even trace this process. Before 19c, you can do

alter system set events='immediate trace name listener_registration level 3';

But 19c has a different action name LREG_STATE, the command above will give you the errors ORA-49101 and ORA-49102:

SQL> alter system set events='immediate trace name listener_registration level 3';
alter system set events='immediate trace name listener_registration level 3'
*
ERROR at line 1:
ORA-49101: Failed to parse action [LISTENER_REGISTRATION]
ORA-49102: Action definition for [LISTENER_REGISTRATION] not found

And you need to use the following commands:

alter system set events 'trace[LREG] disk highest';
alter system set events = 'immediate trace name LREG_STATE level 3';

SQL> SELECT VALUE FROM V$DIAG_INFO WHERE NAME = 'Diag Trace';

VALUE
--------------------------------------------------
/opt/oracle/diag/rdbms/PROD/trace

[oracle@joetest trace]$ ls -lart /opt/oracle/diag/rdbms/PROD/trace/*lreg*

-rw-r-----. 1 oracle oinstall 186816 Apr  6 11:24 /opt/oracle/diag/rdbms/PROD/trace/PROD_lreg_2160.trm
-rw-r-----. 1 oracle oinstall 725272 Apr  6 11:24 /opt/oracle/diag/rdbms/PROD/trace/PROD_lreg_2160.trc

LREG_STATE is one of oradebug event actions. You can see all actions with:

SQL>  oradebug doc event action

Actions in library DIAG:
---------------------------
evfunc                - Get posting function name
evfile                - Get posting file name
evline                - Get posting file line number as ub8
.
.
.
SQL> oradebug doc event action LREG_STATE
LREG_STATE
        - Dump listener registration state
Usage
-------
LREG_STATE( level           <ub4> default '1')

Some other handy commands to get more event information from oradebug:

SQL> oradebug help

SQL> oradebug doc

Internal Documentation
**********************

  EVENT                           Help on events (syntax, event list, ...)
  COMPONENT       [<comp_name>]   List all components or describe <comp_name>

SQL> oradebug doc event

SQL> oradebug doc event name

SQL> oradebug doc event action

SQL> oradebug doc component

You might see the abbreviation UTS when playing with oradebug and tracing. It stands for Unified Tracing Servcie. For example:

SQL> oradebug doc event name trace

trace: Main event to control UTS tracing

Usage
-------
trace [ component       <string>[0] ]
   disk            < default | lowest | low | medium | high | highest | disable >,
   memory          < default | lowest | low | medium | high | highest | disable >,
   get_time        < disable | default | seq | highres | seq_highres >,
   get_stack       < disable | default | force >,
   operation       <string>[32],
   function        <string>[32],
   file            <string>[32],
   line            <ub4>,
   conuid          <ub4>

References:

  1. https://docs.oracle.com/en/database/oracle/oracle-database/21/netrf/database-net-services-reference.pdf
  2. https://www.orafaq.com/papers/oradebug.pdf
  3. http://www.soocs.de/public/talk/181120_DOAG2018_Kernel_Debug_Diagnostics_Tracing_Infrastructure_PPT.pdf

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s