我上一次碰到这个报错是在一个客户的现场凌晨三点的跑批脚本突然全挂日志里反反复复刷出同一行[-502]:OUT OF TEMPORARY DATABASE SPACE。当时我的第一反应是临时表空间又快满了结果真正动手查才发现这个错误背后藏的原因比想象中多不少处理方式也完全不一样。这篇文章就围绕达梦数据库的临时表空间不足问题从一个真实排查案例出发把-502报错的触发原理、定位方法、扩容操作和根治手段完整讲一遍适合被临时表空间不足困扰过的DBA、刚上手达梦的运维同学以及每天和大SQL打交道的跑批开发工程师。1. 读懂-502临时表空间不足的触发逻辑1.1 -502错误码的准确含义达梦的-502错误对应英文提示“OUT OF TEMPORARY DATABASE SPACE”翻译过来就是临时表空间不够了。注意这个报错跟磁盘满、归档满不是一回事它指的是数据库在向临时表空间申请临时段时分配失败。临时表空间是什么可以把它理解成数据库的“临时工位”。当一个SQL需要进行排序、哈希关联、去重这类操作而内存里的缓冲区又装不下那么多数据时数据库就把中间结果先写到临时表空间里暂存。等内存腾出位置再来回读写。如果这个临时工位本身不够用了数据库就只能抛-502。很多人在网上查-502时会直接搜到“扩容临时表空间”这一个办法实际上这样做并不总能解决问题。有些场景里临时表空间才用了20%一样会报-502原因在于会话级的临时段分配失败或者并发瞬间把剩下的空间抢光了。所以第一步要先搞清楚这个错误在达梦内部的分配逻辑否则后面对症处理会跑偏。1.2 哪些操作在消耗临时表空间了解什么时候会用到临时表空间比背报错码更有用。在我实际跟踪过的达梦实例里下面几类操作是消耗临时表空间的大户带有ORDER BY、GROUP BY、DISTINCT、UNION的查询结果集大到内存装不下时。大表之间做哈希连接优化器选择HASH JOIN连接过程的中间结果极占临时空间。创建索引、重建索引。索引排序的数据量可以估算往往一次就是好几个GB。数据统计类SQL比如收集表的统计信息时做全局排序。递归查询、分析函数窗口函数的排序段。大批量数据装载或迁移场景中目标表带索引且源数据乱序。有一个很容易被忽略的点临时表空间的使用量跟执行计划强相关。同一个SQL上次走索引查询不需要排序这次因为统计信息过期走了全表扫描加排序临时空间占用可能猛增几十倍。这也是为什么很多报-502的现场看起来“SQL没变、数据量也没增加多少”。1.3 为什么临时表空间会“突然”不够用数据库的容量问题很少是“突然”的通常都是积累到一个临界点才暴露。我在排查中见过的典型触发路径有这么几条数据量增长但容量规划没跟上。临时表空间是项目初期的固定大小比如16GB业务翻了几倍之后某天一条大SQL直接打爆。自动扩展没开或者开了但MAXSIZE写死了。很多项目为了控制磁盘占用会把临时数据文件的最大值设得很保守到了上限就只能报-502。多个大排序操作并发。单条SQL只占5GB十个会话一起跑瞬间把40GB塞满。某个会话的排序段没有释放。比如应用程序打开连接执行排序后迟迟不提交或者事务挂起临时段一直占着不放。执行计划恶化。统计信息不更新或者参数变化导致优化器选错方案从“少量排序”变成“海量排序”。这些原因里只有第一种是单纯“空间不够”后面几种都跟空间大小没有直接关系。所以排查时先别急着头脑一热去扩容先把现场看清楚。2. 排查定位谁占满了临时表空间2.1 先查容量配置临时表空间多大、自动扩展开没开遇到-502第一件事不是看SQL而是看临时表空间的现状。用下面这条SQL可以快速查看临时数据文件的信息SELECT TABLESPACE_NAME, FILE_NAME, BYTES / 1024 / 1024 AS SIZE_MB, MAX_BYTES / 1024 / 1024 AS MAX_MB, AUTOEXTENSIBLE FROM DBA_TEMP_FILES;这条SQL会列出所有临时表空间数据文件的大小、最大值和自动扩展状态。我通常会重点看三个地方AUTOEXTENSIBLE是不是NO如果是NO空间用完就没了直接扩容或开启自动扩展。SIZE_MB和MAX_MB是不是已经相等如果已经顶到最大值说明自动扩展即使开着也到顶了。临时表空间所在磁盘分区剩余空间是否足够这个要在操作系统层面用df -h确认。再看一下临时表空间内部的实际占用情况SELECT TABLESPACE_NAME, BYTES_USED / 1024 / 1024 AS USED_MB, BYTES_FREE / 1024 / 1024 AS FREE_MB FROM V$TEMP_SPACE_HEADERS;这里能看出来表空间里还有多少空闲空间。如果FREE_MB已经很小那基本坐实容量不足如果FREE_MB还很大但依然报-502就要进入下一步查会话。2.2 再查现场哪条SQL占着临时段不撒手临时表空间不足的现场定位“凶手”很关键。我个人习惯先查排序段占用视图再关联会话视图找SQL。达梦里可以参考下面这种写法不过不同小版本的字段名可能有出入实际使用时要根据当前版本调整SELECT S.SESS_ID, S.SQL_TEXT, U.TABLESPACE_NAME, U.SEGTYPE, U.BLOCKS FROM V$SESSIONS S, V$SORT_USAGE U WHERE S.SESS_ID U.SESSION_ID;这条SQL能直接看到哪个会话正在排序、排序段占了多大、当前执行的是什么SQL。如果你的环境不允许实时连数据库查询也可以打开达梦的SQL日志等报错复现时看最后一批进入日志的SQL基本能锁定方向。还有一个实战经验排查-502时不要只看当前跑着的SQL。有时候报错的是会话A但临时空间是被会话B占满的会话A只是压垮骆驼的最后一根稻草。所以必须把V$SORT_USAGE里所有占用临时段的会话都列出来按占用大小倒序看而不是只看报错会话。2.3 三分钟判断根因类型拿到现场数据后可以按下面的对照表快速归类现场特征大概率根因优先处理方案使用率长期90%以上空闲空间很小容量规划不足扩容、开启自动扩展使用率不高但某时刻突然报-502并发瞬间打满或临时段释放慢杀掉占用会话分析并发单个SQL排序量巨大占了几GBSQL或执行计划问题SQL改写、更新统计信息、调缓冲区多个临时表空间并存且使用率不均默认临时表空间配置不对调整默认临时表空间指向大空间磁盘分区满了导致AUTOEXTEND失败文件系统空间/inode不足清理磁盘或迁移数据文件大多数-502都能归到这几类里。判断清楚类型之后再动手处理方向就不会错。3. 解决实操扩容、调参与SQL治理3.1 紧急扩容先让业务恢复如果确认就是容量不足尤其是现场业务已经中断最直接的办法是给临时表空间扩容。新增一个临时数据文件是最常用的操作ALTER TABLESPACE TEMP ADD DATAFILE /dm/data/TEMP02.DBF SIZE 32G AUTOEXTEND ON NEXT 512M MAXSIZE 64G;这条SQL的意思是在TEMP表空间里新增一个初始大小32GB、自动扩展步长512MB、最大上限64GB的临时数据文件。执行完不需要重启实例立即生效。如果只是现有数据文件把MAXSIZE设置得太小也可以直接调整现有文件的自动扩展上限不新增文件ALTER DATABASE DATAFILE /dm/data/TEMP01.DBF AUTOEXTEND ON NEXT 256M MAXSIZE 128G;这里需要提醒一下扩容不是无脑把MAXSIZE设到无穷大。临时表空间文件增长不受控会慢慢蚕食磁盘空间最终把操作系统分区撑满。我遇到过不止一次临时文件增长到几百GB磁盘彻底写满连正常的数据库日志都写不进去。所以扩容前先看磁盘分区空间给临时表空间划好一个合理上限比如“当前峰值用量再加50%余量”。3.2 参数调优让排序和哈希少“溢出”扩容只是治标真正要关心的是为什么内存没能消化掉排序。达梦数据库在排序、哈希操作时会先申请内存缓冲区装不下了再溢写到临时表空间。和这个问题直接相关的参数主要有这几个参数名作用调优思路SORT_BUF_SIZE单会话排序缓冲区大小单位MB调大后排序更少溢写磁盘但占用更多内存HAGR_HASH_SIZE单会话哈希连接缓冲区大小单位MB调大后哈希连接更少使用临时空间SORT_BUF_GLOBAL_SIZE整个实例排序缓冲区的总上限防止所有会话把内存吃光HJ_BUF_GLOBAL_SIZE整个实例哈希缓冲区总上限同样是全局兜底修改这些参数可以使用系统函数例如-- 动态调整实例参数scope的取值和生效方式以当前版本手册为准 SP_SET_PARA_VALUE(1, SORT_BUF_SIZE, 8); SP_SET_PARA_VALUE(1, HAGR_HASH_SIZE, 16);如果函数改完不生效或者不确定scope含义直接改dm.ini然后重启实例也可以。注意调参必须做全局评估把SORT_BUF_SIZE从2MB调到8MB意味着每个并发排序会话最多能多用6MB内存如果同时跑200个会话额外内存需求就是1.2GB。服务器的物理内存不够时调大参数反而会引发内存交换整个数据库性能跟着崩。从我的经验看这类参数适合“小步调整、持续观察”。每次调大一点观察几天看临时表空间峰值是否下降、内存是否稳定再决定要不要继续调。3.3 应用侧优化从源头减少临时空间需求参数调优能缓解问题但遇到单条SQL本身排序量过大再大的缓冲区也兜不住。这时候必须做应用侧优化我常用的手段有这些检查SQL能不能走索引避免排序。ORDER BY字段如果已经有合适索引优化器可以直接走索引顺序避免额外排序。改写SQL减少不必要的大排序。比如报表只需要Top10却先把全量结果ORDER BY一遍这完全是浪费临时空间先过滤再排序能省下几个数量级的临时段。更新统计信息。很多排序问题都是统计信息过期导致的“执行计划恶化”更新之后优化器重新选择计划可能完全绕开排序。避免在视图里写ORDER BY。有些人开发时习惯在视图里带上ORDER BY每次查询都强制排序客户端又用不到白白消耗临时空间。控制并发大查询。对于跑批类任务限制同时执行的会话数错峰调度比事后扩容更省心。这些优化手段里性价比最高的是“更新统计信息”。我曾经处理过一个案例报表SQL连续报-502实际数据量没怎么涨就是统计信息太旧优化器选了笛卡尔积加排序。更新统计信息之后执行计划回到索引路径临时表空间占用直接从8GB降到100MB以内。3.4 特殊场景大表建索引怎么估算临时空间创建索引是临时表空间不足的高发场景而且特别容易被低估。原因是建索引时数据库要把整表的目标键值全部排序一遍排序量接近“表行数 × (索引键总长度 行ID长度)”实际计算时往往还要乘上2倍左右的膨胀系数。举个例子某张表有8000万行要建一个平均键长50字节的联合索引估算排序量基础数据量 8000万 × (50 10) ≈ 4.8GB加膨胀系数 4.8GB × 2 ≈ 9.6GB这意味着临时表空间至少要预留10GB以上的空闲空间最好还能留出50%的余量。如果临时表空间只有8GB建索引几乎必然碰到-502。所以在大表建索引前先做这个估算再决定是否需要临时扩容。另外建大索引时可以使用并行度让排序分散到多个工作线程例如CREATE INDEX IDX_ORDER_NO ON T_ORDER(ORDER_NO) PARALLEL 4;并行建索引能缩短执行时间但对临时空间的瞬时需求也可能增大因为每个并行线程都要自己的排序段。实际使用时要先确认临时表空间扛得住再决定并行度。4. 报错复现与经典排查实录4.1 案例一一纸报表的ORDER BY把临时表空间打满某个客户的固定报表任务每周一凌晨跑某天突然报-502。我上去看的时候临时表空间16GB用了100%V$SORT_USAGE里有一条排序段占了10GB以上。顺着会话找到SQL是一条报表查询逻辑很简单把一张大明细表里半年的数据取出来按某个字段排序再取出前100条。问题就在于开发人员图省事先全量排序再取前100结果排序量巨大。我把SQL改成先过滤再排序在子查询里用聚合条件缩小数据范围临时空间占用从10GB降到200MB后续再也没有报过-502。这个案例是典型的“SQL写法问题”扩容能暂时救火但救不了一次一次爆发的趋势。4.2 案例二扩容到80GB之后依然报-502另一个环境更有意思客户把临时表空间从20GB扩到80GB第二天照样报-502。我上去查DBA_TEMP_FILES空间明明很充足空闲几十GB。再看V$SORT_USAGE发现同一个业务会话有多个排序段占用的总量不大但一直不释放。进一步排查发现是应用层的一个连接长时间空闲却一直没提交事务持有的临时段被数据库保留着。数据库层面杀掉这个会话后空间立刻释放。这个案例说明空间不足不一定真的是空间不够很可能是某个会话把资源攥着不放。遇到-502先查会话状态不要一门心思扩容。4.3 案例三临时表空间明明很大业务却走错了默认有一个实例里存在两个临时表空间TEMP大小20GBTEMP2大小200GB。新建的业务用户默认走TEMP跑了一段时间后TEMP打满TEMP2却闲得发慌。查业务配置才发现新用户没有指定表空间全部落到默认的TEMP上。解决方式是把默认临时表空间切换到大的那个达梦兼容Oracle风格的语法可以执行ALTER DATABASE DEFAULT TEMPORARY TABLESPACE TEMP2;如果你的版本不支持这条命令也可以在管理工具里直接修改库属性里的默认临时表空间。这个案例提醒我查看临时表空间配置时不光要看总容量还要确认业务会话实际在用哪一个。4.4 案例四磁盘没满自动扩展却没生效还有一个现场令人迷惑临时表空间数据文件只有32GBMAXSIZE是64GB看起来远没到顶但报-502就是反复出现。查操作系统磁盘发现根分区可用空间还有几百GB似乎不存在空间问题。后来仔细看挂载关系才发现临时数据文件所在的挂载点是一个单独的分区这个分区容量只有40GB已经被撑到99%。文件系统本身没空间AUTOEXTEND当然扩不动数据库只能报-502。处理方式是清理该分区上的旧归档和临时文件并把临时数据文件迁移到容量更充足的分区。这个案例说明排查-502时一定要把“数据库内部空间”和“操作系统磁盘空间”一起看缺一不可。5. 预防方案把监控和容量规划做在前面5.1 监控指标与告警阈值-502报错最可怕的是在半夜突袭与其等报警再救火不如提前做监控。我建议至少盯住四个指标临时表空间使用率。按数据文件维度统计超过80%预警超过90%触发告警。V$SORT_USAGE中的活跃排序段数量。短时间内激增说明有大SQL或异常并发。临时表空间所在磁盘分区的使用率。这个比数据库内部空间更容易被忽略。单条SQL的临时空间峰值。可以通过定期查询动态性能视图把Top SQL记录下来作为基线。如果公司有监控系统可以直接用SQL对接五分钟采集一次就够。没有监控系统的话数据库定时作业里放一条检查SQL发现使用率超阈值就调用系统命令推送告警也能起到类似效果。5.2 容量规划怎么估算给临时表空间做容量规划不能靠拍脑袋。我的估算口径很简单把高峰时段可能并发执行的大排序任务全列出来分别计算排序量再求和最后乘上1.5的安全系数。常用场景的估算方式可以参考这个表操作类型估算依据经验公式ORDER BY / DISTINCT结果集行数与排序键长度结果行数 × (键长 行ID)GROUP BY输入行数与分组键长度输入行数 × (分组键长 聚合列长度)哈希连接参与连接的大表行数大表行数 × 连接键长度创建索引表行数与索引键总长度行数 × (键总长 行ID) × 2把算出来的数字加到一起再对比当前临时表空间容量。如果超过70%就说明容量已经偏紧应该考虑扩容或清理无用大SQL。这套方法实操起来成本很低但能避免很多半夜的突发状况。5.3 跑批失败后的快速恢复清单最后整理一份现场处置清单给自己团队用也合适连接数据库执行DBA_TEMP_FILES和V$TEMP_SPACE_HEADERS查询确认容量状态。查询V$SORT_USAGE和V$SESSIONS定位占用临时段的会话。如果会话异常直接杀掉异常会话释放临时段恢复业务。如果确认容量不足立即扩容或调整MAXSIZE上限。检查操作系统磁盘空间排除AUTOEXTEND扩容失败的隐性原因。问题恢复后把当次SQL和占用数据记入问题台账分析是否需要SQL优化或参数调整。这套流程走下来大部分-502能在十几分钟内处理完。真正花时间的往往是后面的SQL治理但那是防止问题再次出现必须做的事。我个人在实际操作中的体会是-502报错七成以上不是单纯的空间不够而是某条SQL、某个会话或者某个配置项出了问题。扩容只是救火SQL治理和监控预警才是根治手段。每次处置完-502之后我会习惯性地把当时的SQL、临时表空间占用峰值、参数调整记录整理下来慢慢积累成本团队的容量基线和SQL黑名单。如果你也正在被这个报错困扰建议先从V$SORT_USAGE看起别急着扩容很多时候真正的答案就藏在那几条没释放的排序段里。