rman备份应轮询备库而非仅在主库执行，因主库承担核心业务压力，全量备份会引发i/o与cpu负载激增、性能抖动甚至超时；而data guard下db_unique_name不同但db_name相同的备库处于read only with apply模式，可作为只读备份源——rman连接其执行compressed backupset不触发日志切换、不写归档、零干扰主库事务，从而分散备份压力、规避单点瓶颈。
为什么不能只在主库做备份，而要轮询多个备库
主库承担核心业务压力，rman全量备份会显著增加i/o和cpu负载，容易引发性能抖动甚至超时。data guard环境下，db_unique_name不同但db_name相同的备库，可直接作为“只读备份源”——rman连接备库执行backup as compressed backupset database不触发日志切换、不写归档、不干扰主库事务。轮询的本质是把备份压力分散到多个备库节点，避免单点瓶颈。
RMAN连接备库前必须确认的4个前提条件
不是所有备库都适合立即用于备份。以下检查缺一不可：
-
SELECT open_mode, database_role FROM v$database返回READ ONLY WITH APPLY（非MOUNTED或READ ONLY） -
SELECT recovery_mode FROM v$archive_dest_status WHERE dest_id = 2显示MANAGED REAL TIME APPLY -
STANDBY_FILE_MANAGEMENT参数为AUTO（否则新增数据文件无法同步，后续备份可能失败） - 备库的
db_recovery_file_dest空间充足，且路径对oracle用户可写（RMAN会在该路径下生成backupset，不是仅用主库FRA）
轮询脚本的核心逻辑：按db_unique_name动态选库 + 错误自动跳过
硬编码IP或SID不可靠，应通过SQL查询实时获取可用备库列表。关键点在于：不依赖DNS或hosts，只查v$archive_dest和v$database：
#!/bin/bash
# 获取当前所有ACTIVE的物理备库（排除主库自身）
STANDBY_LIST=$(sqlplus -s / as sysdba 1
AND d.status = 'VALID'
AND d.target = 'STANDBY'
AND d.db_unique_name IS NOT NULL
AND d.db_unique_name != b.db_unique_name;
EXIT;
EOF
)
<p>for DBUN in $STANDBY_LIST; do
echo "Starting backup on standby: $DBUN"</p><h1>使用tnsnames.ora中已配好的连接串（格式：$DBUN_DG）</h1><p>rman target sys/password@${DBUN}<em>DG nocatalog ${DBUN}<em>%T</em>%s<em>%p.bkp';
BACKUP CURRENT CONTROLFILE FORMAT '/backup/ctl</em>${DBUN}_%T.bkp';
RELEASE CHANNEL c1;
}
EXIT;
EOF</em></p><h1>检查RMAN退出码，非0则记录并跳过，不中断整个轮询</h1><p>if [ $? -ne 0 ]; then
echo "Backup failed on $DBUN, skipping..." >> /var/log/rman_dg_backup.log
continue
fi
done</p>
备份后必须清理归档日志，但策略与主库完全不同
在备库执行backup archivelog all delete input是危险操作——它会删除尚未应用到备库数据文件的归档，导致MRP进程报错ORA-00308。正确做法是只删已应用的归档：
- 先确认归档应用位置：
SELECT sequence#, applied FROM v$archived_log WHERE applied = 'YES' ORDER BY sequence# DESC FETCH FIRST 10 ROWS ONLY - 再用RMAN删除这些已应用的归档：
DELETE ARCHIVELOG UNTIL SEQUENCE <max_applied_seq> THREAD 1;</max_applied_seq> - 不要用
delete input，改用delete noprompt archivelog until time 'sysdate-3'（配合crosscheck archivelog all）更安全
轮询方案最易被忽略的是备库角色切换后的状态漂移——某台备库升级为主库后，其db_unique_name仍在轮询列表里，但RMAN连接会因权限或模式失败。必须在脚本开头加入角色校验，且每次连接后执行SELECT database_role FROM v$database二次确认，否则备份可能静默失效。
