报错信息：
Thread 1 cannot allocate new log, sequence 187398
Checkpoint not complete
处理方法：
查看REDO日志组
select group#,member from v$logfile;
select group#,sequence#,bytes,members,status from v$log; 查看每组日志的状态
alter database add logfile group 4 ('/opt/oradata/orclbj/redo04.log') size 200M; 增加1组日志组 视情况而定增加日志组的大小。
alter database add logfile group 5 ('/opt/oradata/orclbj/redo05.log') size 200M;
alter database add logfile group 6 ('/opt/oradata/orclbj/redo06.log') size 200M;
3、alter system switch logfile; 切换日志组
4、alter database drop logfile group 1; 删除日志组1 在线增加日志组的时候，删除日志组的时候只能删除 日志组状态为 INACTIVE 的日志组。
5、alter database add logfile group 1 ('/opt/oradata/orclbj/redo1.log') size 200M;--新创建的为redo1,上一步drop掉的为redo01
拓展内容：
Thread 1 cannot allocate new log, sequence 2594
Checkpoint not complete
这个实际上是个比较常见的错误。通常来说是因为在日志被写满时会切换 日志组，这个时候会触发一次checkpoint，DBWR会把内存中的脏块往数据文件中写，只要没写结束就不会释放这个日志组。如果归档模式被开启的 话，还会伴随着ARCH写归档的过程。如果redo log产生的过快，当CPK或归档还没完成，LGWR已经把其余的日志组写满，又要往当前的日志组里面写redo log的时候，这个时候就会发生冲突，数据库就会被挂起。并且一直会往alert.log中写类似上面的错误信息。
警告消息中也可能指出Archival required而不是Checkpoint not complete，但是效果几乎都一样。必须当心这种情况。如果数据库试图重用一个在线重做日志文件，但是发现做不到，就会把这样一条消息写到服务器上的alert.log中。如果DBWR还没有完成重做日志所保护数据的检查点(checkpointing)，或者ARCH还没有把重做日志文件复制到归档目标，就会发生这种情况。对最终用户来说，这个时间点上数据库实际上停止了。它会原地不动。DBWR或ARCH将得到最大的优先级以将redo块刷新输出到磁盘。完成了检查点或归档之后，一切又回归正常。数据库之所以暂停用户的活动，这是因为此时已经没地方记录用户所做的修改了。Oracle试图重用一个在线重做日志文件，但是由于万一出现失败而要恢复数据库时可能还需要这个文件(Checkpoint not complete)，或者由于归档进程尚未完成这个文件的复制(Archival required)，所以Oracle必须等待(相应地，最终用户也必须等待)，直到能安全地重用这个重做日志文件为止。
如果你看到会话因为一个“日志文件切换”、“日志缓冲区空间”或“日志文件切换检查点或归档未完成”等待了很长时间，就很可能遇到了这个问题。如果日志文件大小不合适，或者DBWR和ARCH太慢，在漫长的数据库修改期间，你就会注意到这个问题。
要解决这个问题，有下面几种做法
.让DBWR更快一些。让DBA对DBWR调优，为此可以启用ASYNC I/O、使用DBWR I/O从属进程，或者使用多个DBWR进程。看看系统产生的I/O，查看是否有一个磁盘(或一组磁盘)“太热”，相应地需要将数据散布开。这个建议对ARCH也适用。这种做法的好处是，不用付出什么代价就能有所收获，性能会提高，而且不必修改任何逻辑/结构/代码。这种方法确实没有缺点。
.增加更多重做日志文件。在某些情况下，这会延迟Checkpoint not complete的出现，而且过一段时间后，可以把Checkpoing not complete延迟得足够长，使得这个错误可能根本不会出现。这个方法也同样适用于Archival required消息。这种方法的好处是可以消除系统中的“暂停”。其缺点是会消耗更多的磁盘空间，但是在此利远远大于弊。
.重新创建更大的日志文件。这会扩大填写在线重做日志与重用这个在线重做日志文件之间的时间间隙。如果重做日志文件的使用呈“喷射状”，这种方法同样适用于Archival required消息。倘若一段时间内会大量生成日志(如每晚加载、批处理等)，其后一段时间却相当平静，如果有更大的在线重做日志，就能让ARCH在平静的期间有足够的时间“赶上来”。这种方法的优缺点与前面增加更多文件的方法是一样的。另外，它可能会延迟检查点的发生，由于每个日志切换都会发生检查点，而现在日志切换间隔会更大。
.让检查点发生得更频繁、更连续。可以使用一个更小的块缓冲区缓存，或者使用诸如FAST_START_MTTR_TARGET、LOG_CHECKPOINT_INTERVALT和LOG_CHECKPOINT_TIMEOUT之类的参数设置。这会强制DBWR更频繁地刷新输出脏块。这种方法的好处是，失败恢复的时间会减少。在线重做日志中应用的工作肯定更少。其缺点是，如果经常修改块，可能会更频繁地写至磁盘。缓冲区缓存本该更有效的，但由于频繁地写磁盘，会导致缓冲区缓存不能充分发挥作用。
究竟选择哪一种方法，这取决于你的实际环境。应该在数据库级确定它，要把整个实例都考虑在内。
产生此问题的原因分析：
CKPT这个后台进程的就是做checkpoint这件事，checkpoint被触发的条件之一是就发生redo log switch，Checkpoint的具体工作包括：
• 触发DBWn向磁盘写入Dirty data。
• 把checkpoint信息更新到datafile header上。
• 把checkpoint信息更新到control file里。
Checkpoint做的事情之一是触发DBWn把buffer cache中的Dirty cache磁盘。另外就是把最近的系统的SCN更新到datafile header和control file（每一个事务都有一个SCN），做第一件事的目的是为了减少由于系统突然宕机而需要的恢复时间，做第二件事实为了保证数据库的一致性。 而redo log switch就是触发checkpoint的主要的事件(event) ，当第一组redo log被用完之后，Oracle就要停止使用当前的redo log，转而使用另一组redo log，这就叫做log switch。而log switch触发checkpoint。 Oracle要求的最少的redo group 的是2个，但我们一般都建议配置3个或3个以上redo log group。假设我们只有两个redo log group：group 1和group 2，并且系统中总是有大量的dirty block需要写入datafile，当我们从group 1 switch to group 2的时候，会触发checkpoint, checkpoint要求DBWn把buffer cache中的dirty block写入datafile，然而，当我们再次用完group 2里面的空间，需要再次switch to group 1并重用group 1的时候，如果我们发现redo log group 1所保护的那些dirty block还没有完全写入到datafile，整个数据库必须等待DBWn把所有的dirty block写入到datafile之后才能做其他的事情，这就是我们遇到的“checkpoint not complete”问题。这个问题往往暗示了redo log的配置有问题，就本例而言，要么是redo log太小，要么是像我们这里的redo log group太少，只有2个。而这个问题的解决方案就是加大redo log或添加更多redo log group，不管哪一种解决方案，我们的目的都是给DBWn争取更多的时间。
（
参考其它解释如下：
当系统要重新利用某个日志文件的时候，系统需要将该日志文件所 包括的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
参考资料：
这个主题使DBA能对checkpoint和checkpoint优化的参数有一个较好的理解:
- FAST_START_MTTR_TARGET
- LOG_CHECKPOINT_INTERVAL
- LOG_CHECKPOINT_TIMEOUT
- LOG_CHECKPOINTS_TO_ALERT
它也解释了怎样解释和处理出现在ALERT.LOG file中的
checkpoint的错误"'Checkpoint not Complete' and 'Cannot Allocate New Log"
什么是checkpoint?
checkpoint是为了内存中已经被修改的数据块与磁盘数据文件同步的一种数据库事件。它提供了一种
保持事务提交以后数据一致的手段。往Oracle磁盘写脏数据的机制与事务提交不是同步的。
checkpoint有两个目地：1.确保数据一致性。2.使数据库能快速地恢复。怎样快速恢复呢?
因为数据库会把所有的改变都在数据文件上设置checkpoint,并一直增加，它不需要请求checkpoint
之前的重做日志.Checkpoint能保证所有在缓存区的数据写到相应的数据文件，防止因为意外的实例
失败导致的数据丢失。
Oracle写这个脏数据只在一定的条件下：
后面的进程需要1/4个db_block_buffer参数的大小
每三秒
当一个checkpoint产生
一个checkpoint有5中事件类型：
每次重做日志的切换
LOG_CHECKPOINT_TIMEOUT 这个延迟参数的到达。
相应字节(LOG_CHECKPOINT_INTERVAL* size of IO OS blocks)被写到当前的重做日志
IO OS blocks: 在UNIX下可以 # fstyp -v /dev/vg00/lvol1
vxfs
version: 5
f_bsize: 8192
ALTER SYSTEM SWITCH LOGFILE 这个命令会直接导致checkpoint发生
ALTER SYSTEM CHECKPOINT
Checkpoint期间会有下面进程发生:
DBWR写所有脏数据到数据文件
LGWR更新控制文件和数据文件的SCN
Checkpoints和优化
Checkpoints是一个数据库优化的难点。频繁的Checkpoints可以实现快速的恢复，但也会使性能
下降。DBA怎样处理这个问题呢？
依赖于数据库数据文件的数量，一个Checkpoint可能是高速的运行。因为所有的数据文件在Checkpoint
期间都会被冻结。更频繁的Checkpoints可以快速恢复数据库。这也客户对不按规定系统宕机的容忍的原因。
然而，在一些特殊情况下，频繁的Checkpoints也不能保证可以快速恢复。我们假设数据库在95%的时间
内是正常运行，5%由于实例失败导致不可用，要求恢复。对大多数客户而言，他们更希望调整95%
的性能而不是5%的宕机时间。
这个假设表明，性能是摆在第一位的，所以我门的目标就是在优化期间减少Checkpoints的频繁度。
优化Checkpoints包括4个关键的初始化参数：
- FAST_START_MTTR_TARGET
- LOG_CHECKPOINT_INTERVAL
- LOG_CHECKPOINT_TIMEOUT
- LOG_CHECKPOINTS_TO_ALERT
详细介绍每个参数:
FAST_START_MTTR_TARGET
Oracle9i以来FAST_START_MTTR_TARGET 参数是调整checkpoint的首选的方法。
FAST_START_MTTR_TARGET 可以指定单实例恢复需要的秒数。基于内部的统计，增长的
checkpoint会自动调整的checkpint的目标以满足FAST_START_MTTR_TARGET 的需求。
V$INSTANCE_RECOVERY.ESTIMATED_MTTR 显示当前估计需要恢复的秒数。这个值会被显示
即使FAST_START_MTTR_TARGET 没有被指定。
V$INSTANCE_RECOVERY.TARGET_MTTR 表明在短时间内MTTR的目标。
V$MTTR_TARGET_ADVICE 显示这个当前MTTR设置的工作量产生的I/O数量和其他I/O。
这个视图帮助用户评定这个在优化和恢复之前的平衡。
LOG_CHECKPOINT_INTERVAL
LOG_CHECKPOINT_INTERVAL 参数指定这个最大的重做块的间隔数目。
如果FAST_START_MTTR_TARGET被指定，LOG_CHECKPOINT_INTERVAL不能被设置为0.
在大多数Unix系统的OS块大小是512字节。设置LOG_CHECKPOINT_INTERVAL=10000意味着
这个增长的checkpoint不能追加到当前日志因为多于5M。如果你的重做日志是20M，你将
发出4个checkpoint对每个重做日志。
LOG_CHECKPOINT_INTERVAL 会发生影响当一个checkpoint发生时，小心设置这个参数，
保持它随着重做日志文件大小变化而变化。checkpoint频繁是这个影响数据库恢复的原因之一。
短的checkpoint间隔意味数据库将快速恢复，也增加了资源的利用。
这个参数也影响数据库向前回滚的时间。实际的恢复时间是基于这个时间，当然还有失败的类型和
需要归档日志的数量。
LOG_CHECKPOINT_TIMEOUT
这个参数指定checkpoint发出的时间间隔。换句话说，它指定一次脏数据多少时间写出一次。
checkpoint频率会影响这个数据库恢复的时间。长时间的间隔会要求数据库恢复要求更久。
Oracle建议用LOG_CHECKPOINT_interval去控制checkpoint而不用LOG_CHECKPOINT_TIMEOUT
,LOG_CHECKPOINT_TIMEOUT每n秒发一次checkpoint,不顾事务提交的频率。这可能会导致一些
没有必要的checkpoint在事务已经变化的情况下。不必要的checkpoint必须被避免。
还有一个容易误解的地方：LOG_CHECKPOINT_TIMEOUT 会间隔性地发出log switch。
而Log switch会触发一个checkpoint,但checkpoint不会导致一个log switch.唯一手工方式
alter system switch logfile或者重新设置redo logs大小 可以导致频繁switch.
在线重做日志的大小是关键的对于优化和恢复。
解决方法:
If redo logs switch every 3 minutes, you will see performance degradation.
This indicates the redo logs are not sized large enough to efficiently handle
the transaction load.
size of the redolog files.
Using Statspack to determine Checkpointing problems
Statspack snapshots can be taken every 15 minutes or so, these reports gather useful
information about number of checkpoints started and checkpoints completed and number
of database buffers written during checkpointing for that window of time . It also contains
statistics about redo activity. Gathering and comparing these snapshot reports gives you
a complete idea about checkpointing performance at different periods of time.Another important thing to watch in statspack report is the following wait events,
they could be a good indication about problems with the redo log throughput and checkpointing:
log file switch (checkpoint incomplete)
log file switch (archiving needed)
log file switch/archive
log file switch (clearing log file)
log file switch completion
log switch/archive
log file sync
In the case when one or more of the above wait events is repeated frequently
with considerable values then you need to take an action like adding More
online redo log files or increasing their sizes and/or modifying checkpointing parameters