网友发来告警日志，原本是关于一个死锁的情形，而另外的一个问题则是从redo log buffer写出到redo log file出现了不能分配新的日志，Private strand flush not complete的等待事件。这是个和redo log相关的话题，从Meatlink也找到了对此的描述如下文。
1、错误消息
2、Meatlink 对此的描述(Doc ID 372557.1)
Oracle Database - Enterprise Edition - Version 10.2.0.1 to 11.2.0.3 [Release 10.2 to 11.2]
Information in this document applies to any platform.
Private strand flush not complete
"Private strand flush not complete" messages are being populated to the alert log, example:
Mon Jan 23 16:09:36 2012
Thread 1 cannot allocate new log, sequence 18358
Private strand flush not complete
Current log# 7 seq# 18357 mem# 0: /u03/oradata/bitst/redo07.log
Thread 1 advanced to log sequence 18358
Current log# 8 seq# 18358 mem# 0: /u03/oradata/bitst/redo08.log
When you switch logs all private strands have to be flushed to the current log before the switch is allowed to proceed.
--切换日值前，所有的private strands必须写入到当前的redo logfile
The message means that we haven't completed writing all the redo information to the log when we are trying to switch. It is similar in nature to a "checkpoint not complete" except that is only involves the redo being written to the log. The log switch can not occur until all of the redo has been written.
-->该消息意味着在日志切换前我们不能够完整的写出redo到日志文件。其本质类似于checkpoint not complete等待事件。所不同的是它仅仅涉及到正在被写入到日志的redo
A "strand" is new terminology for 10g and it deals with latches for redo . -->strand是一个用于处理redo latch的新术语
Strands are a mechanism to allow multiple allocation latches for processes to write redo more efficiently in the redo buffer and is related to the log_parallelism parameter present in 9i.
The concept of a strand is to ensure that the redo generation rate for an instance is optimal and that when there is some kind of redo contention then the number of strands is dynamically adjusted to compensate.
-->最大的作用是用于确保redo产生的速率达到最佳，并在出现相关redo竞争的时候动态调整strand的值进行补偿
The initial allocation for the number of strands depends on the number of CPU's and is started with 2 strands with one strand for active redo generation.
For large scale enterprise systems the amount of redo generation is large and hence these strands are *made active* as and when the foregrounds encounter this redo contention (allocated latch related contention) when this concept of dynamic strands comes into play.
There is always shared strands and a number of private strands .
Oracle 10g has some major changes in the mechanisms for redo (and undo), which seem to be aimed at reducing contention.
-->在10g中有很大的变化，最主要的目的还是为了减少竞争
Instead of redo being recorded in real time, it can be recorded 'privately' and pumped into the redo log buffer on commit.
Similarly the undo can be generated as 'in memory undo' and applied in bulk. This affect the memory used for redo management and the possibility to flush it in pieces. The message you get is related to internal Cache Redo File management.
...You can disregard these messages as normal messages. --->可以当作常规消息被忽略
These messages are not a cause for concern unless there is a significant time gap between the "cannot allocate new log" message and the "advanced to log sequence" message. --->如果"cannot allocate new log" 与"advanced to log sequence"有明显的时间间隔，应考虑增加db_writer_processes
Increasing the value for db_writer_processes can in some situations help to avoid the message from being generated. Why, because one of the DBWR main function is to keep the buffer cache clean by writing out dirty buffer blocks. So having multiple db_writer_processes should be able to produce a higher throughput.
Fina