ora-01652报错在备库上99%是因temp表空间无文件或仅含小文件，主库扩容temp不生成redo，备库mrp无法同步；需在open read only with apply状态下手动添加tempfile，并确保路径、权限、表空间名正确。
ora-01652报错时，别查主库归档，先看备库temp有没有文件
物理备库报ora-01652，99%不是同步问题，而是备库本地temp表空间压根没文件，或只有1个100mb的temp01.dbf。主库扩容temp不会触发redo，备库mrp进程收不到任何指令——这是设计行为，不是bug。
验证方式很简单：
-
SELECT tablespace_name, file_name, bytes/1024/1024 mb FROM dba_temp_files;—— 在备库执行，结果为空或只有一行小文件 -
SELECT * FROM v$tablespace WHERE contents = 'TEMPORARY';—— 表空间存在，但dba_temp_files为空，说明控制文件里没记录物理文件
备库OPEN READ ONLY WITH APPLY状态下才能加TEMPFILE
必须确保备库处于OPEN READ ONLY WITH APPLY状态（即ADG模式），否则ALTER TABLESPACE TEMP ADD TEMPFILE会直接报ORA-01109: database not open。
如果当前是传统恢复模式（RECOVER MANAGED STANDBY DATABASE持续挂起在MOUNT），得先停恢复、开只读、加文件、再重启应用：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;ALTER DATABASE OPEN READ ONLY;-
ALTER TABLESPACE TEMP ADD TEMPFILE '/u01/oradata/STBY/temp02.dbf' SIZE 2G AUTOEXTEND ON NEXT 100M MAXSIZE 8G;（路径必须是备库本地真实可写路径） ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
注意：这个过程会中断实时同步几秒，生产环境要选窗口期。
standby_file_management=AUTO对TEMP完全无效
standby_file_management=AUTO只作用于永久表空间（如SYSTEM、USERS），对TEMP表空间零影响。主库执行ALTER TABLESPACE TEMP ADD TEMPFILE不生成redo，备库MRP根本看不到这条语句。
临时文件信息只固化在控制文件中，且仅在创建备用控制文件那一刻快照。所以：
- 主库新增了
temp03.dbf，但备库没重建过控制文件 → 新文件永远不会出现在备库 - 备库OPEN时尝试按旧控制文件创建tempfile → 路径不存在就失败，或创建到错误位置
- 想长期统一管理，必须定期用主库最新trace重建备库控制文件（含所有当前
tempfile路径）
临时文件路径和权限最容易被忽略
加TEMPFILE失败，80%是因为路径问题：
- 路径必须是备库操作系统上真实存在的目录，且
oracle用户有读写权限 - 若用ASM，路径格式必须是
+DATA/STBY/TEMPFILE/temp02.dbf，不能写错磁盘组名或数据库名 - 表空间名要核对清楚：
SELECT tablespace_name FROM dba_tablespaces WHERE contents = 'TEMPORARY';，有些环境叫TEMP01或PDB$SEED:PDBTEMP，写错就报ORA-00959
加完后别忘了验证：SELECT * FROM v$tempfile; 和 SELECT * FROM v$temp_space_header; 看是否已计入使用统计。临时表空间不像永久表空间那样“一劳永逸”，它需要和业务查询复杂度持续对齐——尤其当报表逻辑变重、排序量翻倍时，上次配的2G可能下周就不够用了。
