Noteworthy changes in Oracle RAC 18c and 19c

 

Customers monitoring Oracle RAC Databases running on Oracle 18c, Oracle19c with the latest RUs will notice the following changes. These are documented here for information only and there is no manual action to be taken.

New RS process

$ps -ef |grep rs00 |grep -v grep
S oracle 438809   1 0 20 19 0  - 64439 964916 pipe_wait     18:09 ?    00:00:00 oracle+ASM1_rs00_anair1 

Starting with Oracle 18c and higher releases, RMV process has been renamed to RS. RS process helps LMS* processes during remastering. Please refer to my blog post for more details on remastering. Information about the new rs00 process is currently missing from the Oracle documentation as of today (22-Nov-2019). The documentation is planned to be updated in the next refresh cycle, until then the current description of RMV processes in the documentation can be used to understand the functionality of RS process.

LMS is not running in Higher Priority

Customers may notice that the LMS* processes are not running in high priority mode. For example, in Oracle RAC 12c, ps command shows that LMS process is running in "RR" mode

$ ps -o user,pid,cls,priority,cmd -e |grep -v grep|egrep '^USER|lms'|grep -v ASM 

USER       PID CLS PRI CMD
racusr   12912  RR  -2 ora_lms0_acct2

While in Oracle RAC 19c, the same Oracle RAC 19c LMS process is running in "TS" mode

$ ps -o user,pid,cls,priority,cmd -e |grep -v grep |egrep '^USER|lms'|grep -v ASM
USER       PID CLS PRI CMD
racusr   341887  TS  20 ora_lms0_V19c1
racusr   341889  TS  20 ora_lms1_V19c1
racusr   341891  TS  20 ora_lms2_V19c1

However checking the Oracle Database alert log shows that the LMS was indeed started in higher priority

LMS0 started with pid=24, OS id=341887 at elevated (RT) priority

This discrepancy is caused due to a change in the architecture whereby Oracle RAC LMS process now runs as multiple threads. The command therefore to get the details of individual threads and their scheduling class is

$ps -eLo user,pid,cls,priority,cmd -e |grep -v grep |grep 'lms'|grep -v ASM

USER      PID   CLS  PRI  CMD
racusr   341887  TS  20 ora_lms0_V19c1
racusr   341887  RR  -2 ora_lms0_D19c1
racusr   341887  TS  20 ora_lms0_D19c1
racusr   341887  TS  20 ora_lms0_D19c1
racusr   341889  TS  20 ora_lms1_D19c1
racusr   341889  RR  -2 ora_lms1_D19c1
racusr   341889  TS  20 ora_lms1_D19c1
racusr   341889  TS  20 ora_lms1_D19c1
racusr   341891  TS  20 ora_lms2_D19c1
racusr   341891  RR  -2 ora_lms2_D191c
racusr   341891  TS  20 ora_lms2_D19c1
racusr   341891  TS  20 ora_lms2_D19c1

Lot more information about LMS process can be found in My Oracle Support Note 558185.1 **(requires login)

USM processes

It was a coincidence that during my visit to a customer site, I was asked about these processes. Incidentally, Liron also reached out to me that same evening to ask about these USM processes. The following ps command can be used to see the details of these processes as shown below.

ps -ef |grep -i USM
root      6931     2  0 Sep30 ?        00:00:02 [UsmGeneral]
root      6932     2  0 Sep30 ?        00:00:02 [UsmGeneral]
root      6933     2  0 Sep30 ?        00:01:49 [UsmMonitor]
root      6934     2  0 Sep30 ?        00:00:02 [UsmGeneral]
root      6939     2  0 Sep30 ?        00:00:02 [UsmGeneral]
root      6943     2  0 Sep30 ?        00:00:02 [UsmGeneral]
root      7333     2  0 Sep30 ?        00:00:00 [USM:RD:02]
root      7335     2  0 Sep30 ?        00:00:00 [USM:RD:01]
root      7337     2  0 Sep30 ?        00:01:49 [UsmMonitor]
root      7338     2  0 Sep30 ?        00:00:00 [USM:RD:00]
root      7340     2  0 Sep30 ?        00:00:00 [usmfqp1]
root      7341     2  0 Sep30 ?        00:00:00 [usmfqp0]
root      7343     2  0 Sep30 ?        00:01:47 [UsmMonitor]
root      7358     2  0 Sep30 ?        00:00:00 [USM:RD:03]
root      7374     2  0 Sep30 ?        00:00:00 [USM:RD:04]
...
...
root      7665     2  0 Sep30 ?        00:00:00 [USM:WR:29]
root      7666     2  0 Sep30 ?        00:00:00 [USM:WR:30]
root      7667     2  0 Sep30 ?        00:00:00 [USM:WR:31]

These processes are created for various functions in the ACFS, ADVM and OKS driver layer. They are created on demand, generally idle and only intervene during specific events. There is no user action needed at this time. Also note that the USM processes are not involved in the Oracle RAC Global Cache Management, I added this section here so there is a centralized location for changes that customers can refer to while working with Oracle RAC Database.