不能直接对单个PDB执行RESTORE DATABASE，因RMAN在CDB级别运行时恢复整个CDB；PDB无独立数据文件，物理归属CDB表空间，指定PDB会报ORA-65086等错。
为什么不能直接对单个PDB执行 RESTORE DATABASE
rman 的 restore database 命令在 cdb 级别运行，它会恢复整个容器数据库（包括所有 pdb），不支持只指定一个 pdb。这是底层架构决定的：数据文件物理上属于 cdb，pdb 本身没有独立的数据文件集合（除了 system、sysyem、undo 等共享部分外，用户数据文件仍归属 cdb 表空间）。强行指定 pdb 名会报错：ora-19554: error allocating device, device type: sbt_tape 或更常见的 ora-65086: cannot perform this operation on a pluggable database。
实操建议：
- 必须先用
ALTER PLUGGABLE DATABASE <pdb_name> CLOSE IMMEDIATE关闭目标 PDB，否则后续RECOVER PLUGGABLE DATABASE会失败 - 确保 CDB 处于
ARCHIVELOG模式，且归档日志完整覆盖目标时间点——PDB PITR 依赖的是 CDB 级别的归档流，不是 PDB 自己的日志 - 不要尝试在
OPEN状态下对 PDB 执行恢复；RMAN 不允许，Oracle 内核会直接拒绝
怎么触发 PDB 级别的时间点恢复（RECOVER PLUGGABLE DATABASE）
Oracle 12.2 引入了真正意义上的 PDB PITR，核心命令是 RECOVER PLUGGABLE DATABASE，它会在 CDB ROOT 中执行，但作用域精确到指定 PDB。该命令自动完成：还原 PDB 相关的数据文件（从备份中）、应用归档日志到指定 SCN/TIMESTAMP/LOGSEQ，并跳过其他 PDB 的变更。
实操建议：
- 连接到
CDB$ROOT，不是 PDB：使用sqlplus / as sysdba，然后SHOW CON_NAME确认是CDB$ROOT - 语法必须带
UNTIL子句，例如：RECOVER PLUGGABLE DATABASE pdb1 UNTIL TIME 'SYSDATE-1/24'（1 小时前） - 支持三种
UNTIL类型：TIME（最常用）、SCN、LOGSEQ；注意TIME是基于服务器系统时间，不是 PDB 本地时区 - 如果目标时间点之后有 DDL（如表被删），恢复后该对象不会自动重建——PDB PITR 不恢复数据字典变更历史，只回滚已提交事务的影响
备份前提：为什么必须有 PDB 全量备份或 CDB 全量备份 + 归档
PDB PITR 不是“无备份恢复”。它依赖两类备份之一：BACKUP PLUGGABLE DATABASE pdb1（12.2+ 支持），或更常见的 BACKUP DATABASE（CDB 全备）。没有对应备份，RECOVER PLUGGABLE DATABASE 会报 ORA-19625: error identifying file ... ORA-27037: unable to obtain file status。
实操建议：
- 检查备份是否存在：
LIST BACKUP OF PLUGGABLE DATABASE pdb1或LIST BACKUP OF DATABASE - 如果只有 CDB 全备，RMAN 能自动识别哪些数据文件属于目标 PDB（通过控制文件中的
FILE# → CON_ID映射） - 若使用压缩备份（
AS COMPRESSED BACKUPSET），恢复速度可能下降 20–30%，但磁盘节省明显；生产环境建议权衡 - 不要依赖闪回数据库（
FLASHBACK DATABASE）来替代 PDB PITR——它是 CDB 级别操作，会影响所有 PDB
恢复后常见卡点：ORA-65122 和 PDB 打不开
恢复完成后执行 ALTER PLUGGABLE DATABASE pdb1 OPEN RESETLOGS 时，常遇到 ORA-65122: Pluggable database GUID conflict detected。这不是数据损坏，而是 Oracle 检测到该 PDB 的 GUID 与当前 CDB 中已注册的某个 PDB（可能是同名但不同实例）冲突。本质是恢复过程未重置 PDB 的内部标识。
实操建议：
- 加
RESETLOGS后立刻执行：ALTER PLUGGABLE DATABASE pdb1 OPEN RESETLOGS—— 必须带RESETLOGS，否则报错 - 如果仍报
ORA-65122，说明该 PDB 曾被拔出再插入过，GUID 重复；需用CREATE PLUGGABLE DATABASE pdb1 USING '/path/to/xml' SOURCE_FILE_NAME_CONVERT=... CREATE_FILE_DEST='...' REUSE重建，再恢复 - 打开后立即查
V$PDB_HISTORY确认恢复时间点是否准确：SELECT PDB_NAME, OPERATION, CLONED_FROM_PDB_NAME, TIMESTAMP FROM V$PDB_HISTORY WHERE PDB_NAME = 'PDB1'
最易被忽略的是：恢复窗口内若发生过 CDB 级别操作（如添加新 PDB、修改 UNDO_TABLESPACE），可能导致目标 PDB 的 undo 表空间状态异常——此时需手动切换 undo 并验证 SELECT STATUS FROM DATABASE_PROPERTIES WHERE PROPERTY_NAME = 'LOCAL_UNDO_ENABLED'。
