關於 Private strand flush not complete

      網友發來警示日誌，原本是關於一個死結的情形，而另外的一個問題則是從redo log buffer寫出到redo log file出現了不能分配新的日誌，Private strand flush not complete的等待事件。這是個和redo log相關的話題，從Meatlink也找到了對此的描述如下文。

 

Tue Sep 24 14:27:48 2013
Thread 1 cannot allocate new log, sequence 22120
Private strand flush not complete
  Current log# 4 seq# 22119 mem# 0: /u01/app/oracle/oradata/orcl/redo04.log

 

Information in this document applies to any platform.

Private strand flush not complete

Symptoms

"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

Changes

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

Cause

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.

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.     

Solution

These messages are not a cause for concern

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.

Finally,

 

      在高並發，多使用者的資料庫系統中，所有用戶端進程都是通過向redo log buffer寫入重做資料來確保資料的完整與一致性。對於redo log buffer的管理，則通過latch的機制來實現。和redo相關的latch主要有兩個，一個是redo allocation latch，一個是redo copy latch。前者負責將為新的redo在redo log buffer中分配空間，後者則是pga中的redo複製到redo log buffer。下面是描述一下redo產生的流程。

 

 

      如前文Doc ID 372557.1所述，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中。由於新機制的引入，相應的redo的產生髮生了一些變化，如下：

 

     

      對於這個新的機制，在進行redo被寫出到logfile時，LGWR需要將shared strand與private strand的內容寫出。當redo flush發生時，所有的publicredo allocation latch需要被擷取，所有的public strands的redo copy latch需要被檢查，所有包含活動事務的private strands需要被持有。

 

      由上可知，Private strand flush not complete事件的出現是通過增加參數DBWn的值來避免。因為DBWn會觸發LGWR將redo寫入到logfile。

 

   

     使用crs_profile管理RAC資源設定檔
     RAC 資料庫的啟動與關閉
     再說 Oracle RAC services
     Services in Oracle Database 10g
     Migrate datbase from single instance to Oracle RAC
     Oracle RAC 串連到指定執行個體
     Oracle RAC 負載平衡測試(結合伺服器端與用戶端)
     Oracle RAC 伺服器端串連負載平衡(Load Balance)
     Oracle RAC 用戶端串連負載平衡(Load Balance)
     ORACLE RAC 下非預設連接埠監聽配置(listener.ora tnsnames.ora)
     ORACLE RAC 監聽配置 (listener.ora tnsnames.ora)
     配置 RAC 負載平衡與容錯移轉
     CRS-1006 , CRS-0215 故障一例 
     基於Linux (RHEL 5.5) 安裝Oracle 10g RAC
     使用 runcluvfy 校正Oracle RAC安裝環境

     配置非預設連接埠的動態服務註冊
     配置sqlnet.ora限制IP訪問Oracle
     Oracle 監聽器日誌配置與管理
     設定 Oracle 監聽器密碼(LISTENER)
     配置ORACLE 用戶端串連到資料庫

     Oracle 冷備份
     Oracle 熱備份
     Oracle 備份恢複概念
     Oracle 執行個體恢複
     Oracle 基於使用者管理恢複的處理
     SYSTEM 資料表空間管理及備份恢複
     SYSAUX資料表空間管理及恢複
     Oracle 基於備份控制檔案的恢複(unsing backup controlfile)

     RMAN 概述及其體繫結構
     RMAN 配置、監控與管理
     RMAN 備份詳解
     RMAN 還原與恢複
     RMAN catalog 的建立和使用
     基於catalog 建立RMAN儲存指令碼
     基於catalog 的RMAN 備份與恢複
     RMAN 備份路徑困惑
     使用RMAN實現異機備份恢複(WIN平台)
     使用RMAN遷移檔案系統資料庫到ASM
     linux 下RMAN備份shell指令碼
     使用RMAN遷移資料庫到異機

     Oracle 資料表空間與資料檔案
     Oracle 密碼檔案
     Oracle 參數檔案
     Oracle 聯機重做記錄檔(ONLINE LOG FILE)
     Oracle 控制檔案(CONTROLFILE)
     Oracle 歸檔日誌
     Oracle 復原(ROLLBACK)和撤銷(UNDO)
     Oracle 資料庫執行個體啟動關閉過程
     Oracle 10g SGA 的自動化管理
     Oracle 執行個體和Oracle資料庫(Oracle體繫結構)