oracle redo与undo_笔记5:为什么不能分配一个新日志

为什么不能分配一个新日志

在服务器上的alert.log中会得到一条警告消息

Thread 1 cannot allocate new log,sequence 1466

Checkpoint not complete

Current log# 3 seq# 1465 mem# 0: /.../...redo3.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更频繁地刷新输出脏块。这种方法的好处是，失败恢复的时间会减少。在线重做日志中应用的工作肯定更少。其缺点是，如果经常修改块，可能会更频繁地写至磁盘。缓冲区缓存本该更有效的，但由于频繁地写磁盘，会导致缓冲区缓存不能充分发挥作用。

究竟选择哪一种方法，这取决于你的实际环境。应该在数据库级确定它，要把整个实例都考虑在内。

本文来源 我爱IT技术网 http://www.52ij.com/jishu/5265.html 转载请保留链接。