免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
› 论坛 › IT运维 › 存储备份 › Veritas技术交流区 › nbu oracle恢复
12下一页
最近访问板块 发新帖
查看: 10985 | 回复: 12
打印 上一主题 下一主题

[Veritas NBU] nbu oracle恢复 [复制链接]

edxi

论坛徽章:
0
跳转到指定楼层
1楼 [收藏(0)] [报告]
发表于 2010-03-29 17:06 |只看该作者 |倒序浏览
想在另外一台机器上面恢复（oracle_link做了，主机名ip不一样，hosts里面加了个一样的主机名别名还是不行）

RMAN> run{
ALLOCATE CHANNEL ch00 TYPE 'SBT_TAPE';
2> 3> set until time "to_date('03/26/10 03:00:00','MM/DD/YY HH24:MI:SS')";
4> restore controlfile;
5> release channel ch00;
6> }

allocated channel: ch00
channel ch00: sid=9 devtype=SBT_TAPE
channel ch00: Veritas NetBackup for Oracle - Release 6.5 (2009050107)

executing command: SET until clause

Starting restore at 29-MAR-10

channel ch00: starting datafile backupset restore
channel ch00: restoring controlfile
output filename=/TAHdata/oradata/muhol/control01.ctl
released channel: ch00
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 03/29/2010 16:50:05
ORA-19507: failed to retrieve sequential file, handle="cntrl_426_1_714410356", parms=""
ORA-27029: skgfrtrv: sbtrestore returned error
ORA-19511: Error received from media manager layer, error text:
   Backup file <cntrl_426_1_714410356> not found in NetBackup catalog

list backup of controlfile;也看到存在备份的
BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
5207957 Full    2M         SBT_TAPE    00:00:47     23-MAR-10      
        BP Key: 5207958   Status: AVAILABLE   Tag: TAG20100323T151916
        Piece Name: cntrl_426_1_714410356
  Controlfile Included: Ckp SCN: 24952427     Ckp time: 23-MAR-10

BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
5217728 Incr 0  2M         SBT_TAPE    00:11:03     27-MAR-10      
        BP Key: 5217729   Status: AVAILABLE   Tag: HOT_DB_BK_LEVEL0
        Piece Name: bk_427_1_714753995
  Controlfile Included: Ckp SCN: 25066580     Ckp time: 27-MAR-10

BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
5217977 Full    2M         SBT_TAPE    00:00:47     27-MAR-10      
        BP Key: 5217978   Status: AVAILABLE   Tag: TAG20100327T151516
        Piece Name: cntrl_434_1_714755716
  Controlfile Included: Ckp SCN: 25067154     Ckp time: 27-MAR-10

怎么办
恢复, 恢复
jgtvisionnex

论坛徽章:
0
2楼 [报告]
发表于 2010-03-29 17:47 |只看该作者
做异机恢复，需要增加那个文件，No.restrictions，具体参考下文！写的挺清楚的了！

具体链接：http://omarchina.itpub.net/post/31742/400951

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

说明：
10.10.0.58 backupdatabase ,假设此为使用中重要DB ，通过veritas 全库备份至磁带机。
10.10.0.53 ctdb04 ,假设此为新服务器，无数据库。
10.10.0.59 cdim ,veritas server软件服务器，(windows 2000)。
说明：
1，58数据库有完整全备份在磁带机中（包括controlfile）,其参数文件和controlfile也有第三方手段进行备份。
2，58服务器宕机，无法修复，需要用将数据恢复至53服务器中。
操作流程如下：
1） 利用oracle tar包在10.10.0.53部署数据库。（略过，见文档XXX）；目录与58保持一致。（数据库不用创建）
2） 53服务器上部署veritas client,agnet。（略过，见veritas安装使用帮助文档）。
3） 将通过第三放备份58的相关文件(controlfile，init参数文件， listener.ora，tnsnames.ora，
bash_profile)拷贝至53数据库相应目录，并修改至正确配置。
4） 在veritas server软件服务器（10.10.0.59）上Crogram 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）,但丢失了第三放备份的控制文件。
2，58服务器宕机，无法修复，需要用将数据恢复至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: {<RET>=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: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
Media recovery cancelled.
SQL> alter database open resetlogs;
Database altered.
SQL> select count(*) from v$session;
COUNT(*)
----------
28
SQL>
至此数据库的恢复工作完成! 数据库成功开启！
实战分享：从技术角度谈机器学习入门| 【大话IT】RadonDB低门槛向MySQL集群下战书 | ChinaUnix打赏功能已上线！ | 新一代分布式关系型数据库RadonDB知多少？
无牙

论坛徽章:
1
CU十二周年纪念徽章 日期:2013-10-24 15:41:34
3楼 [报告]
发表于 2010-03-29 17:53 |只看该作者
不错
实战分享：从技术角度谈机器学习入门| 【大话IT】RadonDB低门槛向MySQL集群下战书 | ChinaUnix打赏功能已上线！ | 新一代分布式关系型数据库RadonDB知多少？
ry715

论坛徽章:
0
4楼 [报告]
发表于 2010-03-30 09:10 |只看该作者
异机恢复还要set DBID吧
实战分享：从技术角度谈机器学习入门| 【大话IT】RadonDB低门槛向MySQL集群下战书 | ChinaUnix打赏功能已上线！ | 新一代分布式关系型数据库RadonDB知多少？
edxi

论坛徽章:
0
5楼 [报告]
发表于 2010-03-30 09:41 |只看该作者
感激！可以了！谢谢！
实战分享：从技术角度谈机器学习入门| 【大话IT】RadonDB低门槛向MySQL集群下战书 | ChinaUnix打赏功能已上线！ | 新一代分布式关系型数据库RadonDB知多少？
jgtvisionnex

论坛徽章:
0
6楼 [报告]
发表于 2010-03-30 09:52 |只看该作者
其实这样做完了，你可以把你整个的操作过程记录下来，供大家参考一下，然后把环境介绍一直，对其他人会有更多的帮助！不过挺辛苦的！
实战分享：从技术角度谈机器学习入门| 【大话IT】RadonDB低门槛向MySQL集群下战书 | ChinaUnix打赏功能已上线！ | 新一代分布式关系型数据库RadonDB知多少？
ry715

论坛徽章:
0
7楼 [报告]
发表于 2010-03-31 10:31 |只看该作者
对呀，咋就可以了，啥问题，怎么解决的，是不是也可以分享一下呢???
实战分享：从技术角度谈机器学习入门| 【大话IT】RadonDB低门槛向MySQL集群下战书 | ChinaUnix打赏功能已上线！ | 新一代分布式关系型数据库RadonDB知多少？
michael1983

论坛徽章:
10
处女座 日期:2015-01-22 16:08:50技术图书徽章 日期:2018-09-13 11:25:52技术图书徽章 日期:2018-09-13 11:25:45技术图书徽章 日期:2018-09-13 11:25:37技术图书徽章 日期:2018-09-13 11:25:29黑曼巴 日期:2018-06-04 09:03:192017金鸡报晓 日期:2017-01-10 15:19:56极客徽章 日期:2016-12-07 14:03:402015年迎新春徽章 日期:2015-03-04 09:50:28技术图书徽章 日期:2018-09-13 11:26:01
8楼 [报告]
发表于 2010-03-31 12:14 |只看该作者
楼主分享下经验啊
实战分享：从技术角度谈机器学习入门| 【大话IT】RadonDB低门槛向MySQL集群下战书 | ChinaUnix打赏功能已上线！ | 新一代分布式关系型数据库RadonDB知多少？
edxi

论坛徽章:
0
9楼 [报告]
发表于 2010-03-31 13:05 |只看该作者
因为后来又发现新问题了，所以没有回复，回复control file解决是通过吧bp.conf里面的client改成备份的那台机器名就解决了，然后现在回复数据库还是有问题，我这些天比较忙，等有空了继续弄
实战分享：从技术角度谈机器学习入门| 【大话IT】RadonDB低门槛向MySQL集群下战书 | ChinaUnix打赏功能已上线！ | 新一代分布式关系型数据库RadonDB知多少？
ry715

论坛徽章:
0
10楼 [报告]
发表于 2010-04-01 09:03 |只看该作者
这么麻烦吗？？？
实战分享：从技术角度谈机器学习入门| 【大话IT】RadonDB低门槛向MySQL集群下战书 | ChinaUnix打赏功能已上线！ | 新一代分布式关系型数据库RadonDB知多少？
12下一页
返回列表 发新帖
高级模式
B Color Image Link Quote Code Smilies
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号：11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们：huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP