1. 首页
  2. IT资讯

关于ORACLE 和MYSQL INNODB 触发脏数据写的机制对比

首先要说明在ORACLE和INNODB触发checkpoint方面都采用LRU进行管理,并且都有全量检查点和增量检查点一说
在MYSQL中全量检查点叫做sharp checkpoint,增量检查点叫做FUZZY CHECKPOINT,

在ORACLE中更加细化,加入了LRUW链表,并且加入CHECKPOINT-Q列表,两者共同配合完成增量CHECKPOINT,在ORACLE
中DBWR写是按照CHECKPOINT-Q的顺序写的其是LRBA的链表,其触发条件受到MTTR的限制,如果ORACL估计能够达到INSTANCE
CRASH RECOVERY的时间就会不触发CHECKPOINT-Q写,而加入LRUW列表更是为了减轻按照CHECKPOINT-Q来写的负担,如果检查到
哪些每3秒访问少2次的脏块就会从LRU中拿下计入LRUW,等待DBWR3秒醒来触发写,对于3秒访问大于等于2次的脏块,依然按照
checkpoint-Q来写,因为很可能还会修改,写完后从CHECKPOINT-Q下摘下。这样LRUW基本就是为了那些修改次数少的脏块而生的,
目的在于优先写入修改次数少脏块减轻CHECKPOINT-Q增量检查点压力。
其实在ORACLE中LRU和LRUW都分为辅助和主列两个,关于这一点是为了加快扫描LRU的效率,详细参加吕海波ORACLE内核揭秘
这里给出ORACLE写脏块的机制(来自吕海波ORACLE内核揭秘)
1、DBWR 3秒写冷脏块上面说的3秒内访问一次的脏块
2、CHEKPOINT-Q 写入,他也是DBWR来判断的如果不能满足MTTR的设置就开始写,由CKPT修改CONTROLFILE里面的各种信息,重要的
就是LRBA,关于LRBA和脏块数量可能通过X$KCCCP来查看
3、服务器进程扫描LRU发现25%的脏块直接出发DBWR写,不需要等待3秒,从LRUW进行写,有隐含参数_db_large_dirty_queue控制默认25%
4、服务器进程扫描超过40%的BUFFER没有找到可用的BUFFER来缓存新的数据块,不需要等待3秒,从LRUW进行, 
   由隐含_db_block_max_scan_pct控制
5、各种全量检查点
   alter system checkpoint
   SHUTDOWN DATABASE非ABORT
   log switch
   表空间OFFLINE 表空间一级检查点
   DDL语句drop truncate等对象一级检查点

在MYSQL中一切其实差不多,但是从MYSQL内幕innodb存储引擎一书来看,所有的脏块和干净的块都在LRU列中,同时还存放了一份
在flush列表中(类似ORACLE的CHECKPOINT-q),同样MASTER进程也是用来读取FLUSH列表进行脏数据写的,但是MYSQL没有LRUW的
概念,所以所有的脏块正常情况下都是冲FLUSH列表中的脏块写入的。
这里给出MYSQL写脏块的机制(姜承晓MYSQL内幕innodb存储引擎)
FUZZY CHECKPOINT
1、MASTER进程每秒或者每10秒从FLUSH列表中按照顺序写入脏块
2、根据innodb_lru_scan_depth 参数设置默认5.6 1024,如果没有PAGE CLEANR 进程发现没有1024可用空闲页,刷出LRU链尾端的页
   如果有脏块触发脏块写show engine innodb status 来看及如下:
   Buffer pool size   70400
   Free buffers       32776–这里
   Database pages     34879
   Old database pages 12711
   Modified db pages  662
   
3、根据日志的使用情况,如果从show engine innodb status 来看及如下:
   Log sequence number 3100866076
   Log flushed up to   3100744765
   Pages flushed up to 3099998234
   Last checkpoint at  3099878300
   
   75%*日志量>Log sequence number-Last checkpoint at 不需要触发脏块写
   75%*日志量<Log sequence number-Last checkpoint at<90%*日志量触发异步写
   Log sequence number-Last checkpoint at>90%*日志量触发同步写

4、根据INNODB_MAX_DIRTY_PAGE_PCT设置默认75,当脏块数量达到75%进行脏数据库写
   Buffer pool size   70400
   Free buffers       32776
   Database pages     34879
   Old database pages 12711
   Modified db pages  662  —这里
   
sharp checkpoint 只有在关闭数据库的时候触发并且INNODB_FAST_SHUTDOWN=1的情况下(默认设置)

由此来看ORACLE的第一条和第二条属于正常刷新他们对应了MYSQL第一条
ORACLE的第三条属于脏块过多刷新对应MYSQL的第四条
ORACLE的第四条属于没有可用的BUFFER BLOCK对应MYSQL的第二条
ORACLE虽然没有根据日志量的使用情况来判断是否需要写脏块,但是ORACLE实际每次SWITCH LOGFILE
都会触发检查点,那么也就不存在这样的问题了。
最后思考一个问题,ORACLE中实际上可能会出现脏数据写赶不上日志切换的速度会出现等待
Checkpoint not complete,这个时候可能要加大LOGFILE 组来满足,或者减少LOG生成量,我想
MYSQL INNODB中应该也会有同样的情况发生,但是没有模拟出来,也不知道怎么查看。
我这里对比只是为了更加加深两种不同数据库的CHECKPOINT和脏数据写机制,同时加入了自己的一些理解,可能有误
给出参考文献尊重原著

参考:吕海波ORACLE内核揭秘
参考:姜承晓MYSQL内幕innodb存储引擎

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/7728585/viewspace-1764910/,如需转载,请注明出处,否则将追究法律责任。

主题测试文章,只做测试使用。发布者:深沉的少年,转转请注明出处:http://www.cxybcw.com/183392.html

联系我们

13687733322

在线咨询:点击这里给我发消息

邮件:1877088071@qq.com

工作时间:周一至周五,9:30-18:30,节假日休息

QR code