ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 一次带库备份异常

一次带库备份异常

原创 Linux操作系统 作者:yangtingkun 时间:2007-06-22 00:00:00 0 删除 编辑

今天在测试RAC的备份时发现,一个节点上备份到带库出现异常。


现象是在一个节点上备份到带库,整个备份过程就没有任何的相应了。

通过netbackup的图形管理工具jnbSA,发现后台备份job已经失败。错误状态54

前台进程必须通过CTRL+C来手工中止,其中错误信息类似如下:

RMAN> backup spfile;

启动 backup 22-6 -07忽略 SBT_TAPE 通道 2 的配置分配的通道: ORA_SBT_TAPE_1通道 ORA_SBT_TAPE_1: sid=288 实例=testrac1 devtype=SBT_TAPE通道ORA_SBT_TAPE_1: VERITAS NetBackup for Oracle - Release 6.0 (2006110304)通道 ORA_SBT_TAPE_1: 启动全部数据文件备份集通道 ORA_SBT_TAPE_1: 正在指定备份集中的数据文件在备份集中包含当前的 SPFILE通道 ORA_SBT_TAPE_1: 正在启动段 1 22-6 -07
^C

MAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: backup
命令 (ORA_SBT_TAPE_1 通道上, 06/22/2007 20:24:54 ) 失败
ORA-19506:
无法创建顺序文件, 名称 = "p3ikujbo_1_1", 参数 = ""
ORA-27028: skgfqcre: sbtbackup
返回错误

ORA-19511:
从介质管理器层接收到错误, 错误文本为:
VxBSACreateObject: Failed with error:
Server Status: Communication with the server has not been iniatated or the server status has not been retrieved from the server.

RMAN>
MAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00558:
分析输入命令时出错
RMAN-01006:
在分析时出错信号
RMAN-02003:
无法识别的字符:

或者:

$ rman target /

恢复管理器: Release 10.2.0.3.0 - Production on 星期五 6 22 22:00:42 2007

Copyright (c) 1982, 2005, Oracle. All rights reserved.

连接到目标数据库: TESTRAC (DBID=4291216984)

RMAN> backup spfile;

启动 backup 22-6 -07使用目标数据库控制文件替代恢复目录忽略 SBT_TAPE 通道 2 的配置分配的通道: ORA_SBT_TAPE_1通道 ORA_SBT_TAPE_1: sid=283 实例=testrac1 devtype=SBT_TAPE通道ORA_SBT_TAPE_1: VERITAS NetBackup for Oracle - Release 6.0 (2006110304)通道 ORA_SBT_TAPE_1: 启动全部数据文件备份集通道 ORA_SBT_TAPE_1: 正在指定备份集中的数据文件在备份集中包含当前的 SPFILE通道 ORA_SBT_TAPE_1: 正在启动段 1 22-6 -07
^C
接受到用户中断
完成 backup 22-6 -07

MAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03099:
按用户要求取消作业

RMAN>
RMAN> RUN
2> {
3> ALLOCATE CHANNEL C1 DEVICE TYPE SBT;
4> BACKUP TABLESPACE USERS;
5> }

释放的通道: ORA_SBT_TAPE_1分配的通道: C1通道 C1: sid=283 实例=testrac1 devtype=SBT_TAPE通道C1: VERITAS NetBackup for Oracle - Release 6.0 (2006110304)

启动 backup 22-6 -07通道 C1: 启动全部数据文件备份集通道 C1: 正在指定备份集中的数据文件输入数据文件 fno=00005 name=+DISK/testrac/datafile/users.267.618591279通道 C1: 正在启动段 1 22-6 -07
^C
接受到用户中断
完成 backup 22-6 -07

释放的通道: C1
MAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03099:
按用户要求取消作业

通过jnbSA的图形界面,观测错误信息的详细记录发现:

1: (54) timed out connecting to client

看来似乎是连接出了问题,但是如果连接失败,RAC环境就会出现问题,其中一个实例会自动关闭,而现在仍然是正常的,检查网络也未发现异常。

而且,这个问题只发生在一个节点上,对另一个节点上的RMAN运行没有影响。

莫非是配置的问题,检查了一下RMAN的配置:

RMAN> SHOW ALL;

RMAN 配置参数为:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF;
CONFIGURE DEFAULT DEVICE TYPE TO 'SBT_TAPE';
CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE 'SBT_TAPE' TO 'c_%F';
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 1 BACKUP TYPE TO BACKUPSET;
CONFIGURE DEVICE TYPE DISK PARALLELISM 2 BACKUP TYPE TO BACKUPSET;
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE SBT_TAPE TO 1; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE SBT_TAPE TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE CHANNEL 1 DEVICE TYPE 'SBT_TAPE' SEND 'NB_ORA_CLIENT=backup,CPF1_POLICY=testoracle,CPF1_SCHED=Default-Application-Backup,CPF2_POLICY=testoracle,CPF2_SCHED=test_multi_copy';
CONFIGURE CHANNEL 2 DEVICE TYPE 'SBT_TAPE' SEND 'NB_ORA_CLIENT=backup,CPF1_POLICY=testoracle,CPF1_SCHED=Default-Application-Backup,CPF2_POLICY=testoracle,CPF2_SCHED=test_multi_copy';
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/data1/backup/%U', '/data1/%U';
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/data/oracle/product/10.2/database/dbs/snapcf_testrac1.f'; # default

发现了为了测试多个备份集而设置了CHANNELSEND配置参数。而且备份参数传递的CLIENT信息就是可以成功备份的那个节点。

莫非就是这个问题导致的,尝试清除所有的CHANNEL配置:

RMAN> CONFIGURE CHANNEL 1 DEVICE TYPE SBT CLEAR;

旧的 RMAN 配置参数:
CONFIGURE CHANNEL 1 DEVICE TYPE 'SBT_TAPE' SEND 'NB_ORA_CLIENT=backup,CPF1_POLICY=testoracle,CPF1_SCHED=Default-Application-Backup,CPF2_POLICY=testoracle,CPF2_SCHED=test_multi_copy';
已成功删除旧的 RMAN 配置参数

RMAN> CONFIGURE CHANNEL 2 DEVICE TYPE SBT CLEAR;

旧的 RMAN 配置参数:
CONFIGURE CHANNEL 2 DEVICE TYPE 'SBT_TAPE' SEND 'NB_ORA_CLIENT=backup,CPF1_POLICY=testoracle,CPF1_SCHED=Default-Application-Backup,CPF2_POLICY=testoracle,CPF2_SCHED=test_multi_copy';
已成功删除旧的 RMAN 配置参数

RMAN> EXIT

恢复管理器完成。
$ rman target /

恢复管理器: Release 10.2.0.3.0 - Production on 星期五 6 22 22:52:56 2007

Copyright (c) 1982, 2005, Oracle. All rights reserved.

连接到目标数据库: TESTRAC (DBID=4291216984)

RMAN> backup spfile;

启动 backup 22-6 -07使用目标数据库控制文件替代恢复目录分配的通道: ORA_SBT_TAPE_1通道 ORA_SBT_TAPE_1: sid=281 实例=testrac1 devtype=SBT_TAPE通道ORA_SBT_TAPE_1: VERITAS NetBackup for Oracle - Release 6.0 (2006110304)通道 ORA_SBT_TAPE_1: 启动全部数据文件备份集通道 ORA_SBT_TAPE_1: 正在指定备份集中的数据文件在备份集中包含当前的 SPFILE通道 ORA_SBT_TAPE_1: 正在启动段 1 22-6 -07通道 ORA_SBT_TAPE_1: 已完成段 1 22-6 -07段句柄=p9ikusus_1_1 标记=TAG20070622T225315 注释=API Version 2.0,MMS Version 5.0.0.0通道 ORA_SBT_TAPE_1: 备份集已完成, 经过时间:00:02:06完成 backup 22-6 -07

居然就是由于SENDCLIENT信息与当前节点不匹配造成的。奇怪的是,前面尝试手工分配CHANNDEL的时候,按说应该不会继承自动配置的结果,没想到也同样的报错了。看来这个SEND配置会对后面所有的CHANNEL都生效。

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

请登录后发表评论 登录
全部评论
暂无介绍

注册时间:2007-12-29

  • 博文量
    1955
  • 访问量
    10355117