【性能优化】增量检查点

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介:
Oracle从8i开始引入了检查点队列这么一种概念,用于记录数据库里面当前所有的脏数据块的信息,DBWR根据这个队列而将脏数据块写入到数据文件中。检查点队列按时间先后记录着数据库里面脏数据块的信息,里面的条目包含RBA(Redo Block Address,重做日志里面用于标识检查点期间数据块在重做日志里面第一次发生更改的编号)和数据块的数据文件号和块号。在检查点期间不论数据块更改几次,它在检查点队列里面的位置始终保持不变,检查点队列也只会记录它最早的RBA,从而保证最早更改的数据块能够尽快写入。当DBWR将检查点队列里面的脏数据块写入到数据文件后,检查点的位置也要相应地往后移,CKPT每三秒会在控制文件中记录检查点的位置,以表示Instance Recovery时开始恢复的日志条目,这个概念称为检查点的“心跳”(heartbeat)。检查点位置发生变更后,Oracle里面通过4个参数用于控制检查点位置和最后的重做日志条目之间的距离。在这里面需要指出的是,多数人会将这4个参数看作控制增量检查点发生的时间。事实上这是错误的,这4个参数是用于控制检查点队列里面的条目数量,而不是控制检查点的发生。

(1、)fast_start_io_target

该参数用于表示数据库发生Instance Recovery的时候需要产生的IO总数,它通过v$filestat的AVGIOTIM来估算的。比如我们一个数据库在发生Instance Crash后需要在10分钟内恢复完毕,假定OS的IO每秒为500个,那么这个数据库发生Instance Recovery的时候大概将产生500*10*60=30,000次IO,也就是我们将可以把fast_start_io_target设置为 30000。

(2、)fast_start_mttr_target

我们从上面可以看到fast_start_io_target来估算检查点位置比较麻烦。Oracle为了简化这个概念,从9i开始引入了 fast_start_mttr_target这么一个参数,用于表示数据库发生Instance Recovery的时间,以秒为单位。这个参数我们从字面上也比较好理解,其中的mttr是mean time to recovery的简写,如上例中的情况我们可以将fast_start_mttr_target设置为600。当设置了 fast_start_mttr_target后,fast_start_io_target这个参数将不再生效,从9i后 fast_start_io_target这个参数被Oracle废除了。

(3、)log_checkpoint_timeout

该参数用于表示检查点位置和重做日志文件末尾之间的时间间隔,以秒为单位,默认情况下是1800秒。

(4、)log_checkpoint_interval

该参数是表示检查点位置和重做日志末尾的重做日志块的数量,以OS块表示。

(5、)90% OF SMALLEST REDO LOG

除了以上4个初始化参数外,Oracle内部事实上还将重做日志文件末尾前面90%的位置设为检查点位置。在每个重做日志中,这么几个参数指定的位置可能不尽相同,Oracle将离日志文件末尾最近的那个位置确认为检查点位置。
                                                                                                                                                                                                                              from ITPUB http://www.itpub.net/thread-1341844-2-1.html
相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
3月前
|
缓存 固态存储 关系型数据库
MySQL性能优化指南:深入分析重做日志刷新到磁盘的机制
MySQL性能优化指南:深入分析重做日志刷新到磁盘的机制
143 0
|
8月前
|
NoSQL Cloud Native Redis
【性能优化下】组织结构同步优化二,全量同步/增量同步,断点续传实现方式
【性能优化下】组织结构同步优化二,全量同步/增量同步,断点续传实现方式
|
机器学习/深度学习 缓存 Oracle
【数据库设计与实现】第7章:缓存与检查点
缓存与检查点设计原则数据缓冲区与检查点是相辅相成的,所以放在同一个章节介绍。由于CPU与持久化设备之间存在巨大的速度差距,所以在内存中引入缓冲区缩小这个差距。从读的角度来看,将热点数据或预判用户可能读取的数据提前加载到内存中,从而将持久化设备的读时延和带宽提升至内存的时延和带宽。从写的角度来看,直接修改缓冲区中的数据而不是磁盘中的数据,可以带来两方面的优势。其一,将持久化设备的写时延和带宽提升至内
【数据库设计与实现】第7章:缓存与检查点
|
缓存 前端开发 JavaScript
性能优化记录
性能优化记录
126 0
性能优化记录
|
SQL 缓存 分布式计算
Flinksql性能优化
Flinksql性能优化
Flinksql性能优化
++i(前增量) 和 i++(后增量)的区别
++i(前增量) 和 i++(后增量)的区别
95 0
增量数据丢失的原因分析(三)
今天开发的同事找到我说,他们发现一个应用今天应该会同步过来一部分数据,但是今天却没有,所以想让我帮忙看看到底是怎么回事。 对于这类需求也算是轻门熟路,不光维护管理数据,补数据也在行。
973 0
|
SQL 存储 网络安全
增量数据丢失的原因分析(二)
今天处理的一个问题比较绕,花费了我不少的时间来分析,当然最后发现是拜拜忙碌一场空,还是有一些历史原因。 大体的环境情况如下,有一台线上库OLTP,其中也有会自己的存储过程,job,结合起来处理一些数据,当然作为统计系统而言,目前有两套统计系统STATDB1,STATDB2,都哟裇相关业务的划分,两者会有一些交集。
918 0
|
存储 网络协议 数据库管理
增量数据丢失的原因分析
今天开发的同事找到我,让我帮他们补一部分数据,因为有一个表的数据已经快一个月没有增量数据了,这个需求听起来有些奇怪是不? 问题的背景是在统计库中存在一个表,供部分应用做统计分析,每天会根据时间生成一条记录,这条记录汇总的数据会作为统计分析所用。
856 0