一、问题现象NBU控制台子作业details……08/16/2013 02:00:03 - Info bphdb (pid=11141420) Waiting for the child status08/16/2013 04:41:32 - Error bpbrm (pid=43384944) from client HOSTNAME: ERR - Script exited with status = 1
二、问题原因 分析子作业失败时间，发现每次都在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------------------------------FRADGTESTDGSYSDG启用该参数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 BACKUPSSymptoms :if the database is running with cluster_database=TRUE and if Block Change Tracking (BCT) for Incremental Backups becomes unintentionally disabled andif 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，修改完成后，再次发起增量备份最后成功，观察几天后，发现问题没有重现。