Skip to Content

Introduction

This blog post is just a short note about an architectural change in the instance / listener registration process starting with Oracle 12c. I noticed this change by testing some Oracle RAC 12c features, which do not work properly at first (which was my fault due to some misconfiguration). Basically my issue was about database service registration in the SCAN listeners and the corresponding quality of service.

I enabled the registration trace as usual (prior 12c) by setting event “immediate trace name listener_registration” and tried to figure out what happens with PMON in detail, but the PMON trace file did not include any information at all. After browsing through other process trace files i found the needed information in the LREG trace file.

Official Oracle documentation

Listener Registration Process (LREG)

The listener registration process (LREG) registers information about the database instance and dispatcher processes with the Oracle Net listener (see “The Oracle Net Listener”). When an instance starts, LREG polls the listener to determine whether it is running. If the listener is running, then LREG passes it relevant parameters. If it is not running, then LREG periodically attempts to contact it.

Note: In releases before Oracle Database 12c, PMON performed the listener registration.

Ok, here we go. I stumbled over a simple RTFM issue. Funny to notice, that Oracle did not change this in the whole Oracle 12c R1 documentation consequently as some graphics still include the PMON process (e.g. The Oracle Net Listener).

Demo

The following demo was run on an Oracle database (12.1.0.1.0) on OEL 6.4.


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






shell> $ADR_HOME/rdbms/t12db/T12DB/trace/T12DB_lreg_1728.trc
Start Registration Information
------------------------------
Last update: 429599631 (10 seconds ago)
Flag: 0x4, 0x0
State: succ=1, wait=0, fail=0
Non-CDB: root pdb 0 last pdb 0 open max pdb 0
Listeners:
  0 - (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=OEL)(PORT=1523))(CONNECT_DATA=(SERVICE_NAME=T12DB))) pdb 0
       state=1, err=0
       nse[0]=0, nse[1]=0, nte[0]=0, nte[1]=0, nte[2]=0
       ncre=0
       endp=(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=OEL)(PORT=1523)))
         flg=0x80000000 nse=0
Instance: T12DB
  flg=0x0, upd=0x8
  info=(INF=(HOST=oel)(REGION=)(DB_NAME=)(VINST_NAME=))
  node load=133, max=15360
  inst load=1, max=474
Services:
  0 - T12DB
       flg=0x4, upd=0x6, pdb=0
       goodnes=0, delta=1
  1 - T12DBXDB
       flg=0x5, upd=0x6, pdb=0
       goodnes=0, delta=1
Handlers:
  0 - Dedicated
       flg=0x80002002, upd=0x2
       services=T12DB
       hdlr load=44, max=299
Dispatcher Handlers:
  0 - D000(1)
       addr=(ADDRESS=(PROTOCOL=tcp)(HOST=OEL)(PORT=15233))
       inf=DISPATCHER <machine: OEL, pid: 1734>
       flg=0x1004, upd=0x0
       services=T12DBXDB
       hdlr load=0, max=1022
CMON Handlers:
CMON Handlers for Listener Networks:
Listen Endpoints:
  0 - (DESCRIPTION=(ADDRESS=(PROTOCOL=tcps)(HOST=OEL)(PORT=5500))(Security=(my_wallet_directory=/oracle/admin/T12DB/xdb_wallet))(Presentation=HTTP)(Session=RAW))
       flg=0x80000000, nse=0, lsnr=, lflg=0x13
       pre=HTTP, sta=0
----------------------------
End Registration Information
----------------------------








Summary

I searched for an explanation after i have noticed that behavior change and found a valid one in book “Expert Oracle RAC 12c” by Syed Jaffar Hussain, Tariq Farooq, Riyaj Shamsudeen and Kai Yu.

In version 11.2, if there are numerous services (100+) and numerous listeners, then there is a possibility that the PMON process might spend more time on service registration to listeners due to the sheer number of services and listeners. But, in version 12c, this possibility is eliminated as the LREG parameter performs service registration and PMON is freed from listener registration.

This explanation makes sense in such environments as PMON is responsible for some other critical tasks as well.

The process monitor (PMON) monitors the other background processes and performs process recovery when a server or dispatcher process terminates abnormally. PMON is responsible for cleaning up the database buffer cache and freeing resources that the client process was using. For example, PMON resets the status of the active transaction table, releases locks that are no longer required, and removes the process ID from the list of active processes.

If you have any further questions – please feel free to ask or get in contact directly, if you need assistance by troubleshooting Oracle database (performance) issues.

References

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply