Backup Pending并非真实数据库状态，而是监控误读或热备未结束所致；应先查dba_tablespaces和v$backup确认真实状态，再决定是否需RMAN介入。
Backup Pending状态不是RMAN能直接恢复的状态，它只是控制文件里一个标记，说明该表空间自上次备份后被修改过——你真正要做的不是“恢复Backup Pending”，而是确认是否需要备份、或是否误判了问题。
Backup Pending到底意味着什么
Backup Pending是V$TABLESPACE或V$DATAFILE中STATUS列的一个值（非官方视图字段，常被DBA误读），实际并不存在名为“Backup Pending”的数据库状态。它通常出现在以下场景：
- 你刚执行过
ALTER TABLESPACE users BEGIN BACKUP，但没执行END BACKUP，此时数据文件在V$DATAFILE中显示STATUS = 'ACTIVE'，而某些监控脚本错误地把它渲染为“Backup Pending” - 你用
RMAN BACKUP TABLESPACE users失败或中断，控制文件未更新完成，导致后续LIST BACKUP OF TABLESPACE users查不到有效备份，但表空间本身完全正常 - 第三方工具把
SCN不一致或CREATION_CHANGE#与CHECKPOINT_CHANGE#有差值的情况，笼统标为“Backup Pending”——这其实是检查点不一致，不是备份问题
遇到“Backup Pending”先别急着RMAN restore
绝大多数所谓“Backup Pending”根本不需要RMAN介入。优先做三件事：
- 查真实状态：
SELECT tablespace_name, status, plugged_in FROM dba_tablespaces WHERE tablespace_name = 'USERS';—— 如果STATUS = 'ONLINE'，表空间就一切正常 - 确认数据文件是否可读：
SELECT file_name, status, enabled FROM dba_data_files WHERE tablespace_name = 'USERS';—— 只要STATUS = 'AVAILABLE'且ENABLED = 'READ WRITE'，物理层面没问题 - 检查是否有未结束的热备：
SELECT * FROM v$backup WHERE status = 'ACTIVE';—— 若有，必须先ALTER DATABASE DATAFILE <file_id> END BACKUP;，否则RMAN会拒绝备份或恢复该文件
RMAN restore tablespace在Backup Pending场景下大概率报错
如果你强行对一个状态正常的表空间执行RESTORE TABLESPACE users，RMAN不会报错，但会静默跳过——因为控制文件里没有“需要还原”的标记（RECOVERY_STATUS不是RECOVERABLE）。更常见的是触发以下错误：
-
RMAN-06023: no backup or copy of datafile X found to restore—— 不是备份丢了，是你根本没做过BACKUP TABLESPACE users，RMAN找不到匹配的备份集 -
ORA-19573: cannot obtain exclusive enqueue for datafile X—— 因为文件处于ACTIVE热备状态，RMAN无法加锁 -
RMAN-06571: no recoverable copy of datafile found—— 你漏写了UNTIL TIME或UNTIL SCN，而RMAN默认不接受“恢复到最新”
真正需要RMAN介入的只有两种情况
如果确认表空间确实异常（比如V$DATAFILE.STATUS = 'RECOVER'或'OFFLINE'），那“Backup Pending”只是表象，背后是介质损坏或误删文件：
- 若数据文件被OS层删除，但控制文件仍记录其存在：启动到
MOUNT后，SELECT name, status FROM v$datafile会看到MISSING路径，此时必须先ALTER DATABASE CREATE DATAFILE '/MISSING01.DBF' AS '/new/path/users01.dbf';，再RESTORE TABLESPACE users; - 若表空间处于
READ ONLY且你又没在备份时加INCLUDE CURRENT CONTROLFILE：RMAN默认跳过只读表空间，恢复时需显式指定BACKUP TABLESPACE users PLUS ARCHIVELOG;，否则RESTORE找不到源
所有这些操作的前提，都是先在CDB$ROOT连接下执行，PDB内直接运行RESTORE会报ORA-65023——这是最容易被忽略的权限上下文陷阱。
