指点成金-最美分享吧

登录

知识大全 OracleRedolog并行机制详解

佚名 举报

篇首语:我们要像海绵一样吸收有用的知识。本文由小编为大家整理,主要介绍了知识大全 OracleRedolog并行机制详解相关的知识,希望对你有一定的参考价值。

OracleRedolog并行机制详解  以下文字资料是由(全榜网网)小编为大家搜集整理后发布的内容,让我们赶快一起来看一下吧!

  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* ) > 服务进程获取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之间动态变化

   HELLODBA >select  nam ksppinm val KSPPSTVL nam ksppdesc

       from    sys x$ksppi nam

               sys x$ksppsv val

       where nam indx = val indx

       AND   nam ksppinm LIKE _%

       AND   upper(nam ksppinm) LIKE %LOG_PARALLE% ;

  

   KSPPINM                    KSPPSTVL   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 strand g以后存在)

   HELLODBA >select indx strand_size_kcrfa from x$kcrfstrand where last_buf_kcrfa != ;

  

         INDX STRAND_SIZE_KCRFA

  

                      

                      

  

   HELLODBA >show parameter log_buffer

  

   NAME                                 TYPE        VALUE

  

   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 strand Private strand不是从log buffer中划分的 而是在shared pool中分配的一块内存空间

   HELLODBA >select * from V$sgastat where name like %strand% ;

  

   POOL NAME BYTES

  

  

  

   shared pool private strands

  

   HELLODBA >select indx strand_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或者mit时 Private strand被批量写入log文件中 如果新事务申请不到Private strand的redo allocation latch 则会继续遵循旧的redo buffer机制 申请写入shared strand中 事务是否使用Private strand 可以由x$ktcxb的字段ktcxbflg的新增的第 位鉴定

   HELLODBA >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或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

  注意 对于未能获取到Private strand的redo allocation latch的事务 在事务结束前 即使已经有其它事务释放了Private strand 也不会再申请Private strand了

  每个Private strand的大小为 K g中 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

  

   HELLODBA >select trunc(value * KSPPSTVL / ) * *

  

   from (select value from v$parameter where name = transactions ) a

  

   (select val KSPPSTVL

  

   from sys x$ksppi nam sys x$ksppsv val

  

   where nam indx = val indx

  

   AND nam ksppinm = _log_private_parallelism_mul ) b;

  

   TRUNC(VALUE*KSPPSTVL/ )* *

  

  

  

  

  

   g:

  

   HELLODBA >select * from V$sgastat where name like %strand% ;

  

   POOL NAME BYTES

  

  

  

   shared pool private strands

  

   HELLODBA >select trunc(value * KSPPSTVL / ) * ( + ) *

  

   from (select value from v$parameter where name = transactions ) a

  

   (select val KSPPSTVL

  

   from sys x$ksppi nam sys x$ksppsv val

  

   where nam indx = val indx

  

   AND nam ksppinm = _log_private_parallelism_mul ) b;

  

   TRUNC(VALUE*KSPPSTVL/ )*( + )*

  

  

  

  

  Private strand的数量受到 个方面的影响 logfile的大小和活跃事务数量

  参数_log_private_mul指定了使用多少logfile空间预分配给Private strand 默认为 我们可以根据当前logfile的大小(要除去预分配给log buffer的空间)计算出这一约束条件下能够预分配多少个Private strand

   HELLODBA >select bytes from v$log where status = CURRENT ;

  

   BYTES

  

  

  

  

  

   HELLODBA >select trunc(((select bytes from v$log where status = CURRENT ) (select to_number(value) from v$parameter where name = log_buffer ))*

  

   (select to_number(val KSPPSTVL)

  

   from sys x$ksppi nam sys x$ksppsv val

  

   where nam indx = val indx

  

   AND nam ksppinm = _log_private_mul ) / / )

  

   as calculated private strands

  

   from dual;

  

   calculated private strands

  

  

  

  

  

   HELLODBA >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 plete 这是可以被忽略的) 会重新根据切换后的logfile的大小计算对Private strand的限制

   HELLODBA >alter system switch logfile;

  

   System altered

  

   HELLODBA >select bytes from v$log where status = CURRENT ;

  

   BYTES

  

  

  

  

  

   HELLODBA >select trunc(((select bytes from v$log where status = CURRENT ) (select to_number(value) from v$parameter where name = log_buffer ))*

  

   (select to_number(val KSPPSTVL)

  

   from sys x$ksppi nam sys x$ksppsv val

  

   where nam indx = val indx

  

   AND nam ksppinm = _log_private_mul ) / / )

  

   as calculated private strands

  

   from dual;

  

   calculated private strands

  

  

  

  

  

   HELLODBA >select count( ) actual private strands from x$kcrfstrand where last_buf_kcrfa = ;

  

   actual private strands

  

  

  

  

  参数_log_private_parallelism_mul用于推算活跃事务数量在最大事务数量中的百分比 默认为 Private strand的数量不能大于活跃事务的数量

   HELLODBA >show parameter transactions

  

   NAME TYPE VALUE

  

  

  

   transactions integer

  

   transactions_per_rollback_segment integer

  

   HELLODBA >select trunc((select to_number(value) from v$parameter where name = transactions ) *

  

   (select to_number(val KSPPSTVL)

  

   from sys x$ksppi nam sys x$ksppsv val

  

   where nam indx = val indx

  

   AND nam ksppinm = _log_private_parallelism_mul ) / )

  

   as calculated private strands

  

   from dual;

  

   calculated private strands

  

  

  

  

  

   HELLODBA >select count( ) actual private strands from x$kcrfstrand where last_buf_kcrfa = ;

  

   actual private strands

  

  

  

  

  注 在预分配Private strand时 会选择上述 个条件限制下最小一个数量 但相应的shared pool的内存分配和redo allocation latch的数量是按照活跃事务数预分配的

lishixinzhi/Article/program/Oracle/201311/16501