Oracle Redo的并行机制运行中要用到的代码

数据库 Oracle
以下的文章主要介绍的是Oracle Redo的并行机制的实际操作,以及其相关实际应用代码的介绍,以下就是文章的具体内容的分析。

我们今天主要介绍的是Redo log 恢复与高级特性的重要相关数据,我们大家都知道一个Oracle redo条目包含了相应操作导致的数据库变化的所有的信息,所有redo条目最终都要被写入redo文件中去。

Redo log buffer是为了避免Redo文件IO导致性能瓶颈而在sga中分配出的一块内存。

一个redo条目首先在用户内存(PGA)中产生,然后由oracle服务进程拷贝到log buffer中,当满足一定条件时,再由LGWR进程写入Oracle 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;

 

  1. 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分配变成了并行的过程,从而减少了Oracle redo allocation latch等待。

shared strand的初始数据量是由参数log_parallelism控制的;在10g中,该参数成为隐含参数,并新增参数_log_parallelism_max控制shared strand的***数量;_log_parallelism_dynamic则控制是否允许shared strand数量在_log_parallelism和_log_parallelism_max之间动态变化。

  1. HELLODBA.COM>select nam.ksppinm, val.KSPPSTVL, nam.ksppdesc   
  2. 2 from sys.x$ksppi nam,   
  3. 3 sys.x$ksppsv val   
  4. 4 where nam.indx = val.indx   
  5. 5 --AND nam.ksppinm LIKE '_%'   
  6. 6 AND upper(nam.ksppinm) LIKE '%LOG_PARALLE%';   
  7.  
  8. KSPPINM KSPPSTVL KSPPDESC   
  9. -------------------------- ---------- ------------------------------------------   
  10. _log_parallelism 1 Number of log buffer strands   
  11. _log_parallelism_max 2 Maximum number of log buffer strands   
  12. _log_parallelism_dynamic TRUE Enable dynamic strands  

每一个shared strand的大小 = log_buffer/(shared strand数量)。strand信息可以由表x$kcrfstrand查到(包含shared strand和后面介绍的private strand,10g以后存在)。 

  1. HELLODBA.COM>select indx,strand_size_kcrfa from x$kcrfstrand where last_buf_kcrfa != '00';   
  2. INDX STRAND_SIZE_KCRFA   
  3. ---------- -----------------   
  4. 0 3514368   
  5. 1 3514368   
  6. HELLODBA.COM>show parameter log_buffer   
  7. NAME TYPE VALUE   
  8. ------------------------------------ ----------- ------------------------------   
  9. log_buffer integer 7028736   

关于shared strand的数量设置,16个cpu之内***默认为2,当系统中存在Oracle 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控制。

 

 

  1. Private strand 

为了进一步降低redo buffer冲突,在10g中引入了新的strand机制——Private strand。Private strand不是从log buffer中划分的,而是在shared pool中分配的一块内存空间。 

 

  1. HELLODBA.COM>select * from V$sgastat where name like '%strand%';  
  2. POOL NAME BYTES  
  3. ------------ -------------------------- ----------  
  4. shared pool private strands 2684928  
  5. HELLODBA.COM>select indx,strand_size_kcrfa from x$kcrfstrand where last_buf_kcrfa = '00';  
  6. INDX STRAND_SIZE_KCRFA  
  7. ---------- -----------------  
  8. 2 66560  
  9. 3 66560  
  10. 4 66560  
  11. 5 66560  
  12. 6 66560  
  13. 7 66560  
  14. 8 66560  
  15. ...  

Private strand的引入为Oracle的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的新增的第13位鉴定:

 

  1. HELLODBA.COM>select decode(bitand(ktcxbflg, 4096),0,1,0) used_private_strand, count(*)  
  2. 2 from x$ktcxb  
  3. 3 where bitand(ksspaflg, 1) != 0  
  4. 4 and bitand(ktcxbflg, 2) != 0  
  5. 5 group by bitand(ktcxbflg, 4096);  
  6. USED_PRIVATE_STRAND COUNT(*)  
  7. ------------------- ----------  
  8. 1 10  
  9. 0 1  

对于使用Private strand的事务,无需先申请Oracle 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的Oracle redo allocation latch的事务,在事务结束前,即使已经有其它事务释放了Private strand,也不会再申请Private strand了

责任编辑:佚名 来源: 互联网
相关推荐

2010-01-06 09:30:51

Oracle Redo

2010-04-27 09:38:57

Oracle修改表ow

2010-07-06 16:45:39

SQL Server创

2010-07-13 10:28:41

SQL Server

2010-07-06 17:02:45

SQL Server创

2010-04-27 10:32:54

Oracle优化CPU

2012-11-21 17:19:55

2010-08-18 14:44:24

JDBC连接DB2实例

2010-03-29 17:03:48

Oracle创建

2014-03-06 15:49:36

iOS开源库汇总

2010-05-06 17:54:54

Oracle锁

2010-06-11 17:36:46

MySQL语句

2010-08-17 11:03:01

DB2恢复误删除表

2010-06-12 10:49:12

2010-08-16 15:06:15

DB2数据类型转换

2010-08-12 17:23:20

DB2存储过程编写流程

2010-05-07 12:46:08

Oracle redo

2010-04-01 18:08:48

Oracle导入

2010-05-12 10:17:59

MySQL数据库优化

2011-03-24 17:21:42

Oracle数据库Redo故障
点赞
收藏

51CTO技术栈公众号