今天用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)

epoll_wait(7, {}, 1024, 3000)           = 0
getrusage(0x1 /* RUSAGE_??? */, {ru_utime={0, 43993}, ru_stime={0, 22996}, ...}) = 0
getrusage(0x1 /* RUSAGE_??? */, {ru_utime={0, 43993}, ru_stime={0, 22996}, ...}) = 0
epoll_wait(7, {}, 1024, 3000)           = 0
getrusage(0x1 /* RUSAGE_??? */, {ru_utime={0, 43993}, ru_stime={0, 23996}, ...}) = 0
getrusage(0x1 /* RUSAGE_??? */, {ru_utime={0, 43993}, ru_stime={0, 23996}, ...}) = 0
epoll_wait(7, {}, 1024, 3000)           = 0

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

open("/proc/loadavg", O_RDONLY)         = 10
fstat(10, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f5f0f198000
read(10, "0.07 0.27 0.25 2/306 3175\n", 1024) = 26
close(10)                               = 0

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

open("/etc/hosts", O_RDONLY|O_CLOEXEC)  = 10
fstat(10, {st_mode=S_IFREG|0644, st_size=169, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f5f0f198000
read(10, "# Do not remove the following li"..., 4096) = 169
read(10, "", 4096)                      = 0
close(10)                               = 0

oracle把listener动态注册从pmon独立出来，让新进程lreg来做动态注册这个事情，我们可以看到：
1. 动态注册的时间短了，原来60秒，现在3秒
2. pmon减轻了压力，注册的事情有lreg进程来完成。

（3）heartbeat redo informer

SQL> l
  1* select sid,spid,event from v$session a,v$process b where a.paddr=b.addr and a.event like '%heart%'
SQL> /

       SID SPID                     EVENT
---------- ------------------------ ----------------------------------------
        20 2152                     heartbeat redo informer

SQL> !ps -ef |grep 2152
54322     2152     1  0 22:35 ?        00:00:00 ora_tt02_ora12c
54322     3486  3448  0 23:13 pts/3    00:00:00 /bin/bash -c ps -ef |grep 2152
54322     3488  3486  0 23:13 pts/3    00:00:00 grep 2152

SQL>
SQL>
SQL> l
  1*   select name,pid,type,role from V$DATAGUARD_PROCESS
SQL> /

NAME  PID                      TYP ROLE
----- ------------------------ --- -----------------------
LGWR  2108                     KSB log writer
TMON  2140                     KSB redo transport monitor
TT00  2148                     KSV gap manager
TT01  2150                     KSV redo transport timer
TT02  2152                     KSV heartbeat redo informer

SQL>

（出自在线文档）

可以看到，原来在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)