oracle 19c物理备库的临时表空间不会自动同步，必须手动干预或依赖控制文件快照；standby_file_management=auto仅作用于永久表空间，alter tablespace temp add tempfile在主库不生成redo，备库mrp无法接收该指令。
oracle 19c物理备库的临时表空间不会自动同步，必须手动干预或依赖控制文件快照——这是所有配置优化的前提。别指望standby_file_management=auto能管到temp表空间，它只对永久表空间生效。
为什么ALTER TABLESPACE TEMP ADD TEMPFILE在备库无效
主库执行ALTER TABLESPACE TEMP ADD TEMPFILE不产生redo，备库MRP进程完全收不到这条指令。你查DBA_TEMP_FILES为空、V$TEMPFILE无记录、甚至SELECT * FROM V$TABLESPACE WHERE CONTENTS='TEMPORARY'显示表空间存在但没物理文件，都是正常现象。这不是同步失败，是设计如此。
- 临时文件（tempfile）信息只存在于控制文件中，且仅在创建备用控制文件那一刻固化
- 备库OPEN时会按控制文件里的定义尝试创建tempfile；若控制文件旧，就只能创建老路径下的旧文件
- 如果主库后来新增了tempfile，而备库没重建过控制文件，那新增部分永远进不了备库
如何让备库拥有与主库一致的tempfile结构
最稳妥的做法不是在备库上单独加文件，而是更新备库的控制文件快照，使其包含主库当前的tempfile定义。操作分三步，缺一不可：
- 在主库执行
ALTER DATABASE BACKUP CONTROLFILE TO TRACE，获取最新控制文件文本（含当前所有tempfile路径） - 在备库停掉MRP：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL - 用主库生成的trace文件重建备库控制文件（注意修改
SET DATABASE和RECOVER DATABASE语句中的DB_UNIQUE_NAME，并确保所有tempfile路径在备库真实存在或可写）
重建后启动备库到READ ONLY WITH APPLY，系统会自动按新控制文件创建缺失的tempfile——这个过程会在alert日志里打出Creating datafile ... tempfile ...，而不是报错。
备库临时表空间扩容的两种安全路径
如果只是想快速扩容、不打算重建控制文件，有两种可行方式，但适用场景不同：
-
路径一（推荐用于紧急扩容）：直接在备库执行
ALTER TABLESPACE TEMP ADD TEMPFILE '/u01/app/oracle/oradata/STBY/temp02.dbf' SIZE 2G;。注意路径必须是备库本地路径，且TEMP表空间名要和备库实际一致（可能叫TEMP、TEMP01或PDB里的PDBTEMP） - 路径二（适用于长期统一管理）：在主库先扩容，再重建备用控制文件并推送到备库。这样后续所有tempfile变更都可通过控制文件快照同步，避免反复手动干预
切记：无论哪种方式，扩容后都要验证V$TEMPFILE中文件状态为ONLINE，且BYTES字段反映新大小；否则查询仍可能触发ORA-25153或ORA-1652。
容易被忽略的CDB/PDB上下文陷阱
在多租户环境下，TEMP表空间不是全局唯一的。CDB根容器有CDB$ROOT.TEMP，每个PDB又有自己的PDBNAME.TEMP。你在备库执行操作前，必须确认当前连接的是哪个容器：
- 查当前容器：
SHOW CON_NAME - 查所有容器的tempfile：
SELECT CON_ID, TABLESPACE_NAME, NAME FROM V$TEMPFILE; - 切换容器再操作：
ALTER SESSION SET CONTAINER = PDB1;，然后再ALTER TABLESPACE TEMP ADD TEMPFILE
漏掉这一步，很可能在CDB$ROOT里加了文件，但报表跑在PDB里，结果还是没空间——这种问题不会报错，只会静默失败。
