确认一个关于CKPT的问题

显示全部楼层 · 2005-10-30 17:05:33

CKPT每3秒钟执行一次，通知DWDMn将data_buffer中的脏数据写入到数据文件中，但是我不知道这些脏数据是已经提交的还是未提交的，想确认一下？谢谢。

千问 · 2005-10-30 17:05:33

可能是提交过的，也可能是未提交的！

千问 · 2005-10-30 17:05:33

ckpt 每3秒执行一次?

千问 · 2005-10-30 17:05:33

ckpt不是每三秒发生的，每三秒只是CKPT在控制文件里面记录检查点位置。写入的脏数据块不管是否提交，只要它是包括于检查点位置和日志文件末尾的更改的块，都将写入到数据文件中。

千问 · 2005-10-30 17:05:33

最初由 rushlight 发布
[B]CKPT每3秒钟执行一次，通知DWDMn将data_buffer中的脏数据写入到数据文件中，但是我不知道这些脏数据是已经提交的还是未提交的，想确认一下？谢谢。 [/B]
3秒只是在控制文件中，ckpt 进程去更新当前dbwr写到哪里了.

千问 · 2005-10-30 17:05:33

每三秒的是lgwr吧？checkpoin是三秒吗？

千问 · 2005-10-30 17:05:33

http://blog.itpub.net/post/94/63495
由于Oracle中LGWR和DBWR工作的不一致，Oracle引入了检查点的概念，用于同步数据库，保证数据库的一致性。在Oracle里面，检查点分为两种：完全检查点和增量检查点。下面我们分别介绍这两种检查点的作用：

1、完全检查点
在Oracle8i之前，数据库的发生的检查点都是完全检查点，完全检查点会将数据缓冲区里面所有的脏数据块写入相应的数据文件中，并且同步数据文件头和控制文件，保证数据库的一致。完全检查点在8i之后只有在下列两种情况下才会发生：
（1、）DBA手工执行alter system checkpoint的命令；
（2、）数据库正常shutdown（immediate,transcational,normal）。
由于完全检查点会将所有的脏数据库块写入，巨大的IO往往会影响到数据库的性能。因此Oracle从8i开始引入了增量检查点的概念。

2、增量检查点
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将离日志文件末尾最近的那个位置确认为检查点位置。

千问 · 2005-10-30 17:05:33

LGWR 和 DBWn 的触发条件中都有三秒这个事件，CKPT没有，这三个后台进程的触发的条件分别如下：
DBW0进程负责将数据缓存中的脏块写回磁盘，这个操作在下面的情形下发生：
Ø
服务器进程不断地将脏块从LRU列表移到脏列表，当脏列表的长度达到阀值时，DBW0将脏列表上的脏块写回磁盘；
Ø
服务器进程在LRU列表上检查太多的块都没能找到一个可用块的时候，DBW0直接从LRU列表上将脏块写回磁盘；
Ø
DBW0进程每三秒被激活一次，将LRU列表上的脏块移到脏列表，若脏列表长度达到阀值时，从脏列表上将脏块写回磁盘；
Ø
检查点发生时，DBW0将脏块从LRU列表移到脏列表，再从脏列表写脏块回磁盘；
Ø
数据库关闭时（不包括Shutdown Abort），DBW0将所有脏块写回磁盘；
Ø
表空间热备前，DBW0将属于这个表空间的所有脏块从LRU列表移到脏列表，然后从脏列表将脏块写回磁盘；
Ø
表空间离线时（Normal，Temporary），DBW0将属于这个表空间的所有脏块从LRU移到脏列表，然后从脏列表将脏块写回磁盘；
Ø
删除段时，DBW0先将这个段的脏块写回磁盘。
LGWR负责将日志缓存中的日志条写到当前的日志文件，这个操作的发生条件是：
Ø
应用程序发出Commit命令时；
Ø
三秒间隔已到时；
Ø
日志缓存三分之一满时；
Ø
日志缓存达到1M时；
Ø
数据库检查点发生时；
检查点可发生在下面情况中：
Ø
每次日志切换时；
Ø
数据库关闭时（不包括Shutdown Abort）
Ø
当通过设置初始化参数LOG_CHECKPOINT_INTERVAL、LOG_CHECKPOINT_TIMEOUT、FAST_START_IO_TARGET 或FAST_START_MTTR_TARGET指定条件满足时；
Ø
当数据库管理员手动请求时；

千问 · 2005-10-30 17:05:33

增量检查点是每三秒触发的。

千问 · 2005-10-30 17:05:33

最初由儿子属羊发布
[B]可能是提交过的，也可能是未提交的！ [/B]
既然如此, 那些未提交的也被写入到数据文件中了, 不就发生
问题了么?