BACKUP DATABASE卡住或报ORA-19566的根本原因是RMAN未显式分配通道且未指定备份路径，导致默认写入FRA时因空间不足、权限问题或归档日志占满而失败；需ALLOCATE CHANNEL并设FORMAT，确认数据库状态、归档模式及控制文件自动备份开关。
BACKUP DATABASE 命令为什么总卡住或报错 ORA-19566？
根本原因不是命令写错了，而是 rman 默认不自动分配通道，也没指定备份目标路径——它会直接用 db_recovery_file_dest（即 fra），一旦空间不足或权限不对，backup database 就会失败或挂起。
- 必须显式分配通道，否则 RMAN 可能用默认的磁盘通道但没设
FORMAT，导致写入失败 - FRA 空间被归档日志占满时，
ORA-19566（超出损坏块阈值）常是假象，实际是备份文件根本写不进去 - 如果数据库处于
NOARCHIVELOG模式，BACKUP DATABASE会要求数据库必须MOUNT，且不能有活动事务——很多人在OPEN状态下直接运行就报ORA-19606
ALLOCATE CHANNEL 和 CONFIGURE CHANNEL 的关键区别
临时通道（ALLOCATE CHANNEL）适合一次性备份脚本；永久配置（CONFIGURE CHANNEL）会影响后续所有备份，但容易被忽略其作用域——它只对当前 RMAN session 生效，除非用 CONFIGURE ... CLEAR 显式重置。
-
ALLOCATE CHANNEL ch1 DEVICE TYPE DISK FORMAT '/u01/backup/%U';必须在RUN块内，且要配RELEASE CHANNEL（虽然 RMAN 退出时会自动释放） -
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/u01/backup/%U';是全局设置，但只对当前 RMAN 连接有效；重启 RMAN 后失效 - 多通道并行时，
ALLOCATE CHANNEL更可控：比如ALLOCATE CHANNEL c1 DEVICE TYPE DISK MAXPIECESIZE 2G;能避免单个备份片过大导致 NFS 挂载点写入失败
备份路径中的 %U、%d、%T 到底怎么选？
%U 最安全，生成唯一文件名（如 bk_u1234567890_1_1），避免重复覆盖；%d（数据库名）和 %T（日期，格式 YYYYMMDD）适合人工识别，但组合不当会导致路径冲突或过长。
- 绝对不要只用
%d_%T当文件名——没有序列号，第二次备份会覆盖第一次 - 路径中含空格或中文？RMAN 会静默失败，错误日志里可能只显示
ORA-19504: failed to create file，检查ls -ld对应目录权限 - NFS 或 ASM 路径需提前验证：比如
DEVICE TYPE DISK FORMAT '+RECO/%d/backup_%U'要确保+RECO磁盘组在线且有空间
备份前必须确认的三个状态点
很多“备份成功”其实没真正落盘，因为 RMAN 报告 SUCCESS 仅表示控制文件已记录备份集元数据，不等于文件已刷盘。这三个状态不满足，备份不可靠。
- 查
V$DATABASE.OPEN_MODE：必须是MOUNT（NOARCHIVELOG）或READ WRITE（ARCHIVELOG）；READ ONLY下BACKUP DATABASE直接报错 - 运行
LIST FAILURE;—— Data Guard 或 I/O 错误可能导致隐性故障，RMAN 不报错但备份集损坏 - 确认
ARCHIVE LOG LIST输出里是Automatic archival Enabled，否则归档日志无法切换，备份可能卡在等待归档完成
BACKUP DATABASE 真正执行时依赖的是底层存储的实时响应能力、FRA 的可用配额、以及控制文件里那个容易被忽略的 CONTROLFILE AUTOBACKUP 开关是否打开——关着的话，哪怕备份成功，恢复时也可能找不到最新控制文件。
