Redo log 是用于恢复和一个高级特性的重要数据
一个redo条目包含了相应操作导致的数据库变化的所有信息
所有redo条目最终都要被写入redo文件中去
Redo log buffer是为了避免Redo文件IO导致性能瓶颈而在sga中分配出的一块内存
一个redo条目首先在用户内存(PGA)中产生
然后由oracle服务进程拷贝到log buffer中
当满足一定条件时
再由LGWR进程写入redo文件
由于log buffer是一块
共享
内存
为了避免沖突
它是受到redo allocation latch保护的
每个服务进程需要先获取到该latch才能分配redo buffer
因此在高并发且数据修改频繁的oltp系统中
我们通常可以观察到redo allocation latch的等待
Redo写入redo buffer的整个过程如下
在PGA中生产Redo Enrey > 服务进程获取Redo Copy latch(存在多个CPU_COUNT*) > 服务进程获取redo allocation latch(仅个) > 分配log buffer > 释放redo allocation latch > 将Redo Entry写入Log Buffer > 释放Redo Copy latch;
shared strand
为了减少redo allocation latch等待在oracle 中引入了log buffer的并行机制其基本原理就是将log buffer划分为多个小的buffer这些小的buffer被成为strand(为了和之后出现的private strand区别它们被称之为shared strand)每一个strand受到一个单独redo allocation latch的保护多个shared strand的出现使原来序列化的redo buffer分配变成了并行的过程从而减少了redo allocation latch等待
shared strand的初始数据量是由参数log_parallelism控制的;在g中该参数成为隐含参数并新增参数_log_parallelism_max控制shared strand的最大数量;_log_parallelism_dynamic则控制是否允许shared strand数量在_log_parallelism和_log_parallelism_max之间动态变化
HELLODBACOM>selectnamksppinm valKSPPSTVL namksppdesc
fromsysx$ksppi nam
sysx$ksppsv val
where namindx = valindx
AND namksppinm LIKE _%
AND upper(namksppinm) LIKE %LOG_PARALLE%;
KSPPINMKSPPSTVL KSPPDESC
_log_parallelism Number of log buffer strands
_log_parallelism_max Maximum number of log buffer strands
_log_parallelism_dynamic TRUE Enable dynamic strands
每一个shared strand的大小 = log_buffer/(shared strand数量)strand信息可以由表x$kcrfstrand查到(包含shared strand和后面介绍的private strandg以后存在)
HELLODBACOM>select indxstrand_size_kcrfa from x$kcrfstrand where last_buf_kcrfa != ;
INDX STRAND_SIZE_KCRFA
HELLODBACOM>show parameter log_buffer
NAME TYPEVALUE
log_buffer integer
关于shared strand的数量设置个cpu之内最大默认为当系统中存在redo allocation latch等待时每增加个cpu可以考虑增加个strand最大不应该超过并且_log_parallelism_max不允许大于cpu_count
注意在g中参数_log_parallelism被取消shared strand数量由_log_parallelism_max_log_parallelism_dynamic和cpu_count控制
Private strand
为了进一步降低redo buffer沖突在g中引入了新的strand机制——Private strandPrivate strand不是从log buffer中划分的而是在shared pool中分配的一块内存空间
HELLODBACOM>select * from V$sgastat where name like %strand%;
POOL NAME BYTES
shared pool private strands
HELLODBACOM>select indxstrand_size_kcrfa from x$kcrfstrand where last_buf_kcrfa = ;
INDX STRAND_SIZE_KCRFA
Private strand的引入为Oracle的Redo/Undo机制带来很大的变化每一个Private strand受到一个单独的redo allocation latch保护每个Private strand作为私有的strand只会服务于一个活动事务获取到了Private strand的用户事务不是在PGA中而是在Private strand生成Redo当flush private strand或者commit时Private strand被批量写入log文件中如果新事务申请不到Private strand的redo allocation latch则会继续遵循旧的redo buffer机制申请写入shared strand中事务是否使用Private strand可以由x$ktcxb的字段ktcxbflg的新增的第位鑒定
HELLODBACOM>select decode(bitand(ktcxbflg )) used_private_strand count(*)
from x$ktcxb
where bitand(ksspaflg ) !=
and bitand(ktcxbflg ) !=
group by bitand(ktcxbflg );
USED_PRIVATE_STRAND COUNT(*)
对于使用Private strand的事务无需先申请Redo Copy Latch也无需申请Shared Strand的redo allocation latch而是flush或commit是批量写入磁盘因此减少了Redo Copy Latch和redo allocation latch申请/释放次数也减少了这些latch的等待从而降低了CPU的负荷过程如下
事务开始 > 申请Private strand的redo allocation latch (申请失败则申请Shared Strand的redo allocation latch) > 在Private strand中生产Redo Enrey > Flush/Commit > 申请Redo Copy Latch > 服务进程将Redo Entry批量写入Log File > 释放Redo Copy Latch > 释放Private strand的redo allocation latch
注意对于未能获取到Private strand的redo allocation latch的事务在事务结束前即使已经有其它事务释放了Private strand也不会再申请Private strand了
每个Private strand的大小为Kg中shared pool中的Private strands的大小就是活跃会话数乘以K而g中在shared pool中需要为每个Private strand额外分配k的管理空间即数量*k
g:
SQL> select * from V$sgastat where name like %strand%;
POOL NAME BYTES
shared pool private strands
HELLODBACOM>select trunc(value * KSPPSTVL / ) * *
from (select value from v$parameter where name = transactions) a
(select valKSPPSTVL
from sysx$ksppi nam sysx$ksppsv val
where namindx = valindx
AND namksppinm = _log_private_parallelism_mul) b;
TRUNC(VALUE*KSPPSTVL/)**
g:
HELLODBACOM>select * from V$sgastat where name like %strand%;
POOL NAME BYTES
shared pool private strands
HELLODBACOM>select trunc(value * KSPPSTVL / ) * ( + ) *
from (select value from v$parameter where name = transactions) a
(select valKSPPSTVL
from sysx$ksppi nam sysx$ksppsv val
where namindx = valindx
AND namksppinm = _log_private_parallelism_mul) b;
TRUNC(VALUE*KSPPSTVL/)*(+)*
Private strand的数量受到个方面的影响logfile的大小和活跃事务数量
参数_log_private_mul指定了使用多少logfile空间预分配给Private strand默认为我们可以根据当前logfile的大小(要除去预分配给log buffer的空间)计算出这一约束条件下能够预分配多少个Private strand
HELLODBACOM>select bytes from v$log where status = CURRENT;
BYTES
HELLODBACOM>select trunc(((select bytes from v$log where status = CURRENT) (select to_number(value) from v$parameter where name = log_buffer))*
(select to_number(valKSPPSTVL)
from sysx$ksppi nam sysx$ksppsv val
where namindx = valindx
AND namksppinm = _log_private_mul) / / )
as calculated private strands
from dual;
calculated private strands
HELLODBACOM>select count() actual private strands from x$kcrfstrand where last_buf_kcrfa = ;
actual private strands
当logfile切换后(和checkpoint一样切换之前必须要将所有Private strand的内容flush到logfile中因此我们在alert log中可能会发现日志切换信息之前会有这样的信息Private strand flush not complete这是可以被忽略的)会重新根据切换后的logfile的大小计算对Private strand的限制
HELLODBACOM>alter system switch logfile;
System altered
HELLODBACOM>select bytes from v$log where status = CURRENT;
BYTES
HELLODBACOM>select trunc(((select bytes from v$log where status = CURRENT) (select to_number(value) from v$parameter where name = log_buffer))*
(select to_number(valKSPPSTVL)
from sysx$ksppi nam sysx$ksppsv val
where namindx = valindx
AND namksppinm = _log_private_mul) / / )
as calculated private strands
from dual;
calculated private strands
HELLODBACOM>select count() actual private strands from x$kcrfstrand where last_buf_kcrfa = ;
actual private strands
参数_log_private_parallelism_mul用于推算活跃事务数量在最大事务数量中的百分比默认为Private strand的数量不能大于活跃事务的数量
HELLODBACOM>show parameter transactions
NAME TYPE VALUE
transactions integer
transactions_per_rollback_segment integer
HELLODBACOM>select trunc((select to_number(value) from v$parameter where name = transactions) *
(select to_number(valKSPPSTVL)
from sysx$ksppi nam sysx$ksppsv val
where namindx = valindx
AND namksppinm = _log_private_parallelism_mul) / )
as calculated private strands
from dual;
calculated private strands
HELLODBACOM>select count() actual private strands from x$kcrfstrand where last_buf_kcrfa = ;
actual private strands
注在预分配Private strand时会选择上述个条件限制下最小一个数量但相应的shared pool的内存分配和redo allocation latch的数量是按照活跃事务数预分配的
因此如果logfile足够大_log_private_parallelism_mul与实际活跃进程百分比基本相符的话Private strand的引入基本可以消除redo allocation latch的争用问题
