今天用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)
|
1 2 3 4 5 6 7 |
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：
|
1 2 3 4 5 |
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配置不正确，也会无法实现动态注册）
|
1 2 3 4 5 6 |
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
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
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)