一次ORA-00257錯誤的處理過程

 

一次ORA-00257錯誤的處理過程

基本情況描述：

　 今天在客戶那邊的一個實際專案中遇到出現ORA-00257錯誤（空間不足錯誤），透過查詢，發現是由於歸檔日誌太多，佔用了全部的硬碟剩餘空間導致的，透過簡單刪除日誌或加大儲存空間就能夠解決。

1、軟硬體環境：

作業系統：Sun Microsystems Inc. SunOS 5.10 Generic January 2005（Solaris 10）

資料庫：Oracle 10.2.0.4.0 - 64bit Production RAC + ASM

2、問題現象：

應用訪問不了，資料庫報錯ORA-00257

SystemErr.log部分報錯資訊如下所示：

[8/2/10 11:51:32:503 CST] 4128c665 SystemErr R   at java.lang.reflect.Method.invoke(Method.java:386)

[8/2/10 11:51:32:503 CST] 4128c665 SystemErr R   at com.ibm.ws.bootstrap.WSLauncher.main(WSLauncher.java:94)

[8/2/10 11:51:32:563 CST] 4128c665 SystemErr R java.sql.SQLException: ORA-00257: archiver error. Connect internal only, until freed.

alert檔案以及相應的trc檔案部分報錯資訊如下所示：

*** 2010-08-02 11:48:54.115 62692 kcrr.c

ARC0: Error 19504 Creating archive log file to '+DG1'

*** 2010-08-02 11:48:54.115 60970 kcrr.c

kcrrfail: dest:1 err:19504 force:0 blast:1

ARCH: Connecting to console port...

ARCH: Connecting to console port...

*** 2010-08-02 11:48:54.130 21373 kcrr.c

ORA-16038: log 1 sequence# 4177 cannot be archived

ORA-19504: failed to create file ""

ORA-00312: online log 1 thread 1: '+DG1/db/onlinelog/group_1.258.690640367'

ORA-00312: online log 1 thread 1: '+DG1/db/onlinelog/group_1.259.690640369'

*** 2010-08-02 11:54:54.337

Failed to create file '+DG1' (file not accessible?)

*** 2010-08-02 11:54:54.337 62692 kcrr.c

ARC0: Error 19504 Creating archive log file to '+DG1'

*** 2010-08-02 11:54:54.337 60970 kcrr.c

kcrrfail: dest:1 err:19504 force:0 blast:1

ARCH: Connecting to console port...

ARCH: Connecting to console port...

*** 2010-08-02 11:54:54.351 21373 kcrr.c

ORA-16038: log 1 sequence# 4177 cannot be archived

ORA-19504: failed to create file ""

ORA-00312: online log 1 thread 1: '+DG1/db/onlinelog/group_1.258.690640367'

ORA-00312: online log 1 thread 1: '+DG1/db/onlinelog/group_1.259.690640369'

*** 2010-08-02 12:00:54.462

Failed to create file '+DG1' (file not accessible?)

*** 2010-08-02 12:00:54.462 62692 kcrr.c

ARC0: Error 19504 Creating archive log file to '+DG1'

3、診斷和解決過程：

1）登陸到第一個節點，切換到oracle使用者：su - oracle

2）更改並輸出環境變數ORACLE_SID：ORACLE_SID=+ASM1;export ORACLE_SID

（如果登入的是叢集第二個節點，相應地：ORACLE_SID=+ASM2;export ORACLE_SID）

3）進入ASM命令列操作介面：asmcmd

ASMCMD>

ASMCMD> lsdg

State Type Rebal Unbal Sector Block AU Total_MB Free_MB Req_mir_free_MB Usable_file_MB Offline_disks Name

MOUNTED EXTERN N N 512 4096 1048576 102140 33 0 33 0 DG1/

(檢視Usable_file_MB一列的ASM磁碟組可用空間數)

如果為0或者接近於0,應該考慮及時清空RAC 資料庫上的歸檔日誌。

cd 到歸檔日誌所在目錄

（BBS資料庫在ASM磁碟組上歸檔日誌位置：+DG1/BBSDB/ARCHIVELOG；

歸檔日誌會在該目錄下以天為單位進行目錄結構組織，例：

ASMCMD> ls

              2009_06_22/

              2009_06_23/

              2009_06_24/

        ）

根據需要使用rm命令清空某天或者某幾天的歸檔日誌：

例，清空2009年6月22日的歸檔日誌：

ASMCMD>rm –rf 2009_06_22

清空完畢後透過lsdg進行驗證無誤後，exit出ASM命令列管理介面。

（注：手動清空歸檔日誌，需要在RMAN下進行check工作,以便及時更新歸檔日誌資訊，具體方式如下：

              ORACLE_SID=db1;export ORACLE_SID ;

恢復ORACLE_SID環境變數

              oracle@db1 $ rman

              RMAN> connect target;

                            connected to target database: DB (DBID=XXXX)

              RMAN> crosscheck archivelog all;

              ……

              RMAN>exit

       之後，應該立即進行一次資料庫全備。

              )

4）按照上面的操作，手工刪除掉了6月的歸檔日誌，歸檔可用空間增大到7G多，應用也早已能正常訪問。

4、總結：

造成本次故障的原因：

由於備份軟體沒有正常執行，還有備份指令碼也有問題，造成歸檔日誌沒有及時刪除。

　　從本次故障解決處理中，我們可以得出經驗教訓：

　　對備份指令碼和備份軟體要進行充分的測試；

對資料庫系統管理員要對Oracle資料庫歸檔日誌、備份軟體執行狀況定期檢查，提前發現、處理可能發生的故障。

附：

附 1）crosscheck archivelog all

crosscheck archivelog all

用RMAN的備份中（Veritas等備份軟體由於歸檔日誌的異常導致歸檔日誌備份失敗）是經常碰到的，解決方法也是非常解單，就是執行2條RMAN的命令：

1. 進入rman

2. connect target /

3. crosscheck archivelog all;

4. delete expired archivelog all;

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

下面說明一下：

在controlfile中記錄著每一個archivelog的相關資訊，當我們在OS下把這些物理檔案delete掉或異常變動後，在controlfile中仍然記錄著這些archivelog的資訊，當我們手工清除archive目錄下的檔案後，這些記錄並沒有被我們從controlfile中清除掉，也就是oracle並不知道這些檔案已經不存在了!這時候我們要做手工的清除。

crosscheck archivelog all；的作用就是檢查控制檔案和實際物理檔案的差別。

delete expired archivelog all;就是同步控制檔案的資訊和實際物理檔案的資訊。

如果單獨執行crosscheck而沒有執行delete那麼備份還是失敗的，原因是那些控制檔案的資訊和實際的資訊還是不同。

crosscheck backupset

crosscheck backupset 是檢查備份集和實際的檔案

1 備份集有兩種狀態A(Available,RMAN認為該項存在於備份介質上)X(Expired，備份存在於控制檔案或恢復目錄中，但

是並沒有物理存在於備份介質上）

2 crosscheck 的目的是檢查RMAN 的目錄以及物理檔案，如果物理檔案不存在於介質上，將標記為Expired。如果物理檔案

存在，將維持Available。如果原先標記為Expired的備份集再次存在於備份介質上（如恢復了損壞的磁碟驅動器後），

crosscheck將把狀態重新從Expired標記回Available。

3 crosscheck 輸出分兩部分。第一部分列出確定存在於備份介質上的所有備份集片，第二部分列出不存在於備份介質上的

備份集片，並將其標記為Expired。當設定備份儲存策略後，一個備份過期，crosscheck之後標記為丟棄的備份狀態依舊為

availabel,要刪除丟棄備份delete obsolete