ORA-01652在Oracle 19c DG备库上因TEMP表空间独立且碎片化/未生效导致排序类只读查询中断；须查v$temp_extent_pool验证新增tempfile是否激活，RAC环境需确保ASM磁盘组全节点可写、路径用别名、禁用AUTOEXTEND。
ORA-01652 在 Oracle 19c Data Guard（DG）备库上出现，并不影响只读查询本身能否执行，但它会直接中断那些需要临时空间的只读查询——比如含 ORDER BY、GROUP BY、UNION、SORT-MERGE JOIN 的语句。根本原因不是“备库临时表空间不够”，而是：备库的临时表空间真不够用，且无法绕过。
备库的临时表空间和主库完全独立，但用途没得选
- DG 备库是只读的，不写 UNDO，也不生成重做，但它要执行 SQL —— 只要 SQL 需要排序、哈希、分析、建索引（如
CREATE INDEX ... ONLINE），就必须用到临时表空间； - 这个临时表空间就是
TEMP（或你设的默认临时表空间），它和主库的TEMP没有任何共享或同步关系； - 主库归档日志里不传临时段信息，所以备库必须自己管好自己的
TEMP；
常见误判点：
- 看到主库
TEMP很大，就以为备库“跟着沾光”——错，备库TEMP是独立创建、独立管理的； - 查
v$database.open_mode是READ ONLY，就默认“不干活”，其实只读模式下照样大量消耗TEMP；
为什么扩容 TEMP 后还报 ORA-01652？
不是加得不够，往往是加得“看不见”或“用不上”：
-
ALTER TABLESPACE TEMP ADD TEMPFILE执行后，新文件可能只被部分实例识别（RAC 环境尤其明显）； - 新增的
TEMPFILE路径在某个节点不可写（比如 ASM 别名解析失败、权限不对、磁盘组未 MOUNTED）； - 查询仍在用老的、已满的
TEMPFILE，而 Oracle 不会自动把负载均衡到新文件（除非显式指定TABLESPACE GROUP）； -
dba_temp_files显示文件存在，但v$temp_extent_pool或v$sort_usage显示没分配空间——说明文件没真正激活；
验证是否生效：
SELECT tablespace_name, file_name, status, bytes/1024/1024 mb FROM dba_temp_files;
SELECT * FROM v$temp_extent_pool WHERE tablespace_name = 'TEMP';
RAC 备库中 TEMP 文件添加必须满足的硬条件
- 所有节点的
GRID用户必须能访问目标 ASM 磁盘组：asmcmd lsdg DATADG输出中State = MOUNTED且Usable_file_mb > 0； - 路径必须用 ASM 别名（如
'+DATADG'），不能写成/u02/oradata/...dbf； - 命令需在所有实例都连上的情况下执行（推荐用
srvctl sqlplus / as sysdba连任一节点执行即可，RAC 会广播）； - 禁用
AUTOEXTEND ON：RAC 中临时文件自动扩展易引发跨节点协调延迟，生产环境应设为AUTOEXTEND OFF并预估够用大小（如SIZE 32G）；
查询端唯一可控的缓解动作：砍掉非必要排序开销
你没法改主库的 UNDO，也难立刻扩容备库存储，但能立刻降低 TEMP 压力：
- 禁用无
WHERE条件的全表扫描 +ORDER BY，例如SELECT * FROM sales ORDER BY sale_date DESC； - 把
ORDER BY拆到应用层（如果结果集不大），避免数据库级排序； - 对报表类长查询，提前物化中间结果到全局临时表（
ON COMMIT PRESERVE ROWS），比反复排序更省TEMP； - 检查绑定变量使用：硬编码值（如
WHERE dept_id = 10）导致硬解析+不同执行计划，可能让原本走索引的查询被迫走SORT-MERGE；
临时表空间不会自动收缩，哪怕所有会话结束，文件尺寸仍卡在历史峰值。真正影响查询的，从来不是“用了多少”，而是“能不能再分一块”。
