1818IP-服务器技术教程,云服务器评测推荐,服务器系统排错处理,环境搭建,攻击防护等

当前位置:首页 - 数据库 - 正文

君子好学,自强不息!

我们今天主要介绍的是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;

sharedstrand

为了减少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之间动态变化。

HELLODBA.COM>selectnam.ksppinm,val.KSPPSTVL,nam.ksppdesc 
2fromsys.x$ksppinam, 
3sys.x$ksppsvval 
4wherenam.indx=val.indx 
5--ANDnam.ksppinmLIKE'_%' 
6ANDupper(nam.ksppinm)LIKE'%LOG_PARALLE%'; 

KSPPINMKSPPSTVLKSPPDESC 
------------------------------------------------------------------------------ 
_log_parallelism1Numberoflogbufferstrands 
_log_parallelism_max2Maximumnumberoflogbufferstrands 
_log_parallelism_dynamicTRUEEnabledynamicstrands

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

HELLODBA.COM>selectindx,strand_size_kcrfafromx$kcrfstrandwherelast_buf_kcrfa!='00'; 
INDXSTRAND_SIZE_KCRFA 
--------------------------- 
03514368 
13514368 
HELLODBA.COM>showparameterlog_buffer 
NAMETYPEVALUE 
----------------------------------------------------------------------------- 
log_bufferinteger7028736 

关于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控制。

Privatestrand

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

HELLODBA.COM>select*fromV$sgastatwherenamelike'%strand%'; 
POOLNAMEBYTES 
------------------------------------------------ 
sharedpoolprivatestrands2684928 
HELLODBA.COM>selectindx,strand_size_kcrfafromx$kcrfstrandwherelast_buf_kcrfa='00'; 
INDXSTRAND_SIZE_KCRFA 
--------------------------- 
266560 
366560 
466560 
566560 
666560 
766560 
866560 
... 

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位鉴定:

HELLODBA.COM>selectdecode(bitand(ktcxbflg,4096),0,1,0)used_private_strand,count(*) 
2fromx$ktcxb 
3wherebitand(ksspaflg,1)!=0 
4andbitand(ktcxbflg,2)!=0 
5groupbybitand(ktcxbflg,4096); 
USED_PRIVATE_STRANDCOUNT(*) 
----------------------------- 
110 
01 

对于使用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了

本文来源:1818IP

本文地址:https://www.1818ip.com/post/11054.html

免责声明:本文由用户上传,如有侵权请联系删除!

发表评论

必填

选填

选填

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。