Oracle临时表空间占满排查：应急恢复与根因优化

别看临时表空间名字里带个临时真要被占满的时候它带来的麻烦一点都不临时。我印象最深的一次是某个结算日的凌晨值班的同学说数据库告警、批量任务全卡住等我连上去看DBA_TEMP_FREE_SPACE里的空闲空间已经只剩几个 GV$TEMPSEG_USAGE上挂着十几个会话每个都在啃几十 G 的临时段。业务侧的表现很有意思——不是连接不上而是原本几秒的报表查询变成几十分钟插入语句报ORA-01652: unable to extend temp segment。这就是临时表空间被占满的典型画像数据库没死但到处都在喘不上气。这篇东西我想把这件事从根上讲透临时表空间在 Oracle 里到底承担什么角色、占用怎么定位到具体会话和 SQL、应急阶段怎么在最小代价下把业务救回来、事后怎么从 SQL 和参数两个层面做根治以及我在实际处理中踩过的那些坑。不管你是刚接手数据库运维的新手还是已经在写复杂 SQL 的开发只要你的系统里有大表关联、批量入库、报表统计这类活儿迟早都会遇到它。1. 先把临时表空间的角色捋清楚1.1 临时表空间不是缓存它是磁盘上的兜底工作台很多人对 temp 的第一误解是把它当成某种缓冲区。其实临时表空间和 undo、redo 一样是实打实的磁盘文件tempfile只不过里面存放的临时段在会话结束或者操作完成后会被回收。它的核心用途只有一个当内存装不下某个操作的中间结果时把这些中间结果落到磁盘。具体哪些操作会产生临时段我按经验从高频到低频列一下ORDER BY排序、GROUP BY聚合、DISTINCT去重、UNION去重注意UNION ALL不会、哈希连接HASH JOIN的构建侧溢出、位图索引的创建与合并、索引创建与重建时的排序、CREATE TABLE AS SELECT、全局临时表的数据存储、以及统计信息收集和逻辑导出时的内部排序。这里要区分一个关键概念临时段分会话级临时段和事务级临时段。会话级临时段的数据在整个会话周期内都有效比如全局临时表ON COMMIT PRESERVE ROWS里的数据事务级临时段在事务提交后就失效典型的例子就是排序。Oracle 官方文档里把这个差别讲得很清楚但实际影响在于——事务级临时段的占用会随着一个长事务里多次排序不断叠加因为它明明已经没用了却因为事务没结束而不能被其他会话复用这也是临时表空间越用越满、但杀了会话就好了的根本原因。注意临时段上的操作几乎不产生 redo只有极少量的字典变更会所以你不能指望从 redo 日志里找回临时段里丢了什么。这既是好事性能也意味着临时段里的数据没有任何恢复价值回收它不会影响数据一致性。1.2 占满有两种一种是空间真没了一种是没法扩展我在排查时习惯先把占满分成两类因为处理路径完全不同。第一类是空间真的用光了。DBA_TEMP_FREE_SPACE显示 free_space 很小新来的排序操作申请不到空间报ORA-01652。第二类其实更隐蔽——表空间里还有空闲 extent但临时文件本身到达了MAXBYTES上限或者所在磁盘满了导致 tempfile 无法 autoextend。这两种情况下应用报的错一模一样但你去看DBA_TEMP_FREE_SPACE结果可能天差地别。还有一种第三类情况值得单独说临时表空间组的成员表空间容量不一致。如果你用了临时表空间组TEMP GROUP默认分配策略是 UNIFORMOracle 会把请求均匀打到各个成员上。这时候如果某个成员的表空间比别的小它会先满而整体看起来还有空间。我遇到过组里两个表空间一个 32G 一个 8G结果 8G 那个天天报错。判断到底属于哪一类一条语句基本够用SELECT TABLESPACE_NAME, TABLESPACE_SIZE/1024/1024 AS TOTAL_MB, ALLOCATED_SPACE/1024/1024 AS ALLOC_MB, FREE_SPACE/1024/1024 AS FREE_MB FROM DBA_TEMP_FREE_SPACE;DBA_TEMP_FREE_SPACE是 10g 之后替代V$TEMP_SPACE_HEADER的视图后者在 12c 之后已经废弃它给出的ALLOCATED_SPACE是当前已经分配给临时段的容量FREE_SPACE是可再分配的容量。我个人的经验阈值是免费空间长期低于总容量 20%就该考虑扩容或优化了如果ALLOCATED_SPACE接近TABLESPACE_SIZE说明已经踩到天花板。1.3 它为什么总在业务高峰被占满临时表空间被占满往往不是持续的而是集中爆发。原因在于临时段是申请-释放模式一个报表 SQL 无论占用 50G 还是 1G跑完就释放。所以你会看到一个奇特的现象——白天一切正常晚上跑批的时候炸。这背后有两个推手。一个是并发度。单个大查询占 10G 不可怕十个同样的查询同时跑就是 100G而临时段的分配很贪心它不会因为还有空闲空间就少申请每个会话都在按自己的执行计划需要去要。另一个是执行计划漂移。同一句 SQL统计信息过期后优化器可能从走索引改成全表扫 哈希连接临时空间需求瞬间翻几倍。我见过最夸张的一句统计 SQL因为一个谓词条件从等值改成了范围执行计划从 INDEX RANGE SCAN 变成 HASH JOIN SORT临时空间从 200M 直接飙到 40G。实操心得如果临时表空间的占用曲线呈现出明显的尖峰形态而不是缓慢爬升那基本可以断定是某几类批量 SQL 或某个并发高峰导致的排查方向应该放在哪个时段、哪些 SQL而不是去查谁忘了提交事务。2. 定位到底是谁在吃临时表空间2.1 三张视图配合使用才能锁到源头定位占用最常用的视图是V$TEMPSEG_USAGE它本质上是V$SORT_USAGE的替代V$SORT_USAGE在 12c 之后已经不推荐使用。这个视图给出的字段不多但够用SESSION_ADDR、SESSION_NUM、SERIAL#、SQLADDR、SQLHASH、TABLESPACE、SEGTYPE、SEGFILE#、SEGBLK#、BLOCKS。注意这里的BLOCKS是块数乘上DB_BLOCK_SIZE才是实际占用。我见过有人直接报某会话占用 400 万其实是 400 万块换算下来 30G 左右。搞清楚单位能少开很多无效会。一条我常用的组合查询直接定位到会话和 SQLSELECT s.SID, s.SERIAL#, s.USERNAME, s.PROGRAM, s.MACHINE, s.STATUS, u.TABLESPACE, u.SEGTYPE, u.BLOCKS * (SELECT VALUE FROM V$PARAMETER WHERE NAMEdb_block_size)/1024/1024/1024 AS GB, q.SQL_ID, q.PLAN_HASH_VALUE, SUBSTR(q.SQL_TEXT,1,120) AS SQL_SNIPPET FROM V$TEMPSEG_USAGE u JOIN V$SESSION s ON s.SADDR u.SESSION_ADDR LEFT JOIN V$SQL q ON q.SQL_ID s.SQL_ID ORDER BY u.BLOCKS DESC;几个字段的实际意义SEGTYPE能告诉你这临时段是干什么的——SORT是排序DATA通常对应全局临时表或索引创建HASH是哈希连接溢出LOB_DATA是 LOB 的临时存储。看到大量HASH八成是某个大表关联的哈希连接在建构建侧看到DATA集中在少数会话上多半是全局临时表被当普通表用了。PLAN_HASH_VALUE我特意留在查询里因为同一个SQL_ID可能有多个执行计划如果同一句 SQL 的临时占用忽大忽小对比计划哈希值往往是突破口。2.2 空间被占满了但视图里一个会话都没有这是最容易让人慌神的场景告警说临时表空间满了你查V$TEMPSEG_USAGE却是空的。原因通常有这几类我按遇到频率排序。第一类是SMON 还没清理完。会话被 kill 或者异常断开之后它占用的临时段要由 SMON 异步回收这个过程有延迟几秒到几分钟都有可能。如果连上去的时候刚刚 kill 过会话稍等一会儿再看通常就正常了。判断方法是看V$SORT_SEGMENT里的FREE_REQUESTS如果它一直是 0 而空间还在被占说明没有新的申请在排队正在等回收。第二类是多实例共享同一个临时表空间。RAC 环境下V$TEMPSEG_USAGE只反映当前实例另一个实例上的会话在上面查出来是看不到的。这种情况要查GV$TEMPSEG_USAGE。我第一次在 RAC 上遇到时愣了十几分钟后来才想起来要加 G。第三类是临时表空间里有残留的碎片。临时表空间是本地管理LOCALLY MANAGED的正常情况下会自动管理 extent但在极少数版本上如果 session 非正常终止而 SMON 又没处理干净会留下无法回收的段。这时候DBA_TEMP_FREE_SPACE显示占用很高但找不到持有者通常只能重建临时表空间。第四类是临时文件被外部进程占用。比如 OFS 或者某些备份工具打开了 tempfile 还没释放从数据库内部看就是空间没回来。注意查不到占用会话时不要急着杀会话或重建表空间。先确认是不是 RAC 跨实例、是不是刚做过 kill、是不是 SMON 还没刷完。我见过有人上来就重建临时表空间结果把正在跑批的任务全部打断复盘时发现只是 SMON 晚了几分钟。2.3 从 SQL 文本和计划里读出为什么这么费空间定位到 SQL_ID 只是第一步。真正要解决得看它的执行计划为什么需要这么多临时空间。方法很简单SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(sql_id, NULL, ALLSTATS LAST));重点看三处。第一处是执行计划里的TEMP TABLE TRANSFORMATION、SORT ORDER BY、HASH JOIN、SORT UNIQUE这些算子它们就是临时空间的消费者。第二处是A-Rows和Buffers的对比如果某个哈希连接的A-Rows是几百万行那它的构建侧肯定要溢出到临时表空间。第三处是PDBLK或者显示的临时空间统计有些版本的DBMS_XPLAN会直接在计划里标出每一步的临时空间使用量。我一般的判断逻辑是如果大临时空间来自HASH JOIN优化方向是把驱动表变小、把连接条件上的索引补起来、或者调大 PGA 让哈希表能留在内存里如果来自SORT ORDER BY方向是看能不能用索引避免排序或者缩小参与排序的行数如果来自SORT UNIQUE去重那就考虑UNION改UNION ALL、DISTINCT改成GROUP BY加过滤、或者干脆改成EXISTS语义。3. 应急先让业务恢复再考虑优雅3.1 扩容还是杀会话取决于这是持续需求还是异常占用应急阶段最容易做错的决定就是在没搞清楚状况的时候直接扩临时表空间。扩容确实最快一条命令就行ALTER TABLESPACE TEMP ADD TEMPFILE /u01/oradata/temp02.dbf SIZE 10G AUTOEXTEND ON NEXT 1G MAXSIZE 32G;但如果你扩了 30G过两天又满了说明问题不在容量而在用法。我见过最典型的一例临时表空间从 32G 扩到 128G一周后照样满最后查出来是一个全局临时表ON COMMIT PRESERVE ROWS的会话开完不关连接池又复用这些连接数据越堆越多。这种情况下扩容只是延缓事故。判断依据其实很简单看占用是不是集中在少数几个会话上且这些会话的 SQL 是否合理。如果是一句统计报表的 SQL 占了 50G而它本来就该占这么多那是容量规划问题扩容合理。如果是 20 个会话各占 2G 但都是同一句跑了很久的批量 SQL 在并发那要考虑限制并发。如果是某个会话占了 80G 而它的 SQL 平淡无奇那大概率是计划漂移杀了以后重新收集统计信息更划算。真要杀会话命令是ALTER SYSTEM KILL SESSION sid,serial# IMMEDIATE;IMMEDIATE这个关键字很关键。不加它Oracle 只是标记会话为 killed等它自己发现再退出可能等到天荒地老加了它会话会被立刻中断、事务回滚。代价是回滚本身可能很耗时——如果这个会话正在做大量 DML回滚时间可能比它已经跑的时间还长。所以在杀之前看一眼会话的STATE和LAST_CALL_ET如果它正在COMMIT或者已经跑了很多小时杀掉之前要想清楚回滚成本。实操心得杀会话前先记下SQL_ID和PLAN_HASH_VALUE这是事后复盘的唯一线索。我有一次急急忙忙杀掉会话事后想追查为什么它会占 40G结果会话一断V$SQL里的执行计划还在但SQL_ID没记只能从 AWR 里翻多花了半小时。3.2 临时表空间快照式重建能解决大部分顽固占用当临时表空间里存在无法回收的残留段或者你想调整表空间大小、把临时文件挪个位置重建是最干净的办法。但这里有个坑默认临时表空间不能直接 drop。正确顺序是新建一个、切换默认、再删旧的-- 1. 建一个新的临时表空间用 bigfile 还是 smallfile 看现有规划 CREATE TEMPORARY TABLESPACE TEMP_NEW TEMPFILE /u01/oradata/temp_new01.dbf SIZE 20G AUTOEXTEND ON NEXT 2G MAXSIZE 64G EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1M; -- 2. 切换数据库默认临时表空间 ALTER DATABASE DEFAULT TEMPORARY TABLESPACE TEMP_NEW; -- 3. 把用户级的临时表空间也切过去如果有 -- 先把现有的查出来 SELECT USERNAME, TEMPORARY_TABLESPACE FROM DBA_USERS WHERE TEMPORARY_TABLESPACE TEMP; -- 然后逐个 ALTER USER xxx TEMPORARY TABLESPACE TEMP_NEW; -- 4. 等旧表空间上的会话全部退出后再删除 DROP TABLESPACE TEMP INCLUDING CONTENTS AND DATAFILES;第 4 步是真正的难点。只要还有任何一个会话在旧表空间上有临时段DROP就会报ORA-12952: The request exceeds the maximum allowed database size或者ORA-14404之类的错误。这时要看V$SESSION里有没有还挂着旧临时表空间的会话通常是长连接池里的会话。稳妥做法是先切换默认然后让应用侧连接池重启一轮或者从数据库侧对应用账号做一次ALTER SYSTEM DISCONNECT SESSION。这一步我在生产上从来不敢图快一般会挑一个业务低峰并且提前和应用侧对齐会有一次重连。3.3 临时表空间组多实例和多租户下的稳妥选择如果你的环境是 RAC 或者需要给不同业务分配不同的临时空间我一般推荐用临时表空间组而不是单个表空间ALTER TABLESPACE TEMP_NEW TABLESPACE GROUP TEMPGRP; ALTER TABLESPACE TEMP_OLD TABLESPACE GROUP TEMPGRP; ALTER DATABASE DEFAULT TEMPORARY TABLESPACE TEMPGRP;组的好处是按 UNIFORM 分配各个成员均摊负载。但它有个必须留意的前提组内各成员容量要接近。前面提过容量不均会导致小块先满而整体看起来还行。所以用组的时候我会定期跑一次检查看各成员的TABLESPACE_SIZE差异是否超过 20%。4. 根因拆解五类最典型的吃 temp 大户4.1 大表排序与哈希连接最常见的两类排序和哈希连接是临时空间的两大主力。区别在于排序的需求量约等于参与排序的行数乘以每行平均长度含排序键和需要带回的列哈希连接的需求量约等于构建侧通常是较小的那张表过滤后的实际行数乘以行宽。举个例子一张 5000 万行的订单表和一个 200 万行的客户表做关联如果用哈希连接构建侧是客户表200 万行 × 每行 300 字节 ≈ 600MB这在 PGA 里放得下就没问题。但如果优化器选错了构建侧拿订单表当构建侧那就是 5000 万 × 300 字节 ≈ 15GB必然溢出到 temp。这类问题的优化思路有三条一是让连接条件用上索引避免走哈希二是如果必须哈希确保构建侧是小表可以通过加提示/* LEADING(小表) USE_HASH(大表) */或者收集准确的统计信息来引导三是调整 PGA但这有个前提——PGA 内存在操作系统层面是预留的不能无脑调大。我做过一个粗略的估算公式用于判断该不该调 PGA如果单会话临时占用经常在峰值时超过PGA_AGGREGATE_TARGET × 20%说明 PGA 不够分了可以试着调大PGA_AGGREGATE_TARGET但一定要同步关注V$PGASTAT里的over allocation count如果这个值在持续增长说明 PGA 内部已经在超配调大总量才有意义。4.2 索引创建与在线 DDL容易被忽略的短时高峰CREATE INDEX和ALTER INDEX REBUILD在排序阶段会占用临时段而且这个占用很陡——它不像报表 SQL 那样慢慢爬升而是一开始就申请一大块。如果是REBUILD ONLINE还要额外的临时空间来存放变更日志。这类操作的坑在于它常常在业务时间执行。我见过运维在上午十点给一张 8000 万行的表加索引结果临时表空间瞬间被吃掉一半同时段的报表全部超时。正确的做法是把这类 DDL 放到窗口期并且提前估算所需空间排序所需空间大致等于索引键列的总长度 × 行数 × 1.2排序过程的额外开销。另一个隐蔽的点是并行度。如果你用PARALLEL 8建索引每个并行从属进程都会各自申请临时段总占用可能是单进程的 8 倍。所以调高并行度不只是加速也是在扩大临时空间需求。4.3 全局临时表从临时变成常驻的典型误用全局临时表GTT的设计初衷是给会话存点中间数据但我在实际项目里见过太多把它当普通表用的场景。尤其是ON COMMIT PRESERVE ROWS这种定义数据在事务提交后还留着只有会话断开才清。而如果应用用的是连接池连接长期不释放这些数据就越堆越多最终把 temp 撑爆。判断方法很直接在V$TEMPSEG_USAGE里看SEGTYPE为DATA的占用然后去DBA_TABLES里查这个表是不是TEMPORARY类型SELECT TABLE_NAME, TEMPORARY, DURATION, OWNER FROM DBA_TABLES WHERE TEMPORARY Y AND OWNER NOT IN (SYS,SYSTEM);DURATION字段是关键——SYS$SESSION表示数据保留到会话结束SYS$TRANSACTION表示事务提交即清。如果你发现某个 GTT 是SYS$SESSION且占用巨大改造成SYS$TRANSACTION或者在使用后主动TRUNCATE往往能立竿见影。注意DURATION可以在不重建表的情况下改ALTER TABLE xxx MODIFY ...不支持直接改 DURATION通常需要重建表或者通过ON COMMIT DELETE ROWS的语义调整。实际改造前务必确认应用逻辑有的业务确实依赖跨事务保留数据。4.4 游标不关、连接池配置不当带来的累积效应这类问题最温水煮青蛙。表现是临时表空间占用缓慢上升一段时间后达到临界值。根因往往在应用侧连接池的最大连接数设置得很小比如 20但同时并发很高导致每个连接被反复复用而每次复用时前面会话的临时段还没来得及被 SMON 回收被新请求复用后继续申请。另一个常见来源是OPEN CURSOR超过OPEN_CURSORS参数有些框架在异常分支里漏了close游标长期挂着它的排序区也就一直不释放。排查这类问题我会看V$SESSTAT里session cursor cache hits和opened cursors current的比值如果opened cursors current长期接近OPEN_CURSORS那基本能确认是游标泄漏方向转到应用侧修代码比在数据库侧调参数有效得多。4.5 统计信息收集与逻辑导出夜间的隐形杀手DBMS_STATS收集统计信息时如果启用了ESTIMATE_PERCENT DBMS_STATS.AUTO_SAMPLE_SIZE之外的策略或者对分区表做全局统计会在内部做大量排序和聚合占用临时空间。而这类任务通常在凌晨跑和跑批任务撞车。逻辑导出expdp如果带QUERY参数或者导出过程涉及排序也会消耗 temp。我在一次夜间故障里发现expdp的一个导出任务占了 30G 临时空间而它在文档里几乎不会提到这件事因为它是由内部的排序操作间接引起的。针对这两类我的建议是错峰统计信息收集和逻辑导出不要和核心跑批挤在同一个时间窗。另外对分区表可以按分区收集把单次所需的排序规模降下来。5. 参数与容量从救火转向可控5.1 PGA 与 temp 不是孤立的两件事很多人调优临时表空间只盯着 temp 本身实际上它的上游是 PGA。Oracle 在自动 PGA 管理PGA_AGGREGATE_TARGET下会把排序、哈希这类工作区尽量放在 PGA 内存里只有当单个工作区超过_SORT_AREA_SIZE的上限或者 PGA 总量吃紧时才会溢出到临时表空间。所以一个很实际的判断逻辑是如果V$PGASTAT里的cache hit percentage长期低于 80%说明大量操作已经溢出到磁盘此时调大PGA_AGGREGATE_TARGET往往比扩临时表空间更治本。反过来如果cache hit percentage已经在 95% 以上但临时空间还是被占满那说明这些操作的规模本身就超出了任何合理内存扩 temp 才是对的。我这里放一张对照表是我在实际排查时常用的决策依据现象更可能的根因优先动作temp 占用尖峰cache hit%低于 80%PGA 不足导致溢出调大PGA_AGGREGATE_TARGETtemp 占用尖峰cache hit%高于 95%单次操作规模过大优化 SQL 或扩 temptemp 占用缓慢爬升不下降GTT 或游标泄漏查V$TEMPSEG_USAGE的SEGTYPE只有部分时段满并发批处理撞车调度错峰扩了 temp 仍反复满执行计划漂移或容量规划错查 AWR 找 TOP SQL用表格对照能省不少来回试的时间。我自己的习惯是每次处理完一个临时表空间问题都把这几个指标记一笔时间长了就能对自家系统的正常水位心里有数。5.2 临时表空间容量怎么估才靠谱估算容量最可靠的办法不是算而是看历史峰值。做法是从 AWR 里取Temporary Space Usage这一段看过去一个月每天的峰值占用取 95 分位数再乘 1.5 倍作为规划容量。原因是临时空间的占用是并发的、非累加的简单按最大单条 SQL × 并发数算出来往往偏大很多导致浪费。如果你想自己算一个粗略的参考是单个大查询的排序空间 ≈ 返回行数 × 行宽 × 1.2哈希连接的构建侧空间 ≈ 构建侧过滤后行数 × 行宽 × 1.3。然后把所有可能并发的重型操作加起来再乘以一个 0.6 左右的折减系数因为实际很少有所有重操作同时到达峰值。但我要强调的是这个算法只适合做初始规划。真正的容量一定是观察出来的AWR 是最可靠的数据源。5.3 监控怎么落地我给临时表空间配的告警是两条线一条是DBA_TEMP_FREE_SPACE里的FREE_SPACE / TABLESPACE_SIZE 20%触发预警另一条是出现ORA-01652直接告警。第二条实际上是被动的但很多问题第一次暴露就是靠它。更进一步的做法是采集V$TEMPSEG_USAGE的快照做 TOP 会话的历史记录。我用一个简单的 PL/SQL 定时任务每 5 分钟记一次占用超过 1G 的会话落到一张监控表里。这样出问题时能直接看过去 24 小时内占用最多的会话排前 20比事后翻 AWR 快得多而且能看到杀掉的那一瞬间还剩下什么。6. 常见问题速查与踩坑记录这一节我按实际被问到最多的顺序整理附上我的处理做法。问题表现排查方向处理动作ORA-01652但V$TEMPSEG_USAGE为空SMON 正在回收等 5-10 分钟再查一次视图为空但空间确实被占RAC 跨实例查GV$TEMPSEG_USAGE杀了会话空间没回来事务回滚尚未完成查V$TRANSACTION和V$SESSION.STATUS同一个SQL_ID占用忽大忽小执行计划漂移对比PLAN_HASH_VALUE重新收集统计信息某个 8G 的临时表空间总是先满临时表空间组成员容量不均调整成员容量或拆分表空间组白天正常夜间炸跑批任务并发或规模过大查 AWR 的 TOP SQL 和时段错峰调度扩容后一周又满使用模式问题而非容量问题查 GTT、游标、计划漂移再说几条我认为最有价值的避坑经验都是花过代价换来的。第一条不要在业务高峰做ALTER TABLESPACE TEMP相关的 DDL。哪怕是看起来无风险的ADD TEMPFILE在某些版本上会有短暂的字典锁我遇到过在高峰加 tempfile 导致几秒钟内所有需要新临时段的操作排队。第二条重建临时表空间之前先把当前默认临时表空间上挂着的用户全查一遍。DBA_USERS里的TEMPORARY_TABLESPACE字段不只是数据库默认很多应用账号会被显式指定到某个临时表空间切默认不会影响这些账号。这一点如果漏了重建之后你会发现有些会话还在旧表空间上跑DROP永远失败。第三条对KILL SESSION要有敬畏。杀掉一个跑了 4 小时的会话回滚可能要跑 2 小时在这期间业务可能一直在报错。所以能等就等尤其是当事务量大且涉及大量 DML 的时候。判断标准是看V$SESSION.USED_UBLK这个值反映了回滚需要处理的 undo 块数数值很大就说明回滚代价高。第四条AWR 里的临时空间数据要单独留档。AWR 默认保留 8 天很多临时空间问题一个月才复发一次等你回头查的时候数据早没了。我会把每周的Temporary Space Usage段导出存下来这个习惯帮我抓到过一次每月的第一个工作日必然报错的规律最后定位是月度结算批处理的并发没控制好。第五条临时表空间的文件放在什么存储上很关键。它写的是临时性数据但压力一点不小——高峰期它的 IO 可能是最忙的。如果它和在线日志或者数据文件挤在同一块盘上会互相拖累。有条件的把它单独放到一个存储池效果比调参数更直接。最后说一个我最近才想明白的点。临时表空间被占满这件事很多时候被当成一个空间问题去处理但它本质上是一个工作负载问题。你扩多大的空间都只是把临界点往后推真正让它不再反复的是搞清楚自家系统里哪几类操作在吃临时空间、它们在什么时段并发、执行计划是否稳定。这三件事摸清了临时表空间的问题基本就变成可预期的了——你会提前知道什么时候该扩容什么时候该拦下某个 SQL什么时候该去查应用侧游标。我现在接手一个新系统第一件事就是把过去一个月的V$TEMPSEG_USAGE历史拉出来看看 TOP 10比读任何文档都直观。