开发者社区> superdba> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

oracle的增量检查点与block buffer

简介: 通过dump工具分析oracle的增量检查点机制
+关注继续查看

增量检查点

  首先本文不会作过多的概念描述,对于增量检查点机制,其实在任何关系型数据库里都会存在。从事务的持久性角度来看,他的目的也是显而易见的,即保证数据块的正常刷新以及崩溃恢复,那么检查点其实也就是对数据块刷新情况的一个位点记录,至于通过什么形式记录,不同的数据库各有差异。因此,要想实现日志预写协议,检查点机制是必不可少的。

dump控制文件

  oracle里的增量检查点是由ckpt进程维护在控制文件里的,这里我们借助trace从控制文件头部找到相关信息。

SQL> alter session set events 'immediate trace name controlf level 2';

Session altered.

接下来查看trace文件,
clipboard
向下寻找出本次dump结果里的checkpoint信息,如下,

***************************************************************************
CHECKPOINT PROGRESS RECORDS
***************************************************************************
 (size = 8180, compat size = 8180, section max = 11, section in-use = 0,
  last-recid= 0, old-recno = 0, last-recno = 0)
 (extent = 1, blkno = 2, numrecs = 11)
THREAD #1 - status:0x2 flags:0x0 dirty:43
low cache rba:(0x211.43f.0) on disk rba:(0x211.540.0)
on disk scn: 0x0000.0073a315 08/14/2015 20:31:34
resetlogs scn: 0x0000.001a002c 08/04/2015 16:38:12
heartbeat: 887720057 mount id: 2580966972

  那么,这里注意几个关键信息.。

low cache rba    最早的脏块对应的日志地址
on disk rba    redolog中最后一条日志所在的地址
on disk scn    LGWR每写完日志,会更新这个值
heartbeat    控制文件每被修改一次,heartbeat增加一次

  我们不难发现,low cache rba与on disk rba之间的日志对应当前数据库中已提交的脏块。而checkpoint主要的功能,也是维护这两个地址。如果此时发生断电,这里就是进行崩溃恢复的依据。

从脏块查看LRBA

SQL> alter system dump datafile 1 block 178440;

System altered.

该操作会dump出磁盘中的数据块、对应的dirty buffer及CR块。
接下来查看刚生成的dump文件,

[oracle@oracle11g trace]$ pwd 
/u01/app/oracle/diag/rdbms/oracle11g/oracle11g/trace 
[oracle@oracle11g trace]$ vim oracle11g_ora_2564.trc

78782bc3f429a0fe836a0153ee05a18975a74e1f

这里需要关注的关键信息如下,

rdba:  数据块地址
ST:    CR/XCURRENT(CR块/当前块)
current块lru:  LRUW链上下指针
ckptq:        检查点队列上下成员指针 
LRBA:        这个脏块第一次被修改时的redo日志地址。为空值表示对应日志还未写入磁盘
LSCN、HSCN:  构造这个脏块所需日志的SCN。为空值表示对应日志还未写入磁盘
cr:[scn:]  构造CR块的SCN号
xid、uba:    构造CR块时读取的undo数据的xid及undo数据块地址

  那么这里,我们看到的是同一个block在buffer中的两种状态,即CR块和XCURRENT块,对于CR块记录的是事务号以及undo块的地址,对于XCURRENT块记录的则是redo日志相关的信息。需要注意的一点是,dirty buffer里的lrba与控制文件中lrba的意义是不一样的,dirty buffer中的记录只会关心与此buffer相关的redo log,而控制文件中的lrba是针对整个buffer cache中的dirty buffer。
  另外,这里还有一个信息,就是ckptq(检查点队列),检查点队列由ckpt进程去维护。dbwr进程沿着此队列进行刷新工作,ckpt进程检查此队列完成向控制文件中的检查点信息维护。

  除buffer之外,trace文件中的block信息如下,
clipboard

rdba:  数据块的地址
scn:   最近写入磁盘的SCN号

  对于DBWR,每次刷新脏块后,会去维护这个block的SCN号,代表这个block的数据版本。

比对事务槽信息

  对于前面dump出来的CR块信息,可以通过查看事务槽的信息来做比对验证。
clipboard
这里我们所关注的uba地址以及xid完全吻合。

ps,关于undo机制以及事务槽的分析,可参考博文:Oracle undo机制拙见

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
Oracle 数据库性能优化3日实战(企业培训)
课程名称一: Oracle性能优化及调整 课程时长 1天 课程深度: 高级 上机实验: 10%-30% 授课对象: Oracle开发人员、Oracle数据库管理人员,应用程序开发人员 课程描述: 本课程讲述Oracle数据库物理层规划,系统性能的监控,数据库性能参数调整,统计信息的收集,使用自动化调试工具优化数据库,I/O子系统的配置与设计以及性能优化方法论等。
1753 0
oracle 判断列是否在数据库中存在
select count('列名') from cols  where table_name=upper('表名') and column_name=upper('列名')其存在与否的结果与oracle 判断某个表是否存在一样,都是返回1或者0
694 0
Oracle数据库性能的优化
      随着网络应用和电子商务的不断发展,各个站点的访问量越来越大,如何使有限的计算机系统资源为更多的用户服务?如何保证用户的响应速度和服务质量?这些问题都属于服务器性能优化的范畴。
983 0
+关注
superdba
Super, not a DBA, not a programmer. May be a singer, poet, ITer, and so on.
18
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
低代码开发师(初级)实战教程
立即下载
阿里巴巴DevOps 最佳实践手册
立即下载
冬季实战营第三期:MySQL数据库进阶实战
立即下载