1. 为什么不能分配一个新日志文件
在批量大量导入数据的时候，我们可能会在服务器端的alert.log文件里面看到这样一条警告信息：
Thread 1 cannot allocate new log, sequence1466
CheckPoint not complete
Current lg#3 seq# 1465 mem#0: /home/ora 10g/oradata/ora 10g/redo03.log
警告消息中也可能指的是Archival required而不是CheckPoint not Complete, 但是一样的，DBA必须当心这种情况。引起的原因是： 如果数据库试图重用一个在线重做日志文件，但是发现做不到，就会把这样一条消息写到服务器上的日志文件中。
发现不能重用的原因有2个：
1. DBWR还没有完成重做日志所保护数据的检查点（checkpointing），也就DBWR还没有把该重做日志文件对应的脏数据块从buffer cache 刷新输出到磁盘。如果还没有输出到磁盘的话，这个时候重用重做日志文件，会使得这些没有输出到磁盘的脏数据无法通过重做日志文件重现。
2. ARCH进程还没有把重做日志文件复制到归档目标。因为如果还没复制就重用的话，就没办法备份那些还没有刷新输出到磁盘的数据。今后如果磁盘坏了的话，这些数据是无法恢复的。
这个时候DBWR或者ARCH将得到最大优先级以将redo块刷新输出到磁盘。这个时候，数据库会暂停用户所有的活动，因为此时已经没有地方记录用户的修改了。完成了检查点或者归档之后，一切又回归正常了。
假如你在进行一个大批量的修改操作，发现前1000行修改很快，停顿一下，然后下1000行修改很快，又停顿一下。如此循环。说明你的数据库可能遇到这方面的问题了。
要解决这个问题，有几种做法：
1. 想办法让DBWR进程更快，比如分配更多的DBWR进程，使用DBWRI/O辅进程
2. 增加更多的重做日志文件，如果一个日志文件满了，可以用另外一个日志文件。