Oracle Redo log并行机制详解(1)

Oracle的数据信息库系统日志称之为Redo log,全部数据信息更改都纪录Redo log,能够用以修补损伤的数据信息库。Redo log 是用以修复和一个高級特点的关键数据信息,一个redo内容包括了相对...

Oracle的数据库日志称为Redo log,所有数据改变都记录Redo log,可以用于修复受损的数据库。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*2) - 服务进程获取redo allocation latch(仅1个) - 分配log buffer - 释放redo allocation latch - 将Redo Entry写入Log Buffer - 释放Redo Copy latch;
shared strand
为了减少redo allocation latch等待,在oracle 9.2中,引入了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控制的;在10g中,该参数成为隐含参数,并新增参数_log_parallelism_max控制shared strand的最大数量;_log_parallelism_dynamic则控制是否允许shared strand数量在_log_parallelism和_log_parallelism_max之间动态变化。
HELLODBA.COM select nam.ksppinm, val.KSP凡科抠图TVL, nam.ksppdesc 2 from sys.x$ksppi nam, 3 sys.x$ksp凡科抠图v val 4 where nam.indx = val.indx 5 --AND nam.ksppinm LIKE '_%' 6 AND upper(nam.ksppinm) LIKE '%LOG_PARALLE%'; KSPPINM KSP凡科抠图TVL KSPPDESC -------------------------- ---------- ------------------------------------------ _log_parallelism 1 Number of log buffer strands _log_parallelism_max 2 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 strand,10g以后存在)。
HELLODBA.COM select indx,strand_size_kcrfa from x$kcrfstrand where last_buf_kcrfa != '00'; INDX STRAND_SIZE_KCRFA ---------- ----------------- 0 3514368 1 3514368 HELLODBA.COM show parameter log_buffer NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ log_buffer integer 7028736 关于shared strand的数量设置,16个cpu之内最大默认为2,当系统中存在redo allocation latch等待时,每增加16个cpu可以考虑增加1个strand,最大不应该超过8。并且_log_parallelism_max不允许大于cpu_count。
注意:在11g中,参数_log_parallelism被取消,shared strand数量由_log_parallelism_max、_log_parallelism_dynamic和cpu_count控制。
Private strand
为了进一步降低redo buffer冲突,在10g中引入了新的strand机制——Private strand。Private strand不是从log buffer中划分的,而是在shared pool中分配的一块内存空间。
HELLODBA.COM select * from V$sgastat where name like '%strand%'; POOL NAME BYTES ------------ -------------------------- ---------- shared pool private strands 2684928 HELLODBA.COM select indx,strand_size_kcrfa from x$kcrfstrand where last_buf_kcrfa = '00'; INDX STRAND_SIZE_KCRFA ---------- ----------------- 2 66560 3 66560 4 66560 5 66560 6 66560 7 66560 8 66560 ... Private strand的引入为Oracle的Redo/Undo机制带来很大的变化。每一个Private strand受到一个单独的redo allocation latch保护,每个Private strand作为“私有的”strand只会服务于一个活动事务。获取到了Private strand的用户事务不是在PGA中而是在Private strand生成Redo,当flush mit时,Private strand被批量写入log文件中。如果新事务申请不到Private strand的redo allocation latch,则会继续遵循旧的redo buffer机制,申请写入shared strand中。事务是否使用Private strand,可以由x$ktcxb的字段ktcxbflg的新增的第13位鉴定:
HELLODBA.COM select decode(bitand(ktcxbflg, 4096),0,1,0) used_private_strand, count(*) 2 from x$ktcxb 3 where bitand(ksspaflg, 1) != 0 4 and bitand(ktcxbflg, 2) != 0 5 group by bitand(ktcxbflg, 4096); USED_PRIVATE_STRAND COUNT(*) ------------------- ---------- 1 10 0 1 对于使用Private strand的事务,无需先申请Redo Copy Latch,也无需申请Shared Strand的redo allocation mit是批量写入磁盘,因此减少了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 。