備份指令碼執行失敗一例

 

隨著技術環境的不斷髮展和增加，運維部門面對的執行環境呈現大規模和複雜兩個趨勢。一兩個運維人員管理公司成百上千臺伺服器的情況將來會是常見的事情。這個時候，集中監控、自動運維平臺是解決問題最好的方法。本篇我們就介紹一個切換到集中備份環境中出現的小問題。

 

1、問題說明

 

一個原先在Windows環境上執行的Oracle伺服器，原來是使用伺服器上自己編寫的指令碼進行備份。執行指令碼通過windows的計劃任務呼叫執行，長期沒有任何問題。

有一天負責伺服器的同事突然聯絡，說連續幾天備份過程失敗。在日誌上，明確顯示失敗。
  一般情況下，生產環境各種配置是比較穩定的，不會有特別的變更。筆者要來了錯誤日誌檢視。

 

 

恢復管理器: Release 10.2.0.1.0 - Production on 星期六 1月 4 22:13:05 2014

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

RMAN> connect target *

2> run{

3> backup database plus archivelog delete input;

4> crosscheck archivelog all;

5> delete noprompt expired backupset;

6> delete noprompt obsolete;

7> }

8>

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

ORA-01031: insufficient privileges

 

恢復管理器完成。

 

 

 

報錯內容不存在語句命令的情況，而是執行許可權錯誤。而之前的日誌顯示，相同的備份執行一直沒有問題，指令碼也沒有修改。

 

2、問題分析

 

呼叫指令碼是兩個檔案，Windows的BAT和RMAN的txt檔案。Rman_bk.bat是主要的執行物件，指令碼如下：

 

rman nocatalog @backup_command.txt Log=rman_log1.log append

 

命令指令碼backup_command.txt如下：

 

connect target /

run{

backup database plus archivelog delete input;

crosscheck archivelog all;

delete noprompt expired backupset;

delete noprompt obsolete;

}

 

執行報錯許可權錯誤，最大的可能是在作業系統使用者匿名登入時候，被拒絕。此時可以試驗一下用作業系統使用者是不是可以用sqlplus登入。

 

 

預設登入沒有什麼問題，說明匿名登入機制沒有被修改。手工執行bat檔案，實驗結果如下：

 

 

執行過程看似正常，備份日誌資訊如下：

 

恢復管理器: Release 10.2.0.1.0 - Production on 星期三 1月 8 17:12:47 2014

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

 

RMAN> connect target *

2> run{

3> backup database plus archivelog delete input;

4> crosscheck archivelog all;

5> delete noprompt expired backupset;

6> delete noprompt obsolete;

7> }

8>

連線到目標資料庫: OTSTEST (DBID=2884314031)

使用目標資料庫控制檔案替代恢復目錄

 

啟動 backup 於 08-1月 -14

當前日誌已存檔

分配的通道: ORA_DISK_1

通道 ORA_DISK_1: sid=132 devtype=DISK

通道 ORA_DISK_1: 正在啟動存檔日誌備份集

（篇幅原因，有省略……）

輸入存檔日誌執行緒 =1 序列 =4151 記錄 ID=1144 時間戳=835178418

 

手工執行指令碼沒有問題。看似很詭異的問題~

 

3、猜想與解決

 

詢問同事最近的環境變化情況，瞭解到一個細節：運維部門同意將伺服器納入到集中備份環境。由於環境的差異，運維部門只是負責呼叫各自的備份程式（自己編寫），之後將備份拷貝到集中磁帶上。

 

這樣引起的筆者的一個猜想：手工執行和報錯執行一個很大的差異就是登陸許可權。不同的作業系統使用者登入，在許可權上是有所不同的。

 

對Oracle而言，作業系統因素有兩個方面，一個是環境變數（$ORACLE_SID等），另一個是系統角色。在Linux/AIX下，環境變數我們通常設定在使用者的層面，使用oracle登入之後，環境變數自動設定。角色上，我們也建立了dba組進行配比。

 

在Windows上，相同的設定也是存在的。環境變數是以登錄檔鍵值的方式儲存在全域性。而管理員角色是以組策略的方式設定，名稱為ora_dba。

 

對Oracle本機上的匿名登入，如果我們沒有將作業系統使用者設定在dba組裡面，是可能登入失敗的。

 

解決問題的思路有兩個：一種策略是分析出集中備份環境的登入使用者，將其加入到dba作業系統使用者組裡面。另一種方法是進行密碼登陸，不使用/登陸。

 

筆者建議使用第二個方法，修改指令碼如下：

 

connect target sys/oracle

run{

backup database plus archivelog delete input;

crosscheck archivelog all;

delete noprompt expired backupset;

delete noprompt obsolete;

}

 

轉到第二天再次執行備份指令碼，執行日誌如下：

 

 

恢復管理器: Release 10.2.0.1.0 - Production on 星期三 1月 8 20:00:01 2014

 

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

 

RMAN> connect target *

2> run{

3> backup database plus archivelog delete input;

4> crosscheck archivelog all;

5> delete noprompt expired backupset;

6> delete noprompt obsolete;

7> }

8>

連線到目標資料庫: OTSTEST (DBID=2884314031)

使用目標資料庫控制檔案替代恢復目錄

 

啟動 backup 於 08-1月 -14

當前日誌已存檔

分配的通道: ORA_DISK_1

 

存檔日誌檔名 =D:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\OTSTEST\ARCHIVELOG\2014_01_08\O1_MF_1_4181_9DTHG3N5_.ARC 記錄 ID=1174 時間戳 =836337603

完成 backup 於 08-1月 -14

 

備份成功，問題解決。

 

4、結論

 

我們在實際工作中，會遇到各種各樣的問題。這也就是為什麼實踐是成長的關鍵原因。綜合各種知識能力，層層剝離，合理假設，可以幫助我們解決問題。

 

 

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/17203031/viewspace-1068929/，如需轉載，請註明出處，否則將追究法律責任。