官方解释如下：
CHANGES
切换日志时，所有 private strand 都必须刷新到当前日志，然后才允许继续切换。
CAUSE
此信息表示我们在尝试切换时，尚未完全将所有 redo 信息写入到日志中。它本质上类似于“checkpoint not complete”，不同的是，它仅涉及到正在被写入日志的redo。在写入所有 redo 前，无法切换日志。
“strand”是 10g 中的新术语，它用于处理 redo 的 latch。
Strands是一种允许进程利用多个 allocation latch 更高效地将 redo 写入 redo 缓冲区的机制，它与 9i 中出现的 log_parallelism 参数相关。
提出 Strand 的概念是为了确保实例的 redo 生成率达到最佳，并能确保在出现某种 redo 争用时，可以动态调整 strand 的数量进行补偿。
初始分配的 strand 数量取决于 CPU 的数量，最少两个 strand，其中一个 strand 用于活动的 redo 生成。
对于大型企业系统，redo 生成的量相当大，因此当前台进程遇到此 redo 争用（allocated latch 竞争）时，这些 strand 会“被激活”，这就是动态 strand 的概念开始发挥作用的时候。
shared strand 总是与多个 private strand 共存。
Oracle 10g 的 redo（和 undo）机制有一些重大变化，目的是为了减少争用。
此机制不再实时记录 redo，而是先记录在一个“私有区域”，并在提交时写到 redo 日志缓冲区中。
与此相似，undo 可作为“in memory undo”生成并成批应用。这会影响用于管理 redo 的内存和分片刷新此内存的可能性。您获取的信息与内部 Cache Redo File 管理相关。
... 该信息是正常的，可以被忽略。
SOLUTION
这些信息不需要特别关注，除非“cannot allocate new log”信息和“advanced to log sequence”信息之间有明显的时间差。
在某些情况下，增大 db_writer_processes 的值有助于避免生成该信息。原因：因为 DBWR 的其中一个主要功能是通过写出脏缓存块来保持缓冲区缓存的干净。因此，使用多个 db_writer_processes 应当能够产生更高的吞吐量。
关于更详细的机制
参考文章
http://blog.csdn.net/tianlesoftware/article/details/6014898