Redo Byte Address (RBA)

Redo Byte Address (RBA)

Recent entries in the redo thread of an Oracle  instance are addressed using a 3-part redo byte address, or RBA. An RBA is  comprised of

  • the log file sequence number (4 bytes)
  • the log file block number (4 bytes)
  • the byte offset into the block at which the redo record starts (2 bytes)

RBAs are not necessarily unique within their thread, because the log  file sequence number may be reset to 1 in all threads if a database is opened  with the RESETLOGS option.

RBAs are used in the following important ways.

With respect to a dirty block in  the buffer cache, the
low RBA is the address of the redo for the  first change that was applied to the block since it was last clean, and the
high RBA is the address of the redo for the most recent change to  have been applied to the block.

Dirty buffers are maintained on the buffer cache  checkpoint queues in low RBA order. The
checkpoint RBA is the  point up to which DBWn has written buffers from the checkpoint queues if  incremental checkpointing is enabled -- otherwise it is the RBA of last full  thread checkpoint. The checkpoint RBA is copied into the
checkpoint progress  record of the controlfile by the checkpoint heartbeat once every 3 seconds.  Instance recovery, when needed, begins from the checkpoint RBA recorded in the  controlfile.
The target RBA is the point up to  which DBWn should seek to advance the checkpoint RBA to satisfy instance  recovery objectives.

The on-disk RBA is the point up to which  LGWR has flushed the redo thread to the online log files. DBWn may not write a  block for which the high RBA is beyond the on-disk RBA. Otherwise transaction  recovery
(rollback) would not be possible, because the redo needed to undo a  change is always in the same redo record as the redo for the change itself.

The term sync RBA is sometimes used to refer to the point up to  which LGWR is required to sync the thread. However, this is not a full RBA --  only a redo block number is used at this point.

The low and  high RBAs for dirty buffers can be seen in X$BH. (There is also a
recovery  RBA
which is used to record the progress of partial block recovery by PMON.)  The incremental checkpoint RBA, the target RBA and the on-disk RBA can all be  seen in X$TARGETRBA. The incremental checkpoint RBA and the on-disk RBA can also  be
seen in X$KCCCP. The full thread checkpoint RBA can be seen in X$KCCRT.

 

时间: 2024-11-30 17:21:30

Redo Byte Address (RBA)的相关文章

Oracle的Commit知识

Oracle还是比较常用的,于是我研究了一下Oracle COMMIT,在这里拿出来和大家分享一下,希望对大家有用.只有当SQL语句影响的所有行所在的最后一个块被读入DB BUFFER并且重做信息被写入REDO LOG BUFFER之后,用户才可以发出COMMIT,Oracle COMMIT触发LGRW,但并不强制立即DBWN来释放所有相应的DB BUFFER块上的锁,但在随后的一段时间内DBWN还在写这条语句涉及的数据块的情形,表头部的行锁,并不是在COMMIT一发出就马上释放,实际上要等到相

对Oracle Commit的研究

Oracle还是比较常用的,于是我研究了一下Oracle COMMIT,在这里拿出来和大家分享一下,希望对 大家有用.只有当SQL语句影响的所有行所在的最后一个块被读入DB BUFFER并且重做信息被写入REDO LOG BUFFER之后,用户才可以发出COMMIT,Oracle COMMIT触发LGRW,但并不强制立即DBWN来释放所有 相应的DB BUFFER块上的锁,但在随后的一段时间内DBWN还在写这条语句涉及的数据块的情形,表头部 的行锁,并不是在COMMIT一发出就马上释放,实际上要

针对checkpoint的概要分析

checkpoint概要 什么是checkpoint 在数据库系统中,写日志和写数据文件是数据库中IO消耗最大的两种操作,在这两种操作中写数据文件属于分散写,写日志文件是顺序写,因此为了保证数据库的性能,通常数据库都是保证在提交(commit)完成之前要先保证日志都被写入到日志文件中,而脏数据块着保存在数据缓存(buffer cache)中再不定期的分批写入到数据文件中.也就是说日志写入和提交操作是同步的,而数据写入和提交操作是不同步的.这样就存在一个问题,当一个数据库崩溃的时候并不能保证缓存里

Oracle Checkpoint

转一篇Oracle checkpoint相关文章, PostgreSQL的checkpoint希望以后能改进其性能, Oracle的增量checkpoint不错. [原文] http://blog.csdn.net/tianlesoftware/article/details/6700085 一. Oracle Checkpoint 说明  1.1  Checkpoint (1)A synchronization event at aspecific point in time (2)Cause

oracle中 SCN号总结 上篇

1.SCN(System Change Number) : SCN是什么? system change number (SCN)是一个非常重要的标记,Oracle使用它来标记数据库在过去时间内的状态和轨迹.Oracle使用SCN来保 存所有变化的轨迹.SCN是一个逻辑时钟来记录数据库事件.它非常的重要,并不是只是为了恢复.SCN的最大值是0xffff.ffffffff.SCN有点类似于sequence,Oracle 在SGA中增加它.当一个事务修改或者插入数据,Oracle首先写入一个新的SCN

oracle 检查点(checkpoint)

以下内容整理自网路,如有侵权,请联系我. checkpoint扫盲 什么是checkpoint 在数据库系统中,写日志和写数据文件是数据库中IO消耗最大的两种操作,在这两种操作中写数据文件属于分散写,写日志文件是顺序写,因此为了保证数据库的性能,通常数据库都是保证在提交(commit)完成之前要先保证日志都被写入到日志文件中,而脏数据块着保存在数据缓存(buffer cache)中再不定期的分批写入到数据文件中.也就是说日志写入和提交操作是同步的,而数据写入和提交操作是不同步的.这样就存在一个问

揭密备份恢复的原理

其实一句话就可以说明白:那就是数据文件的头上不仅包含了checkpoint_change#,更重要的是它包含了这个 checkpoint_change#所在的logfile的sequence#,准确的说是rba.有了rba,在恢复时就能准确的知道到底需要哪个 logfile(archivelog or redo).结果花了很大篇幅,只想以试验的方式做个简单的验证,便于大家理解.欢迎拍砖!另外提个问题:是否存在一些数据字典它是源于redo的? --controlfile中记录的checkpoint

【BBED】丢失归档文件情况下的恢复

[BBED]丢失归档文件情况下的数据文件的恢复   1.1  BLOG文档结构图     1.2  前言部分   1.2.1  导读和注意事项 各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识,~O(∩_∩)O~: ① 若丢失归档情况下数据文件的恢复,bbed和隐含参数(重点) ② 数据库启动过程中的介质恢复,scn号的关系 ③ BBED如何修改文件头 ④ 归档和非归档模式下数据库的全备     Tips:        ① 若文章代码格式有错乱,推荐使用QQ

SCN和Checkpoint

http://www.cnblogs.com/yifan268/archive/2008/07/15/1243418.html 转自   SCN和Checkpoint SCN :system change number.作为数据库内部的逻辑时钟,用来标识数据库在某个确切时刻提交的版本,存在于控制文件.数据文件头.数据块.日志文件头.日志文件change vector.数据文件头中包含该数据文件的checkpoint SCN.Checkpoint :只是一个数据库事件,根本意义在于减少崩溃恢复时间