要求把EGOV-DB上的oracle备份到介质服务器EGOV-TEST3上,EGOV-DB已经安装agent,EGOV-TEST3已经安装BE12.5.
在运行玩全备与复制全备后增加数据库的记录,使之发生变化,产生增量。
停止所有job。
本地恢复,使用复制的全备差异备份集进行恢复,并检查数据。
异地恢复,拷贝复制的全备差异备份集到介质服务器EGOV-TEST1,恢复数据到数据库服务器EGOV-TEST3,并检查数据。
全备设备大小:4G。
全备设备名称:DVDBOracleTesingFull。
复制全备设备名称:DVDBOracleTesingFull2。
差异设备大小:4G。
差异设备名称:DVDBOracleTesingDiff。
复制差异设备名称:DVDBOracleTesingDiff2。
全备介质集名称:MSDBOracleTesingFull, 附加周期为1,覆盖周期为1天。
复制全备介质集名称:MSDBOracleTesingFull2, 附加周期为1,覆盖周期为1天。
差异介质集名称:MSDBOracleTesingDiff, 附加周期为1,覆盖周期为1天。
复制差异介质集名称:MSDBOracleTesingDiff2,附加周期为1,覆盖周期为1天。
策略名称: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结束。
列表名称:BKSelDBOracleTesting
Menu: Tools -> Option –> Media Management
本案例的顺序为:
从本介质集搜索可以覆盖的介质。
从暂存介质集搜索可以覆盖的介质。
从其他介质集搜索可以覆盖的介质。
Menu: Network->Logon Accounts,至少要添加2个帐户,一个是EGOV-DB的OS帐户,一个是Oracle的最高权限帐户。
Menu: Tools->Options
点击Modify list,添加EGOV-DB的OS登陆帐户
全备Device,如下图
复制全备Device,如下图
差异Device,如下图
复制差异Device,如下图
全备Media Set,如下图
复制全备Media Set,如下图
差异Media Set,如下图
复制差异Media Set,如下图
Click Button “Edit Schedule Details”
Recurring Week days, click button “select all”
Time Window,
Preferred source device就是要复制的对象。
Click Button “Edit Schedule Details”
Recurring Week days, click button “select all”
Time Window,
Click Button “Edit Schedule Details”
Recurring Week days, click button “select all”
Time Window,
新建选择项列表
Selections
Resource Credential 测试,
New jobs using policy
Moniter
作业建好后,4个作业开始等待运行。注意运行时间是4月17日。
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>
下图是4月18日第二次运行后的结果
全备的设备DVDBOracleTestingFull
复制全备的设备DVDBOracleTestingFull2
差异的设备DVDBOracleTestingDiff
复制差异的设备DVDBOracleTestingDiff2
全备
第一次运行的时间是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要备份的文件大小是不一样的,这个备份时间是不同的,也会导致覆盖过期时间不同。
所以在设计附件周期与覆盖保护周期要充分考虑这些问题,才能设计的合理。
因为是恢复到不同oracle服务器,属于Oracle Redirection恢复。
目标机器上安装的oracle同版本的数据库
目标数据库的全局数据库名字和实例名称要和源oracle一致。例如本案例的Global Name:testing.egov-db,Instance Name:Testing。
目标数据库要处于归档模式。
目标数据库服务器上安装oracle agent,并配置正确。
为了能保证还原不出现更多的意外,建议在介质服务器上对目标数据库做一次备份,确保所有的设置是正确的。
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一样了,因为我以前恢复过)
到此,目标数据库已经完全准备好了。
拷贝EGOV-TEST3的DVDBOracleTesingFull,DVDBOracleTesingFul2,DVDBOracleTesingDiff,DVDBOracleTesingDiff2目录到EGOV-TEST1的E:/BE下。
全备
复制全备
差异
复制差异
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。
Scan(扫描)
扫描前的Device,是看不到介质的,如下图
在DVDBOracleTestingDiff上右键,Scan,扫描后的介质,等个几分钟才能出来,出来的介质还是不能识别的,所以有个问号,如下图
Inventory(清点介质)
扫描出来的介质有个“?”,说明介质还不能识别出来,需要清点,在Device上右键,选择Inventory,清点后,如下图
Catalog(编录介质)
如果要还原,还需要对介质编录,在介质上右键,选择Catalog Media,如下图
新建还原JOB,RestoreTest3OracleTesting.
一定要从control files还原。
解读上图:
从控制文件(Controll Files)看出,你可以恢复到列出的任何一个时间点,但是从这个看不出哪个是全备,哪个是差异备份,哪个是复制备份。
从控制文件(Controll Files)看出,有2个是相同的,这表明一个全备或者差异,一个是复制全备或者复制差异。我姑且认为上面的复制备份,因为整个列表是按照时间排序的。
从控制文件(Controll Files)看出,可以恢复到的时间点比备份计划的时间点推迟了几分钟。这里多出了3:22:15的时间点,因为原来的差异备份是在设计在这个时间点,但是我忘了向数据库插入记录了,所以为了插入记录,修改了差异备份的时间。
把鼠标放在任何一个表空间,便会有提示。
解读上图:
现在可以一目了然地看出哪个时间点是属于什么备份了。
能看出源oracle的数据库文件的存放目录。
选中任何一个时间点的控制文件。
解读上图:
时间点或者SCN,在恢复时能够用到,让恢复时精确的恢复到这个点。
DatabaseID,在还原时能够用到,目标数据库的ID要与源相同,否则无法恢复。
了解了以上的信息,那么我们就选择一个时间点进行恢复吧。我选择的时间点是第一次差异备份后,如下图:(2个已经被选择,呵呵,不是我选的,我只选择一个,系统自动勾上了另一个)
这一步不能少,结果必须是成功的。
这一步应该是没有用的,在备份的时候才有用,所以我就默认的了。
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安装目录是什么,只要确定一个目标安装目录就可以了,同时要保证目录是存在的。
遇到的错误如下:
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。
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 已经结束。
Oracle Redirection灾难恢复是成功的。
差异恢复是成功的,可以恢复到任何一个时间点。
因为是恢复到不同oracle服务器,属于Oracle Redirection恢复。不同的是备份集里面只有复制集。
本次备份是在恢复1成功后的基础上做的。
查询目标数据库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。
BE
同上。
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>
到此,目标数据库已经完全准备好了。
删除EGOV-TEST1的E:/BE/Backup目录下的DVDBOracleTesingFull,DVDBOracleTesingDiff两个目录。
删除EGOV-TEST1上所遇Device,Media set,再重建,同上。
无需覆盖。
扫描,清点,编录,同上。
新建还原JOB,RestoreTest3OracleTesting2.
一定要从control files还原。
从控制文件(Controll Files)看出,虽然介质集少了,但是所有的全备,复制备份都能显示出来,不理解,难道BE在备份的时候把所有的信息都写在配置文件了?或者是Catalog里。如下图
把鼠标放在任何一个表空间,便会有提示。如下图
选中任何一个时间点的控制文件。如下图
本case恢复第一次全备的。如下图
这一步不能少,结果必须是成功的。
这一步应该是没有用的,第一个例子已经证明了。所以不再设置了。
遇到的错误如下:
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的现存介质
已经失败了,没有后续工作。
Oracle Redirection灾难恢复2是失败的。
可能的原因是备份时复制备份的rule没有选好。默认的是复制所有的备份集,所以我在选择恢复时的controlfiles总是选择2个。如下图
重新执行备份还原计划,请看下一节。