在一个备份的case上遇到备份控制文件报错ORA-245，最终通过修改snapshot controlfile默认位置到ASM磁盘组后解决。
1.问题复现
回来后就想快速记录下这个小知识点，打开尘封的测试环境，结果测试环境上居然没复现？！RMAN> backup current controlfile format '/tmp/current_%d_%s_%p_%T.ctl';
Starting backup at 12-JAN-22
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current control file in backup set
channel ORA_DISK_1: starting piece 1 at 12-JAN-22
channel ORA_DISK_1: finished piece 1 at 12-JAN-22
piece handle=/tmp/current_PROD_8_1_20220112.ctl tag=TAG20220112T174122 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 12-JAN-22
Starting Control File and SPFILE Autobackup at 12-JAN-22
piece handle=/opt/app/oracle/product/11.2.0/dbhome_1/dbs/c-495072076-20220112-03 comment=NONE
Finished Control File and SPFILE Autobackup at 12-JAN-22
RMAN>
再次尝试，在另外节点有业务的情况下，部分复现（备份控制文件ok，只是自动备份那里报错了）：
RMAN> backup current controlfile format '/tmp/current_%d_%s_%p_%T.ctl';
Starting backup at 12-JAN-22
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=59 instance=prod1 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current control file in backup set
channel ORA_DISK_1: starting piece 1 at 12-JAN-22
channel ORA_DISK_1: finished piece 1 at 12-JAN-22
piece handle=/tmp/current_PROD_10_1_20220112.ctl tag=TAG20220112T174247 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 12-JAN-22
Starting Control File and SPFILE Autobackup at 12-JAN-22
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of Control File and SPFILE Autobackup command on ORA_DISK_1 channel at 01/12/2022 17:42:50
ORA-00245: control file backup failed; target is likely on a local file system
继续模拟在另外节点有业务的情况下（简单模拟就是在备份的时候疯狂去切日志），终于复现了（备份控制文件就报错ORA 245了）：
RMAN> backup current controlfile format '/tmp/current_%d_%s_%p_%T.ctl';
Starting backup at 12-JAN-22
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of backup command on ORA_DISK_1 channel at 01/12/2022 17:43:28
ORA-00245: control file backup failed; target is likely on a local file system
2.解决方案
当前默认配置：RMAN> show all;
using target database control file instead of recovery catalog
RMAN configuration parameters for database with db_unique_name PROD are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE ; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/opt/app/oracle/product/11.2.0/dbhome_1/dbs/snapcf_prod1.f'; # default
修改 SNAPSHOT CONTROLFILE 路径到ASM磁盘组中：
RMAN> CONFIGURE SNAPSHOT CONTROLFILE NAME TO '+DATA/PROD/snapcf_prod1.f';
new RMAN configuration parameters:
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '+DATA/PROD/snapcf_prod1.f';
new RMAN configuration parameters are successfully stored
再次测试，无论备份时另外节点如何疯狂去切日志，都会成功备份。