在客户现场实施备份软件时， 客户环境中存在N套primary + 异地DG的Oracle数据库，同时客户要求primary与异地DG都需要备份. primary与异地DG都采用相同的catalog作为rman的repository
primary与异地DG的备份脚本中备份归档日志得部分，都使用了not backed up这个选项。
backup
format 'TEST_TESTDB_11203<testdb_%s:%t:%p>.dbf'
tag 'PRODUCTION'
archivelog all
not backed up;
在生产环境进行数据库的恢复性验证时， 经常出现:
RMAN-06053: unable to perform media recovery because of missing log
RMAN-06025: no backup of archived log for thread 1 with sequence 484631 and starting SCN of 1298100875120 found to restore
RMAN-06025: no backup of archived log for thread 2 with sequence 427592 and starting SCN of 1298100864731 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 484630 and starting SCN of 1298100816565 found to restore
但是通过list backup of archivelog其实是可以看到备份，但是备份是位于异地的备份存储介质上。研究半天，发现问题出在not backed up这个选项上。异地DG备份归档日志时，归档日志文件会在catalog被标记为已备份，这样，生产环境端在使用catalog再次执行备份时，认为这些归档日志已经备份过了，进而跳过这些异地已经备份的归档日志。进而导致问题。
实际上，在RMAN中set backup files for device type SBT to notaccessible可以避免这种问题，但是备份软件对于这种设置是不支持的。同时，这个notaccessible也是个session级别的参数。
解决方案： 不启用not backed up选项， 但是会降低备份速度。客户这边归档日志保留的时间比较长，如果要加快归档日志备份，可以将日志的保留时间调短。
补充一点：这个问题只能在通道为SBT磁带库的情况下才能重现。因磁带是共享的, 不同于备份到磁盘
来自 “ ITPUB博客 ” ，链接：/8520577/viewspace-2285913/，如需转载，请注明出处，否则将追究法律责任。
