ITPub博客

首页 > 数据库 > Oracle > NBU 7.0备份报ORA-19502备份

NBU 7.0备份报ORA-19502备份

Oracle 作者:wxbtsinghua 时间:2015-07-21 14:26:51 0 删除 编辑
NBU 7.0备份报ORA-19502备份



NBU 7.0控制台报ErrorCode 6 后台报ORA-19502备份(LAN方式)失败问题解决

一、问题现象


NBU控制台子作业details

……08/16/2013 02:00:03 - Info bphdb (pid=11141420) Waiting for the child status

08/16/2013 04:41:32 - Error bpbrm (pid=43384944) from client HOSTNAME: ERR - Script exited with status = 1 <the requested operation was partially successful>

08/16/2013 04:41:32 - Error bpbrm (pid=43384944) from client HOSTNAME: ERR - bphdb exit status = 6: the backup failed to back up the requested files

08/16/2013 04:41:34 - Info bphdb (pid=11141420) done. status: 6: the backup failed to back up the requested files

08/16/2013 04:41:34 - end writing

……

备份.out日志文件中对报错的描述

……

通道 ch01: 正在启动段 1 于 16-8月 -13

RMAN-03009: backup 命令 (ch00 通道上, 在 08/16/2013 02:52:08 上) 失败

ORA-27192: skgfcls: sbtclose2 返回错误 - 无法关闭文件

ORA-19511: 从介质管理器层接收到错误, 错误文本为:

   Failed to process backup file <bk_8495_1_823572047>

ORA-19502: 文件 "bk_8495_1_823572047", 块编号 17 (块大小=16384) 上出现写入错误

ORA-27030: skgfwrt: sbtwrite2 返回错误

ORA-19511: 从介质管理器层接收到错误, 错误文本为:

   VxBSASendData: Failed with error:

通道 ch00 已禁用, 将在另一个通道上运行该通道上失败的作业

二、问题原因

 分析子作业失败时间,发现每次都在45分钟的报错,而NBU客户端和服务器的超时都大于此时间,而每次备份报错时,都是增量备份,而每次全备都是成功的,由此推测,此备份策略配置的是LAN方式的备份,每次进行增量备份时,会在NBU客户端和Server端建立一个Socket连接,而在传输数据之前,在NBU客户端会进行大量的分析比对工作,这些工作占用大量的时间,并且分析完后NBU才会传输备份的数据,在分析工作没有完成前,建立的连接一直是“空闲”的,但是超过45分钟后连接被断开了。

三、问题解决

可以断开链接的原因可能有两种。第一种:操作系统的TCP机制;第二种:防火墙的策略机制;第一种可能经过在操作系统上确认相关的TCP参数,排除。第二种,发现防火墙上确实有对空闲连接相关策略。

如从规避防火墙策略的角度解决问题,解决问题又存在两种思路,第一种,对网络设置进行调整,经过沟通,发现修改防火墙从流程(非技术原因。。。 。。。)上非常难。第二种,减少在做增量备份时的分析比对时间,这种比较可行。

(1)Oracle数据开启block_change_tracking


进入到sqlplus下,确认当前数据库是否开启该参数(如果返回结果是DISABLE,说明未开启)

select * from v$block_change_tracking 


确认一下要将开启block_change_tracking后,存放的ASM DG(一般使用共享的ASM DG)


SQL> select name from v$asm_diskgroup;

NAME

------------------------------

FRADG

TESTDG

SYSDG

启用该参数

alter database enable block change tracking using file '+TESTDG' reuse;

对修改结果进行确认(如果是RAC环境需要在每个节点都确认)

SQL> select * from v$block_change_tracking;

修改完成后,需要手工发起全备以使该参数生效。全备完成后,手工发起增量备份,发现问题现象依旧。咨询Oracle工程师,发现在目前环境存在该参数不能生效的BUG(o(╯□╰)o),

10. BUG 13602883 - BLOCK CHANGE TRACKING NOT USED FOR INCREMENTAL BACKUPS

Symptoms :

if the database is running with cluster_database=TRUE and if Block Change Tracking (BCT) for Incremental Backups becomes unintentionally disabled and

if a RMAN session or an instance died during the previous backup and if the  RDBMS-release is <11.2.0.4, it could be this bug.The bug affects 11.2.0.2/3 (or possibly earlier) regardless of the platform(=OS). However, it only affects RAC installations ie. databases running withcluster_database=true.

The bug is fixed in >=11.2.0.4 .

(2)修改备份脚本每个备份片备份文件个数

减少每个备份片分析对比的数据文件个数。备份脚本有关内容如下:

BACKUP

    $BACKUP_TYPE

    SKIP INACCESSIBLE

    TAG hot_db_bk_level0

    FILESPERSET 20

    FORMAT 'bk_%s_%p_%t'

    DATABASE 

    plus 

    ARCHIVELOG

    filesperset 20

    FORMAT 'al_%s_%p_%t'

    DELETE ALL INPUT;

将其中的20修改为2,修改完成后,再次发起增量备份最后成功,观察几天后,发现问题没有重现。

 

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

请登录后发表评论 登录
全部评论

注册时间:2014-09-16

  • 博文量
    17
  • 访问量
    46580