1.1 根據策略創建Job—Oracle複製備份集與差異備份集,再恢復
1.1.1 測試計劃
要求把EGOV-DB上的oracle備份到介質服務器EGOV-TEST3上,EGOV-DB已經安裝agent,EGOV-TEST3已經安裝BE12.5.
在運行玩全備與複製全備後增加數據庫的記錄,使之發生變化,產生增量。
停止所有job。
本地恢復,使用複製的全備差異備份集進行恢復,並檢查數據。
異地恢復,拷貝複製的全備差異備份集到介質服務器EGOV-TEST1,恢復數據到數據庫服務器EGOV-TEST3,並檢查數據。
1.1.2 介質管理
1.1.2.1 Device管理
全備設備大小:4G。
全備設備名稱:DVDBOracleTesingFull。
複製全備設備名稱:DVDBOracleTesingFull2。
差異設備大小:4G。
差異設備名稱:DVDBOracleTesingDiff。
複製差異設備名稱:DVDBOracleTesingDiff2。
1.1.2.2 MediaSet管理
全備介質集名稱:MSDBOracleTesingFull, 附加週期爲1,覆蓋週期爲1天。
複製全備介質集名稱:MSDBOracleTesingFull2, 附加週期爲1,覆蓋週期爲1天。
差異介質集名稱:MSDBOracleTesingDiff, 附加週期爲1,覆蓋週期爲1天。
複製差異介質集名稱:MSDBOracleTesingDiff2,附加週期爲1,覆蓋週期爲1天。
1.1.3 策略管理
策略名稱:PlcDBOracleTesting。
在全備後的10分鐘內向數據庫插入大量記錄模擬增長的差異大小。
全備模板: 名稱爲TplDBOracleTestingFull,每天下午3:00:00運行,3:59:59結束。
複製全備模板:名稱爲TplDBOracleTestingFull2,每天下午3:10:00運行,3:59:59結束。
差異模板: 名稱爲TplDBOracleTestingDiff,每天下午3:45運行,3:59:59結束。
複製差異模板:名稱爲TplDBOracleTestingDiff2,每天下午3:55運行,3:59:59結束。
1.1.4 選擇項列表管理
列表名稱:BKSelDBOracleTesting
1.1.5 BE的設置
1.1.5.1 重要的設置
1.1.5.1.1 介質覆蓋搜索順序
Menu: Tools -> Option –> Media Management
本案例的順序爲:
從本介質集搜索可以覆蓋的介質。
從暫存介質集搜索可以覆蓋的介質。
從其他介質集搜索可以覆蓋的介質。
1.1.5.1.2 登陸帳戶設置
Menu: Network->Logon Accounts,至少要添加2個帳戶,一個是EGOV-DB的OS帳戶,一個是Oracle的最高權限帳戶。
1.1.5.1.3 Oracle 登陸列表設置
Menu: Tools->Options
點擊Modify list,添加EGOV-DB的OS登陸帳戶
1.1.5.2 BE Device設置
全備Device,如下圖
複製全備Device,如下圖
差異Device,如下圖
複製差異Device,如下圖
1.1.5.3 BE Media設置
全備Media Set,如下圖
複製全備Media Set,如下圖
差異Media Set,如下圖
複製差異Media Set,如下圖
1.1.5.4 BE Policy設置
1.1.5.4.1 新建策略
1.1.5.4.2 新建全備模板TplDBOracleTestingFull
1.1.5.4.2.1 新建Backup Template
1.1.5.4.2.2 Device and Media
1.1.5.4.2.3 General
1.1.5.4.2.4 Oracle
1.1.5.4.2.5 Schedule
Click Button “Edit Schedule Details”
Recurring Week days, click button “select all”
Time Window,
1.1.5.4.3 新建複製全備模板TplDBOracleTestingFull2
1.1.5.4.3.1 新建Duplicate Backup Sets Template
1.1.5.4.3.2 Templates
1.1.5.4.3.3 Device and Media
1.1.5.4.3.4 General
Preferred source device就是要複製的對象。
1.1.5.4.3.5 Schedule
Click Button “Edit Schedule Details”
Recurring Week days, click button “select all”
Time Window,
1.1.5.4.4 新建差異模板TplDBOracleTestingDiff
1.1.5.4.4.1 新建Backup Template
1.1.5.4.4.2 Device and Media
1.1.5.4.4.3 General
1.1.5.4.4.4 Oracle
1.1.5.4.4.5 Schedule
1.1.5.4.5 新建複製差異模板TplDBOracleTestingDiff2
1.1.5.4.5.1 Templates
1.1.5.4.5.2 Device and Media
1.1.5.4.5.3 General
1.1.5.4.5.4 Schedule
Click Button “Edit Schedule Details”
Recurring Week days, click button “select all”
Time Window,
1.1.5.5 BE Selection list設置
新建選擇項列表
Selections
Resource Credential 測試,
1.1.5.6 BE Job設置
New jobs using policy
Moniter
作業建好後,4個作業開始等待運行。注意運行時間是4月17日。
1.1.6 BE backup Job運行結果
1.1.6.1 全備運行後,立即向Oracle插入記錄
Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.
C:/Documents and Settings/Administrator>sqlplus sys/123@testing as sysdba;
SQL*Plus: Release 10.2.0.1.0 - Production on Fri Apr 17 15:41:36 2009
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
SQL> create table testing.testDB(name varchar(32));
Table created.
SQL> insert into testing.testDB values('111112222333344445555');
1 row created.
SQL> insert into testing.testDB select * from testing.testDB;
1 row created.
SQL> insert into testing.testDB select * from testing.testDB;
2 rows created.
...
SQL> insert into testing.testDB select * from testing.testDB;
2097152 rows created.
SQL> commit;
Commit complete.
SQL>
1.1.6.2 Monitor
下圖是4月18日第二次運行後的結果
1.1.6.3 Media set
全備的設備DVDBOracleTestingFull
複製全備的設備DVDBOracleTestingFull2
差異的設備DVDBOracleTestingDiff
複製差異的設備DVDBOracleTestingDiff2
1.1.6.4 結論
全備
第一次運行的時間是2009-04-17 3:00:04 PM,結束時間是2009-04-17 3:03:42 PM,由於覆蓋保護週期設的是1天所以他的覆蓋保護週期過期時間是2009-04-18 3:03:42 PM,當然這個我們已經看不到了,因爲已經運行了2次全備。
第二次運行的時間是2009-04-18 3:00:02 PM,結束時間是2009-04-17 3:04:53 PM,由於覆蓋保護週期設的是1天所以他的覆蓋保護週期過期時間是2009-04-19 3:04:53 PM,此時我們可以從介質集的圖上看到過期時間。同時第二次的運行時間比第一次提前了2秒,就是這個關鍵的2秒,再加上我的介質集的附加週期是1天導致第二次全備時直接append在同一個介質上了。
差異備份
第一次運行的時間是2009-04-17 3:45:00 PM,結束時間是2009-04-17 3:47:46 PM,由於覆蓋保護週期設的是1天所以他的覆蓋保護週期過期時間是2009-04-18 3:47:46 PM。
第二次運行的時間是2009-04-18 3:35:03 PM,結束時間是2009-04-18 3:47:57 PM,由於覆蓋保護週期設的是1天所以他的覆蓋保護週期過期時間是2009-04-19 3:47:57 PM,第二次的運行時間大於超過了附加週期且在覆蓋保護週期內,所以他從暫存介質集拿了一個新的介質。
附件週期與覆蓋保護週期
從上面的例子可以看出,全備只用了1個介質,差異用了2個,爲什麼呢?
1. 雖然你的策略設計的很合理,精確到1秒,但是Job運行時要內部計算,加載介質,初始化介質等等一系列工作後才真正開始向介質上寫數據,在寫數據的同時纔開始計算附加週期的。
2. 覆蓋保護週期是在Job向介質上寫完的那一刻纔開始計算的,每次你的job要備份的文件大小是不一樣的,這個備份時間是不同的,也會導致覆蓋過期時間不同。
所以在設計附件週期與覆蓋保護週期要充分考慮這些問題,才能設計的合理。
1.1.7 恢復1,Oracle Redirection+差異
因爲是恢復到不同oracle服務器,屬於Oracle Redirection恢復。
1.1.7.1 恢復前的準備
目標機器上安裝的oracle同版本的數據庫
目標數據庫的全局數據庫名字和實例名稱要和源oracle一致。例如本案例的Global Name:testing.egov-db,Instance Name:Testing。
目標數據庫要處於歸檔模式。
目標數據庫服務器上安裝oracle agent,並配置正確。
爲了能保證還原不出現更多的意外,建議在介質服務器上對目標數據庫做一次備份,確保所有的設置是正確的。
1.1.7.2 目標數據庫EGOV-TEST3設置
Step 1,登陸到目標oracle服務器EGOV-TEST3,進入oracle安裝目錄C:/oracle/product/10.2.0/db_1/database,刪除文件名PWDtesting.ora(testing是我的實例名)。
Step 2,打開cmd,進入C:/oracle/product/10.2.0/db_1/database目錄。
Step 3,運行orapwd file=PWDtesting.ora password=123
前3補的截圖如下
Step 4, 登陸到源oracle 服務器EGOV-DB,查詢DBID
如果源oracle服務器已經宕機,無法查詢,那麼從備份的介質裏也能查詢到DATABASEID。
C:/WINDOWS/system32/drivers/etc>sqlplus sys/123@testing as sysdba
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
SQL> select dbid from v$database;
DBID
----------
29122919
SQL>
Step 5,RMAN登陸到目標oracle 服務器,打開cmd,執行以下命令。
rman target sys/123@testing
RMAN>SHUTDOWN ABORT
RMAN>STARTUP NOMOUNT;
RMAN>SET DBID 29122919
後2步截圖如下(說明:目標數據庫的DBID已經和源數據庫的DBID一樣了,因爲我以前恢復過)
到此,目標數據庫已經完全準備好了。
1.1.7.3 介質管理
1.1.7.3.1 移動備份介質到新的服務器
拷貝EGOV-TEST3的DVDBOracleTesingFull,DVDBOracleTesingFul2,DVDBOracleTesingDiff,DVDBOracleTesingDiff2目錄到EGOV-TEST1的E:/BE下。
1.1.7.3.2 BE上新建一個相同Device
全備
複製全備
差異
複製差異
1.1.7.3.3 覆蓋介質目錄
BE新建Device時會在Device目錄建立新的配置文件,這樣覆蓋將會使用copy過來的配置文件。
E:/BE/DVDBOracleTesingFull –> E:/BE/Backup/DVDBOracleTesingFull。
E:/BE/DVDBOracleTesingFul2–> E:/BE/Backup/DVDBOracleTesingFul2。
E:/BE/DVDBOracleTesingDiff–> E:/BE/Backup/DVDBOracleTesingDiff。
E:/BE/DVDBOracleTesingDiff2–> E:/BE/Backup/DVDBOracleTesingDiff2。
1.1.7.3.4 掃描,清點,編錄Device
Scan(掃描)
掃描前的Device,是看不到介質的,如下圖
在DVDBOracleTestingDiff上右鍵,Scan,掃描後的介質,等個幾分鐘才能出來,出來的介質還是不能識別的,所以有個問號,如下圖
Inventory(清點介質)
掃描出來的介質有個“?”,說明介質還不能識別出來,需要清點,在Device上右鍵,選擇Inventory,清點後,如下圖
Catalog(編錄介質)
如果要還原,還需要對介質編錄,在介質上右鍵,選擇Catalog Media,如下圖
1.1.7.4 BE還原Job設置
新建還原JOB,RestoreTest3OracleTesting.
1.1.7.4.1 General
1.1.7.4.2 Selection
一定要從control files還原。
解讀上圖:
從控制文件(Controll Files)看出,你可以恢復到列出的任何一個時間點,但是從這個看不出哪個是全備,哪個是差異備份,哪個是複製備份。
從控制文件(Controll Files)看出,有2個是相同的,這表明一個全備或者差異,一個是複製全備或者複製差異。我姑且認爲上面的複製備份,因爲整個列表是按照時間排序的。
從控制文件(Controll Files)看出,可以恢復到的時間點比備份計劃的時間點推遲了幾分鐘。這裏多出了3:22:15的時間點,因爲原來的差異備份是在設計在這個時間點,但是我忘了向數據庫插入記錄了,所以爲了插入記錄,修改了差異備份的時間。
把鼠標放在任何一個表空間,便會有提示。
解讀上圖:
現在可以一目瞭然地看出哪個時間點是屬於什麼備份了。
能看出源oracle的數據庫文件的存放目錄。
選中任何一個時間點的控制文件。
解讀上圖:
時間點或者SCN,在恢復時能夠用到,讓恢復時精確的恢復到這個點。
DatabaseID,在還原時能夠用到,目標數據庫的ID要與源相同,否則無法恢復。
瞭解了以上的信息,那麼我們就選擇一個時間點進行恢復吧。我選擇的時間點是第一次差異備份後,如下圖:(2個已經被選擇,呵呵,不是我選的,我只選擇一個,系統自動勾上了另一個)
1.1.7.4.3 Resource Credentials測試
這一步不能少,結果必須是成功的。
1.1.7.4.4 Device設置
這一步應該是沒有用的,在備份的時候纔有用,所以我就默認的了。
1.1.7.4.5 Oracle Redirection設置
Server: 是目標oracle 服務器 EGOV-TEST3,確保能夠ping通。
Server logon account: 操作系統登陸帳戶,如果沒有可以從菜單Network->Logon Account裏添加。
Instance logon account:目標oracle數據庫testing的最高權限的登陸帳戶。如果沒有可以從菜單Network->Logon Account裏添加。
Redirect Oracle files path:是目標oracle服務器EGOV-TEST3的目錄。這裏不管源oracle安裝目錄是什麼,只要確定一個目標安裝目錄就可以了,同時要保證目錄是存在的。
1.1.7.4.6 Schedule,Run Now
遇到的錯誤如下:
Failed Final error: 0xe0001405
1. Failed Final error: 0xe0001405 - Unknown CORBA exception. Unable to contact the media server. Confirm that the Backup Exec Job Engine service is running on the media server. Final error category: Resource Errors For additional information regarding this error refer to link V-79-57344-5125.
2. BE log info,
tarting restore at 18-APR-09 released channel: ch0
RMAN-00571:======================================
RMAN-00569:====== ERROR MESSAGE STACK FOLLOWS =========
RMAN-00571:======================================
RMAN-03002: failure of restore command at 04/18/2009 23:38:56
ORA-27191: sbtinfo2 returned error
大部分ORA-27191: sbtinfo2 returned error的錯誤都是因爲BE的設置有問題導致。本案例也是因爲沒有設置Oracle Redirection.你現在看到有[Oracle Redirection設置]這一節,那是我後來加上去的。
設置Oracle Redirection。
1. Final error: 0xe0000340 - The Database script returned an error. Refer to the Database script output section in job logs for more details.
Final error category: Resource Errors
2. BE log information
starting media recovery
channel ch0: starting archive log restore to user-specified destination
archive log destination=C:/Oracle/Restore/Archivelog
channel ch0: restoring archive log
archive log thread=1 sequence=19
channel ch0: reading from backup piece BE_22kcn663_1_1
channel ch0: restored backup piece 1
piece handle=BE_22kcn663_1_1 tag=TAG20090417T155235
channel ch0: restore complete, elapsed time: 00:00:02
archive log filename=C:/ORACLE/RESTORE/ARCHIVELOG/ARC00019_0684384473.001 thread=1 sequence=19
unable to find archive log
archive log thread=1 sequence=20
released channel: ch0
RMAN-00571: ========================================
RMAN-00569: ======= ERROR MESSAGE STACK FOLLOWS ==========
RMAN-00571: ========================================
RMAN-03002: failure of recover command at 04/19/2009 00:12:20
RMAN-06054: media recovery requesting unknown log: thread 1 seq 20 lowscn 941259
Recovery Manager complete.
3. BE error figure
因爲恢復部分遇到不一致的歸檔日誌,恢復作業將失敗。這是災難恢復過程中常發生的問題。
無需解決。
Final error: 0xe0000340 - The Database script returned an error. Refer to the Database script output section in job logs for more details.
Final error category: Resource Errors
BE log info:
Starting recover at 27-APR-09
released channel: ch0
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 04/27/2009 13:17:49
ORA-19698: E:/ORACLE10G/ORADATA/EGOV01/REDO01.LOG is from different database: id=4155143440, db_name=EGOV01
Recovery Manager complete.
在執行玩shutdown abort,startup nomount,set dbid xxxxx後在刪除redolog。
刪除要恢復的oracle的redo日誌。如下圖,後綴名爲LOG_是我rename的,log是恢復後的redo log。
1.1.7.5 後續工作
Step 1,登陸到目標oracle服務器EGOV-TEST3,打開cmd,輸入SQLPLUS /nolog,connect,如下
看來是登陸不進去了。
Step 2,打開服務器管理器,重啓OracleServiceTesting
Step 3,再次登陸,再次還登陸不進去,多重複幾次,登陸的過程有點長,要有耐心等
Step 4,修改數據庫redo聯機日誌文件
Note:因爲源oracle的安裝目錄是D盤,所以備份時的路徑是D盤,現在還原到目標服務器,所以要修改下。
alter database rename file 'D:/oracle/product/10.2.0/oradata/testing/redo01.log' to 'C:/oracle/product/10.2.0/oradata/testing/redo01.log';
alter database rename file 'D:/oracle/product/10.2.0/oradata/testing/redo02.log' to 'C:/oracle/product/10.2.0/oradata/testing/redo02.log';
alter database rename file 'D:/oracle/product/10.2.0/oradata/testing/redo03.log' to 'C:/oracle/product/10.2.0/oradata/testing/redo03.log';
Step 5,最後重置歸檔爲alter database open resetlogs,並檢查數據。
testing用戶,在還原時已經自動的添加進去了。
至此oracle Redirection 已經結束。
1.1.7.6 結論
Oracle Redirection災難恢復是成功的。
差異恢復是成功的,可以恢復到任何一個時間點。
1.1.8 恢復2,Oracle Redirection+全備
因爲是恢復到不同oracle服務器,屬於Oracle Redirection恢復。不同的是備份集裏面只有複製集。
1.1.8.1 恢復前的準備
本次備份是在恢復1成功後的基礎上做的。
1.1.8.1.1 更改數據庫的DBID
查詢目標數據庫EGOV-TEST3的DBID,用rman登陸數據庫或者select dbid from v$database;。
RMAN登陸到目標數據庫EGOV-DB,查看DBID
C:/>rman target /
Recovery Manager: Release 10.2.0.1.0 - Production on Tue Apr 14 00:27:31 2009
Copyright (c) 1982, 2005, Oracle. All rights reserved.
connected to target database: MICHAEL (DBID=29122919)
RMAN>
sqlplus登陸到目標數據庫EGOV-TEST3,查看DBID
SQL> select DBID from v$database;
DBID
----------
29122919
設置目標數據庫EGOV-TEST3的DBID=393099115
C:/Documents and Settings/Administrator>sqlplus sys/123@michael as sysdba
SQL*Plus: Release 10.2.0.1.0 - Production on Tue Apr 14 00:33:28 2009
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
SQL> select dbid from v$database;
DBID
----------
29122919
SQL> show parameter db_name
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_name string testing
SQL> exec dbms_backup_restore.nidbegin('testing','TESTING','393099115', 29122919,0,0,10)
PL/SQL procedure successfully completed.
SQL> select dbid from v$database;
DBID
----------
393099115
SQL> variable a number;
SQL> variable b number;
SQL> variable c number;
SQL> exec dbms_backup_restore.nidprocessdf(0,0,:a,:b,:c);
PL/SQL procedure successfully completed.
SQL> print :a
A
----------
0
SQL> print :b
B
----------
1
SQL> print :c
C
----------
1
SQL> exec dbms_backup_restore.nidprocesscf(:a,:b);
PL/SQL procedure successfully completed.
SQL> print :a
A
----------
1
SQL> print :b
B
----------
1
SQL> exec dbms_backup_restore.nidend;
PL/SQL procedure successfully completed.
SQL> select dbid from v$database;
DBID
----------
393099115
代碼說明:
show parameter db_name
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_name string testing
SQL> exec dbms_backup_restore.nidbegin('testing','TESTING','393099115', 291229195,0,0,10)
Param 1:目標數據庫的實例名,即VALUE。
Param 2:爲更改後的實例名,必須大寫。
Param 3:爲更改後的DBID。
Param 4:爲原來的DBID。
1.1.8.1.2 更改目標數據庫EGOV-TEST3的數據
BE
1.1.8.2 目標數據庫EGOV-TEST3設置
同上。
C:/WINDOWS/system32/drivers/etc>sqlplus sys/123@testing as sysdba
SQL> select dbid from v$database;
DBID
----------
393099115
SQL>
RMAN登陸到目標oracle 服務器,打開cmd,執行以下命令。
C:/oracle/product/10.2.0/db_1/database>rman target sys/123@testing
Recovery Manager: Release 10.2.0.1.0 - Production on Sun Apr 19 02:30:42 2009
Copyright (c) 1982, 2005, Oracle. All rights reserved.
connected to target database: testing (DBID=393099115)
RMAN> SHUTDOWN ABORT
using target database control file instead of recovery catalog
Oracle instance shut down
RMAN> STARTUP NOMOUNT;
connected to target database (not started)
Oracle instance started
Total System Global Area 612368384 bytes
Fixed Size 1250428 bytes
Variable Size 230689668 bytes
Database Buffers 373293056 bytes
Redo Buffers 7135232 bytes
RMAN> SET DBID 29122919
executing command: SET DBID
RMAN>
到此,目標數據庫已經完全準備好了。
1.1.8.3 介質管理
1.1.8.3.1 移動備份介質到新的服務器
刪除EGOV-TEST1的E:/BE/Backup目錄下的DVDBOracleTesingFull,DVDBOracleTesingDiff兩個目錄。
1.1.8.3.2 BE上新建一個相同Device
刪除EGOV-TEST1上所遇Device,Media set,再重建,同上。
1.1.8.3.3 覆蓋介質目錄
無需覆蓋。
1.1.8.3.4 掃描,清點,編錄Device
掃描,清點,編錄,同上。
1.1.8.4 BE還原Job設置
新建還原JOB,RestoreTest3OracleTesting2.
1.1.8.4.1 General
1.1.8.4.2 Selection
一定要從control files還原。
從控制文件(Controll Files)看出,雖然介質集少了,但是所有的全備,複製備份都能顯示出來,不理解,難道BE在備份的時候把所有的信息都寫在配置文件了?或者是Catalog裏。如下圖
把鼠標放在任何一個表空間,便會有提示。如下圖
選中任何一個時間點的控制文件。如下圖
本case恢復第一次全備的。如下圖
1.1.8.4.3 Resource Credentials測試
這一步不能少,結果必須是成功的。
1.1.8.4.4 Device設置
這一步應該是沒有用的,第一個例子已經證明了。所以不再設置了。
1.1.8.4.5 Oracle Redirection設置
1.1.8.4.6 Schedule,Run Now
遇到的錯誤如下:
Job Log information:
Job Completion Status
Job ended: Sunday, April 19, 2009 at 3:55:54 AM
Completed status: Canceled
The job was canceled because the response to a media request alert was Cancel, or because the alert was configured to automatically respond with Cancel, or because the Backup Exec Job Engine service was stopped.
Errors
Click an error below to locate it in the job log
Restore- EGOV-TEST3V-79-57344-33037 - Error - Mount failed.
Physical Volume Library Media not found.
V-79-57344-33037 - Unable to acquire device for the specified pool and media
V-79-57344-33861 - The media operation was terminated by the user.
Errors Detail
V-79-57344-33037 - Error - Mount failed.
Physical Volume Library Media not found.
Media GUID: {0796A513-B7F0-49C5-AAFD-85A64CA97564}
Media Label: B2D000048
V-79-57344-33037 - Unable to acquire device for the specified pool and media
Physical Volume Library Media not found.
V-79-57344-33861 - The media operation was terminated by the user.
Recovery Manager: Release 10.2.0.1.0 - Production on Sun Apr 19 03:55:31 2009
Copyright (c) 1982, 2005, Oracle. All rights reserved.
# -----------------------------------------------------------------
# RMAN command section
# -----------------------------------------------------------------
RUN {
ALLOCATE CHANNEL ch0
TYPE 'SBT_TAPE';
SEND 'BSA_SERVICE_HOST=135.251.23.145,NBBSA_TOTAL_STREAMS=1,NBBSA_JOB_COOKIE={7DC93467-BEF5-4207-B134-780FBC26078B},NBBSA_DB_DEVICE_NAME=Oracle-Win:://EGOV-TEST3/testing,NBBSA_SOURCE_MACHINE_NAME=EGOV-DB';
RESTORE CONTROLFILE FROM 'BE_1pkcn3j2_1_1';
RELEASE CHANNEL ch0;
alter database mount;
}
connected to target database: testing (not mounted)
using target database control file instead of recovery catalog
allocated channel: ch0
channel ch0: sid=151 devtype=SBT_TAPE
channel ch0: Symantec/BackupExec/1.1.0
sent command to channel: ch0
Starting restore at 19-APR-09
channel ch0: restoring control file
我的備份Job設置時全備,複製全備,差異,複製差異是在一個policy裏面,可能的原因是在還原時這些備份介質都要存在,即使複製備份已經是具有全備的性質。
從Details看出需要B2D000048的介質,而EGOV-TEST1是沒有這個介質的,這個介質是第一次全備的介質,因爲我想從複製備份集來恢復oracle的,已經將他刪除了。通過下面的2副圖,可以看出。
EGOV-TEST3的第一次全備介質
EGOV-TEST1的現存介質
1.1.8.5 後續工作
已經失敗了,沒有後續工作。
1.1.8.6 結論
Oracle Redirection災難恢復2是失敗的。
可能的原因是備份時複製備份的rule沒有選好。默認的是複製所有的備份集,所以我在選擇恢復時的controlfiles總是選擇2個。如下圖
重新執行備份還原計劃,請看下一節。