★ FEATURED ARTICLE 简介围绕某银行DB2系统临时表空间异常膨胀导致SQL执行变慢的真实案例这份DOC文档面向DBA、数据库运维与性能诊断人员系统梳理从ACTIVE SESSION激增、常规资源排查无果到定位TEMPSPACE1达10GB的完整分析过程。文档结合LATCH分析、STACK收集、db2trc暂停实例等工具方法说明临时表空间过大如何引发资源消耗、内存压力、LATCH竞争与磁盘排序开销并给出SQL优化、参数调整和临时对象清理等处置思路适合作为DB2性能排错与案例复盘参考。资源包仅含1个DOC文件约607KB轻量便于查阅已有5903人学习说明该案例在数据库运维群体中具有较高关注度。读者可从中获得真实故障的定位路径、监控指标判读方法、常用诊断工具的组合用法及问题解决框架对日常性能问题分析有较强借鉴价值。1. 临时表空间不是“临时”的10G 的 TEMPSPACE1 如何把 OLTP 拖进 4 秒一次典型的 DB2 性能问题排查最容易被怀疑的是 SQL 本身、锁、缓冲池、I/O而真正的元凶常常是那个几乎没人看的系统临时表空间 TEMPSPACE1——它不存业务数据不参与事务提交涨到 10GB 之后却让一堆毫不相干的简单查询从毫秒级变成 3~6 秒。更反直觉的是拖慢查询的不是往临时表空间里写数据而是读它的元数据。监控代理周期性对表空间做快照快照要遍历 SMS 容器的数据页这段代码持有 pool_table_latch而并发查询在创建内部临时表时必须拿同一把 LATCH于是二十多个 EDU 排成一队ACTIVE SESSION 瞬间冲到几十。这条链路里没有一行用户 SQL 写错搞懂它比记住任何一条调优命令都值钱。2. 活动会话数飙升的真相从 db2top 到 MON_CURRENT_SQL 的排查链路业务侧反馈“系统变慢”这种信号通常是模糊的凭感觉做出的反馈可能有偏差也可能压根是应用层的问题。但当监控频繁捕捉到 ACTIVE SESSION 数量突破 50而历史曲线长期在 10 以内、偶发 30这就不是感觉问题了——数据库层面确实有东西在堵。这一章要解决的是怎么在十分钟内确认“是数据库的问题”并且把范围从“整个实例”收窄到“某几条语句在等某个内部资源”。2.1 ACTIVE SESSION 到底统计了哪些状态ACTIVE SESSION 即活动会话数指当前正在执行的 application 数量。准确地说正在处理 SQL 语句请求的会话都计入而一条语句从编译到执行完成会经历多个状态Compiling、UOW Executing、Lock Waiting、Commit ActiveCOMMIT 本身也是一条语句如果启用了 WLM 的并发限制排队中的会话处于 Queued 状态。这些状态全部计入 ActSess。反过来一个事务里执行完上一条语句、下一条还没开始的会话处于 UOW Waiting不计入。这个口径差异是排查时第一个容易翻车的地方ACTIVE SESSION 高不代表 SQL 都在干活也可能都在等。一般的 OLTP 系统这个数值在 10 以内繁忙系统二三十个再往上就要考虑扩容。当一个平时只有几个会话的系统突然频繁冲到几十只有两种可能——业务访问量真的涨了或者 SQL 执行时间变长了。跟业务负责人确认访问量没有增长基本就可以把排查方向锁定在后者。查看方式有两类。一类是db2top -d dbname进入后按d看数据库整体指标默认 2 秒刷新按l小写 L进 SESSIONS 页面能看到每个会话的具体状态。这次问题里活动会话的状态清一色是 UOW Executing说明它们都在真正执行不是在等锁。另一类是通过db2 LIST APPLICATIONS SHOW DETAIL自己统计状态分布适合脚本化采集和留证。2.2 快速排除法一屏看完 CPU、内存、I/O、命中率、锁确认是数据库问题之后先做一轮成本最低的排除别一上来就扎进语句分析。db2top 的数据库页面基本能在一屏内给出结论CPU 利用率和操作系统内存使用量在正常区间排除资源耗尽HitRatio 正常排除缓冲池不足导致的物理读放大没有 Lock Waiting排除锁等待链右下角四个指标 AvgPRdTime平均物理读时间、AvgDRdTime平均直接读时间、AvgPWrTime平均物理写时间、AvgDWrTime平均直接写时间正常排除 I/O 抖动。这一屏里还有两个容易被误读的数字。一个是 Deadlocks 218看着吓人但它是累计值只要不在持续增长就不影响当前性能另一个是 SortOvf排序溢出为 10偏高但应用本身有大量排序语句有溢出属于预期。判断一个指标要不要追标准是“它是否在时间维度上和故障窗口重合”而不是“它的绝对值是否好看”。这条经验在后面识别 TEMPSPACE1 时还会再用一次。2.3 抓慢语句的三条路径db2top、MON_CURRENT_SQL、MON_GET_PKG_CACHE_STMT排除完外围开始抓执行时间长的语句。三条路径的粒度和用途不同配合着用效率最高。第一条是 db2top 里的包缓存视图。在界面输入D进入动态 SQL 列表再输入z上方会提示Column number for descending sort:输入4回车即按 Avg ExecTime 降序。这次看到前几条平均执行时间接近 4 秒但 Num Execution 都只有几次——原因是应用拼凑 SQL 字符串而没有用变量绑定几乎每条语句对 DB2 来说都是全新的缓存里统计不到执行次数。看到这种“次数极少但时间很长”的形态可以直接推断同类语句全都慢不要因为样本小就放过。第二条是管理视图用来抓“此刻正在跑什么”。当 ACTIVE SESSION 高企时这条 SQL 能按已运行时长倒序列出当前语句-- 查看当前正在执行的语句按已运行秒数倒序 SELECT COORD_MEMBER AS MEMBER, VARCHAR(SESSION_AUTH_ID, 10) AS USER, VARCHAR(CLIENT_APPLNAME, 10) AS APPNAME, ELAPSED_TIME_SEC AS ELAPSEDTIME, VARCHAR(ACTIVITY_STATE, 10) AS STATE, TOTAL_CPU_TIME, ROWS_READ, ROWS_RETURNED, QUERY_COST_ESTIMATE, DIRECT_READS, DIRECT_WRITES, VARCHAR(STMT_TEXT, 2000) AS STMT_TEXT FROM SYSIBMADM.MON_CURRENT_SQL ORDER BY ELAPSED_TIME_SEC DESC;ELAPSED_TIME_SEC是语句从开始执行到查询视图那一刻的累计秒数所以抓到的值一定比完整执行时间短这是这个视图的固有偏差不是数据错误。另一个坑是它只反映“抓的这一刻”语句跑完就消失需要多执行几次才能在会话高峰时命中现场。抓到的语句数量接近 30 条正好和 ACTIVE SESSION 的数量对上。第三条是表函数用来做时间分布的归因分析。这是整轮排查里信息密度最高的一个工具-- 按语句统计平均执行时间并计算各类等待占总执行时间的百分比 SELECT MEMBER, NUM_EXECUTIONS, STMT_EXEC_TIME, DECIMAL((TOTAL_ACT_WAIT_TIME / DOUBLE(STMT_EXEC_TIME)) * 100, 5, 2) AS pct_wait, DECIMAL((POOL_READ_TIME / DOUBLE(STMT_EXEC_TIME)) * 100, 5, 2) AS pct_read, DECIMAL((LOCK_WAIT_TIME / DOUBLE(STMT_EXEC_TIME)) * 100, 5, 2) AS pct_lock, DECIMAL((LOG_DISK_WAIT_TIME / DOUBLE(STMT_EXEC_TIME)) * 100, 5, 2) AS pct_log, DECIMAL((TOTAL_SECTION_SORT_TIME / DOUBLE(STMT_EXEC_TIME)) * 100, 5, 2) AS pct_sort, CAST(FLOAT(STMT_EXEC_TIME) / FLOAT(NUM_EXECUTIONS) AS DECIMAL(10,3)) AS AVG_EXEC_TIME, VARCHAR(STMT_TEXT, 500) AS STMT_TEXT FROM TABLE(MON_GET_PKG_CACHE_STMT(NULL, NULL, NULL, -2)) WHERE NUM_EXECUTIONS 1 AND STMT_EXEC_TIME 0;三个 NULL 参数分别对应“不限定成员、不限定语句、不限定应用”最后的-2表示获取所有成员上的全部语句如果只想看某个成员把第一个参数换成成员号。NUM_EXECUTIONS 1是为了过滤掉只执行过一次的噪声语句STMT_EXEC_TIME 0是防止除零。结果里能看到平均执行时间在 2~6 秒不等其中 5 条以with开头的语句PCT_WAIT在 95% 以上——执行时间几乎全耗在等待上但 wait 的构成里 READ、LOCK、日志写、排序都不是大头。到这里可以往查询里加TOTAL_EXTENDED_LATCH_WAIT_TIME字段答案就浮出来了它们在等 LATCH。另外 5 条慢语句是调用存储过程的从这条查询看不出时间分布属于工具的能力边界得换个思路。提示pct_* 这一组百分比是基于总执行时间算的几条语句加起来可能超过 100%因为它统计的是“等待类型占比”而不是互斥的耗时切片别拿它做严格的时间守恒校验。此时很容易做出一个错误决策既然抓到了慢 SQL那就优化 SQL。这次也确实先这么干了——给几个全表扫描的语句建索引快是快了但系统整体没恢复。回过头看那些既长又复杂的 SQL 逻辑并不是最近才上线的应用没变更、数据库没变更努力方向从一开始就偏了。及时打住比继续埋头优化更重要慢语句是症状LATCH 等待才是可追的线索。3. LATCH 机制DB2 内部的轻量锁与 pool_table_latch 为什么会被表空间快照抓住从“语句慢在 LATCH 等待”到“具体是哪个 LATCH、谁持有、持有者在干什么”中间隔着一层没有文档覆盖的黑匣子。DB2 的表函数只暴露了TOTAL_EXTENDED_LATCH_WAIT_TIME这样的汇总监控元素对 LATCH 本身没有任何介绍性材料这在排查时是实打实的障碍。这一章把 LATCH 的定位、pool_table_latch 的归属以及怎么把“一瞬间”的等待抓成证据讲清楚。3.1 LATCH 与 LOCK 的分工保护内部结构 vs 保护用户数据可以这样理解 DB2 中的 LATCH它的目的是保证多线程访问内部共享资源的一致性本质是一种轻量锁锁的对象是数据库引擎自己的内存数据结构不是用户的行、表、页。举个具体例子。内存里有一个预取队列PREFETCH QUEUE结构处理用户请求的协调 EDU 需要预取时往队列里塞任务多个预取 EDU 不停地从队列里读任务。为了协调这两类 EDU 对同一个队列的访问每次访问前都要先获取一个 LATCH其他 EDU 等它释放才能进。LATCH 和 LOCK 的区别由此可以推出来LOCK 的持有期跟事务绑定可能持续到 COMMIT持有者是用户事务等待者能被db2pd -wlocks或事件监控看到LATCH 的持有期通常只有微秒到毫秒级跟着一段临界区代码走持有者是 EDU不体现在任何锁视图里。这解释了一个常见的困惑明明没有锁等待语句却卡住不动。LATCH 是引擎内部的自旋/短等没有“锁等待时间”这个维度只能靠TOTAL_EXTENDED_LATCH_WAIT_TIME或直接抓现场。3.2 pool_table_latch 保护什么表池结构与 SMS 容器页统计LATCH 的名字用的是内部命名规则从字面看不出什么有用信息pool_table_latch尤其如此。它的完整符号是SQLO_LT_SQLB_PTBL__pool_table_latch从命名拆解SQLO是操作系统抽象层SQLB是缓冲池与表空间管理模块PTBL是 pool table最后才是 latch 类型。也就是说它保护的是“表池”这个描述表空间与容器映射关系的内部结构。关键点在于这个结构是全局粒度的——一个数据库实例里所有表空间的元信息共享一把 LATCH而不是每表空间一把。任何要读表空间元信息的操作都得先拿它包括两个看起来毫不相关的动作查询执行时创建内部临时表需要确认系统临时表空间的位置和数据池走sqlbGetSysTempDatapool要拿这把 LATCH监控采集表空间快照需要遍历 SMS 表空间的容器、统计数据页走sqlbSnapshotTablespace → sqlbMonSMSGetContainerPages也要拿这把 LATCH。前者的持有时间几乎恒定取决于结构查找的复杂度后者的持有时间跟容器数量和页数正相关。当 TEMPSPACE1 只有一个很小的初始尺寸时这个遍历几微秒就结束了谁也不会注意到当它膨胀到 10GB、354661 个页、4 个容器时同样的遍历要做的活儿多了几个数量级持有时间被拉长到足以让并发查询排队的程度。这就是“表空间变大”和“查询变慢”之间那条看不见的因果链。3.3 db2pd -latches -rep 2把一瞬间的等待抓成证据理解机制之后取证是下一步。第一轮快速排除时已经跑过db2pd -latches没发现异常——因为 LATCH 等待只有几秒就清除了单次采样大概率撞在空档上。改用带重复参数的命令持续观察# 每 2 秒采样一次 LATCH 状态并持续输出到屏幕用于捕捉瞬时争用 db2pd -latches -rep 2-rep 2的含义是每隔 2 秒重复执行并打印不指定次数就一直跑CtrlC 结束。输出里能看到 EDU ID 11665 持有类型为pool_table_latch的 LATCH而 ID 2877、2981 等 23 个 EDU 在等同一把。23 个等待者意味着此刻至少有 24 个 EDU 被这一个临界区堵住——ACTIVE SESSION 冲到几十源头就在这里。采样间隔的选择有讲究。间隔太大容易错过太小则每次输出的采集本身也会消耗资源而且刷屏太快反而看不清。对于持续几秒量级的争用2 秒是个能兼顾命中率和可读性的经验值如果怀疑争用更短促可以降到 1 秒但要接受输出量翻倍。注意db2pd -latches只给出 Holder 和 Waiter 的 EDU 编号与 LATCH 类型不给出“它们当时在执行哪行代码”。真正定位到函数级得靠下一章的 STACK 取证。4. STACK 取证db2pd -stack 与 analyzestack 怎么把 Holder 和 Waiter 的调用链对上拿到 EDU 编号和 LATCH 类型等于拿到了嫌疑人的身份证号但还不知道他在干什么。DB2 的db2pd支持在收集 STACK 的同时把每个 EDU 当时的 LATCH 信息和 LOCK 信息一并抓下来这就把“谁持有”和“持有者在执行什么代码”绑在了一起。这一章讲采集方法、两个栈的读法以及那个藏在安装目录里的分析脚本。4.1 采集命令与生产环境的代价先把现场抓下来再慢慢分析。采集脚本大致如下# 进入一个容量足够的临时目录避免 STACK 文件写满根分区 cd /tmp mkdir -p stack0531 # 对实例内所有 EDU 抓栈每隔 3 秒抓一次连续抓 10 次 # dumpdir 指定输出目录默认会落在 DIAGPATH 下 db2pd -stack all dumpdir/tmp/stack0531 -rep 3 10-stack all表示实例内所有 EDU也可以只抓指定 EDU 编号dumpdir决定*.stack.txt落在哪生产环境务必显式指定到一个容量足够的目录因为一次all加十轮重复可能产生上百个文件-rep 3 10是每 3 秒一轮、共 10 轮这个组合是专门为“间歇性出现”的争用准备的——抓一次碰不上就连着抓十次。代价必须说清楚抓栈会让每个 EDU 在信号处理点短暂停顿数据库越繁忙这个停顿对吞吐的影响越明显。所以采集前要评估时间窗口尽量避开业务高峰或者把轮次降下来。这是典型的用性能换可观测性的操作别在问题上头的时候无脑-rep 1 100。采集完成后先用 grep 快速确认有没有捞到目标# 在所有栈文件里搜索目标 LATCH确认是否捕捉到 Holder / Waiter cd /tmp/stack0531 grep pool_table_latch *.stack.txt命中的行会形如Holding Latch type: (SQLO_LT_SQLB_PTBL__pool_table_latch) - Address: (0x...), Line: 9032, File: sqlmonss.C或者Waiting on latch type: ... Line: 11384, File: sqlbpool.C。第一轮没抓到就再跑一轮这种间歇性争用抓不到是常态不是工具坏了。4.2 两个栈的读法从函数名反推操作类型函数名是内部符号看着劝退但其实信息量很大。不用看懂每一行只需要抓住调用链里那几个“语义明显”的函数结合 DB2 的模块划分就能定位操作类型。Holder 的栈节选关键调用链自下而上sqleProcessSubRequest -- 处理子请求监控采集走的独立请求通道 sqlmPdbRequestRouter -- 监控请求路由 sqlmonssagnt -- 监控快照代理 sqlbSnapshotTablespace -- 对表空间做快照 sqlbMonSMSGetContainerPages -- 统计 SMS 表空间的容器页 SQLB_FIND_BUF::next -- 遍历文件查找缓冲 sqlofindn2 -- 文件查找 __xstat64 -- 系统调用取文件状态从sqlbSnapshotTablespace → sqlbMonSMSGetContainerPages这两级就能读出来这个 EDU 在对表空间做快照具体动作是统计 SMS 表空间的容器数据页。再往下走到__xstat64说明它在对容器文件做 stat 系统调用取文件状态。容器文件越多、目录项越复杂这段就越慢——TDA 文件堆积正好会把这里撑爆。Waiter 的栈同样节选sqlrita -- 运行时聚合 sqlriFetch -- 取行 sqlsfetc -- 从排序/临时结构取数 sqldEvalDataPred -- 谓词求值 sqldTableCreateTemp -- 创建临时表 sqldInternalCreateTable -- 内部建表 sqlbGetSysTempDatapool -- 获取系统临时数据池 SQLO_SLATCH_CAS64::getConflict -- 争用 LATCH这条链的意思是一个查询在执行谓词求值时需要建内部临时表建表过程要拿系统临时表空间对应的数据池于是去申请pool_table_latch撞上 Holder 没释放卡在getConflict里自旋/等待。两边一对因果就闭合了监控代理定期抓表空间快照 → 快照遍历 SMS 容器页 → 持有 pool_table_latch → 并发查询建临时表拿不到锁 → 排队 → ACTIVE SESSION 飙升 → 业务感知变慢。整个过程里没有任何一条用户 SQL 有逻辑错误也没有任何配置被改坏。4.3 analyzestack把上百个栈文件聚合成结论手工 grep 加肉眼比对在十来个文件时还行上百个就撑不住了。安装目录的sqllib/pd下有一个 Perl 脚本analyzestack能把指定目录里所有*.stack.txt中相同的 STACK 汇总统计并顺带做 LATCH 分析# -d 50 : 对比栈时比较的函数个数越大越严格 # -i 目录 : 栈文件所在目录也可以直接列多个 stack.txt # -l : 执行 LATCH 分析 perl ~/sqllib/pd/analyzestack -d 50 -i /tmp/stack -l它会生成LatchAnalysis.out和StackAnalysis.out两个结果文件文件名可通过参数改。-d这个参数值得多说一句它决定“函数调用链前多少个函数相同才算同一个栈”值调小会把不同的栈合并调大则可能把本该合并的栈拆开。默认值在多数场景够用遇到调用链高度相似但归属不同的情况再上下调。这个脚本的定位要说清楚它是随产品一起提供的示例脚本脚本头部明确声明按现状提供、不做任何保证官方知识中心也找不到它的使用说明用法只能靠-help自己摸。这不影响它在排查中的实用价值但要清楚它的输出是线索而不是结论最终的判断还得回到调用链语义上。提示analyzestack对栈文件的命名格式有依赖手工重命名过*.stack.txt之后再跑可能解析失败采集后保持原始文件名最省事。5. 避坑清单临时表空间、TDA 文件与诊断工具的五个常见坑排查走到这一步机制已经清楚了但真正落地修复时踩的坑往往比分析阶段更多。下面五条都是这次或类似场景里真实绊过人的地方按“现象 → 原因 → 解决”记下来。5.1 临时表空间相关的三个坑坑一重启实例之后临时表空间还是那么大。现象是执行db2 LIST TABLESPACES SHOW DETAIL依然要好几秒TEMPSPACE1 的 Total pages 纹丝不动业务侧的卡顿只是短暂缓解又复发。原因是 SMS 系统临时表空间里的 TDA 文件形如SQL04313.MEMBER0000.TDA在特定条件下会遗留在表空间内并占满空间这是产品的既定行为不是缺陷实例重启不会重建这些容器文件只有数据库级别的 deactivate/activate 才会。解决方式是安排维护窗口执行db2 deactivate db dbname再db2 activate db dbname执行完立刻复查 Total pages 和 Used pages 是否归零。这次的 10GB 就是靠这一步一次性释放的之后LIST TABLESPACES恢复到秒内返回。坑二临时表空间暴增之后只盯着当前负载看忽略了历史曲线。现象是问题复现时负载并不高怎么都解释不了 10GB 是怎么来的。原因是暴涨发生在过去的某个时间点和当前负载无关。这次翻监控系统的表空间大小历史曲线才看到某个时刻从 0 直接跳到 10G对应的是那一瞬间 ACTIVE SESSION 冲到 800 多——大量语句同时使用临时表空间数据库没崩、语句也都执行成功了但留下了一堆 TDA 文件成了后来踩到的雷。解决方法是在排查任何“空间异常”类问题时第一动作是拉历史曲线找突变点再拿突变点时间去比对当时的会话数、慢语句和告警记录而不是在当前时刻的指标里找答案。坑三把“临时表空间设大一点”当成优化手段。现象是有人建议直接扩容 TEMPSPACE1 来“避免溢出”或者反过来把它改小来“防止膨胀”。原因是对因果关系的方向判断反了这次的问题不是空间不够而是空间太大导致元数据遍历变慢。SMS 临时表空间的容器与页数直接决定了快照和建临时表这两条路径的成本盲目扩容只会让每次遍历更贵。解决方法是先确认是否存在 TDA 文件残留把残留清掉恢复常态再根据真实排序溢出去调SORTHEAP之类的内存参数临时表空间的物理大小不该作为性能调节旋钮。5.2 诊断工具相关的两个坑坑四单次采样看不到 LATCH 争用就判定“没有 LATCH 问题”。现象是db2pd -latches跑一次干干净净于是把 LATCH 这条线索划掉了。原因是这类争用只持续几秒单点采样的命中率很低。解决方法是改用-rep持续采样并且把采样窗口拉到能覆盖业务毛刺的时间段如果还是抓不到就上db2pd -stack多轮抓栈用grep在文件堆里找证据。判断“某个瞬时现象不存在”需要的是采样密度不是采样次数。坑五在生产高峰长时间抓栈把可观测性操作变成了二次故障。现象是抓完栈之后业务反馈更卡了监控上 CPU 和响应时间同时恶化。原因是抓栈会让每个 EDU 在信号处理点停顿-stack all在几百个 EDU 的实例上代价很高。解决方法是把抓栈窗口压到最小比如-rep 3 10这种三十秒量级的窗口、避开高峰、抓够证据就立刻停同时把dumpdir指向容量充足的目录避免栈文件写满分区引发另一类故障。工具本身没问题问题在于把它当成了无成本操作。6. 从 10G 到 0table pool latch 的设计取舍与用 db2trc 钉死因果链把 table pool 的 LATCH 做成全局粒度是一个典型的设计取舍。做细粒度每表空间一把、甚至每容器一把能显著降低并发争用代价是 LATCH 数量随表空间和容器数量线性增长每次查找要先定位到正确的锁实例内存开销和查找路径都变长而表空间元信息变更本身是低频操作绝大多数系统里这把锁的争用压根不可观测。站在引擎设计者的角度选全局一把是合理的——它把复杂度留给了极端场景把简洁和低开销留给了常态。这次踩到的正是那个极端场景一个本应很小、却因为 TDA 文件残留膨胀到 10GB 的临时表空间把低频操作的临界区拉长了几百倍正好撞上高频的建临时表路径。所以真正的修复动作不是在数据库里调什么参数而是把异常状态清掉、恢复到设计假设的前提上。这也是这类问题的通用解法当机制在设计假设内运行时一切正常出问题的往往是某个对象偏离了假设排查的重点应该是“什么让它偏离了”而不是“怎么绕过这个机制”。因果链到这里是靠推理闭合的还能不能实测验证一次可以db2trc提供了把实例“暂停”在指定函数入口的能力让原本一闪而过的现场定格下来# 终端一连接数据库开启跟踪并在目标函数入口挂起实例 db2 CONNECT TO mydb db2trc on -crash DB2.SQLB.sqlbSMSGetContainerPages.entry -suspend # 此时实例在进入该函数时被挂起从容抓取现场信息 db2pd -latches db2pd -stack all dumpdir/tmp/stack_trc # 终端二抓完现场后恢复执行并关闭跟踪 db2trc off-crash表示只跟踪指定入口点相关的事件把开销和 trace 文件体积压到最小-suspend是关键它让实例在命中该入口时停住正好是表空间快照即将遍历容器页、即将持有 pool_table_latch 的那一刻。在这个定格状态下抓-latches能稳定看到 Holder 是谁抓-stack能稳定拿到那条sqlbSnapshotTablespace → sqlbMonSMSGetContainerPages的调用链。相比靠-rep撞运气这是把因果链从“推断”变成“复现”的手段。这条路径我后来固定成了习惯凡是遇到“间歇性、无锁等待、语句莫名变慢”的问题先确认有没有一个高频监控动作在抓表空间或容器级信息再看相关对象的规模是不是偏离了常态。那次之后我每次接手一个新库都会先把 TEMPSPACE1 的 Total pages 和容器数记进基线表并在监控里给临时表空间大小单独加一条曲线——不是因为它重要恰恰是因为它太容易被忽略血泪经验告诉我安静的对象膨胀起来最没有征兆。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
