oracle 19c rac中temp表空间不足本身不会导致节点挂起，但若同时触发/tmp分区满（尤其是tmpfs类型），可能引发会话卡死、asm扫描失败及crs异常；须分别排查数据库ora-1652错误与os层no space left on device，确认后在asm磁盘组空间充足且路径全节点一致前提下，以alter tablespace temp add tempfile '+datadg' size 32g autoextend off安全扩容。
oracle 19c rac中temp表空间不足不会直接导致节点挂起，但若同时触发/tmp分区满（尤其是/tmp挂载为tmpfs），则可能让节点无法创建临时文件、卡住会话甚至阻塞asm扫描，最终表现为节点“假死”或crs资源异常。真正需要扩容的是数据库级temp表空间，而非os的/tmp——但两者必须分开排查、同步处理。
确认是数据库TEMP表空间还是OS /tmp分区问题
先区分故障根源，避免误操作：
- 查数据库错误日志：若出现
ORA-1652: unable to extend temp segment，说明是数据库TEMP表空间不足；若出现ORA-01114、write failed: No space left on device且路径含/tmp/OraInstall或/tmp/hsperfdata_，则是OS/tmp满 - 查
/tmp使用率：df -h /tmp；若Type为tmpfs且已100%，立即清理或切换TMPDIR - 查数据库TEMP使用峰值：
SELECT tablespace_name, used_blocks * 8 / 1024 AS gb_used FROM v$sort_segment;，再对比dba_temp_files总大小 - RAC中注意：一个节点报
ORA-1652，不代表所有节点都缺空间——每个实例的排序段独立，但共享同一TEMP表空间
向TEMP表空间添加新临时数据文件（RAC安全操作）
在RAC中直接ALTER TABLESPACE TEMP ADD TEMPFILE必须确保ASM磁盘组有足够空间，且路径在所有节点一致可写：
- 先验证磁盘组剩余空间：
SELECT name, free_mb, type FROM v$asm_diskgroup WHERE name IN (SELECT tablespace_name FROM dba_tablespaces WHERE contents = 'TEMPORARY');——若free_mb （即约20GB），不建议只加小文件 - 路径必须用ASM别名（如
'+DATADG'），不能用物理设备路径；命令示例：ALTER TABLESPACE TEMP ADD TEMPFILE '+DATADG' SIZE 32G AUTOEXTEND OFF; - 执行前检查所有节点grid用户能否访问该磁盘组：
asmcmd lsdg DATADG，输出中State必须为MOUNTED，Usable_file_mb > 0 - 不要用
AUTOEXTEND ON——RAC中临时文件自动扩展可能因节点间协调延迟引发争用，生产环境推荐AUTOEXTEND OFF+ 预留足够初始大小
为什么RAC加完TEMPFILE后仍报ORA-1652
常见不是加得不够，而是没被实例真正“看到”：
-
v$sort_segment只显示当前实例正在使用的临时段，新加的TEMPFILE默认不会立刻分配；需触发一次大排序（如SELECT /*+ ORDER_BY */ * FROM big_table ORDER BY 1）才会激活 - 检查
dba_temp_files中status是否为AVAILABLE；若为INVALID，说明ASM路径不可写或权限不对（属主应为grid:asmadmin） - RAC中某节点执行
ADD TEMPFILE后，其他节点不会自动感知——但只要磁盘组在线，所有实例都能用；无需跨节点重复执行 - 如果用了
DEFAULT TEMPORARY TABLESPACE，确保用户没被显式指定到另一个已满的临时表空间：SELECT username, temporary_tablespace FROM dba_users WHERE username = 'XXX';
临时表空间扩容后仍不稳定？重点检查这三点
加完文件只是第一步，真正容易被忽略的是：
-
/tmp分区是否仍被Oracle安装/补丁/日志进程持续写入——即使TEMP够了，/tmp满仍会导致sqlplus连接失败、CRS启动卡住 - 应用是否大量使用
GLOBAL TEMPORARY TABLE且未及时TRUNCATE，导致temp段长期不释放；可用SELECT * FROM v$tempseg_usage;看各会话实际占用 - 是否存在SQL走错执行计划（如NLJ变HASH JOIN）、PGA设置过低（
pga_aggregate_limit太小），把本该内存完成的操作硬压进TEMP——这类问题加再多文件也治标不治本
