adg备库上手动添加temp文件无效，因临时表空间由主库完全控制，本地操作被忽略或覆盖；必须在主库执行alter database tempfile offline drop及add tempfile等操作，通过重做日志同步至备库。
备库上手动添加 temp 文件通常无效，甚至会引发 ora-01157、ora-01110 或启动失败——因为 adg 备库的临时表空间由主库完全控制，本地操作会被忽略或覆盖。
为什么 ALTER TABLESPACE temp ADD TEMPFILE 在 ADG 备库上不生效
ADG（Active Data Guard）备库处于只读 + 恢复模式，其 TEMP 表空间结构（包括文件路径、大小、自动扩展策略）全部从主库的控制文件和重做日志中同步而来。任何在备库上执行的 ALTER TABLESPACE ... ADD TEMPFILE 语句：
- 不会写入重做流，因此主库看不到，也不会反向同步
- 即使语句成功返回，该 tempfile 在备库控制文件中仍为
INVALID状态（查DBA_TEMP_FILES可见STATUS = 'INVALID'） - 重启备库后，该条目通常消失；若未消失，MRP 进程可能在分配临时段时尝试访问它，触发 I/O 错误
- 根本原因：Oracle 不允许备库“自定义”临时表空间结构，这是为了保证主备角色切换时临时段行为一致
Temp 文件报错的真实来源与判断方法
看到 ORA-01157 / ORA-01110 并不意味着备库磁盘真丢了文件——更可能是：
- 主库上
TEMP表空间包含一个已损坏或路径错误的 tempfile（比如原路径在 NAS 上，但备库没挂载同名路径） - 主库执行过
ALTER DATABASE TEMPFILE '/old/path/temp01.dbf' DROP INCLUDING DATAFILES，但控制文件元数据未清理干净，该文件仍残留在DBA_TEMP_FILES中 - 主库使用了 ASM 别名或 UDI 路径，而备库的 ASM 实例未识别该别名（常见于 RAC+ADG 场景）
验证方式：SELECT file_name, status, enabled FROM dba_temp_files; —— 若某行 STATUS = 'INVALID' 或 FILE_NAME 指向不存在路径，问题就在这里。
正确修复路径：必须从主库端统一处理
所有修改必须在主库发起，并确保变更能通过重做日志传播到备库：
- 先确认主库
TEMP表空间是否健康：SELECT file_name, bytes/1024/1024 mb, autoextensible FROM dba_temp_files WHERE tablespace_name = 'TEMP'; - 若存在无效文件，**不要**在主库直接
DROP（可能被会话占用），改用：ALTER DATABASE TEMPFILE '/bad/path/temp01.dbf' OFFLINE DROP; - 再重建干净的 tempfile（推荐使用 ASM）：
ALTER TABLESPACE temp ADD TEMPFILE '+DATA' SIZE 100M AUTOEXTEND ON NEXT 10M; - 等待归档传输 & MRP 应用完成后，备库的
DBA_TEMP_FILES会自动刷新，旧无效条目消失，新文件状态变为ONLINE - 验证备库：
SELECT file_name, status FROM dba_temp_files WHERE tablespace_name = 'TEMP';—— 所有行应为ONLINE且路径可访问
备库临时空间不足？别加文件，换思路
如果报错本质是“排序撑爆临时空间”，而非文件损坏，优先考虑：
- 调大主库
TEMP表空间总容量（加文件 or 扩容现有文件），让变更同步过去 - 检查是否因主库启用了
INMEMORY或大量并行查询，导致临时段需求激增——这类负载本就不该在 ADG 备库执行；确保备库应用的是只读报表类 SQL，避免ORDER BY、HASH JOIN、CREATE GLOBAL TEMPORARY TABLE等高消耗操作 - 极端情况下可临时在备库启用
CREATE STANDBY CONTROLFILE后重建备库，但这是最后手段
关键点始终只有一个：ADG 备库的 TEMP 是只读副本，它的结构和生命周期完全绑定主库——想修它，得动主库的配置，而不是在备库上“打补丁”。
