备库临时表空间扩容必须在备库本地手动执行，因主库alter tablespace temp操作不生成redo，无法同步；备库仅根据控制文件重建首个tempfile，其余需dba显式添加并确保路径权限、autoextend配置及控制文件固化。
备库临时表空间扩容不能靠主库操作同步，必须在备库本地手动执行。 主库执行 alter tablespace temp add tempfile 不产生 redo，备库永远收不到这条变更 —— 这是绝大多数 dba 踩坑的起点。
为什么 ALTER TABLESPACE TEMP 在备库无效
Oracle DataGuard 的物理备库不复制 tempfile 操作，根本原因在于：TEMPFILE 属于“非持久化结构”，其增删不写入 redo 日志流。备库启动到 READ ONLY WITH APPLY 状态时，仅依据控制文件中记录的 tempfile 列表尝试重建第一个文件（temp01.dbf），其余文件不会自动创建，也不会继承主库后续添加的大小或路径配置。
常见错误现象包括：
- 报表作业报
ORA-01652: unable to extend temp segment -
SELECT * FROM dba_temp_files返回空或仅 1 行，且bytes明显偏小（如仅 100MB） - 日志中反复出现
ORA-01157: cannot identify/lock datafile 201和自动重建提示
READ ONLY WITH APPLY 模式下扩容操作步骤
这是生产环境最常遇到的状态。扩容必须在备库上以 RESTRICTED 方式进行，且不能中断日志应用。
- 先确认当前状态：
SELECT open_mode, database_role FROM v$database;应为READ ONLY WITH APPLY - 临时关闭日志应用：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; - 以
MOUNT方式重启备库：SHUTDOWN IMMEDIATE; STARTUP MOUNT; - 添加新 tempfile（指定独立路径，避免与主库冲突）：
ALTER TABLESPACE TEMP ADD TEMPFILE '/oradata/standby/temp02.dbf' SIZE 2G AUTOEXTEND ON NEXT 128M MAXSIZE 8G; - 重启日志应用：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT; - 验证：
SELECT file_name, bytes/1024/1024 size_mb FROM dba_temp_files;
路径、权限与自动扩展配置要点
备库 tempfile 路径不是“照抄主库”，而是要匹配实际存储布局和 OS 权限。否则即使 SQL 执行成功，后续首次使用时仍会因权限或空间不足触发 ORA-27040 或 ORA-01119。
- 路径必须由 DBA 提前创建并赋予
oracle用户读写权限：mkdir -p /oradata/standby; chown oracle:oinstall /oradata/standby - 避免使用 ASM 别名路径（如
+DATA），除非备库 ASM 实例已完全对齐主库磁盘组结构 -
AUTOEXTEND ON是必要的，但MAXSIZE建议设为明确上限（如8G），防止失控增长挤占共享存储 - 不建议删除旧 tempfile（如
temp01.dbf），因其可能被正在运行的查询持有；可保留但设为OFFLINE：ALTER DATABASE TEMPFILE '/oradata/orcl/temp01.dbf' OFFLINE;
扩容后需验证的两个隐性环节
很多人加完文件就认为完成，但漏掉这两个点，几天后仍会复现问题：
- 检查
v$temp_extent_pool视图，确认新文件是否已被分配 extent 池：SELECT tablespace_name, file_id, used_bytes/1024/1024 used_mb FROM v$temp_extent_pool; - 确认备库控制文件是否已固化该变更：重启备库（不带
FORCE）后再次查dba_temp_files，若记录消失，说明控制文件未更新成功，需重新执行ALTER TABLESPACE并确认无报错
临时表空间扩容不是“加个文件就完事”，它依赖控制文件快照、OS 层路径有效性、以及日志应用机制的短暂让步 —— 任一环节断开，都会导致下次备库重启时回到原始状态。
