造成数据库checkpoint时间较长的可能原因有哪些

1、系统补丁没打完全，导致关于系统数据库在执行io *** 作时，写数据的时间较长，且占用率较高，导致数据库checkpoint时间较长。

2、informix的onconfig中的某些参数（如：buffer）配置不规范或者不符合现网需求，导致系统性能下降，不能发挥数据库的性能。

3、数据库系统未对某些大数据量表进行优化，导致执行checkpoint的时间较长。

什么是checkpoint?

checkpoint是个数据库事件，他将已修改的数据从高速缓存刷新到磁盘，并更新控制文件和数据文件。

什么时候发生checkpoint?

我们知道了checkpoint会刷新脏数据，但什么时候会发生checkpoint呢？以下几种情况会触发checkpoint。

1.当发生日志组转换的时候

2.当符合 LOG_CHECKPOINT_TIMEOUT，LOG_CHECKPOINT_INTERVAL，fast_start_io_target,fast_start_mttr_target 参数设置的时候

3.当运行ALTER SYSTEM SWITCH LOGFILE的时候

4.当运行ALTER SYSTEM CHECKPOINT的时候

5.当运行alter tablespace XXX begin backup，end backup的时候

6.当运行alter tablespace ,datafile offline的时候

当我们进行redo 切换的时候，会触发checkpoint 事件。 触发该事件有5个条件。 下文有说明。 Checkpoint做的事情之一是触发DBWn把buffer cache中的Dirty cache磁盘。另外就是把最近的系统的SCN更新到datafile header和control file（每一个事务都有一个SCN），做第一件事的目的是为了减少由于系统突然宕机而需要的恢复时间，做第二件事实为了保证数据库的一致性。

Checkpoint will flush dirty block to datafile, 从而触发DBWn书写dirty buffer，等到redo log覆盖的dirty block全部被写入datafile后才能使用redo log（循环使用），如果DBWn写入过慢，LGWR必须等待DBWn完成，则这时会出现“checkpoint not completed！”。 所以当出现checkpointnot competed的时候，还会伴随cannot allocate new log的错误。

如果遇到这个问题，可以增加日志组和增大日志文件，当然也可以修改 checkpoint参数使得检查点变频繁一些。

在出现这个错误的时候，数据库是短暂hang住的，等待checkpoint的完成。 在hang住的时候，没有日志产生。

---