ITPub博客

首页 > 应用开发 > IT综合 > vertias异机恢复过程

vertias异机恢复过程

原创 IT综合 作者:OmarChina 时间:2007-09-28 14:05:49 0 删除 编辑

情况():拥有控制文件的恢复

[@more@]

说明:

10.10.0.58 backupdatabase ,假设此为使用中重要DB ,通过veritas 全库备份至磁带机。

10.10.0.53 ctdb04 ,假设此为新服务器,无数据库。

10.10.0.59 cdim ,veritas server软件服务器,(windows 2000)

说明:

158数据库有完整全备份在磁带机中(包括controlfile,其参数文件和controlfile也有第三方手段进行备份。

258服务器宕机,无法修复,需要用将数据恢复至53服务器中。

操作流程如下:

1) 利用oracle tar包在10.10.0.53部署数据库。(略过,见文档XXX);目录与58保持一致。(数据库不用创建)

2) 53服务器上部署veritas client,agnet。(略过,见veritas安装使用帮助文档)。

3) 将通过第三放备份58的相关文件(controlfileinit参数文件, listener.oratnsnames.ora

bash_profile)拷贝至53数据库相应目录,并修改至正确配置。

4) veritas server软件服务器(10.10.0.59)上C:Program FilesVERITASNetBackupdb目录下创建altnames目录,并在此目录下建立No.restrictions空文件。----此步骤为打开veritas软件允许异机恢复功能。

5) 53数据库上变更veritas 的配置属性。

[oracle@ctdb04 netbackup]$ cd /usr/openv/netbackup/

[oracle@ctdb04 netbackup]$ cat bp.conf

SERVER = cdim ------此为veritas软件服务器主机名

CLIENT_NAME = ctdb04 ------此为53主机名,需变更为58主机名backupdatabase

---修改bp.conf-----

cat bp.conf

SERVER = cdim

CLIENT_NAME = backupdatabase

6) 进行恢复操作:

启动数据库至Mount状态

[oracle@ctdb04 netbackup]$ rman nocatalog target /

nocatalog的方式连接53(ctdb04)

Recovery Manager: Release 8.1.7.4.0 - Production

RMAN-06005: connected to target database: SOUTHDB (DBID=4120592817)

RMAN-06009: using target database controlfile instead of recovery catalog

运行脚本如下:

run {

allocate channel t1 type 'sbt_tape' parms="ENV=(NB_ORA_CLIENT=backupdatabase)";

set archivelog destination to '/u01/app/oracle/product/8.1.7/dbs/';

restore database skip tablespace TEMP,USERS;

recover database skip forever tablespace USERS;

release channel c1;

}

RMAN> run {

2> allocate channel t1 type 'sbt_tape' parms="ENV=(NB_ORA_CLIENT=backupdatabase)";

分配通道sbt_tape表明磁带,并配置磁带参数

3> set archivelog destination to ' /u01/app/oracle/admin/southdb/arch ';

设置归档的目的地(有归档的话)

4> restore database skip tablespace TEMP,USERS;

还原数据库,不还原部分表空间为了加速测试还原的速度,若全库还原用restore

database 即可。

5> recover database skip forever tablespace USERS;

恢复数据库,跳过表空间。若全库恢复的话recover database即可.

6> release channel c1;

7> }

若脚本运行正常,观察到59服务器veritas的状况如图所示:

磁带机中的文件正在往ctdb04还原。

1) 至此58数据库(有controlfile)异机恢复至53数据库案例完成。

情况():丢失控制文件的恢复

说明:

1 58数据库有完整全备份在磁带机中(包括controlfile,但丢失了第三放备份的控制文件。

258服务器宕机,无法修复,需要用将数据恢复至53服务器中。

操作流程如下:

1) 重复上述步骤(1)至步骤(5),除了controlfile无法还原至指定目的地。

2) 查看rman最后一次备份的日志,

获得备份的控制文件的备份集名称:bk_u02io9uqc_s2_p1_t629472076

3) 把数据库开启至NOMOUNT的状态

其下演示恢复控制文件至指定路径下:

SQL> startup nomount

ORACLE instance started.

Total System Global Area 735150240 bytes

Fixed Size 73888 bytes

Variable Size 256655360 bytes

Database Buffers 471859200 bytes

Redo Buffers 6561792 bytes

#####开始还原控制文件#####

SQL> DECLARE

2 devtype varchar2(256);

3 done boolean;

4 BEGIN

5 devtype:=sys.dbms_backup_restore.deviceAllocate(type=>'sbt_tape',ident=>'t1');

6 sys.dbms_backup_restore.restoreSetDatafile;

7 sys.dbms_backup_restore.restoreControlfileTo(cfname=>'/u01/control.bak');

8 sys.dbms_backup_restore.restoreBackupPiece(done=>done,handle=>

'bk_u02io9uqc_s2_p1_t629472076',params=>'ENV=(NB_ORA_CLIENT=backupdatabase)');

9 sys.dbms_backup_restore.deviceDeallocate;

10 END;

11 /

PL/SQL procedure successfully completed.

#####控制文件还原完成#####

[oracle@ctdb04 u01]$ ls co*

control.bak

[oracle@ctdb04 u01]$ cp control.bak /u01/app.../control01.ctl

[oracle@ctdb04 u01]$ cp control.bak /u01/app.../control02.ctl

[oracle@ctdb04 u01]$ cp control.bak /u01/app.../control03.ctl

其下演示直接在NOMOUNT的状态下恢复归档日志文件。

检查RMAN备份日志得到归档日志备份集合的名称为arch-s3-p1-t629474852

#####还原归档日志文件至默认路径下#####

SQL> DECLARE

2 devtype varchar2(256);

3 done boolean;

4 BEGIN

5 devtype:=sys.dbms_backup_restore.deviceAllocate (type=>'sbt_tape',ident=>'t1');

6 sys.dbms_backup_restore.restoreSetArchivedlog;

7 sys.dbms_backup_restore.restoreArchivedLogRange(0,281474976710655);

8 sys.dbms_backup_restore.restoreBackupPiece(done=>done,handle=>

'arch-s3-p1-t629474852', params=>'ENV=(NB_ORA_CLIENT=backupdatabase)');

11 sys.dbms_backup_restore.deviceDeallocate;

12 END;

13 /

PL/SQL procedure successfully completed.

#####归档日志文件还原完成#####

其下演示直接在NOMOUNT的状态下恢复归档数据文件。

检查RMAN备份日志得到数据文件备份集合的名称为arch-s3-p1-t629474852

MOUNT的状态下通过此SQL语句

SELECT 'sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>' || File# ||
',toname=>''' || NAME || '''' || ');'
FROM V$datafile;

生成如下所示:

sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>18,toname=>'/u01/app.../users010.dbf');

…….

sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>35,toname=>'/u01/app.../users026.dbf');

sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>44,toname=>'/u01/app.../users035.dbf');

把数据库打开至Nomount的状态

SQL> conn / as sysdba

Connected.

#####还原数据文件至默认路径下#####

SQL> DECLARE

2 devtype varchar2(256);

3 done boolean;

4 BEGIN

5 devtype:=sys.dbms_backup_restore.deviceAllocate (type=>'SBT_TAPE',ident=>'t1');

6 sys.dbms_backup_restore.restoreSetDatafile;

7 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>1,toname=>'/u01/app.../system01.dbf');

8 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>2,toname=>'/u01/app.../tools01.dbf');

9 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>3,toname=>'/u01/app.../rbs01.dbf');

10 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>4,toname=>'/u01/app.../users001.dbf');

11 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>5,toname=>'/u01/app.../users002.dbf');

12 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>6,toname=>'/u01/app.../indx01.dbf');

13 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>7,toname=>'/u01/app.../drsys01.dbf');

14 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>8,toname=>'/u01/app.../users003.dbf');

15 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>9,toname=>'/u01/app.../users004.dbf');

16 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>10,toname=>'/u01/app.../rbs02.dbf');

17 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>11,toname=>'/u01/app.../rbs03.dbf');

18 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>12,toname=>'/u01/app.../rbs04.dbf');

19 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>13,toname=>'/u01/app.../users005.dbf');

20 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>14,toname=>'/u01/app.../users006.dbf');

21 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>15,toname=>'/u01/app.../users007.dbf');

22 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>16,toname=>'/u01/app.../users008.dbf');

23 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>17,toname=>'/u01/app.../users009.dbf');

24 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>18,toname=>'/u01/app.../users010.dbf');

25 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>19,toname=>'/u01/app.../users011.dbf');

26 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>20,toname=>'/u01/app.../users012.dbf');

27 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>21,toname=>'/u01/app.../users013.dbf');

28 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>22,toname=>'/u01/app.../users014.dbf');

29 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>23,toname=>'/u01/app.../users015.dbf');

30 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>24,toname=>'/u01/app.../users016.dbf');

31 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>25,toname=>'/u01/app.../users017.dbf');

32 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>26,toname=>'/u01/app.../users018.dbf');

33 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>27,toname=>'/u01/app.../datant01.dbf');

34 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>28,toname=>'/u01/app.../users019.dbf');

35 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>29,toname=>'/u01/app.../users020.dbf');

36 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>30,toname=>'/u01/app.../users021.dbf');

37 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>31,toname=>'/u01/app.../users022.dbf');

38 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>32,toname=>'/u01/app.../users023.dbf');

39 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>33,toname=>'/u01/app.../users024.dbf');

40 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>34,toname=>'/u01/app.../users025.dbf');

41 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>35,toname=>'/u01/app.../users026.dbf');

42 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>36,toname=>'/u01/app.../users027.dbf');

43 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>37,toname=>'/u01/app.../users028.dbf');

44 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>38,toname=>'/u01/app.../users029.dbf');

45 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>39,toname=>'/u01/app.../users030.dbf');

46 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>40,toname=>'/u01/app.../users031.dbf');

47 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>41,toname=>'/u01/app.../users032.dbf');

48 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>42,toname=>'/u01/app.../users033.dbf');

49 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>43,toname=>'/u01/app.../users034.dbf');

50 sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>44,toname=>'/u01/app.../users035.dbf');

51 sys.dbms_backup_restore.restoreBackupPiece(done=>done,

handle=>'bk_u02io9uqc_s2_p1_t629472076',params=>'ENV=(NB_ORA_CLIENT=backupdatabase)');

53 sys.dbms_backup_restore.deviceDeallocate;

54 END;

55 /

PL/SQL procedure successfully completed.

#####数据文件还原完成#####

其下演示完成控制文件,数据文件,归档日志文件的还原后进行恢复的流程:

SQL> alter database mount;

Database altered.

SQL> alter database open;

alter database open;

ERROR at line 1:

ORA-01589: must use RESETLOGS or NORESETLOGS option for database open

SQL> recover database using backup controlfile until cancel;

ORA-00279: change 73242185 generated at 07/12/2007 15:20:41 needed for thread1

ORA-00289: suggestion : /u01/app/oracle/product/8.1.7/dbs/arch1_482.dbf

ORA-00280: change 7324213885 for thread 1 is in sequence #482

Specify log: {=suggested | filename | AUTO | CANCEL}

auto

ORA-00279: change 7324213955 generated at 08/01/2007 14:07:05 needed for thread1

ORA-00289: suggestion : /u01/app/oracle/product/8.1.7/dbs/arch1_483.dbf

ORA-00280: change 7324213955 for thread 1 is in sequence #483

ORA-00278: log file '/u01/app/oracle/product/8.1.7/dbs/arch1_482.dbf' no longer

needed for this recovery

ORA-00308: cannot open archived log

'/u01/app/oracle/product/8.1.7/dbs/arch1_483.dbf'

ORA-27037: unable to obtain file status

Linux Error: 2: No such file or directory

Additional information: 3

SQL> recover database using backup controlfile until cancel;

ORA-00279: change 7324213955 generated at 08/01/2007 14:07:05 needed for thread1

ORA-00289: suggestion : /u01/app/oracle/product/8.1.7/dbs/arch1_483.dbf

ORA-00280: change 7324213955 for thread 1 is in sequence #483

Specify log: {=suggested | filename | AUTO | CANCEL}

cancel

Media recovery cancelled.

SQL> alter database open resetlogs;

Database altered.

SQL> select count(*) from v$session;

COUNT(*)

----------

28

SQL>

至此数据库的恢复工作完成! 数据库成功开启!

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/9925929/viewspace-973408/,如需转载,请注明出处,否则将追究法律责任。

上一篇: ORA-02062号错误
请登录后发表评论 登录
全部评论
  • 博文量
    68
  • 访问量
    997957