备库启动报ORA-01157/ORA-01110指向temp01.dbf，本质是临时文件路径缺失或不匹配；需在MOUNT状态用ALTER DATABASE CREATE TEMPFILE ... AS ... REUSE重建并指向本地有效路径，确保standby_file_management=AUTO且默认临时表空间正确。
备库启动报 ORA-01157 / ORA-01110，指向 temp01.dbf 怎么办
这不是归档或 SCN 问题，是临时文件路径或缺失导致的典型报错。ADG 备库不参与临时表空间的写入，也不同步临时文件，所以主库创建的 temp01.dbf 在备库上根本不存在或路径不对——MRP 尝试打开它时就直接失败。
关键点：不能从主库拷贝临时文件（二进制无效），也不能用 ALTER DATABASE OPEN 强行打开（ADG 只读模式由 MRP 自动维护）。
- 先确认当前状态：
SELECT name, status FROM v$tempfile;—— 若返回空或显示MISSING，说明临时文件未注册或损坏 - 确保目标目录存在、属组为
oracle:oinstall、有写权限（例如/u01/app/oracle/oradata/STBY/temp01.dbf） - 在 MOUNT 状态下重建：
ALTER TABLESPACE temp ADD TEMPFILE '/u01/app/oracle/oradata/STBY/temp01.dbf' SIZE 100M; - 如果旧 tempfile 还挂着但路径已失效，先执行
ALTER DATABASE TEMPFILE '/old/path/temp01.dbf' DROP INCLUDING DATAFILES;再 ADD
为什么 ALTER DATABASE CREATE TEMPFILE 比 ADD TEMPFILE 更常用
因为多数情况下，备库的 V$TEMPFILE 里仍残留着主库路径的记录（比如 /u01/app/oracle/oradata/PRIM/temp01.dbf），直接 ADD 会报 ORA-01119（文件已存在）。这时必须先“替换”而非“新增”。
-
ALTER DATABASE CREATE TEMPFILE '/u01/app/oracle/oradata/PRIM/temp01.dbf' AS '/u01/app/oracle/oradata/STBY/temp01.dbf' SIZE 100M REUSE;会覆盖原记录并指向新路径 -
REUSE参数很重要：它允许复用已有文件名（即使物理文件不存在），避免 ORA-01119 - 执行后务必查
SELECT * FROM V$TEMPFILE;确认路径和 status 是ONLINE - 别漏掉
SIZE—— Oracle 12c+ 默认 100M，但老版本可能需显式指定，否则用 system default（常太小）
MRP 启动后秒退，alert.log 里反复出现 temp 相关错误
这说明 MRP 进程在应用日志前就卡在 tempfile 初始化阶段。不是延迟问题，是启动失败。常见于：刚重建完控制文件、或 standby_file_management 切成 MANUAL 后忘了切回 AUTO。
- 检查
SELECT value FROM v$parameter WHERE name = 'standby_file_management';—— 必须是AUTO，否则后续新增临时文件不会自动注册 - 确认
temp表空间是否被设为默认：SELECT property_name, property_value FROM database_properties WHERE property_name = 'DEFAULT_TEMP_TABLESPACE';，如果不是temp，MRP 可能跳过初始化 - 如果用了多临时表空间（如
temp_ts1,temp_ts2），每个都得单独处理 ——V$TEMPFILE里每条记录都要对应修复 - 重启 MRP 前，先停一次：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;，再用USING CURRENT LOGFILE DISCONNECT重新启
备库 alert.log 显示 ORA-01157 但 v$managed_standby 里 MRP 是 APPLYING_LOG
这种情况看似矛盾，其实是 MRP 已开始工作，但某次日志应用中触发了临时表空间操作（比如主库执行了 CREATE GLOBAL TEMPORARY TABLE），而备库该 tempfile 缺失或路径不可写，导致单次应用失败并报错——MRP 不会退出，但会跳过这条 redo，后续持续重试。
真正影响的是：这类 DDL 日志无法应用，临时对象在备库不可见；但普通 DML 不受影响。容易被忽略的点是：
- 错误只出现在 alert.log 的某几行，不是连续刷屏，要仔细 grep：
grep -i "temp\|1157" alert_*.log | tail -20 - 查
v$log_history和v$archived_log里applied='NO'的最新几条，看 sequence# 是否集中在某几个 —— 如果全是同一 sequence，大概率就是这个 tempfile 卡点 - 修复后无需重启实例，只需让 MRP 重试：
ALTER SYSTEM CHECKPOINT;在主库触发一次日志切换，就能推动 MRP 继续
