免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
12下一页
最近访问板块 发新帖
查看: 8912 | 回复: 11

[Veritas NBU] 我遇到了一个nbu的问题,半个月没有找到问题的原因... [复制链接]

论坛徽章:
0
发表于 2008-02-14 15:30 |显示全部楼层
30可用积分
刚接手nbu,也没有人带我,全屏自己摸索,自己最近遇到一个问题,搞不定呀。且听我慢慢描述,由于是总结性的描述,时间过去也有那么一段了,难免有细节记得不清楚,但是应该大的方面不会错。有经验的朋友都帮忙给我出出主意吧,谢谢啦!
1月28号的时候,接到项目组的客服申请:说备份状态不正常。上去查看,看到备份状态码是196,照着troubleshooting上说的,备份窗口不够,就和项目组的人说了一下,把窗口调大些,延长了两个小时,因为归档日志占据了磁盘空间,让他们手动删了一部分日志,我在rman做了crosscheck,然后我又让他自己手动起一下之前因为时间窗口不够没有成功的全备,他答应了,我没多想,这事也就过去了。
    顺便提一下我们的项目备份情况:一个专用的备份服务器(b2000),安装的netbackup server,连着两台L25带库,有两台数据库服务器(v880)通过连接备份服务器进行数据库的备份。目前的情况是数据库A上所有的备份正常,数据库B上的备份报了196的错误。
   过了三天的样子,项目组又来找我,说目录空间达到90%。我心想,难道时间窗口还是不够吗?再次查看,数据库服务器B对应的两个策略,分别出现了6、25、54的错误,由于可能导致25和54的原因太多,我就从6着手处理,联系了一下项目组,说之后并没有手动备份过。我重新删除了一些归档日志,登录rman,做crosscheck,然后手动把备份都起了一下(手动起备份不考虑时间窗口的问题呀)。------等待结果。
   然后就开始春节放假了。腊月27、正月初一、正月初四,分别接到电话,都是在反映空间满。每次都是相同的提示:6、25、54.每次我都对命令进行微调:分别用了如下的方法进行处理(都是在服务器B上进行的操作)。
   1、rman target / catalog rman/rman@rman
      RMAN>crosscheck archivelog all;
   2、rman target / catalog rman/rman@rman
      RMAN>allocate channel for maintenance type disk;
      RMAN> change archivelog all crosscheck;
      RMAN>release channel;
   3、rman target / catalog rman/rman@rman
     RMAN>ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE DISK;
     RMAN>CROSSCHECK BACKUP;
     RMAN>DELETE EXPIRED BACKUP;
     RMAN>RELEASE CHANNEL;
最后的结果都是一样的,那三个返回码像幽灵一样挥之不去。甚至于我把所有的策略都改回最初的状态时,还看到了199的返回码。就这样,到了春节上班。
找到以前的同事,告诉我看日志信息。将2月7日的日志(我将与我们项目有关的信息用**代替了)贴上来吧:
hot_database_archivelog_backup.sh.out.20080207
Script /usr/openv/script1/hot_database_archivelog_backup.sh
==== started on 2008年02月07日 星期四 12时07分43秒 CST ====

RMAN: /opt/oracle/product/9.2.0.1/bin/rman
ORACLE_SID: **db1
ORACLE_USER: oracle
ORACLE_HOME: /opt/oracle/product/9.2.0.1
NB_ORA_FULL: 1
NB_ORA_INCR: 0
NB_ORA_CINC: 0
NB_ORA_SERV: b2000
NB_ORA_POLICY: oracle2_**_archivelog_backup
Full backup requested
Sun Microsystems Inc.   SunOS 5.8       Generic February 2000
You have new mail.
RMAN> 2> 3> 4> 5> 6> 7> 8> 9> 10> 11> 12> 13> 14> 15> 16> 17> 18> 19> 20> 21> 22> 23> 24> RMAN> l rights reserved.
连接到目标数据库: **DB1 (DBID=1820329014)
连接到恢复目录数据库
RMAN> 2> 3> 4> 5> 6> 7> 8> 9> 10> 11> 12> 13> 14> 15> 16> 17> 18> 19> 20> 21> 22> 23> 24>
分配的通道: ch00
通道 ch00: sid=134 devtype=SBT_TAPE
通道ch00: VERITAS NetBackup for Oracle - Release 5.0GA (2003103006)
分配的通道: ch01
通道 ch01: sid=45 devtype=SBT_TAPE
通道ch01: VERITAS NetBackup for Oracle - Release 5.0GA (2003103006)
启动 backup 于 2008-02-07 12:07:48
当前日志已存档
通道 ch00: 正在启动存档日志备份集
通道 ch00: 正在指定备份集中的存档日志
输入存档日志线程 =1 序列 =44637 记录 ID=85052 时间戳=645812283
输入存档日志线程 =1 序列 =44638 记录 ID=85053 时间戳=645814637
输入存档日志线程 =1 序列 =44639 记录 ID=85054 时间戳=645816713
输入存档日志线程 =1 序列 =44640 记录 ID=85055 时间戳=645818979
输入存档日志线程 =1 序列 =44641 记录 ID=85056 时间戳=645821250
输入存档日志线程 =1 序列 =44642 记录 ID=85057 时间戳=645823643
输入存档日志线程 =1 序列 =44643 记录 ID=85058 时间戳=645825718
输入存档日志线程 =1 序列 =44644 记录 ID=85059 时间戳=645827914
输入存档日志线程 =1 序列 =44645 记录 ID=85060 时间戳=645830210
输入存档日志线程 =1 序列 =44646 记录 ID=85061 时间戳=645832206
输入存档日志线程 =1 序列 =44647 记录 ID=85062 时间戳=645834555
输入存档日志线程 =1 序列 =44648 记录 ID=85063 时间戳=645836567
输入存档日志线程 =1 序列 =44649 记录 ID=85064 时间戳=645838821
输入存档日志线程 =1 序列 =44650 记录 ID=85065 时间戳=645840946
输入存档日志线程 =1 序列 =44651 记录 ID=85066 时间戳=645841258
输入存档日志线程 =1 序列 =44652 记录 ID=85067 时间戳=645841805
输入存档日志线程 =1 序列 =44653 记录 ID=85068 时间戳=645843701
输入存档日志线程 =1 序列 =44654 记录 ID=85069 时间戳=645845909
通道 ch00: 正在启动段 1 于 2008-02-07 12:08:09
通道 ch01: 正在启动存档日志备份集
通道 ch01: 正在指定备份集中的存档日志
输入存档日志线程 =1 序列 =44655 记录 ID=85070 时间戳=645847356
输入存档日志线程 =1 序列 =44656 记录 ID=85071 时间戳=645847689
输入存档日志线程 =1 序列 =44657 记录 ID=85072 时间戳=645848634
输入存档日志线程 =1 序列 =44658 记录 ID=85073 时间戳=645850316
输入存档日志线程 =1 序列 =44659 记录 ID=85074 时间戳=645852512
输入存档日志线程 =1 序列 =44660 记录 ID=85075 时间戳=645854562
输入存档日志线程 =1 序列 =44661 记录 ID=85076 时间戳=645857212
输入存档日志线程 =1 序列 =44662 记录 ID=85077 时间戳=645859591
输入存档日志线程 =1 序列 =44663 记录 ID=85078 时间戳=645861728
输入存档日志线程 =1 序列 =44664 记录 ID=85079 时间戳=645864064
输入存档日志线程 =1 序列 =44665 记录 ID=85080 时间戳=645866020
输入存档日志线程 =1 序列 =44666 记录 ID=85081 时间戳=645868358
输入存档日志线程 =1 序列 =44667 记录 ID=85082 时间戳=645870605
输入存档日志线程 =1 序列 =44668 记录 ID=85083 时间戳=645873037
输入存档日志线程 =1 序列 =44669 记录 ID=85084 时间戳=645874979
输入存档日志线程 =1 序列 =44670 记录 ID=85085 时间戳=645877288
输入存档日志线程 =1 序列 =44671 记录 ID=85086 时间戳=645879540
输入存档日志线程 =1 序列 =44672 记录 ID=85087 时间戳=645881539
通道 ch01: 正在启动段 1 于 2008-02-07 12:08:09
释放的通道: ch00
释放的通道: ch01
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of backup command on ch00 channel at 02/07/2008 23:54:15
ORA-19506: 无法创建顺序文件, 名称 = "al_47259_1_646056488", 参数 = ""
ORA-27028: skgfqcre: sbtbackup 返回错误
ORA-19511: 从介质管理器层接收到错误, 错误文本为:
   VxBSACreateObject: Failed with error:
   Server Status:  unable to process request because the server resources are busy
RMAN>
恢复管理器完成。
Script /usr/openv/script1/hot_database_archivelog_backup.sh
==== ended in error on 2008年02月08日 星期五 11时38分29秒 CST ====
hot_database_backup.sh.out.20080207Script /usr/openv/script1/hot_database_backup.sh
==== started on 2008年02月07日 星期四 03时09分00秒 CST ====

RMAN: /opt/oracle/product/9.2.0.1/bin/rman
ORACLE_SID: **db1
ORACLE_USER: oracle
ORACLE_HOME: /opt/oracle/product/9.2.0.1
NB_ORA_FULL: 0
NB_ORA_INCR: 1
NB_ORA_CINC: 0
NB_ORA_SERV: b2000
NB_ORA_POLICY: oracle_add_**
Differential incremental backup requested
Sun Microsystems Inc.   SunOS 5.8       Generic February 2000
You have new mail.
RMAN> 2> 3> 4> 5> 6> 7> 8> 9> 10> 11> 12> 13> 14> 15> 16> 17> 18> 19> 20> 21> 22> 23> 24> 25> 26> 27> 28> 29> 30> 31> 32> 33> 34> 35
> 36> 37> 38> RMAN> 9014)
连接到恢复目录数据库
RMAN> 2> 3> 4> 5> 6> 7> 8> 9> 10> 11> 12> 13> 14> 15> 16> 17> 18> 19> 20> 21> 22> 23> 24> 25> 26> 27> 28> 29> 30> 31> 32> 33> 34> 35
> 36> 37> 38>
分配的通道: ch00
通道 ch00: sid=369 devtype=SBT_TAPE
通道ch00: VERITAS NetBackup for Oracle - Release 5.0GA (2003103006)
分配的通道: ch01
通道 ch01: sid=416 devtype=SBT_TAPE
通道ch01: VERITAS NetBackup for Oracle - Release 5.0GA (2003103006)
启动 backup 于 2008-02-07 03:09:04
通道 ch00: 正在启动 incremental level 1 数据文件备份集
通道 ch00: 正在指定备份集中的数据文件
输入数据文件 fno=00002 name=/u03/oradata/undotbs01.dbf
输入数据文件 fno=00014 name=/u01/oradata/unicomdbs1.dbf
输入数据文件 fno=00073 name=/u01/oradata/datafile/d_perf2_dbs.dbf
输入数据文件 fno=00114 name=/u01/oradata/ADPINDB01.dbf
输入数据文件 fno=00115 name=/u01/oradata/adpindb02.dbf
通道 ch00: 正在启动段 1 于 2008-02-07 03:10:11
通道 ch01: 正在启动 incremental level 1 数据文件备份集
通道 ch01: 正在指定备份集中的数据文件
输入数据文件 fno=00131 name=/u02/oradata/unicomdbs2.dbf
输入数据文件 fno=00135 name=/u01/oradata/datafile/D_ALARM_DBS1.dbf
输入数据文件 fno=00053 name=/u01/oradata/datafile/i_pdsn_perf_dbs.dbf
输入数据文件 fno=00190 name=/u01/oradata/SYMANTEC_I3_ORCL.dbf
输入数据文件 fno=00004 name=/u01/oradata/drsys01.dbf
通道 ch01: 正在启动段 1 于 2008-02-07 03:10:11
释放的通道: ch00
释放的通道: ch01
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of backup command on ch00 channel at 02/08/2008 14:27:39
ORA-19506: 无法创建顺序文件, 名称 = "bk_47257_1_646024211", 参数 = ""
ORA-27028: skgfqcre: sbtbackup 返回错误
ORA-19511: 从介质管理器层接收到错误, 错误文本为:
   VxBSACreateObject: Failed with error:
   Server Status:  unable to process request because the server resources are busy
RMAN>
恢复管理器完成。
Script /usr/openv/script1/hot_database_backup.sh
==== ended in error on 2008年02月09日 星期六 02时10分29秒 CST ====
网上搜了一下,暂时没发现有什么特别管用信息。怀疑是不是这台服务器与b2000的软件配置这一块已经损坏了,故在服务器B增加了一个策略test,将某个目录下的文件直接备份到磁带中,观察是否能够成功完成,如果成功,那么可以将软件配置的问题排除。目前任务还在队列中,不知道结果如何。等待吧。

[ 本帖最后由 雪凤凰 于 2008-2-14 15:32 编辑 ]

论坛徽章:
0
发表于 2008-02-15 08:36 |显示全部楼层
分给得不够还是写的太罗嗦呢?
如果不行 那我只有重新配置客户端了...

论坛徽章:
2
IT运维版块每日发帖之星
日期:2016-03-19 06:20:00数据库技术版块每日发帖之星
日期:2016-07-05 06:20:00
发表于 2008-02-15 08:59 |显示全部楼层
我不懂NBU,给你一提示好吧,到Oracle网站查查RMAN-03009;ORA-19506;ORA-27028;RA-19511是什么类型的错误,有什么修复方法.
刚才查了,应该是你的客户端的配置问题,删除重配.

[ 本帖最后由 bencyber 于 2008-2-15 09:27 编辑 ]

论坛徽章:
0
发表于 2008-02-15 10:34 |显示全部楼层
谢谢了!我也正打算重配呢,呵呵。

论坛徽章:
0
发表于 2008-02-15 12:40 |显示全部楼层
按NBU的troubleshooting中的办法,打开NBU的log。

论坛徽章:
0
发表于 2008-02-17 11:25 |显示全部楼层
原帖由 gbz 于 2008-2-15 12:40 发表
按NBU的troubleshooting中的办法,打开NBU的log。

然后呢?查看有无异常还是问题就解决了?
我现在怀疑是不是网络连接有问题了

论坛徽章:
2
IT运维版块每日发帖之星
日期:2016-03-19 06:20:00数据库技术版块每日发帖之星
日期:2016-07-05 06:20:00
发表于 2008-02-18 11:31 |显示全部楼层
呵呵,给你一个案例:
The status code 6 error was encountered in the following NetBackup environment:

Master/Media server: Solaris 8.0
Client: Windows 2000, Clustered (Active-Passive), Oracle 9i, Oracle Failsafe, Inside the firewall
Virtual server name: virtualnode
Node names: nodeA, nodeB


The dbclient log showed the following:
10:42:12.012 [4080.4336] <2> logconnections: BPRD CONNECT FROM 204.22.80.176.3970 TO 10.43.124.104.13720
10:42:12.449 [4080.4336] <2> int_GetBfsDateRange: INF - Start Time = 09/14/04 11:42:10
10:42:12.449 [4080.4336] <2> int_GetBfsDateRange: INF - End Time = 09/16/04 11:42:10
10:42:12.449 [4080.4336] <2> logconnections: BPRD CONNECT FROM 204.22.80.176.3971 TO 10.43.124.104.13720
10:42:12.668 [4080.4336] <16> VxBSAQueryObject: ERR - dbc_get_string() failed 135
10:42:12.668 [4080.4336] <16> xbsa_QueryObject: ERR - VxBSAQueryObject: Failed with error:
  Server Status:  client is not validated to perform the requested operation
10:42:12.668 [4080.4336] <16> int_StartJob: ERR - Failed to process backup file <bk_u7jg01ns2_s243_p1_t536928130>


The bprd log showed the following:
10:42:13.740 [24355] <2> db_valid_client: no alternate names to check in /usr/openv/netbackup/db/altnames - No such file or directory (2)
10:42:13.740 [24355] <2> db_valid_client: client_name=virtualnode peername=nodeA
10:42:13.740 [24355] <2> db_valid_client: nodeA is not a valid client
10:42:13.741 [24355] <2> hosts_equal: hostnames DO NOT compare
10:42:13.741 [24355] <2> hosts_equal: name1=nodeA  name2=virtualnode
10:42:13.741 [24355] <2> hosts_equal: hostbuf=nodeA  hostentry->h_name=virtualnode
10:42:13.741 [24355] <2> hosts_equal: there were NO aliases for virtualnode
10:42:13.741 [24355] <2> hosts_equal: there were NO aliases for nodeA
10:42:13.741 [24355] <2> hosts_equal: addresses DO NOT match
10:42:13.741 [24355] <2> hosts_equal: nodeA=0xcc1650b0 virtualnode=0xcc1650b6
10:42:13.741 [24355] <2> process_request: client virtualnode peername nodeA is invalid for list request
10:42:13.947 [19900] <2> childterm: pid=24355 exit=135, signo=0 core=no


The bpdbsbora log showed the following errors:
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of backup command on ch00 channel at 09/10/2004 15:10:57
10:42:58.663 [4060.3084] <2> logconnections: BPRD CONNECT FROM 204.22.80.176.3580 TO 10.43.124.104.13720
ORA-19506: failed to create sequential file, name="bk_u6jfvl1nu_s211_p1_t536512254", parms=""
ORA-27028: skgfqcre: sbtbackup returned error
ORA-19511: Error received from media manager layer, error text:
  Failed to process backup file <bk_u6jfvl1nu_s211_p1_t536512254>


Based on the above logs, client name nodeA which is the peername for virtual server name virtualnode is not allowed to perform the list and backup operation by the master server. To resolve this issue, create the following touch file in the master server in the following path:

/usr/openv/netbackup/db/altnames/No.Restrictions

OR:
Create the following touch files on the master server:
/usr/openv/netbackup/db/altnames/nodeA
/usr/openv/netbackup/db/altnames/nodeB

OR:
A more restrictive method is to create the above files, nodeA and nodeB, that now contain the name virtualnode as text in the file rather than just as a touch file.

论坛徽章:
0
发表于 2008-02-18 15:59 |显示全部楼层
观望

论坛徽章:
0
发表于 2008-02-18 16:07 |显示全部楼层
在oracle用户下执行你的脚本再看看错误会不会是通道分配的原因.rman cmdfile 你的脚本.

论坛徽章:
0
发表于 2008-02-19 00:19 |显示全部楼层
Hope this could help:

Re: [Veritas-bu] RMAN error:ORA-19506
http://www.mail-archive.com/veritas-bu@mailman.eng.auburn.edu/msg10319.html
...
Found that the bprd service had hung / not responding. Therefore, reloaded
inetd, then bprd started listening. After this, the backups are working fine.
...
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

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

清除 Cookies - ChinaUnix - Archiver - WAP - TOP