编辑手记：本文介绍12C中一些新的等待事件，大家有更多发现或者总结的欢迎留言或者在大讲堂群交流讨论。

作者简介：何剑敏 

Oracle ACS华南区售后团队，首席技术工程师。多年从事第一线的数据库运维工作，有丰富项目经验、维护经验和调优经验，专注于数据库的整体运维。

今天用swingbench加载数据的时候，发现了一些之前没有看过的等待事件，列举一下：

（1）LGWR worker group idle

这是因为12c默认是以adaptive方式启用scalable lgwr，即会在自动的在 single<-->scalable 之间进行切换，参考文章末尾的知识补充。

设置 alter system set “_use_single_log_writer”=true scope=spfile; 之后，即可恢复到12c之前的模式，从而不再有LGWR worker group idle等待。

（2）lreg timer

12c有一个新的进程LREG：

LREG (Listener Registration Process) Registers the instance with the listeners。在12c之前，是有pmon将数据库注册到listener中（动态注册，大约需要60秒的时间才会注册进去，除非alter system register）。

而在12c之后，将有lreg进程来做这个事情。当instance启动的时候，lrge进程会轮询listener是否已经启动，如果已经启动就将数据库的信息注册到listener中。如果listner还没有启动，轮询就会间隔大约每3000毫秒检查一次。strace的结果可以看到：epoll_wait(7, {}, 1024, 3000)

注：还会去读/proc/loadavg，猜测可能在资源消耗高的情况下，延缓注册database到listener：

也还会读/etc/hosts文件（所以如果hosts配置不正确，也会无法实现动态注册）

oracle把listener动态注册从pmon独立出来，让新进程lreg来做动态注册这个事情，我们可以看到：

1. 动态注册的时间短了，原来60秒，现在3秒

2. pmon减轻了压力，注册的事情有lreg进程来完成。

（3）heartbeat redo informer

官方文档的描述如下：

可以看到，原来在11g中，有arch进程来做dataguard的heartbeat检测，在12c中，也多出来TMON和TTnn进程来做dataguard之间的gap检测和心跳检测。

但是这个进程，不管是否启用dataguard，都会存在。当没有dataguard的时候，他就处于heartbeat redo informer这个空闲等待了

注：TMON进程是Redo Transport Process monitor，是async模式下用来监控redolog和standby redolog之间的同步关系，TTnn是TMON派生出来的slave进程

参考：
New Idle Events are Erroneously Listed in STATSPACK Report (Doc ID 1998538.1)
New Background Processes In 12c (Doc ID 1625912.1)

补充知识

在12c之前的行为，LGWR主线程负责redo strand的读取，而由spawn出来的thread来模拟异步IO进行redo的写入，然后由main thread通知FG进程而结束log file sync的等待。（可以看到第0个lwp的CPU占据比其他几个lwp稍高。）

12c中有了scalable lgwr的功能，LGWR作为主进程做协调工作，具体的事情有slave进程LGnn来做。LGWR负责保证redo是按照顺序写入的，而slave LGnn根据LGWR的指示来进行redo strand的读取和redo的磁盘写入，并且由LGnn来直接通知FG进程写入完成而结束log file sync的等待。

1. lgwr的子进程lgnn，适用在多CPU的系统中，Oracle由参数_use_single_log_writer控制，（默认值是adaptive，另外还有true和false），当设置为默认值adaptive，会根据系统负载，自动的调节是single log writer还是scalable log writer。调节的时候，在lgwr的trace文件中可以看到：

2. LGnn的最多个数，有_max_outstanding_log_writes决定。

3. Dataguard的SYNC模式不能用到multiple LGWR属性

LGnn (Log Writer Worker) On multiprocessor systems, LGWR creates worker processes to improve the performance of writing to the redo log.

LGWR workers are not used when there is a SYNC standby destination. Possible processes include LG00-LG99.

参考：New Background Processes In 12c (Doc ID 1625912.1)

4. 存在 scheduling delay for the slaves。

在single instance中，high priority和highest priority都没有放LGWR；在RAC中，high priority中有放LGWR，但是没有LG*，可能会导致LGWR虽然有较高优先级，但是子进程没有较高优先级。所以，可能需要设置和lgwr一样priority的lgwr slave进程 。

参考Bug 20055279 : RAC PERF: LGWR CHOOSES TO USE SCALABLE LGWR BUT SINGLE LGWR PERFORMS BETTER

5. multiple LGWR适合多CPU的系统，特别是CPU高于64个以上的系统。

我个人猜测是一方面在scalable lgwr情况下，lgwr起到协调者的作用，协调的时候需要消耗CPU进行计算。另外一方面，多个子进程之间也需要CPU资源进行同步信息，以保证其写的顺序。

LGWR workers are used when using a single LGWR would perform better. This applies to small systems (<= 64 cpus).

参考Bug 20055279 : RAC PERF: LGWR CHOOSES TO USE SCALABLE LGWR BUT SINGLE LGWR PERFORMS BETTER 

6. LGnn进程之间会进行同步.

我想这也是为什么能保证写redo log的时候，保证其一致性的原因。有的时候，LGnn之间不必要的同步，会导致性能变慢。 This means there will be unneeded LGWR slaves in each group and we will incur intra group synchronization costs for these. 

参考 Bug 18683889 : SIGNIFICANT WAIT ON ''LGWR INTRA GROUP SYNC" WITH SCALABLE LGWR

7. 在AIX和HPIA环境中，启用scalable lgwr还可能导致数据库起不来，需要提前打好patch 21915719(注：打完patch 21915719之后，_use_single_log_writer=true就自动设置好了。) 

参考 ALERT: Bug 21915719 Database hang or may fail to OPEN in 12c IBM AIX or HPUX Itanium - ORA-742, DEADLOCK or ORA-600 [kcrfrgv_nextlwn_scn] ORA-600 [krr_process_read_error_2] (Doc ID 1957710.1) 

注意，这个文档已经变成ALERT类型，说明已经发生过比较多的问题。一般ALERT文档都是值得注意的预警性文档。

文章转自数据和云公众号，