oracle数据库管理-12C新特性等待事件

（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等待。

[root@rac02 bin]# ps -ef|grep lg
grid     600974      1  0 13:33 ?        00:00:00 asm_lgwr_+ASM2
oracle   601556      1  0 13:33 ?        00:00:00 ora_lgwr_orcl2
oracle   601560      1  0 13:33 ?        00:00:00 ora_lg00_orcl2
oracle   601564      1  0 13:33 ?        00:00:00 ora_lg01_orcl2
oracle   601568      1  0 13:33 ?        00:00:00 ora_lg02_orcl2
oracle   601576      1  0 13:33 ?        00:00:00 ora_lg03_orcl2
oracle   601584      1  0 13:33 ?        00:00:00 ora_lg04_orcl2
oracle   601588      1  0 13:33 ?        00:00:00 ora_lg05_orcl2
root     624177 596085  0 14:10 pts/1    00:00:00 grep --color=auto lg
[root@gzrac02 bin]# 

（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配置不正确，也会无法实现动态注册）

[root@rac02 bin]# ps -ef|grep lreg
grid     600980      1  0 13:33 ?        00:00:00 asm_lreg_+ASM2
grid     601188      1  0 13:33 ?        00:00:00 apx_lreg_+APX2
oracle   601574      1  0 13:33 ?        00:00:00 ora_lreg_orcl2
root     625328 596085  0 14:12 pts/1    00:00:00 grep --color=auto lreg
[root@gzrac02 bin]# 

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

1. 动态注册的时间短了，原来60秒，现在3秒
2. pmon减轻了压力，注册的事情有lreg进程来完成。

（3）heartbeat redo informer

select sid, b.SPID, a.EVENT
  from v$session a, v$process b
 where a.PADDR = b.ADDR
   and a.EVENT like '%heart%';

select name,pid,role from v$dataguard_process;

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

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

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

[root@rac02 bin]# ps -ef|grep tmon
oracle   601750      1  0 13:33 ?        00:00:00 ora_tmon_orcl2
root     626219 596085  0 14:13 pts/1    00:00:00 grep --color=auto tmon
[root@gzrac02 bin]# 

oracle   601854      1  0 13:33 ?        00:00:00 ora_tt01_orcl2
oracle   601863      1  0 13:33 ?        00:00:00 ora_tt02_orcl2

补充知识：

在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决定。

select ksppinm,ksppdesc,ksppstvl from x$ksppi a,x$ksppsv b where a.indx= b.indx
and a.ksppinm like '%outstanding_log%';

select name,pid,role from v$dataguard_process;

3. Dataguard的SYNC模式不能用到multiple LGWR属性 12C出现sync affrim模式。

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文档都是值得注意的预警性文档。