还是南京那个客户的库，alert.log日志还报了如下的错误：
Fri Oct 17 19:59:51 2014 Thread 1 cannot allocate new log, sequence 4722 Private strand flush not complete Current log# 1 seq# 4721 mem# 0: /oradata/sgomp5/redo01.log Thread 1 advanced to log sequence 4722 (LGWR switch) Current log# 2 seq# 4722 mem# 0: /oradata/sgomp5/redo02.log
在MOS社区中找到了一篇关于这个问题的文章：
Historically, Every user session wrote the changes to redo log buffer and changes from redo log buffer are flushed to redo logs on disk by lgwr. As number of users increased, the race and the need to get latch for redo allocation and redo copy on the public redo buffer increased. So, starting from 10g, Oracle came up with concept ofprivate redo (x$kcrfstrand) and in-memory undo (x$ktifp). Every session has private redo where session writes to and then a (small) batch of changes is written to public redo and finally from public redo log buffer to redo log files on disk. This mechanismreduces the gets/sleeps on redo copy and redo allocation latches on the public redo buffer and hence makes the architecture more scalable.
It is also worth noting that oracle falls back to old redo mechanism in case transaction is too big (with lots of changes) and if changes done by that transaction can't fit into private redo buffers.
当
数据库切换日志时，所有private strand都必须刷新到当前日志，然后才能继续。此信息表示我们在尝试切换时，还没有完全将所有 redo信息写入到日志中。这有点类似于“checkpoint not complete”，不同的是，它仅涉及到正在被写入日志的redo。在写入所有redo前，无法切换日志。
Private Strands是10gR2才有的，它用于处理redo的latch（redo allocation latch）。是一种允许进程利用多个allocation latch更高效地将redo写入redo buffer cache的机制，它与9i中出现的log_parallelism参数相关。提出Strand的概念是为了确保实例的redo生成率达到最佳，并能确保在出现某种redo争用时，可以动态调整strand的数量进行补偿。初始分配的strand数量取决于CPU的数量，最少两个strand，其中一个strand用于active的redo生成。
对于大型的oltp系统，redo生成量非常大，因此当前台进程遇到redo争用时，这些strand会被激活。shared strand总是与多个private strand共存。Oracle 10g的redo（和undo）机制有一些重大变化，目的是为了减少争用。此机制不再实时记录redo，而是先记录在一个private area，并在commit时flush到redo log buffer中去。在这种新机制引入后，一旦用户进程申请到private strand，redo不再保存到pga中，因此不再需要redo copy latch这个过程。
如果新事务申请不到private strand的redo allocation latch，则会继续遵循旧的redo buffer机制，申请写入shared strand中。对于这个新的机制，在进行redo被写出到logfile时，LGWR需要将shared strand与private strand的内容写出。当redo flush发生时，所有的public strands的redo allocation latch需要被获取，所有的public strands的redo copy latch需要被检查，所有包含活动事务的private strands需要被持有。
其实，对于这个现象也可以忽略，除非“cannot allocate new log”信息和“advanced to log sequence”信息之间有明显的时间差。
如果想要在alert.log中避免出现Private strand flush not complete事件，那么可以通过增加参数db_writer_processes的值来实现，因为DBWn会触发LGWR将redo写入到logfile，如果有多个DBWn进程一起写，可以加速redo buffer cache写入redo logfile。
可以使用以下命令修改： SQL> alter system set db_writer_processes=4 scope=spfile; --该参数时静态参数，必需重启数据库后生效
注意，DBWR进程数应该与逻辑CPU数相当。另外地，当oracle发现一个DB_WRITER_PROCESS不能完成工作时，也会自动增加其数量，前提是已经在初始化参数中设定过最大允许的值。
关于DB_WRITER_PROCESSES和DBWR_IO_SLAVES参数的一些说明：
DB_WRITER_PROCESSES replaces the Oracle7 parameter DB_WRITERS and specifies the initial number of database writer processes for an instance. If you use DBWR_IO_SLAVES, only one database writer process will be used, regardless of the setting for DB_WRITER_PROCESSES
DB_WRITER_PROCESSES参数就是在Oracle 7中的DB_WRITERS参数，用来指定数据库实例的DBWR进程个数，当
系统中还配置了DBWR_IO_SLAVES参数时（默认为0），则只能利用到一个DBWn进程，而忽略其他的。
DBWR_IO_SLAVES If it is not practical to use multiple DBWR processes, then Oracle provides a facility whereby the I/O load can be distributed over multiple slave processes. The DBWR pr