轉載自：http://blog.csdn.net/tianlesoftware/article/details/6015400
前幾天一個朋友問了我一個問題。 說她在alert log裏面看到了如下信息：
Thread 1 cannot allocate new log, sequence 415
Private strand flush not complete
Current log# 4 seq# 414 mem# 0: /dev/rora_redotb04
Thread 1 advanced to log sequence 415
Current log# 5 seq# 415 mem# 0: /dev/rora_redotb05
Thu Nov 11 16:01:51 2010
我遇到的是：Checkpoint not complete。 有關這方面的解釋參考我的Blog：
Redo Log 和Checkpoint not complete
http://blog.csdn.net/tianlesoftware/archive/2009/12/01/4908066.aspx
在oracle 官網搜了一下：
|
Alert Log Messages: Private Strand Flush Not Complete [ID 372557.1] |
||
|
|
||
|
|
Modified 01-SEP-2010 Type PROBLEM Status MODERATED |
|
In this Document
Symptoms
Cause
Solution
References
Platforms: 1-914CU;
|
This document is being delivered to you via Oracle Support's Rapid Visibility (RaV) process and therefore has not been subject to an independent technical review. |
Oracle Server - Enterprise Edition - Version: 10.2.0.1 to 11.1.0.7 - Release: 10.2 to 11.1
Information in this document applies to any platform.
"Checked for relevance on 04-Dec-2007"
Private strand flush not complete
"Private strand flush not complete" messages are being populated to the alert log for unknown
reasons.
ALERT LOG EXAMPLE:
>>>
Fri May 19 12:47:29 2006
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
<<<
>>
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.
A "strand" is new terminology for 10g and it deals with latches for redo .
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.
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.
Instead of redo being recorded in real time, it can be recorded 'privately' and pumped into the redo log buffer on commit.
Similary 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.
When you switch logs all private strands have to be flushed to the current log before the switch is allowed to proceed.
These messages are not a cause for concern unless there is a significant gap in seq# between the "cannot allocate new log" message and the "advanced to log sequence" message.
This issue is infact not a bug and is expected behavior.
In some cases, this message can be resolved by increasing db_writer_process value.
這裏面涉及到一些Redo 的機制問題。 具體參考Blog：
Oracle Redo 並行機制
http://blog.csdn.net/tianlesoftware/archive/2010/11/17/6014898.aspx
一個redo條目包含了相應操作導致的數據庫變化的所有信息，所有redo條目最終都要被寫入redo文件中去。 Redo log buffer是爲了避免Redo文件IO導致性能瓶頸而在sga中分配出的一塊內存。 一個redo條目首先在用戶內存(PGA)中產生，然後由oracle服務進程拷貝到log buffer中，當滿足一定條件時，再由LGWR進程寫入redo文件。
由於log buffer是一塊“共享”內存，爲了避免衝突，它是受到redo allocation latch保護的，每個服務進程需要先獲取到該latch才能分配redo buffer。因此在高併發且數據修改頻繁的oltp系統中，我們通常可以觀察到redo allocation latch的等待。
爲了減少redo allocation latch等待，在oracle 9.2中，引入了log buffer的並行機制。其基本原理就是，將log buffer劃分爲多個小的buffer，這些小的buffer被成爲Shared Strand。每一個strand受到一個單獨redo allocation latch的保護。多個shared strand的出現，使原來序列化的redo buffer分配變成了並行的過程，從而減少了redo allocation latch等待。
爲了進一步降低redo buffer衝突，在10g中引入了新的strand機制——Private strand。Private strand不是從log buffer中劃分的，而是在shared pool中分配的一塊內存空間。
Private strand的引入爲Oracle的Redo/Undo機制帶來很大的變化。每一個Private strand受到一個單獨的redo allocation latch保護，每個Private strand作爲“私有的”strand只會服務於一個活動事務。獲取到了Private strand的用戶事務不是在PGA中而是在Private strand生成Redo，當flush private strand或者commit時，Private strand被批量寫入log文件中。如果新事務申請不到Private strand的redo allocation latch，則會繼續遵循舊的redo buffer機制，申請寫入shared strand中。事務是否使用Private strand，可以由x$ktcxb的字段ktcxbflg的新增的第13位鑑定：
對於使用Private strand的事務，無需先申請Redo Copy Latch，也無需申請Shared Strand的redo allocation latch，而是flush或commit是批量寫入磁盤，因此減少了Redo Copy Latch和redo allocation latch申請/釋放次數、也減少了這些latch的等待，從而降低了CPU的負荷。
看了這些理論知識，我們在來看一下之前的錯誤：
Private strand flush not complete
當我們flush或者commit的時候，必須先將buffer中的內容寫入到redo中，才能去接收新的記錄。 這個錯誤就是發生在這個過程中。 Oracle 對這個問題提了2個方法：
（1） 忽略，在使用之前，必須要等待buffer的信息flush完成。 這時候進程是會短暫的hang住。
（2） 增加db_writer_process的數據。