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
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
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，修改完成後，再次發起增量備份最後成功，觀察幾天後，發現問題沒有重現。