一次例行巡检，在客户数据库中发现大量Private strand flush not complete错误，alert日志信息如下：
客户DB版本为11.2.0.3 64位
Thread 1 cannot allocate new log, sequence 11004
Private strand flush not complete
Current log# 2 seq# 11003 mem# 0: /oradata1/JZH/redo02a.log
Current log# 2 seq# 11003 mem# 1: /oradata1/JZH/redo02b.log
Thread 1 advanced to log sequence 11004 (LGWR switch)
Current log# 1 seq# 11004 mem# 0: /oradata1/JZH/redo01a.log
Current log# 1 seq# 11004 mem# 1: /oradata1/JZH/redo01b.log
Archived Log entry 7548 added for thread 1 sequence 11003 ID 0x1e37f2c7 dest 2:
ALTER SYSTEM ARCHIVE LOG
Thread 1 advanced to log sequence 11005 (LGWR switch)
Current log# 3 seq# 11005 mem# 0: /oradata1/JZH/redo03a.log
Current log# 3 seq# 11005 mem# 1: /oradata1/JZH/redo03b.log
Archived Log entry 7549 added for thread 1 sequence 11004 ID 0x1e37f2c7 dest 2:
Sun Jan 04 02:00:00 2015
Closing scheduler window
Closing Resource Manager plan via scheduler window
Clearing Resource Manager plan via parameter
Sun Jan 04 06:00:00 2015
Setting Resource Manager plan SCHEDULER[0x318F]:DEFAULT_MAINTENANCE_PLAN via scheduler window
Setting Resource Manager plan DEFAULT_MAINTENANCE_PLAN via parameter
Sun Jan 04 06:00:00 2015
Starting background process VKRM
Sun Jan 04 06:00:00 2015
VKRM started with pid=22, OS id=23342
Sun Jan 04 06:00:00 2015
Begin automatic SQL Tuning Advisor run for special tuning task "SYS_AUTO_SQL_TUNING_TASK"
End automatic SQL Tuning Advisor run for special tuning task "SYS_AUTO_SQL_TUNING_TASK"
Sun Jan 04 10:29:07 2015
Thread 1 cannot allocate new log, sequence 11006
Private strand flush not complete
Current log# 3 seq# 11005 mem# 0: /oradata1/JZH/redo03a.log
Current log# 3 seq# 11005 mem# 1: /oradata1/JZH/redo03b.log
Thread 1 advanced to log sequence 11006 (LGWR switch)
Current log# 2 seq# 11006 mem# 0: /oradata1/JZH/redo02a.log
Current log# 2 seq# 11006 mem# 1: /oradata1/JZH/redo02b.log

此信息表示我们在尝试切换时，尚未完全将所有 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 管理相关。
... 该信息是正常的，可以被忽略。
这些信息不需要特别关注，除非“cannot allocate new log”信息和“advanced to log sequence”信息之间有明显的时间差。
在某些情况下，增大 db_writer_processes 的值有助于避免生成该信息。原因：因为 DBWR 的其中一个主要功能是通过写出脏缓存块来保持缓冲区缓存的干净。因此，使用多个 db_writer_processes 应当能够产生更高的吞吐量。