今天发现数据库报Private strand flush not complete这个错误，数据库版本为10.2.0.4。
先看一个strand是啥？
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.--初始的strands数量依赖CPU的数量
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.--大型的企业应用中，大量的redo产生时，就会遇到redo争用，这时动态的strands就会被激活。
There is always shared strands and a number of private strands .--strand也会为共享和私有的。
那private strand 是为何物？
oracle9.2引入的log_parallelism机制就是shared strand的前身，而private strand是10GR2之后引入的。
Oracle 9.2之后引入了log_parallelism机制，当该参数的值大于1的时候，数据库会分配多个共享的redo log buffer，也就是说redo log buffer被再次细分，使得每个共享的buffer使用独立的redo allocation latch来进行保护以提高redo的并发性。这些个共享的redo log buffer就被称之为 shared strand。在10gR2以后了又多出了一个private strand，这个东东是从shared pool中分配而不是先前的log buffer。private strand为大量小的私有内存，通常每个大小在64kb-128kb左右，被独立的redo allocation latch所保护。每个特定的小事务会绑定到独立且空闲的private redolog strand，即绑定到一个活动事务。在这种新机制引入后，一旦用户进程申请到private strand，redo不再保存的pga中，因此不再需要redo copy latch这个过程。如果新事务申请不到private strand的redo allocation latch，则会继续遵循旧的redo buffer机制，申请写入shared strand中。
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.
--私有的strands用来记录redo记录，这些记录不是实时的更新到redo log buffer，而是当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.
--为何log的问题，需要增加dbwr的线程来解决？因为一个instnace只能有一个lgwr，而在dbwr执行写入之前会触发lgwr。另外还要考虑磁盘写入的速度，提前磁盘速度肯定也会有帮助。
Finally, these messages have also been seen when there are issues with the storage side or network for the archive log destination, as this leads to delay or hang in LGWR switch.