oracle資料庫故障一例

標籤：oracle

資料庫出現如下的報錯

650) this.width=650;" src="http://s5.51cto.com/wyfs02/M00/89/C6/wKioL1gcObWztHE_AADGHTpt7Vs609.jpg" title="1112.jpg" alt="wKioL1gcObWztHE_AADGHTpt7Vs609.jpg" />

分析：

當資料庫切換日誌時，所有private strand都必須重新整理到當前日誌，然後才能繼續。此資訊表示我們在嘗試切換時，還沒有完全將所有 redo資訊寫入到日誌中。這有點類似於“checkpoint not complete”，不同的是，它僅涉及到正在被寫入日誌的redo。在寫入所有redo前，無法切換日誌。

Private Strands 是10gR2才有的，它用於處理redo的latch（ redo allocation latch）。 是一種允許進程利用多個allocation latch更高效地將redo寫入redo buffer cache的機制，它與9i中出現的 log_parallelism 參數相關。提出Strand的概念是為了確保執行個體的redo產生率達到最佳，並能確保在出現某種redo爭用時，可以動態調整strand的數量進行補償。初始分配的strand數量取決於CPU的數量，最少兩個strand，其中一個strand用於active的redo產生。

對於大型的oltp系統，redo產生量非常大，因此當前台進程遇到redo爭用時，這些strand會被啟用。 shared strand總是與多個private strand共存 。 Oracle 10g的redo（和undo）機制有一些重大變化，目的是為了減少爭用。 此機制不再即時記錄redo，而是先記錄在一個private area，並在commit時flush到redo log buffer中去 。 在這種新機制引入後，一旦使用者進程申請到private strand，redo不再儲存到pga中，因此 不再需要redo copy latch這個過程 。

如果新事務申請不到private strand的redo allocation latch，則會繼續遵循舊的redo buffer機制，申請寫入shared strand中 。 對於這個新的機制，在進行redo被寫出到logfile時，LGWR需要將shared strand與private strand的內容寫出。當redo flush發生時，所有的public   strands的 redo allocation latch需要被擷取，所有的public strands的redo copy latch需要被檢查，所有包含活動事務的private strands需要被持有。

其實，對於這個現象也可以忽略，除非 “cannot allocate new log”資訊和“advanced to log sequence”資訊之間有明顯的時間差。

如果想要在alert.log中避免出現Private strand flush not complete事件，那麼可以通過增加參數db_writer_processes的值來實現，因為DBWn會觸發LGWR將redo寫入到logfile，如果有多個DBWn進程一起寫，可以加速redo buffer cache寫入redo logfile。

解決：

可以使用以下命令修改：

SQL> alter system set db_writer_processes=4  scope=spfile ;   -- 該參數時靜態參數，必需重啟資料庫後生效

注意，DBWR進程數應該與邏輯CPU數相當。另外地，當oracle發現一個DB_WRITER_PROCESS不能完成工作時，也會自動增加其數量，前提是已經在初始化參數中設定過最大允許的值。

如果系統支援 AIO（disk_async_io=true） ，一般不用設定多dbwr 或io slaves。

如果在有多個cpu的情況下建議使用DB_WRITER_PROCESSES，因為這樣的情況下不用去類比非同步模式，但要注意進程數量不能大於cpu數量。而在只有一個cpu的情況下建議使用DBWR_IO_SLAVES來類比非同步模式，以便提高資料庫效能。

如果"cannot allocate new log" 與"advanced to log sequence"有明顯的時間間隔，應考慮增加db_writer_processes

mos文檔建議增加db_write_processes,通過增加db_write_processes來增加髒塊的寫出速率。個人認為和io的關係應該
最大.也有部分的bug會導致該提示拋出.增加redo group和增大redo file的size,從而減少log switch的次數，可能效果
會更好一些.

還有出現這樣“cannot allocate new log”的資訊

也可以

是個比較常見的錯誤。通常來說是因為在日誌被寫滿時會切換日誌組，這個時候會觸發一次checkpoint，DBWR會把記憶體中的髒塊往資料檔案中寫，只要沒寫結束就不會釋放這個日誌組。如果歸檔模式被開啟的話，還會伴隨著ARCH寫歸檔的過程。如果redo log產生的過快，當CPK或歸檔還沒完成，LGWR已經把其餘的日誌組寫滿，又要往當前的日誌組裡面寫redolog的時候，這個時候就會發生衝突，資料庫就會被掛起。並且一直會往alert.log中寫類似上面的錯誤資訊。

分析原因：
伺服器有三個日誌組g1、g2、g3.當g1寫完時，要往g2上寫，這時候g1要進行歸檔，還要進行checkpoint。然後另外兩個日誌組繼續寫。當g2和g3都寫完之後，又要往g1上寫，但是問題來了，g1還沒有完成歸檔和checkpoint操作。所以這時就會警示。
解決方案：
多加幾個日誌組，並且每個日誌組空間大一點，這樣就可以延緩時間，會留給g1充分的時間來完成歸檔和checkpoint任務。就不會有報錯。

本文出自 “滴水穿石孫傑” 部落格，請務必保留此出處http://xjsunjie.blog.51cto.com/999372/1869485

oracle資料庫故障一例