【12c新特性】多LGWR进程SCALABLE LGWR “_use_single_log_writer”

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

_use_single_log_writer = true

 

 

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 传输的。

 

关注dbDao.com的新浪微博

扫码关注dbDao.com 微信公众号:

Speak Your Mind

TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569