请问oracle的commit等于锁表么?如果不一样,那如何锁表呢?另外,好像在sql server中insert语句后,就没有commit,这个和DB有关么?这个锁表还不是很明白,是说insert之后,commit之前,是锁表的状态?
◆ゝ簢棜﹏
oracle的commit就是提交数据（这里是释放锁不是锁表）,在未提交前你前面的操作更新的都是内存,没有更新到物理文件中.执行commit从用户角度讲就是更新到物理文件了,事实上commit时还没有写date file,而是记录了redo log file,要从内存写到data物理文件,需要触发检查点,由DBWR这个后台进程来写,这里内容有点多的,如果不深究的话你就理解成commit即为从内存更新到物理文件.锁有很多种,一般我们关注的都是DML操作产生的,比如insert,delete,update,select...for update都会同时触发表级锁和行级锁 补充：对的,insert以后commit之前是锁表的状态,其他事务无法对该表进行操作.
为您推荐：
其他类似问题
扫描下载二维码新手园地& & & 硬件问题Linux系统管理Linux网络问题Linux环境编程Linux桌面系统国产LinuxBSD& & & BSD文档中心AIX& & & 新手入门& & & AIX文档中心& & & 资源下载& & & Power高级应用& & & IBM存储AS400Solaris& & & Solaris文档中心HP-UX& & & HP文档中心SCO UNIX& & & SCO文档中心互操作专区IRIXTru64 UNIXMac OS X门户网站运维集群和高可用服务器应用监控和防护虚拟化技术架构设计行业应用和管理服务器及硬件技术& & & 服务器资源下载云计算& & & 云计算文档中心& & & 云计算业界& & & 云计算资源下载存储备份& & & 存储文档中心& & & 存储业界& & & 存储资源下载& & & Symantec技术交流区安全技术网络技术& & & 网络技术文档中心C/C++& & & GUI编程& & & Functional编程内核源码& & & 内核问题移动开发& & & 移动开发技术资料ShellPerlJava& & & Java文档中心PHP& & & php文档中心Python& & & Python文档中心RubyCPU与编译器嵌入式开发驱动开发Web开发VoIP开发技术MySQL& & & MySQL文档中心SybaseOraclePostgreSQLDB2Informix数据仓库与数据挖掘NoSQL技术IT业界新闻与评论IT职业生涯& & & 猎头招聘IT图书与评论& & & CU技术图书大系& & & Linux书友会二手交易下载共享Linux文档专区IT培训与认证& & & 培训交流& & & 认证培训清茶斋投资理财运动地带快乐数码摄影& & & 摄影器材& & & 摄影比赛专区IT爱车族旅游天下站务交流版主会议室博客SNS站务交流区CU活动专区& & & Power活动专区& & & 拍卖交流区频道交流区
家境小康, 积分 1418, 距离下一级还需 582 积分
论坛徽章:1
本帖最后由 蓦然princes 于
00:02 编辑
oracle中讲到transaction时提到，只有commit之后才一个事物才算完成。例如 一条insert语句，如果不commit
则，数据一致在SGA中，并没有写入Redolog file中。只有commit之后才会将SGA中的数据写入Redolog file中
一个transaction才算完成。
问题：在讲到后台进程时说：DBWR进程是由checkpoint时间触发、或者data Buffer cache达到一定界值之后触发
& && && &那就是说，如果一个insert语句执行完了，不进行commit，此时checkpoint时间发生，或者data Buffer cache
& && && &达到一定界限值，又或是，日志切换发生，都将触发DBWR进程进行数据写操作，但是在DBWR进行之前会
& && &&&触发LGWR进程。此时没有进行commit的数据自动从SGA中的Relog Buffer中写道Redolog file中。
请问：这样不是和transaction中说的如果没有commit事物就没有完成矛盾了吗？？？？也就是说，即使没有commit
& && & 那insert这个transaction也可能完成。
& &&&也就是说，任何操作不用commit进行提交，等到LGWR进程启动时（如：redolog Buffer达到1/3满，每三秒等）Sga中的redolog Buffer会写入到redolog file中， 这样的话，对于一个transaction，没有commit，也很有可能由于LGWR启动，将
sga中的数据写入到日志了啊。。。。我不知道哪里理解错了，请高手们指点小弟一下！！！感激不尽啊！！！
&&nbsp|&&nbsp&&nbsp|&&nbsp&&nbsp|&&nbsp&&nbsp|&&nbsp
论坛徽章:17
蓦然princes
& & 不矛盾的，一般checkpoint的时候，脏数据会写入日志和数据文件，即使是没有提交commit也会写入数据文件，同时在日志文件中会有相关的信息描述，未提交commit和提交commit的数据都会在数据文件中，区别在于日志文件中记录的信息不同，一旦自动或者是手动执行rollback回滚操作的话，未提交commit的数据会被恢复为前映像的状态，不知道我的回答你是否满意？
家境小康, 积分 1418, 距离下一级还需 582 积分
论坛徽章:1
还不能确定你说的是不是正解，因为除了你没有其他人恢复啊？？？？？为什么，难道是我问的问题没法回答吗？？？？回复
jackson198574
论坛徽章:17
本帖最后由 jackson198574 于
09:32 编辑
蓦然princes
官方文档Concept：
checkpoint
1. A data structure that marks the checkpoint position, which is the SCN in the redo
thread where instance recovery must begin. Checkpoints are recorded in the control
file and each data file header, and are a crucial element of recovery.
2. The writing of dirty data blocks in the database buffer cache to disk. The database
writer (DBWn)process writes blocks to disk to synchronize the buffer cache with the
data files.
Checkpoint Process (CKPT)
The checkpoint process (CKPT)updates the control file and data file headers with
checkpoint information and signals DBWnto write blocks to disk. Checkpoint
information includes the checkpoint position, SCN, location in online redo log to begin
recovery, and so on. As shown in Figure 15–4, CKPT does not write data blocks to data
files or redo blocks to online redo log files.
checkpoint.png (34.4 KB, 下载次数: 1)
09:28 上传
家境小康, 积分 1418, 距离下一级还需 582 积分
论坛徽章:1
高手，请问你的这段”不矛盾的，一般checkpoint的时候，脏数据会写入日志和数据文件，即使是没有提交commit也会写入数据文件，同时在日志文件中会有相关的信息描述，未提交commit和提交commit的数据都会在数据文件中，区别在于日志文件中记录的信息不同，一旦自动或者是手动执行rollback回滚操作的话，未提交commit的数据会被恢复为前映像的状态，不知道我的回答你是否满意？“内容在联机文旦哪里能找到，我找不到这段内容在官方文档中的讲解位置。。。。感激不尽回复
jackson198574
论坛徽章:17
蓦然princes
& & 不是官方文档里的，你谷歌一下吧。
论坛徽章:17
蓦然princes
& & 我这段描述回头看有问题，不过既然你看过官方文档了，最好自己多安排一些精力在研究官方文档上。
论坛徽章:7
commit做了什么？
commit的本质是把 log buffer里的日志数据块刷新到redo logfiles磁盘中，保证了数据部丢失。
白手起家, 积分 102, 距离下一级还需 98 积分
论坛徽章:0
2楼回答的很正确 闲来无聊 翻翻帖子查看: 2768|回复: 15
关于LGWR，CKPT，DBWR之间关系的问题？
论坛徽章:0
我有个问题，请各位大虾赐教：
比如有个SCOTT的会话，做了很多的DML的操作，但是没有COMMIT。只要不COMMIT，那么就不会触发LGWR。但是当REDO BUFFER 积累到三分之一满的时候，就自动触发了LGWR。而且当其中的REDO LOG文件满了，需要切换日志组的时候就又触发了CKPT。而CKPT触发之后，就会同时触发DBWR。那么这些数据就会被写入数据文件了。
ORACLE是怎么避免这种情况发生呢？
论坛徽章:0
麻烦解答的详细些。
论坛徽章:0
只有被提交的事务才会写到数据文件中！！
论坛徽章:86
Re: 关于LGWR，CKPT，DBWR之间关系的问题？
最初由 fadeaway 发布
[B]我有个问题，请各位大虾赐教：
比如有个SCOTT的会话，做了很多的DML的操作，但是没有COMMIT。只要不COMMIT，那么就不会触发LGWR。但是当REDO BUFFER 积累到三分之一满的时候，就自动触发了LGWR。而且当其中的REDO LOG文件满了，需要切换日志组的时候就又触发了CKPT。而CKPT触发之后，就会同时触发DBWR。那么这些数据就会被写入数据文件了。
ORACLE是怎么避免这种情况发生呢？ [/B]
oracle 没有避免& &未提交数据被写入数据文件中，因为这没问题，回滚段的变化前信息也一起被写入了文件，即使掉电也不怕
论坛徽章:4
最初由 Kill Japanese 发布
[B]只有被提交的事务才会写到数据文件中！！ [/B]
提交的事物有可能写入数据文件，也可能没有被写入数据文件。
没有提交的事物也是可能写入数据文件，也可能没有被写入数据文件.
论坛徽章:28
Re: Re: 关于LGWR，CKPT，DBWR之间关系的问题？
最初由 biti_rainy 发布
oracle 没有避免& &未提交数据被写入数据文件中，因为这没问题，回滚段的变化前信息也一起被写入了文件，即使掉电也不怕 [/B]
biti的就是准确，补充一点——rbs也是由redolog保护的，所以即使掉电的时候rbs没有进dbfile，rbs的redolog也会恢复rbs。
论坛徽章:0
Re: Re: 关于LGWR，CKPT，DBWR之间关系的问题？
最初由 biti_rainy 发布
oracle 没有避免& &未提交数据被写入数据文件中，因为这没问题，回滚段的变化前信息也一起被写入了文件，即使掉电也不怕 [/B]
那么ORACLE是如何知道哪些是没有被COMMIT过的呢。我知道应该是查找REDO LOG文件的。但是我想知道的更具体些。如何查找？查找什么信息？比如REDO LOG ，CONTROLFILE ，DATAFILE之间的同步是通过查看SCN来获得。它是否有什么东西可以让我们知道它COMMIT过与否！！
论坛徽章:0
Re: Re: 关于LGWR，CKPT，DBWR之间关系的问题？
最初由 biti_rainy 发布
oracle 没有避免& &未提交数据被写入数据文件中，因为这没问题，回滚段的变化前信息也一起被写入了文件，即使掉电也不怕 [/B]
还有假设这个时候另外一个用户访问这个数据，那他怎么知道应该访问的其实是回滚段里的数据呢。
论坛徽章:86
这说来话太长了
1: 先弄清楚回滚段是干吗的，是查回滚段不是redo log 。
2: 再搞清楚oracle里面一致读的概念
不过没关心，只要有心，慢慢就会了
你就去多搜索下 回滚段 和 一致读&&的文章多看看吧
还有关键字就是 block and&&ITL
招聘 : 论坛徽章:3
LGWR并不是没有commit就不写~可以再看看concept~
明确redo和undo的不同作用~
明确检查点的作用和过程，还有触发条件~
深入点的话了解下增量检查点与完全检查点~
itpub.net All Right Reserved. 北京皓辰网域网络信息技术有限公司版权所有　　　　
　北京市公安局海淀分局网监中心备案编号：　广播电视节目制作经营许可证：编号（京）字第1149号新手园地& & & 硬件问题Linux系统管理Linux网络问题Linux环境编程Linux桌面系统国产LinuxBSD& & & BSD文档中心AIX& & & 新手入门& & & AIX文档中心& & & 资源下载& & & Power高级应用& & & IBM存储AS400Solaris& & & Solaris文档中心HP-UX& & & HP文档中心SCO UNIX& & & SCO文档中心互操作专区IRIXTru64 UNIXMac OS X门户网站运维集群和高可用服务器应用监控和防护虚拟化技术架构设计行业应用和管理服务器及硬件技术& & & 服务器资源下载云计算& & & 云计算文档中心& & & 云计算业界& & & 云计算资源下载存储备份& & & 存储文档中心& & & 存储业界& & & 存储资源下载& & & Symantec技术交流区安全技术网络技术& & & 网络技术文档中心C/C++& & & GUI编程& & & Functional编程内核源码& & & 内核问题移动开发& & & 移动开发技术资料ShellPerlJava& & & Java文档中心PHP& & & php文档中心Python& & & Python文档中心RubyCPU与编译器嵌入式开发驱动开发Web开发VoIP开发技术MySQL& & & MySQL文档中心SybaseOraclePostgreSQLDB2Informix数据仓库与数据挖掘NoSQL技术IT业界新闻与评论IT职业生涯& & & 猎头招聘IT图书与评论& & & CU技术图书大系& & & Linux书友会二手交易下载共享Linux文档专区IT培训与认证& & & 培训交流& & & 认证培训清茶斋投资理财运动地带快乐数码摄影& & & 摄影器材& & & 摄影比赛专区IT爱车族旅游天下站务交流版主会议室博客SNS站务交流区CU活动专区& & & Power活动专区& & & 拍卖交流区频道交流区
白手起家, 积分 29, 距离下一级还需 171 积分
论坛徽章:0
本帖最后由 houhuaw 于
23:58 编辑
onconfig文件中CKPTINTVL设定为300s，可实际检查点间隔时间大部份为10分钟，也有少部分是5分钟的，但没有超过10分钟间隔仍旧不执行的。
比如上一个检查点执行时间是00：00：00
在00：05：00执行onstat -R显示大部份都是0 dirty（这台机子业务量很大，不可能不更新数据库，confonfig LRU配置为：BUFFERPOOL& && &size=2K,buffers=500000,lrus=32,lru_min_dirty=0.390000,lru_max_dirty=0.780000）：
& onstat -R显示：
IBM Informix Dynamic Server Version 11.10.FC2& &&&-- On-Line -- Up 168 days 10:22:38 -- 1375204 Kbytes
Buffer pool page size: 2048
0 dirty, 500000 queued, 500000 total, 524288 hash buckets, 2048 buffer size
start clean at& &0.780% (of pair total) dirty, or 122 buffs dirty, stop at
大部份情况下过了5分钟后才会出现lru buffer中dirty不为0的情况，大部份情况为19 dirty。
&onstat -F显示：
IBM Informix Dynamic Server Version 11.10.FC2& &&&-- On-Line -- Up 168 days 10:17:55 -- 1375204 Kbytes
Fg Writes& &&&LRU Writes& & Chunk Writes
0& && && && & 1368228& && & 1572810& && &
& onstat -p显示：
IBM Informix Dynamic Server Version 11.10.FC2& &&&-- On-Line -- Up 168 days 10:20:47 -- 1375204 Kbytes
dskreads& &pagreads& &bufreads& &%cached dskwrits& &pagwrits& &bufwrits& &%cached
3903022& & && 99.95& &3411397& & 9564319& & & &95.93&&
isamtot& & open& && & start& && &read& && & write& && &rewrite& & delete& &&&commit& &&&rollbk
&&&& & &139680& &&&& &626166& &&&2
gp_read& & gp_write& &gp_rewrt& &gp_del& &&&gp_alloc& &gp_free& & gp_curs& &
0& && && & 0& && && & 0& && && & 0& && && & 0& && && & 0& && && & 0& && && &
ovlock& &&&ovuserthread ovbuff& &&&usercpu&&syscpu& &numckpts& &flushes& &
0& && && & 0& && && && &0& && && & 10.57 27426& && &27929& &&&
bufwaits& &lokwaits& &lockreqs& &deadlks& & dltouts& & ckpwaits& &compress& &seqscans&&
29885& && &0& && && &
0& && && & 0& && && & 749& && &&&1811164& & 2038837& &
ixda-RA& & idx-RA& &&&da-RA& && &RA-pgsused lchwaits&&
338& && &&&0& && && & 134146& &&&134484& &&&
&&nbsp|&&nbsp&&nbsp|&&nbsp&&nbsp|&&nbsp&&nbsp|&&nbsp
大富大贵, 积分 13273, 距离下一级还需 6727 积分
论坛徽章:11
& & onstat -g ckp&&看最近20个检查点的详细情况。。
白手起家, 积分 29, 距离下一级还需 171 积分
论坛徽章:0
本帖最后由 houhuaw 于
15:56 编辑
& onstat -g ckp& && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && &
& && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && &
IBM Informix Dynamic Server Version 11.10.FC2 -- On-Line -- Up 169 days 01:59:21 -- 1375204 Kbytes& && && && && && && && && && && && && &
& && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && &
AUTO_CKPTS=On& &RTO_SERVER_RESTART=Off& && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && &
& && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && &
& && && && && && && && && && && && && && && && && && && && && & Critical Sections& && && && && && && && &&&Physical Log& & Logical Log& &
& && && && && & Clock& && && && && && && && && && && && && && && && & Total Flush Block #& && &Ckpt&&Wait&&Long&&# Dirty& &Dskflu&&Total& & Avg& & Total& & Avg& &
Interval& & Time& && &&&Trigger& && && &LSN& && && && && & Time Time&&Time Waits Time&&Time&&Time&&Buffers& &/Sec& & Pages& & /Sec& &Pages& & /Sec&&
37955& && &13:00:01 *User& && && &&&273:0x35f03c& &0.0& &0.0& &0.0& &1& && &0.0& &&&0.0& & 0.0& &&&0& && && &&&0& && && &&&0& && &&&0& && && & 1& && &&&0& &&&
37956& && &13:05:14&&CKPTINTVL&&273:0x.0& &0.0& &0.0& &0& && &0.0& &&&0.0& &0.0& & 19& && && & 19& && && &19& && & 0& && && & 3& && &&&0& &&&
37957& && &13:15:14&&CKPTINTVL&&273:0x.0& &0.0& &0.0& &0& && &0.0& & 0.0& & 0.0& & 19& && && & 19& && && &19& && & 0& && && & 3& && &&&0& &&&
37958& && &13:25:15&&CKPTINTVL&&273:0x36f018& &0.0& &0.0& &0.0& &0& && &0.0& & 0.0& & 0.0& & 43& && && & 43& && && &42& && & 0& && && &10& && & 0& &&&
37959& && &13:35:16&&CKPTINTVL&&273:0x.0& &0.0& &0.0& &0& && &0.0& & 0.0& & 0.0& & 19& && && & 19& && && &19& && & 0& && && &&&3& && &&&0& &&&
37960& && &13:45:16&&CKPTINTVL&&273:0x.0& &0.0& &0.0& &0& && &0.0& & 0.0& & 0.0& & 19& && && & 19& && && &19& && & 0& && && &&&3& && &&&0& &&&
37961& && &13:55:17&&CKPTINTVL&&273:0x.0& &0.0& &0.0& &0& && &0.0& & 0.0& & 0.0& & 19& && && & 19& && && &19& && & 0& && && &&&3& && &&&0& &&&
37962& && &14:05:19&&CKPTINTVL&&273:0x37b018&&0.0& &0.0& &0.0& &0& && &0.0& & 0.0& & 0.0& & 19& && && & 19& && && &19& && & 0& && && &&&3& && &&&0& &&&
37963& && &14:15:20&&CKPTINTVL&&273:0x37e6f8& &0.0& &0.0& &0.0& &0& && &0.0& & 0.0& & 0.0& & 25& && && & 25& && && &25& && & 0& && && &&&3& && &&&0& &&&
37964& && &14:20:20&&CKPTINTVL&&273:0x.0& &0.0& &0.0& &0& && &0.0& & 0.0& & 0.0& & 203& && &&&203& && & 88& && & 0& && && &&&259& & 0& &&&
37965& && &14:25:21&&CKPTINTVL&&273:0x4b& &0.0& &0.0& &0& && &0.0& & 0.0& & 0.0& & 80& && && & 80& && && &77& && & 0& && && &&&51& && &0& &&&
37966& && &14:35:22&&CKPTINTVL&&273:0x5bb018&&0.0& &0.0& &0.0& &0& && &0.0& & 0.0& & 0.0& & 194& && &&&194& && & 79& && & 0& && && &&&263& & 0& &&&
37967& && &14:45:23&&CKPTINTVL&&273:0x5be018&&0.0& &0.0& &0.0& &0& && &0.0& & 0.0& & 0.0& & 19& && && & 19& && && &19& && & 0& && && &&&3& && &&&0& &&&
37968& && &14:50:23&&CKPTINTVL&&273:0x5bf608& &0.0& &0.0& &0.0& &0& && &0.0& & 0.0& & 0.0& & 6& && && && &6& && && &&&7& && && &0& && && &&&1& && &&&0& &&&
37969& && &14:55:24&&CKPTINTVL&&273:0x5c25e4&&0.0& &0.0& &0.0& &0& && &0.0& & 0.0& &&&0.0& & 25& && && &25& && && &25& && & 0& && && &&&3& && &&&0& &&&
37970& && &15:00:24&&CKPTINTVL&&273:0x5c& &0.0& &0.0& &0& && &0.0& & 0.0& &&&0.0& & 2& && && &&&2& && && &&&0& && && &0& && && &&&1& && &&&0& &&&
37971& && &15:05:25&&CKPTINTVL&&273:0x5c& &0.0& &0.0& &0& && &0.0& & 0.0& &&&0.0& & 19& && && &19& && && &19& && & 0& && && &&&3& && &&&0& &&&
37972& && &15:15:26&&CKPTINTVL&&273:0x5c95e4&&0.0& &0.0& &0.0& &0& && &0.0& & 0.0& &&&0.0& & 25& && && &25& && && &25& && & 0& && && &&&3& && &&&0& &&&
37973& && &15:20:26&&CKPTINTVL&&273:0x5ca608&&0.0& &0.0& &0.0& &0& && &0.0& & 0.0& &&&0.0& & 6& && && &&&6& && && &&&7& && && &0& && && &&&1& && &&&0& &&&
37974& && &15:25:26&&CKPTINTVL&&273:0x5d& &0.0& &0.0& &0& && &0.0& & 0.0& &&&0.0& & 36& && &&&36& && && &35& && & 0& && && &&&8& && &&&0& &&&
& && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && &
Max Plog& && && &Max Llog& && & Max Dskflush& &Avg Dskflush& &Avg Dirty& && &Blocked& && && && && && && && && && && && && && && && && && && && &
pages/sec& && &pages/sec& && &Time& && && && && &pages/sec& && & pages/sec& && &Time& && && && && && && && && && && && && && && && && && && && && &
8450& && && && &&&6008& && && && && &0& && && && && && &&&1& && && && && && && &&&0& && && && && && & 0
家境小康, 积分 1576, 距离下一级还需 424 积分
论坛徽章:0
& & 要命的CHECKPOINT，为了不影响运行，优先级还是比较低，而且有CHK_REQ这种状态，如果你想了解到底怎么做，加上TRACECKPT环境变量，不要过要重启生效，结果好像在ONLINE.LOG里，好久没有用了。
大富大贵, 积分 13273, 距离下一级还需 6727 积分
论坛徽章:11
& onstat -g ckp& && && && && && && && && && && && && && && && && && && && && && && && && && && && &&&...
houhuaw 发表于
& & 有的是5分钟，有的是10分钟，可能在10分钟内并没有update/insert操作（或者说明使用了buffered log的库，更新并没有刷回磁盘），故数据库认为这个ckptinteval内数据库没有改变，等到下一个ckptinteval才做检查点。。
白手起家, 积分 29, 距离下一级还需 171 积分
论坛徽章:0
有几十台这样的机子，onconfig配置都是一模一样的，数据库表结构也都是一模一样的，数据库操作也具有同质性，但却有几台出现了这样的问题，其他的都是5分钟正常执行，所用的库是with buffered log。
&3sane” 兄CHK_REQ是什么状态啊，可否指点一二。
以下是以前打开XTRACE跟踪的结果：
Component& && && & Feature& && && &File& && && & Line& & Pid& &&&Time Stamp&&csvr thrd& && &trans rstcb&&session MESSAGE
XTF_CHECKPOINT XTF_DEBUG&&rsrecvr.c&& 00:42:31 1& &0& & 8& & 8cc need_to_ckpt() intvl 14071 phyused 17 n_dirty_buffs 17 dskflush_per_sec 1000 plogs_per_sec 8450 llogs_per_sec 6008
.......................
XTF_CHECKPOINT XTF_DEBUG&&rsrecvr.c&& 00:42:31 1& &0& & 8& & 8cc need_to_ckpt() intvl 14071 phyused 17 n_dirty_buffs 17 dskflush_per_sec 1000 plogs_per_sec 8450 llogs_per_sec 6008
XTF_CHECKPOINT XTF_DEBUG&&rsrecvr.c&& 00:46:17 47&&0& & 8& & 8cc checkpoint start - intvl 14071 phyused 17 physize 500000
XTF_CHECKPOINT XTF_DEBUG&&rsrecvr.c&& 00:46:17 48&&0& & 8& & 8cc checkpoint active
XTF_CHECKPOINT XTF_DEBUG&&rsrecvr.c&& 00:46:17 49&&0& & 8& & 8cc prev intvl 14070 cur intvl 14071 phypos 85327 logpos 128:de77018 cp_dbsoffset 4&&cp_chkoffset 6 cp_mchkoffset 8
XTF_CHECKPOINT XTF_DEBUG&&rsrecvr.c&& 00:46:17 50&&0& & 8& & 8cc checkpoint normal broadcast
XTF_FLUSHER& && & XTF_DEBUG&&rsflush.c& &647& &:17 51&&0& & 8& & 8cc dskflush(0 1 14071)
XTF_CHECKPOINT XTF_DEBUG&&rsrecvr.c&& 00:46:17 52&&0& & 8& & 8cc dskflush over 0 phyused 17
XTF_CHECKPOINT XTF_DEBUG&&rsrecvr.c&& 00:46:17 53&&0& & 8& & 8cc write reserved pages
XTF_CHECKPOINT XTF_DEBUG&&rsrecvr.c&& 00:46:17 54&&0& & 8& & 8cc ckptwrite() 1:2
XTF_CHECKPOINT XTF_DEBUG&&rsrecvr.c&& 00:46:17 55&&0& & 8& & 8cc ckpt done time_between 602 run_time 0 plogs/S 0 llogs/S 0 phyused 0 blockflags 0
XTF_CHECKPOINT XTF_DEBUG&&rsrecvr.c&& 00:51:17 56&&0& & 8& & 8cc checkpoint start - intvl 14072 phyused 0 physize 500000
XTF_CHECKPOINT XTF_DEBUG&&rsrecvr.c&& 00:52:32 57&&0& & 8& & 8cc need_to_ckpt() intvl 14072 phyused 17 n_dirty_buffs 17 dskflush_per_sec 1000 plogs_per_sec 8450 llogs_per_sec 6008
.....................
XTF_CHECKPOINT XTF_DEBUG&&rsrecvr.c&& 00:56:17 103 0& & 8& & 8cc checkpoint start - intvl 14072 phyused 17 physize 500000
XTF_CHECKPOINT XTF_DEBUG&&rsrecvr.c&& 00:56:17 104 0& & 8& & 8cc checkpoint active
XTF_CHECKPOINT XTF_DEBUG&&rsrecvr.c&& 00:56:17 105 0& & 8& & 8cc prev intvl 14071 cur intvl 14072 phypos 85344 logpos 128:de7a018 cp_dbsoffset 4&&cp_chkoffset 7 cp_mchkoffset 8
XTF_CHECKPOINT XTF_DEBUG&&rsrecvr.c&& 00:56:17 106 0& & 8& & 8cc checkpoint normal broadcast
XTF_FLUSHER& && & XTF_DEBUG&&rsflush.c& &647& &:17 107 0& & 8& & 8cc dskflush(0 1 14072)
XTF_CHECKPOINT XTF_DEBUG&&rsrecvr.c&& 00:56:17 108 0& & 8& & 8cc dskflush over 0 phyused 17
XTF_CHECKPOINT XTF_DEBUG&&rsrecvr.c&& 00:56:17 109 0& & 8& & 8cc write reserved pages
XTF_CHECKPOINT XTF_DEBUG&&rsrecvr.c&& 00:56:17 110 0& & 8& & 8cc ckptwrite() 1:3
XTF_CHECKPOINT XTF_DEBUG&&rsrecvr.c&& 00:56:17 111 0& & 8& & 8cc ckpt done time_between 600 run_time 0 plogs/S 0 llogs/S 0 phyused 0 blockflags 0
XTF_FLUSHER& && & XTF_DEBUG&&rsflush.c& &647& & :01 112 0& & 50& &8cc35ba20 13dskflush(0 1 0)
XTF_CHECKPOINT XTF_DEBUG&&rsrecvr.c&& 01:00:01 113 0& & 8& & 8cc checkpoint start - intvl 14073 phyused 0 physize 500000
XTF_CHECKPOINT XTF_DEBUG&&rsrecvr.c&& 01:00:01 114 0& & 8& & 8cc checkpoint active
XTF_CHECKPOINT XTF_DEBUG&&rsrecvr.c&& 01:00:01 115 0& & 8& & 8cc prev intvl 14072 cur intvl 14073 phypos 85344 logpos 128:de7b03c cp_dbsoffset 4&&cp_chkoffset 7 cp_mchkoffset 8
XTF_FLUSHER& && &&&XTF_DEBUG&&rsflush.c&&647& & :01 116 0& & 8& & 8cc dskflush(0 1 14073)
XTF_CHECKPOINT XTF_DEBUG&&rsrecvr.c&& 01:00:01 117 0& & 8& & 8cc dskflush over 0 phyused 0
XTF_CHECKPOINT XTF_DEBUG&&rsrecvr.c&& 01:00:01 118 0& & 8& & 8cc write reserved pages
XTF_CHECKPOINT XTF_DEBUG&&rsrecvr.c&& 01:00:01 119 0& & 8& & 8cc ckptwrite() 1:2
XTF_CHECKPOINT XTF_DEBUG&&rsrecvr.c&& 01:00:01 120 0& & 8& & 8cc ckpt done time_between 224 run_time 0 plogs/S 0 llogs/S 0 phyused 0 blockflags 0
XTF_CHECKPOINT XTF_DEBUG&&rsrecvr.c&& 01:02:32 121 0& & 8& & 8cc need_to_ckpt() intvl 14074 phyused 17 n_dirty_buffs 17 dskflush_per_sec 1000 plogs_per_sec 8450 llogs_per_sec 6008
XTF_CHECKPOINT XTF_DEBUG&&rsrecvr.c&& 01:02:37 122 0& & 8& & 8cc need_to_ckpt() intvl 14074 phyused 17 n_dirty_buffs 17 dskflush_per_sec 1000 plogs_per_sec 8450 llogs_per_sec 6008
..............................
XTF_CHECKPOINT XTF_DEBUG&&rsrecvr.c&& 01:05:17 154 0& & 8& & 8cc need_to_ckpt() intvl 14074 phyused 17 n_dirty_buffs 17 dskflush_per_sec 1000 plogs_per_sec 8450 llogs_per_sec 6008
XTF_CHECKPOINT XTF_DEBUG&&rsrecvr.c&& 01:05:17 155 0& & 8& & 8cc checkpoint start - intvl 14074 phyused 17 physize 500000
XTF_CHECKPOINT XTF_DEBUG&&rsrecvr.c&& 01:05:17 156 0& & 8& & 8cc checkpoint active
XTF_CHECKPOINT XTF_DEBUG&&rsrecvr.c&& 01:05:17 157 0& & 8& & 8cc prev intvl 14073 cur intvl 14074 phypos 85361 logpos 128:de7e018 cp_dbsoffset 4&&cp_chkoffset 6 cp_mchkoffset 8
XTF_CHECKPOINT XTF_DEBUG&&rsrecvr.c&& 01:05:17 158 0& & 8& & 8cc checkpoint normal broadcast
XTF_FLUSHER& && & XTF_DEBUG&&rsflush.c& &647& & :17 159 0& & 8& & 8cc dskflush(0 1 14074)
XTF_CHECKPOINT XTF_DEBUG&&rsrecvr.c&& 01:05:17 160 0& & 8& & 8cc dskflush over 0 phyused 17
XTF_CHECKPOINT XTF_DEBUG&&rsrecvr.c&& 01:05:17 161 0& & 8& & 8cc write reserved pages
XTF_CHECKPOINT XTF_DEBUG&&rsrecvr.c&& 01:05:17 162 0& & 8& & 8cc ckptwrite() 1:3
XTF_CHECKPOINT XTF_DEBUG&&rsrecvr.c&& 01:05:17 163 0& & 8& & 8cc ckpt done time_between 316 run_time 0 plogs/S 0 llogs/S 0 phyused 0 blockflags 0
XTF_CHECKPOINT XTF_DEBUG&&rsrecvr.c&& 01:10:17 164 0& & 8& & 8cc checkpoint start - intvl 14075 phyused 0 physize 500000
XTF_CHECKPOINT XTF_DEBUG&&rsrecvr.c&& 01:12:32 165 0& & 8& & 8cc need_to_ckpt() intvl 14075 phyused 17 n_dirty_buffs 17 dskflush_per_sec 1000 plogs_per_sec 8450 llogs_per_sec 6008
家境小康, 积分 1576, 距离下一级还需 424 积分
论坛徽章:0
& & CHK_REQ也许我拼错了，就是等待做CHECKPOINT，这会延迟CHECKPOINT的执行时间，看起来间隔就长了。从LOG里看还真有PHYLOG为0 used的情况，回头看，你设的LRU_MIN很小，所以都被LRU清理掉了。而且修改量不是太大，留给CHECKPOINT做的事情就不多了。
& &另外建议你尽快升级数据库版本，不要用11.10或11.20的版本。
白手起家, 积分 29, 距离下一级还需 171 积分
论坛徽章:0
& & &就是等待做CHECKPOINT，这会延迟CHECKPOINT的执行时间&，CHECKPOINT不是到了CKPTINTVL间隔的时间或者其他事件触发的吗，这个是否等待做CHECKPOINT在什么地方可以设置？请指教
& &&PHYLOG为0 used“，phyused 0指的是LRU的buffer 0个为dirty的吧。为啥5分钟之内不往LRU里面写东西呢？不可能没有修改数据库记录的操作吧，其他业务量小得多的或者没有承载业务在那里空转的机子都 按时执行了检查点，这台机子没有承载业务之前就出现了这个情况。其他机子没有承载业务之前也是按时执行检查点。
& &&你设的LRU_MIN很小，所以都被LRU清理掉了&，有几十台这样的机子，配置都一样，就这几台出现了这个问题。所以我很迷惑。
白手起家, 积分 29, 距离下一级还需 171 积分
论坛徽章:0
& & &可能在10分钟内并没有update/insert操作（或者说明使用了buffered log的库，更新并没有刷回磁盘），故数据库认为这个ckptinteval内数据库没有改变，等到下一个ckptinteval才做检查点&
& &&&有几十台从数据库本身配置看来一样的机子，在没有承载业务之前都是按时执行检查点的，这台机子没有承载业务之前就出现了这个问题，承载业务后问题依旧。没有承载业务就是说：主机和磁阵启动状态，数据库Online状态，但没有什么东东来更改数据库记录。
大富大贵, 积分 13273, 距离下一级还需 6727 积分
论坛徽章:11
& & 从你的onstat -g ckp的输出上看
37960& && &13:45:16&&CKPTINTVL&&273:0x.0& &0.0& &0.0& &0& && &0.0& & 0.0& & 0.0& & 19& && && & 19& && && &19& && & 0& && && &&&3& && &&&0& &&&
37961& && &13:55:17&&CKPTINTVL&&273:0x.0& &0.0& &0.0& &0& && &0.0& & 0.0& & 0.0& & 19& && && & 19& && && &19& && & 0& && && &&&3& && &&&0& &&&
37962& && &14:05:19&&CKPTINTVL&&273:0x37b018&&0.0& &0.0& &0.0& &0& && &0.0& & 0.0& & 0.0& & 19& && && & 19& && && &19& && & 0& && && &&&3& && &&&0& &&&
37963& && &14:15:20&&CKPTINTVL&&273:0x37e6f8& &0.0& &0.0& &0.0& &0& && &0.0& & 0.0& & 0.0& & 25& && && & 25& && && &25& && & 0& && && &&&3& && &&&0& &&&
37964& && &14:20:20&&CKPTINTVL&&273:0x.0& &0.0& &0.0& &0& && &0.0& & 0.0& & 0.0& & 203& && &&&203& && & 88& && & 0& && && &&&259& & 0& &&&
37965& && &14:25:21&&CKPTINTVL&&273:0x4b& &0.0& &0.0& &0& && &0.0& & 0.0& & 0.0& & 80& && && & 80& && && &77& && & 0& && && &&&51& && &0& &&&
每次检查点间的逻辑日志量都非常少的。。就可能出现一段时间没有更新（或者更新在仍在缓存里），导致数据库认为没有变动的。。故不需要做检查点的。。
如37960 到 37961 之间的逻辑日志差为 0x378018& &-&&0x375018 = 0x 字节，这其中还包括上次检查点的记录的量。。这个是非常小的。。
而37964 到 37965 之间的逻辑日志差为 0x4b4018& &-&&0x481664 = 0x329B4(207284)字节，这个应该已经超过逻辑日志缓冲区的大小了，因此有提交，有改变，做了检查点。。
BTW：检查点是为了保证数据库一致的机制。。只要它做就好了。。。5分钟一次，10分钟一次并没有什么问题。。。