今天发现alter.log有以下信息：

Thread 1 cannot allocate new log, sequence 6166

Private strand flush not complete

对于这个错误信息得解释如下：

当系统要重新利用某个日志文件的时候，系统需要将该日志文件所包括的buffer cache 中的dirty block 写到相应的数据文件。由于对于一个数据库操作而言，它可能产生的redo 量仅仅是几十字节，但是对于buffer cache中确是一个block （一般为8k）。所以，对于一个仅仅是几百M的日志文件，它所保护的buffer cache 可能是几个G

一旦发生"Thread 1 cannot allocate new log"，表明系统的checkpoint 没有来得及完成，也就是说 buffer cache 中的dirty data还没有完全写到数据文件，就已经有大量的日志需要写入到系统。而系统只能通知应用：checkpoint 还没有完成，你只能等待。这个时候，系统就基本处于hang 状态了 When the database waits on checkpoints,redo generation is stopped until the log switch is done

如果，我们在这个时候查看系统信息，就会发现：v$log中的日志状态大多处于active 状态； v$session_wait 中会有很多log file switch 事件的发生

解决办法： a. 添加更多的日志文件  b. 加大checkpoint 触发的频度  c. 减小redo log 的size d. 提高DBWR的效率 e. 为了更好的了解系统的运行，可以设置

log_checkpoint_interval = 0

log_checkpoint_timeout = 0

log_checkpoints_to_alert=True

9i以后可能大家都喜欢通过设置fast_start_mttr_target来控制instance recovery的粒度。但是仍然有两个参数一直影响着我们的checkpoint，就是他们：

log_checkpoint_interval
Oracle8.1版本后log_checkpoint_interval指的是两次checkpoint之间操作系统数据块的个数。checkpoint时Oracle把内存里修改过的数据块用DBWR写到物理文件，用LGWR写到日志和控制文件（在8i的时候lgwr进程在兼有ckpt进程的作用，呵呵。为了减轻我们本来就可能在高压情况下疲于奔命的LGWR兄弟的负担，Oracle引入了ckpt来更新我们的控制文件和数据文件头的SCN信息）。   
一般UNIX操作系统的数据块为512bytes。   
从性能优化的角度来说,建议log_checkpoint_interval=redologfilesizebytes / 512bytes,根据我们的online redo file的大小来指定我们数据块的个数.
from concept:
LOG_CHECKPOINT_INTERVAL specifies the frequency of checkpoints(用来指定检查点发生的频率) in terms of the number of redo log file blocks that can exist between an incremental checkpoint and the last block written to the redo log. This number refers to physical operating system blocks, not database blocks.
Regardless of this value, a checkpoint always occurs when switching from one online redo log file to another. Therefore, if the value exceeds the actual redo log file size, checkpoints occur only when switching logs. Checkpoint frequency is one of the factors that influence the time required for the database to recover from an unexpected failure.  

log_checkpoint_timeout   
Oracle8.1版本后log_checkpoint_timeout指的是两次checkpoint之间时间秒数(单位是秒)。   
Oracle建议不用这个参数来控制，因为事务(transaction)大小不是按时间等量分布的(事务的长短并不是最重要的，重要的是我们的业务逻辑和数据的完整性)。那么我们用log_checkpoint_interval参数控制会更好一些。   
 我们可以通过log_checkpoint_timeout=0来禁用此参数或者按默认的900。   
LOG_CHECKPOINT_TIMEOUT specifies (in seconds) the amount of time that has passed since the incremental checkpoint at the position where the last write to the redo log (sometimes called the tail of the log) occurred. This parameter also signifies that no buffer will remain dirty (in the cache) for more than integer seconds.
Specifying a value of 0 for the timeout disables time-based checkpoints. Hence, setting the value to 0 is not recommended unless FAST_START_MTTR_TARGET is set.