原文
http://www.askmaclean.com/archives/12cr1-scalable-lgwr-_use_single_log_writer.html
SCALABLE LGWR是12cR1中引入的一个令人激动的特性， 这是由于在OLTP环境中LGWR写日志往往成为系统的主要性能瓶颈， 如果LGWR进程能像DBWR(DBW0~DBWn)那样多进程写出redo到LOGFILE那么就可能大幅释放OLTP的并发能力，增长Transcation系统的单位时间事务处理能力。
在12cR1 中真正用SCALABLE LGWR实现了这个目的， 也可以俗称为多LGWR进程。
select * from opt_12cR1 where name like '%log%' _use_single_log_writer ADAPTIVE Use a single process for redo log writing _max_outstanding_log_writes 2 Maximum number of outstanding redo log writes
SCALABLE LGWR主要受到隐藏参数_use_single_log_writer的控制， 该参数默认值为ADAPTIVE 。
该参数主要有三个可选值 true， false， adaptive， 默认值为ADAPTIVE。
- 对于ADAPTIVE 和False 如果CPU个数大于一个则会有多个lg0n进程
- 对于true 则不会生成多个lg0n进程，而如同12.1之前那样仅有单个LGWR
SQL> show parameter _use_single_log_writer NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ _use_single_log_writer string ADAPTIVE [oracle@maclean1 ~]$ ps -ef|grep lg grid 4344 1 0 08:07 ? 00:00:00 asm_lgwr_+ASM1 oracle 12628 1 0 08:48 ? 00:00:00 ora_lgwr_MAC_1 oracle 12636 1 0 08:48 ? 00:00:00 ora_lg00_MAC_1 oracle 12640 1 0 08:48 ? 00:00:00 ora_lg01_MAC_1 oracle 13206 7447 0 08:51 pts/2 00:00:00 grep lg
可以使用 10468 level 2 来trace adaptive scalable LGWR
[oracle@maclean1 trace]$ oerr ora 10468 10468, 00000, "log writer debug module" // *Document: NO // *Cause: // *Action: Set this event to the appropriate level for log writer debugging. // alter system set events '10468 trace name context forever,level 2'; LGWR TRACE: kcrfw_slave_adaptive_updatemode: time=426523948079110 scalable slave=1 arbiter=3 group0=10678 all=12733 delay=100 rw=98774 single=1973 48 scalable_nopipe=197548 scalable_pipe=108651 scalable=180439 kcrfw_slave_adaptive_savewritecounts: time=426523954275133 group0=10695 all=12752 kcrfw_slave_adaptive_savewritecounts: time=426523954662537 group0=10696 all=12753 CKPT TRACE: *** 2014-12-07 10:52:21.528 kcrfw_slave_adaptive_saveredorate: time=426523941528521 curr=16649627696 prev=16635613056 rate=14014640 avg=14307212 *** 2014-12-07 10:52:24.553 kcrfw_slave_adaptive_saveredorate: time=426523944553556 curr=16664120996 prev=16649627696 rate=14493300 avg=14318490
实际测试可以发现 仅在redo 生成率非常高的环境中SCALABLE LGWR 对于redo写出的吞吐量有所帮助，进而提高OLTP环境的TPS。
_use_single_log_writer = adaptive 2个LG slave进程：
| Per Second | Per Transaction | Per Exec | Per Call | |
|---|---|---|---|---|
| DB Time(s): | 2.8 | 0.0 | 0.00 | 0.33 |
| DB CPU(s): | 2.6 | 0.0 | 0.00 | 0.31 |
| Redo size (bytes): | 8,180,730.6 | 545.6 | ||
| Logical read (blocks): | 46,382.1 | 3.1 | ||
| Block changes: | 60,219.5 | 4.0 |
| Function Name | Reads: Data | Reqs per sec | Data per sec | Writes: Data | Reqs per sec | Data per sec | Waits: Count | Avg Tm(ms) |
|---|---|---|---|---|---|---|---|---|
| LGWR | 1M | 0.14 | .004M | 4.3G | 29.80 | 16.16M | 1785 | 79.10 |
_use_single_log_writer = true 使用single lgwr
| Per Second | Per Transaction | Per Exec | Per Call | |
|---|---|---|---|---|
| DB Time(s): | 2.8 | 0.0 | 0.00 | 0.34 |
| DB CPU(s): | 2.6 | 0.0 | 0.00 | 0.32 |
| Redo size (bytes): | 8,155,843.5 | 545.0 | ||
| Logical read (blocks): | 46,550.1 | 3.1 | ||
| Block changes: | 60,036.7 | 4.0 |
| Function Name | Reads: Data | Reqs per sec | Data per sec | Writes: Data | Reqs per sec | Data per sec | Waits: Count | Avg Tm(ms) |
|---|---|---|---|---|---|---|---|---|
| LGWR | 1M | 0.13 | .003M | 4.8G | 25.49 | 16.141M | 1611 | 95.97 |
相关AWR附件：
_use_single_log_writer = adaptive
LGWR Scalability 的正面积极意义：
12c通过并发辅助进程以及优化的log file写算法有效改善 多CPU环境中由LGWR引起的等待瓶颈，释放LGWR性能。
一般来说这种性能改善在中小型的数据库实例中并不明显，实际上它们主要是为了那些64个CPU或更多CPU可用的数据库实例。但有性能测试报告显示在最少8个CPU的情况下对性能也有改善。
在之前的版本中，单一的LGWR处理所有的redo strands收集redo记录并将其写出到redo logfile中。在Oracle Database 12c中，LGWR开始并协调多个辅助helper进程，并行地完成以前LGWR一个人做的工作。
- LGWR进程变成了多个LGnn形式的helper进程的协调指挥者，并负责保证这一堆并发进程所做的工作仍满足正确的LGWR顺序
- LGnn进程负责读取一个或多个redo strands，负责实际写出到log file以及post前台进程
限制
在Oracle database 12c中，当使用SYNC同步redo传输方式传输redo到standby database时， 不支持使用上述的并行写SCALABLE LGWR，讲返回到串行写的老路子上。 但是Parallel LGWR/SCALABLE LGWR是支持ASYNC异步redo 传输的。