简介：面向DB2数据库运维人员与性能调优工程师的一份实战案例文档，源自某银行真实故障：SQL执行时间骤增，ACTIVE SESSION异常升高，常规检查未见异常，最终定位为系统临时表空间TEMPSPACE1异常膨胀至10GB。文档完整梳理了从CPU、内存、I/O、缓冲池命中率等常规指标排查，到通过db2top观察活动会话、db2pd分析LATCH等待、收集STACK堆栈、利用db2trc暂停实例抓取现场的分步过程，同时解释了临时表空间过大引发资源消耗、内存压力、LATCH竞争和磁盘排序开销增大的机制，并给出优化SQL、调整排序参数、清理临时对象等具体解决措施。整个资源为1个doc文档，约607KB，内容精炼且步骤可复用，特别适合遇到临时表空间膨胀或活动会话数飙升的DBA对照排查。该案例已被5898人学习浏览，来自一线运维经验，具有很高的实战参考价值。
1. 系统临时表空间满了，DB2 却说自己还有 90% 空闲——这个性能问题别重启了事
DB2 告警里出现“临时表空间使用率超过 90%”的时候，最诡异的一点是：你连上数据库，查db2 list tablespaces，系统临时表空间明明显示还有大量空闲页，可用空间充足，可数据库就像被什么东西扼住喉咙——应用连接堆积、查询集体卡在排序和哈希连接上、跑批任务超时。这就是 DB2 系统临时表空间过大引发的性能问题的典型现场：空间看着没满，性能已经崩了。
我当时第一反应也是重启，db2stop再db2start，瞬间恢复。可第二天同一个时段，问题原封不动地回来。能靠重启解决的问题，说明不是硬件瓶颈，而是 DB2 内部资源的分配和释放出了岔子。这个问题的根源在系统临时表空间的区段分配机制上，跟普通的表数据空间完全是两套逻辑。本文就把排查路径、参数设置和后续治理讲清楚，给同样被 DB2 临时表空间拖垮过的运维同行一个完整参考。
2. 系统临时表空间为什么会“假空闲、真阻塞”：先说透分配机制
2.1 临时表空间的角色：排序、哈希连接和重组的公共垃圾场
DB2 里有三种表空间：常规表空间存业务数据，大型表空间存大对象和索引数据，系统临时表空间则专门处理数据库管理器运行期间产生的中间数据。凡是 SQL 执行计划里出现排序（sort）、哈希连接（hash join）、去重（distinct）、分组（group by）、游标操作，以及reorg重建索引和表时产生的临时数据，都会往系统临时表空间里写。
关键点在于：这个空间是“用完即走”的，理论上会话结束后区段会被释放。但如果某个 DBA 把它建成了 DMS 表空间，又给了个很大的初始大小，同时还配置了自动扩展，那它就会像一个只进不出的黑匣子——分配出去的空间，DB2 不会自动还给操作系统。时间一长，文件系统层面这个临时表空间文件越涨越大，数据库内部却因为区段被碎片化占用，在高峰期申请不到连续的临时页，直接报SQL0964C（事务无法在临时表空间中分配空间）。
2.2 排序内存排序溢出：临时表空间膨胀的第一推手
我处理的案例里，九成临时表空间膨胀都跟排序有关。DB2 的排序分内存排序和溢出排序两段式。sortheap参数控制单个排序操作能用的内存上限，sheapthres控制所有排序操作共享的内存阈值。当排序数据量超过sortheap限制，DB2 会把中间结果写到系统临时表空间，这叫“排序溢出”。
一个错误的参数配比就能让情况恶化：比如sortheap设得太大，比如超过 4GB，排序大部分在内存里完成，临时表空间使用率反而不高，但内存会被挤爆；sortheap设得太小，比如低于 256MB，大量排序疯狂落盘，临时表空间立刻告急。更隐蔽的是sheapthres设成 0，意味着数据库管理器不强制限制总排序内存，每个连接都能抢占内存做排序，直到数据库内存耗尽。我在生产环境见过sheapthres=0配合 2000 个并发连接，系统临时表空间一小时内涨了 60GB。
2.3 FILO 栈式分配：为什么空间满了却无法回收
系统临时表空间还有一个特殊机制：区段分配遵循类似栈（FILO）的复用逻辑。DB2 优先复用最近释放的区段，而不是从头扫描找空闲区段。这个设计本意是提高缓存命中率，但在长会话、大批量排序场景下会出问题：一个会话占用了一批靠上的区段，释放后只归还了顶部一小块；后续会话不断申请新区段，只能从当前游标位置继续向上扩展——这就导致底部大量区段明明空闲，却永远轮不到复用。
最终表现就是：临时表空间已经扩展到几百 GB，文件系统快撑不住了，但db2 list tablespaces showing detail看到的空闲页比例很高。因为空闲页分布在被占用的区段之间，不连续，排序申请连续页时会话一直等待，性能就此崩塌。这解释了标题里“系统临时表空间过大引发的性能问题”的底层逻辑，空间大是表象，分配策略才是病灶。
3. 用 10 分钟定位临时表空间瓶颈：监控命令与指标解读
3.1 先看空间快照与当前活动语句，别急着调参数
收到告警后，第一步不是改配置，而是确认临时表空间的真实状态和哪些语句在占用。按以下顺序执行：
# 1. 查看表空间总体状态与自动扩展设置 db2 list tablespaces showing detail # 2. 查看系统临时表空间的详细容器信息 db2 list tablespace containers for <tablespace_id> showing detail # 3. 查看当前占用临时表空间的操作 db2 get snapshot for database on <dbname> | grep -i "temp"执行完第一步，重点关注State字段是否为0x0000（正常），以及Max size是否为-1（表示不限制自动扩展）；第二步确认容器文件所在文件系统的剩余空间；第三步快照输出里重点看Total temporary space used、High water mark和Temporary space used by active queries。如果高水位线远高于当前使用量，说明历史上曾经分配过大量临时空间但未释放，这就是“假空闲”的直接证据。
3.2 抓出吃临时表空间的“肇事 SQL”
空间快照能确认问题，但要定位到具体语句，需要查活动语句快照。标准做法是用db2pd取数据库级快照，再结合MON_GET_TABLE表函数看 TEMP 分区上的读写量：
-- 查看当前正在消耗临时空间的语句快照 SELECT application_handle, application_name, workload_name, total_sort_time, sorts, sort_overflows, total_execution_time FROM TABLE(MON_GET_UNIT_OF_WORK(NULL,-2)) AS U ORDER BY total_sort_time DESC FETCH FIRST 10 ROWS ONLY;MON_GET_UNIT_OF_WORK是 DB2 10.5 及以上版本推荐的监控函数，sort_overflows字段如果持续大于 0，说明排序溢出正在发生，配合total_sort_time能看到是哪些应用在持续吃临时空间。注意，不要用 LIST APPLICATIONS 代替，它只显示连接状态，看不到排序活动和临时空间占用，容易漏判。
3.3 区分“正常膨胀”和“异常膨胀”：看高水位与当前值的差
用db2pd -dbsize可以按表空间粒度看分配和已用量，这是区分临时表空间膨胀类型最直接的工具：
# 查看数据库所有表空间的分配细节，包括扇区数和扩展情况 db2pd -dbsize -db <dbname>输出里Total pages是当前文件系统上实际分配的总页数，Usable pages是当前可用页数，Used pages是已使用页数。如果Total pages远大于Used pages，说明数据库管理层次上，文件已经被撑大但内部没写满——异常膨胀；如果两者接近，说明临时表空间确实承载了大量数据，需要在语句优化或排序内存上想办法。
再配合db2pd -tcbst查看每个表空间的缓存池命中和读操作：
# 查看临时表空间上的物理读、逻辑读和异步读 db2pd -tcbst -db <dbname> | grep -A 20 "TEMP"POOL_TEMP_DATA_L_READ和POOL_TEMP_DATA_P_READ是临时表空间上的逻辑读和物理读计数。物理读比例高说明溢出严重，数据在内存和临时空间之间来回搬运，这时候改sortheap比扩临时表空间文件更有效。
4. 临时表空间治理避坑：4 个高频症状、根因与止血方案
4.1 现象：SQL0964C报错但表空间实际有空闲页
这是误导性最强的报错。应用报“无法在临时表空间分配空间”，但查表空间详情明明还有几十 GB 空闲。原因就是 2.3 节说的 FILO 栈式分配中的碎片化——空闲页存在但不连续，DB2 分配连续页段失败。
解决路径分三步。先看sortheap和sheapthres是否合理（具体配比见第五章）；再看是否有长事务或长会话（用MON_GET_UNIT_OF_WORK查执行时长超过 2 小时的会话）；最后如果确认是碎片化，最有效的止血手段是断开所有连接后执行：
db2 force applications all db2 deactivate db <dbname> db2stop db2start db2 activate db <dbname>这里的逻辑是：数据库重启会清空所有分配给系统临时表空间的区段，让文件恢复到初始大小（前提是文件系统支持收缩）。如果业务不允许重启，就只能通过ALTER TABLESPACE增加容器临时缓解，但这不是长久之计。
4.2 现象：db2stop正常但db2start后临时表空间依然巨大
重启后临时表空间文件大小没变化，很多人会以为是重启失败。实际上，如果临时表空间是用 DMS 类型建的，并且PREFETCHSIZE和OVERHEAD配置不当，重启后 DB2 会根据表空间定义重新预分配初始空间，而不是恢复到最小状态。
检查表空间定义时重点看USER子句里的PREFETCHSIZE是否过大，比如超过 16MB。同时确认创建语句里是否用 USING 指定了初始大小，初始大小定了 100GB，那重启后就是 100GB。解决方法是重建系统临时表空间，在维护窗口执行：
db2 "CREATE SYSTEM TEMPORARY TABLESPACE SYSTOOLSTMPSPACE \ IN IBMCATGROUP PAGESIZE 32K \ MANAGED BY DATABASE USING (FILE '/db2data/temp_ts' 5000) \ EXTENTSIZE 32 \ PREFETCHSIZE 64 \ BUFFERPOOL IBMDEFAULTBP"这里的核心参数是MANAGED BY DATABASE USING (FILE ... )指定初始文件大小，5000 单位是页，32K 页大小下约 160MB 起步，后续靠自动扩展增长。EXTENTSIZE 32表示每次扩展 32 页，PREFETCHSIZE 64是预读 64 页，这两个值配合默认缓冲池避免碎片化提前出现。
4.3 现象：监控脚本发现临时表空间文件每天固定时间暴涨
如果暴涨时间点固定，比如每天早上 9 点到 10 点，大概率是批处理任务集中启动，排序操作叠加导致临时空间峰值集中。单纯调大临时表空间只会让峰值更高，正确做法是错峰和限流。
用db2 list applications查看这段时间的并发连接数，再用MON_GET_UNIT_OF_WORK抓这段时间内排序时间最长的应用。如果是 ETL 工具的并行加载，可以调整其并发度；如果是报表查询，可以限制查询优先级。通过这些手段降低峰值期的排序并发，远比无条件扩容有意义。
4.4 现象：历史库的临时表空间连续数月持续增长
这种增长通常没有急性故障，但文件系统告警不断，而且增速稳定。根因大多是统计信息过期导致执行计划选择了大规模哈希连接或排序。DB2 里统计信息直接影响优化器选择排序还是嵌套循环，统计信息过期时优化器会高估行数，选择排序且分配超大临时空间。
解决方案是周期性运行RUNSTATS，并且不只是对表，对索引也要跑：
db2 "RUNSTATS ON TABLE <schema>.<table> WITH DISTRIBUTION \ AND DETAILED INDEXES ALL"配合REORG定期整理碎片：
db2 "REORG TABLE <schema>.<table>"WITH DISTRIBUTION选项会收集列分布统计信息，DETAILED INDEXES ALL收集索引的详细统计。对于大表，注意设置UTIL_IMPACT_LIM限制工具影响度，避免REORG本身占用过多临时表空间。
5. 从止血到长效治理：排序内存配比与自动清理方案
5.1 排序内存参数：setheap 和 sheapthres 的推荐起点
sortheap和sheapthres是影响临时表空间使用最直接的两个参数。常见做法是：先看数据库内存总量和并发连接数，然后按比例设置。我的建议配比是sortheap取数据库共享内存的 2% 到 5%，sheapthres取sortheap的 4 到 6 倍。
落地命令如下：
# 查看当前配置 db2 get db cfg | grep -i sortheap # 修改排序堆大小（单位是 4KB 页） db2 update db cfg using sortheap 1024 db2 update db cfg using sheapthres 6144这里sortheap 1024表示 1024 个 4KB 页，即 4MB；sheapthres 6144表示 6144 个 4KB 页，即 24MB。修改后无需重启立即生效。注意，不要简单地把 sortheap 调到 20000 以上，那会让排序全部走内存，看起来临时表空间问题没了，但内存换页会让整机性能崩掉。判断标准是看 3.2 节的sort_overflows：如果调整后该值归零，说明排序全在内存完成，sortheap还可以小幅下调；如果仍持续增长，说明内存排序写满了sortheap后才开始溢出，再加临时空间意义有限，应该从 SQL 层面减少排序。
5.2 规划轮询清空任务：定期整理临时表空间的碎片
生产环境无法频繁重启数据库，但可以做一个轻量级的轮询任务：每周在低峰时段执行一次“温和清理”，即把所有活动连接强制断开后执行一次db2 deactivate db，再db2 activate db。这个操作比db2stop/start轻得多，效果是让数据库管理器重新评估临时表空间的使用，回收部分碎片空间。
关键点是不能在业务高峰期做，deactivate会断开所有连接。更安全的做法是先用db2 list applications确认活跃连接数，低于 10 再执行。如果deactivate后临时表空间文件还是没有收缩，说明文件系统不支持在线收缩，只能走重建临时表空间路线（见 4.2 节命令）。
5.3 自动化监控脚本：提前 3 天预警而不是等告警
把这条 SQL 放到服务器 crontab 里，每 5 分钟执行一次，检查临时表空间使用率和高水位线变化趋势：
#!/bin/bash DB_NAME=yourdb DB_USER=db2inst1 DB_PASS=yourpass db2 connect to $DB_NAME user $DB_USER using $DB_PASS > /dev/null 2>&1 # 输出临时表空间使用率和高水位 db2 "SELECT TABLESPACE_NAME, CURRENT_USED_PAGES, \ HIGHWATERMARK_PAGES, \ (HIGHWATERMARK_PAGES * 100 / CURRENT_USED_PAGES) AS WASTE_RATE \ FROM SYSIBMADM.TBSP_UTILIZATION \ WHERE TBSP_TYPE = 'SYSTEM TEMPORARY' \ ORDER BY WASTE_RATE DESC" db2 terminateTBSP_UTILIZATION管理视图会输出每种表空间的高水位页数（HIGHWATERMARK_PAGES），如果高水位是当前使用量的数倍，说明碎片化严重。把WASTE_RATE超过 200% 作为第一优先修复阈值，超过 150% 作为预警阈值。脚本配上邮件通知，能在业务感知到卡顿前的 2 到 3 天发现问题。
5.4 业务层优化：减少无序排序的 SQL 改写思路
排序内存和临时表空间是下游，上游是 SQL 写法。常见减少临时空间占用的改写思路：
ORDER BY尽量走索引避免显式排序，db2expln里看到TBSCAN SORT就要考虑加索引。- 大表连接优先走 HASH JOIN，但要让小表作为内表，减少哈希表构建开销。
- 分页查询用
FETCH FIRST N ROWS ONLY配合OPTIMIZE FOR N ROWS，限制 DB2 为排序预留的临时空间。 - 去掉
DISTINCT，改用GROUP BY配合COUNT统计，减少一步去重排序。
曾有一个报表存储过程，只是把OPTIMIZE FOR 1000 ROWS加到分页查询里，临时表空间峰值就从 70% 降到 20%。这类改动不涉及架构调整，POC 阶段就可以快速验证。
6. 重建系统临时表空间的完整流程：把文件大小收回去并验证性能
如果前面的治理手段全部执行后，临时表空间文件依然持续膨胀，最后一个手段是重建整个系统临时表空间。这套流程的核心思路：新建一个临时表空间接管负载，删掉旧的高水位表空间，让文件回到初始百 MB 级别。
前提是数据库必须允许短暂中断业务，建议在维护窗口操作。步骤分六步：
# 1. 确认当前临时表空间 ID 和文件路径 db2 list tablespaces showing detail | grep -A 8 "TEMPORARY" # 2. 创建新的系统临时表空间，初始文件大小不要太大 db2 "CREATE SYSTEM TEMPORARY TABLESPACE TEMPSPACE_NEW \ IN IBMCATGROUP PAGESIZE 32K \ MANAGED BY DATABASE USING (FILE '/db2data/temp_ts_new' 1000) \ EXTENTSIZE 32 \ PREFETCHSIZE 64 \ BUFFERPOOL IBMDEFAULTBP" # 3. 把新表空间设置为默认临时表空间 db2 "UPDATE DATABASE CONFIGURATION USING DFT_TBSP_NAME TEMPSPACE_NEW" # 4. 删除旧的临时表空间 db2 "DROP TABLESPACE TEMPSPACE1" # 5. 如果删除时报 5 字节锁等待，先确认无活动会话，再重新执行 db2 force applications all db2 "DROP TABLESPACE TEMPSPACE1" # 6. 验证配置 db2 "SELECT TABLESPACE_NAME, TBSP_TYPE FROM SYSIBMADM.TBSP_UTILIZATION"执行第 3 步后，DFT_TBSP_NAME指向新临时表空间，后续新会话默认使用它。第 4 步删除旧表空间时，DB2 会同步释放其占用的所有文件空间。如果第 4 步报错，常见原因是仍有会话持有旧表空间的游标，所以第 5 步先强制断开连接，再重试删除。
重建完成后，观察两个指标：一是db2 list tablespaces showing detail里新表空间总页数是否稳定在初始水平；二是按第五章的监控 SQL 持续跟踪WASTE_RATE。如果重建后一个月内WASTE_RATE又超过 200%，说明排序溢出确实高频发生，问题不在空间而在语句。
我处理过最头疼的一次，重建后第三天temp_ts_new还是涨到了 40GB，后来查出是一个 BI 工具每次全量抽取时用了DISTINCT。把它的抽取 SQL 从“先 DISTINCT 后 JOIN”改成“先 JOIN 再 GROUP BY”，峰值立刻降回了 5GB 以内。这说明临时表空间治理，七分在 SQL，三分在数据库参数。希望这个从定位、配参到重建的完整路径，能帮你下次碰到同类问题时少走几次弯路。
本文还有配套的精品资源，点击获取
