ORA-01652报错源于DG物理备库TEMP表空间未手动扩容，需在OPEN READ ONLY WITH APPLY状态下用ALTER TABLESPACE TEMP ADD TEMPFILE添加临时文件，并确保路径权限正确。
备库只读查询报错 ORA-01652：临时表空间无法扩展
这是 dg（data guard）物理备库上非常典型的“假性空间不足”问题。物理备库是只读 + 应用归档的模式，temp 表空间本身不参与主库的传输或恢复，它的数据文件不会随主库变更自动同步。一旦备库执行排序、哈希连接、物化视图刷新等需要临时段的操作，就可能因本地 temp 表空间过小或未配置而直接报 ora-01652: unable to extend temp segment。
关键点在于：这不是主库的问题，也不是归档没传完，而是备库自己缺“干活用的临时地盘”。
- 主库扩了
TEMP，备库不会自动跟着加文件 - 备库默认可能只有 1 个很小的
temp01.dbf（比如 100MB），根本扛不住报表类查询 - 即使备库开了
ADG（Active Data Guard），TEMP仍需手动管理
在备库本地添加临时数据文件的正确操作
必须在备库实例上以 sys 身份登录后操作，且需确保数据库处于 OPEN READ ONLY WITH APPLY 状态（即 ADG 模式）。不能连主库操作，也不能在 MOUNT 状态下执行。
- 先查当前临时表空间和文件：
SELECT tablespace_name, file_name, bytes/1024/1024 mb FROM dba_temp_files; - 确认目标表空间名（通常是
TEMP，但需核对，避免写错） - 添加新临时文件（推荐使用
ADD TEMPFILE，不是ALTER DATABASE ADD DATAFILE）：ALTER TABLESPACE TEMP ADD TEMPFILE '/u01/oradata/DBNAME/temp02.dbf' SIZE 2G AUTOEXTEND ON NEXT 100M MAXSIZE 8G;
- 注意路径权限：Oracle 用户必须有写权限，且目录存在；若用 ASM，路径要写成
+DATA/.../temp02.dbf
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 下无法加临时文件？
如果备库还卡在传统物理备库模式（即只读前没启 ADG，而是靠 RECOVER MANAGED STANDBY DATABASE 持续恢复），那它实际处于 MOUNT 状态 —— 此时 ALTER TABLESPACE ... ADD TEMPFILE 会报 ORA-01109: database not open。这不是语法错，是状态限制。
- 必须先停止恢复：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; - 再切换为只读：
ALTER DATABASE OPEN READ ONLY; - 此时才能加临时文件；加完后，如需继续同步，得重新启恢复：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT; - 但注意：这个流程会中断实时同步几秒，生产环境需评估窗口
为什么不用 CREATE TEMPORARY TABLESPACE 换一个表空间？
可以创建新临时表空间，但必须同时改用户默认临时表空间，否则旧 SQL 还是走原 TEMP，问题照旧。而且多数中间件、ETL 工具、BI 平台默认依赖 TEMP，硬切容易引发隐性故障。
- 改默认临时表空间命令：
ALTER DATABASE DEFAULT TEMPORARY TABLESPACE temp2; - 但所有已有用户（包括
SYSTEM、SYS）的TEMPORARY TABLESPACE属性不会自动更新，得逐个改：ALTER USER scott TEMPORARY TABLESPACE temp2; - 更麻烦的是：主库用户 DDL 不同步到备库，所以主库上新建用户带的临时表空间设置，在备库并不存在对应对象
- 结论：不如直接扩容原
TEMP，省事、兼容、无副作用
chown oracle:oinstall /u01/oradata/DBNAME，或者死守着 MOUNT 状态硬试 ADD TEMPFILE。 
