Oracle 19c PDB SYSAUX膨胀清理与ORA-65040避坑

接手一套多租户环境之后最容易让人半夜爬起来处理的告警往往不是业务库连不上而是某个 PDB 的 SYSAUX 表空间使用率突然从 40% 跳到 85%。业务侧一切正常监控侧却在反复告警登录进去一查V$SYSAUX_OCCUPANTS里排第一的是SM/ADVISOR再往下的段级排序里WRI$_ADV_OBJECTS赫然在列。这个表是SQL Tuning Advisor 和自动 SQL 调优保存顾问对象元数据的地方属于 Oracle 19c 多租户架构下 SYSAUX 膨胀最常见的来源之一单行不一定大但架不住几十万行地堆。更麻烦的是很多人在 PDB 里照着 root 的脚本敲命令第一条就撞上ORA-65040: operation not allowed from within a pluggable database然后开始怀疑权限、怀疑账号、怀疑人生。这篇内容面向的是已经在维护 19c 多租户库、能独立登录 PDB 做维护操作的 DBA也适合刚接手 CDB/PDB 架构、需要快速补上SYSAUX 里哪些东西能删、怎么删、删完怎么把空间要回来这块认知的同学。我会把定位路径、ORA-65040 的真正成因、按任务粒度回收的官方做法、残留行的受控清理、物理空间回收以及如何压住再增长一条链路讲完整给出可以直接抄走的 SQL 和判断标准。1. 先确认空间去哪儿了SYSAUX 占用拆解的正确顺序1.1 V$SYSAUX_OCCUPANTS 只是第一层别停在它上面很多人查到这里就结束了看到SM/ADVISOR占了几十个 GB直接开始找删除脚本。这个视图给的是按功能组件聚合的统计它能告诉你哪个模块在吃空间但不能告诉你具体是哪个段、哪张表、哪个 LOB。更关键的是V$SYSAUX_OCCUPANTS里的SPACE_USAGE_KBYTES反映的是该组件相关段的总和其中可能混着索引、LOB 段、分区甚至一些你根本没打算动的历史数据。所以在 PDB 里执行下面这条语句拿到排序之后下一步必须继续往段级走否则很容易删错东西。SELECT occupant_name, occupant_desc, ROUND(space_usage_kbytes / 1024, 2) AS mb FROM v$sysaux_occupants ORDER BY space_usage_kbytes DESC;在 19c 的 PDB 中查询这个视图返回的是当前容器的占用情况也就是说你连到哪个 PDB看到的就是哪个 PDB 的数据这一点在多租户下非常重要。经常出现的误判是在 root 里查了一遍发现占用不高就以为整个库没问题实际上某个业务 PDB 的 SYSAUX 已经快满了。反过来也有人在 PDB 里查到SM/ADVISOR很高却跑到 root 去删任务结果一条都没删掉——因为 root 的WRI$_ADV_*里根本没有那些行。顺带提一句这个视图还有一列MOVE_PROCEDURE它给出的是该组件历史数据的搬迁过程有些组件比如 AWR、统计信息历史支持用官方过程把数据搬到别的表空间。对于SM/ADVISOR这一列通常指向一个顾问历史数据搬迁过程可用性视版本而定实际动手前建议先用SELECT * FROM v$sysaux_occupants WHERE occupant_nameSM/ADVISOR;看清楚当前实例返回了什么不要照抄别人环境里的过程名。1.2 段级定位从 DBA_SEGMENTS 到 WRI$_ADV_OBJECTS 的 LOB 段段级排序是最直接的一步。注意DBA_SEGMENTS里的段大小是分配给该段的空间不是实际数据量删除行之后它不会立刻变小这也是后面必须做空间回收的原因。SELECT owner, segment_name, segment_type, ROUND(bytes / 1024 / 1024, 2) AS mb FROM dba_segments WHERE tablespace_name SYSAUX ORDER BY bytes DESC FETCH FIRST 30 ROWS ONLY;跑完这条正常会看到WRI$_ADV_OBJECTS本体、它对应的 LOB 段段名形如SYS_LOB开头加一串数字、以及若干WRI$_ADV_*的索引。真正的大头常常不是表本身而是 LOB 段——顾问对象里保存的执行计划、建议明细、SQL 文本这些内容都放在大字段里几十万行累积下来LOB 段涨到表本体的好几倍是常态。所以不要看到表只有 3 GB 就觉得问题不大往下一看 LOB 段 40 GB 的情况我见过不止一次。确认 LOB 段归属哪张表、哪一列用DBA_LOBS最稳SELECT table_name, column_name, segment_name, index_name FROM dba_lobs WHERE table_name LIKE WRI$_ADV% ORDER BY table_name, column_name;这条语句的价值在于后面做空间回收时你需要知道到底该 shrink 哪一列而不是笼统地对整张表执行SHRINK SPACE CASCADE然后等半小时。另外如果 LOB 段的名字在DBA_SEGMENTS里排得很靠前但DBA_LOBS里查不到对应记录那就要怀疑是不是有已经 drop 掉的对象留下了未回收的段这种情况需要单独排查不在本篇的常规处理路径里。1.3 判断是自动任务堆积还是手动任务没人清定位到表之后接下来要回答的问题是这些行是谁产生的。WRI$_ADV_OBJECTS里的数据来源大致分两类一类是自动 SQL 调优任务任务名通常是SYS_AUTO_SQL_TUNING_TASK每次执行产生的记录另一类是人工或业务侧调用DBMS_SQLTUNE创建的调优任务留下的记录。两者的清理方式完全不同前者靠保留期参数自动过期后者要靠DROP_TUNING_TASK主动删。先看对象类型分布和行数规模SELECT object_type, COUNT(*) AS cnt FROM wri$_adv_objects GROUP BY object_type ORDER BY cnt DESC;再看任务层面的分布把行数和任务挂上钩SELECT t.task_name, COUNT(o.id) AS obj_cnt, MIN(t.created) AS first_created, MAX(t.created) AS last_created FROM wri$_adv_tasks t LEFT JOIN wri$_adv_objects o ON o.task_id t.task_id GROUP BY t.task_name ORDER BY obj_cnt DESC FETCH FIRST 20 ROWS ONLY;如果排在前面的全是SYS_AUTO_SQL_TUNING_TASK说明是自动任务的执行记录在堆重点应该放在过期参数是否生效上而不是急着删数据。如果排前面的是各种业务命名的手动任务比如按日期命名的临时调优任务那就是典型的人走了任务还在用DROP_TUNING_TASK批量清掉即可。还有一种混合情况自动任务的记录占大头但里面有相当比例的行其TASK_ID在WRI$_ADV_TASKS里已经找不到对应父记录这就是所谓的孤儿行通常是历史清理过程中断留下的需要走受控删除路径。2. ORA-65040 的真实含义不是权限问题是容器层级错位2.1 三种最常见的触发路径ORA-65040: operation not allowed from within a pluggable database这个报错的字面意思非常明确这个操作不允许在 PDB 内部执行。它和ORA-01031: insufficient privileges完全是两回事后者是权限不够前者是位置不对——你手里的账号权限再大站在 PDB 里也执行不了只能在根容器做的事。清理WRI$_ADV_OBJECTS的过程中这条错误基本集中在三个场景。第一种在 PDB 里修改自动 SQL 调优任务的参数。自动调优任务定义在根容器它的保留期、时间限制这些参数属于容器级配置在 PDB 内调用相关设置过程就会被挡回来。这是最常见的一种因为网上大量脚本是直接在 PDB 里执行参数修改的复制过来就报错。第二种脚本里混进了实例级语句。有些从单实例时代流传下来的清理脚本开头会带一句ALTER SYSTEM CHECKPOINT或者日志切换之类的语句用来让数据落盘。这些语句在 PDB 里执行必然报 ORA-65040。这类问题最好排查因为报错位置很靠前一眼就能看到。第三种跨容器删除对象。任务定义在根容器但执行产物落在 PDB你在 PDB 里试图用删除过程把这个任务整体干掉容器边界不匹配同样会撞上 ORA-65040。这种情况最容易被误判成这个任务删不掉然后转而去直接 DELETE 内部表反而把问题搞复杂。2.2 怎么确认自己站在哪个容器里排查这类问题的第一步永远是确认当前会话所在容器别凭连接串猜。最直接的两条SELECT SYS_CONTEXT(USERENV, CON_NAME) AS cur_container, SYS_CONTEXT(USERENV, DB_NAME) AS db_name FROM dual;用 SQL*Plus 的话SHOW CON_NAME更省事。这里有个细节值得强调连接串里写的是 PDB 的服务名那CON_NAME就是 PDB如果写的是根容器的服务名CON_NAME就是CDB$ROOT。有些人用同一个通用账号连库以为自己在 PDB 里操作实际连的是根容器于是出现我在 PDB 里查不到这张表的数据这种自相矛盾的现象——不是数据没了是根本没连对地方。确认完当前容器还不够还要确认目标任务属于哪个容器。在根容器里可以用带CON_ID的 CDB 级顾问视图跨容器看SELECT con_id, task_name, advisor_name, status, created FROM cdb_advisor_tasks WHERE advisor_name SQL Tuning Advisor ORDER BY con_id, created DESC;这条语句能一次性看清各个 PDB 里分别有哪些调优任务对于判断到底该去哪个容器动手非常有用。如果你在 PDB 里用DBA_ADVISOR_TASKS查不到任何任务但WRI$_ADV_OBJECTS里明明有几十万行那基本可以断定这些是父任务已经被删掉的孤儿数据处理方式要切换到受控删除路径。2.3 把命令放回正确的容器执行定位清楚之后处理动作本身反而简单参数类的操作回根容器任务级的删除留在任务所在容器。修改自动调优任务保留期的语句必须在根容器执行切换容器有两种方式一种是用根容器的服务名重新建立连接另一种是在具备公共用户权限的前提下用ALTER SESSION SET CONTAINER切换。后者在脚本里更灵活但要注意切换之后当前会话的默认 schema 和权限上下文都会变脚本里最好显式带上 schema 前缀。-- 在根容器执行 ALTER SESSION SET CONTAINER CDB$ROOT; BEGIN DBMS_AUTO_SQLTUNE.SET_AUTO_TUNING_TASK_PARAMETER( parameter EXECUTION_DAYS_TO_EXPIRE, value 15); END; /这里有个实操心得执行完参数修改之后别急着回 PDB 继续删数据先在根容器确认参数确实写进去了。查看方式是从顾问参数视图里读SELECT parameter_name, parameter_value FROM dba_advisor_parameters WHERE task_name SYS_AUTO_SQL_TUNING_TASK AND parameter_name IN (EXECUTION_DAYS_TO_EXPIRE, TIME_LIMIT);参数生效不是立竿见影的自动清理发生在后续的自动任务执行周期里指望改完参数马上看到表变小是不现实的。我的习惯是改完参数、记下当时的行数隔一个维护窗口再对比一次用数据说话。如果行数完全不降那说明过期机制在这个环境里没起作用需要往受控清理的方向走。3. 走官方路径用 DBMS_SQLTUNE.DROP_TUNING_TASK 按任务粒度回收3.1 先摸清任务和执行记录的分布在动任何一行数据之前把要删什么列清楚。19c 里一个调优任务可以有多次执行记录WRI$_ADV_OBJECTS里的行是按执行维度挂上去的所以清理粒度应该是任务 执行而不是笼统地按任务删。查询待清理候选的语句如下时间阈值根据实际情况调整我一般先用 30 天做一次试算确认数量级合理再动手。SELECT t.task_name, e.execution_name, e.execution_start, e.execution_end, t.status FROM dba_advisor_tasks t JOIN dba_advisor_executions e ON e.task_id t.task_id WHERE t.advisor_name SQL Tuning Advisor AND e.execution_end SYSDATE - 30 ORDER BY e.execution_end;跑完这条先看两个数字总行数以及最早和最晚的执行时间跨度。如果跨度只有几天但行数巨大说明某次执行产生了异常多的对象这种情况要先看看那次执行是不是扫了特别大的 SQL 集合盲目删掉只是治标。如果跨度覆盖了半年以上那就是典型的保留策略失效按时间从旧到新分批删即可。3.2 批量生成 DROP 语句并控制节奏手工一条条敲DROP_TUNING_TASK不现实用 SQL 生成语句是常规操作。生成的时候要注意引号转义任务名里带特殊字符的情况虽然少见但确实存在。SELECT EXEC DBMS_SQLTUNE.DROP_TUNING_TASK(task_name || t.task_name || , execution_name || e.execution_name || ); AS cmd FROM dba_advisor_tasks t JOIN dba_advisor_executions e ON e.task_id t.task_id WHERE t.advisor_name SQL Tuning Advisor AND e.execution_end SYSDATE - 30 ORDER BY e.execution_end;把输出落到一个文本文件里先抽十条在测试 PDB 上跑一遍确认没有报错再全量执行。这个步骤看起来啰嗦但删任务是不可逆操作跑错一次就得从备份恢复代价远大于多花十分钟验证。执行节奏上有两个建议。一是分批次跑每批 50 到 100 个任务中间留几十秒间隔避免瞬间对数据字典造成过大压力。二是把输出重定向到日志文件跑完之后统计一下成功和失败的数量。失败的那些单独拎出来看报错如果是 ORA-65040说明任务归属容器判断错了如果是任务不存在说明并发有其他清理动作忽略即可。这里要提醒一句DROP_TUNING_TASK删除的是任务及其关联的顾问对象它不会立刻释放物理空间表的高水位线还在原地所以删完之后表大小看起来没变是正常的不要以为没删掉。3.3 自动任务的执行记录为什么不能硬删对于SYS_AUTO_SQL_TUNING_TASK这类自动任务情况要复杂一些。它的任务定义在根容器执行产物分布在各个 PDBPDB 侧只是持有执行记录。你在 PDB 里对这个任务名调用删除过程一部分版本上会直接抛 ORA-65040另一部分版本上会返回任务不存在或者干脆静默跳过行为不太一致。正确的处理思路是让自动机制自己清也就是前面说的保留期参数而不是去硬删自动任务本身。自动任务被删掉之后下次自动维护窗口又会重新创建删了等于没删还可能留下不一致的状态。如果保留期参数调整之后观察了两三个维护窗口仍然不降那说明遇到了过期逻辑没有覆盖到的情况这时候才考虑受控删除残留数据而且要在有完整备份的前提下做。还有一点容易被忽略自动任务的执行记录里WRI$_ADV_OBJECTS只占一部分WRI$_ADV_TASKS、WRI$_ADV_ACTIONS、WRI$_ADV_RECOMMENDATIONS这些表也有对应增长。清理的时候如果只盯着WRI$_ADV_OBJECTS可能出现主表删了、子表留着的情况虽然不一定立刻报错但数据一致性已经被破坏了。所以要么完整走删除过程要么在受控删除时严格按依赖顺序处理不能挑着删。4. 残留行清理什么情况下才允许碰内部表4.1 清理前的三道保险直接对SYS下的内部表做 DML属于官方过程解决不了时的兜底手段前提是你在做之前已经把退路铺好了。我一般要求三道保险齐了才动手。第一道是备份。最稳妥的是对目标 PDB 做一次完整的 RMAN 备份如果备份窗口紧张至少要把待删数据的标识范围记录下来——把要删的 ID 或 ROWID 落到一张普通表里这张表不要建在 SYSAUX 表空间否则一边删一边涨等于白忙。建议放在专门的维护表空间或者 USERS 里。第二道是数量基线。删除前记录三个数字目标表的当前行数、待删行数、删除后预期剩余行数。这三个数字在删除过程中要反复比对一旦实际删除行数和预期偏差超过 5%立刻停下来查原因。第三道是回滚预案。把删除语句写成可重复执行的幂等形式也就是按主键或 ROWID 精确删除而不是按时间范围模糊删除。这样万一中途中断重新跑一遍不会误伤。同时确认 UNDO 表空间有足够余量大批量删除产生的 UNDO 量经常被低估删到一半报ORA-30036是很常见的事故。4.2 按依赖顺序分批删除如果确认要走受控删除顺序必须是从子到父。顾问相关的表之间通过任务 ID 关联先删对象表再删任务表是安全的反过来就可能因为外键约束失败或者留下悬空引用。一个务实的做法是先把要删的任务 ID 收进一张临时表后续所有删除都基于这张临时表做关联避免每次都重新计算条件。-- 把待清理的任务 ID 固化到维护表非 SYSAUX 表空间 CREATE TABLE maint_adv_task_ids TABLESPACE users AS SELECT task_id FROM wri$_adv_tasks WHERE task_name LIKE TASK_2024% AND created SYSDATE - 60;固化之后删除动作按批进行。每批控制在 5000 行左右每批提交一次这样 UNDO 压力可控中断之后也能从断点继续。下面这段 PL/SQL 是分批删的骨架用ROWID定位比用主键更高效因为内部表不一定有合适的主键索引。DECLARE v_rows NUMBER : 1; BEGIN WHILE v_rows 0 LOOP DELETE FROM sys.wri$_adv_objects WHERE rowid IN ( SELECT rid FROM ( SELECT rowid rid FROM sys.wri$_adv_objects WHERE task_id IN (SELECT task_id FROM maint_adv_task_ids) AND rownum 5000 ) ); v_rows : SQL%ROWCOUNT; COMMIT; DBMS_LOCK.SLEEP(1); END LOOP; END; /DBMS_LOCK.SLEEP(1)这一秒不是摆设它给了日志写和检查点一点喘息时间在高负载库上能明显降低对业务的影响。对象表清完之后再按同样的方式处理动作表、建议表、任务表顺序不要颠倒。4.3 删完之后必须做的校验删完不等于结束至少要做三项校验。第一项是行数核对把实际剩余行数和预期的剩余行数比一遍差值应该为零或极小。第二项是一致性检查确认没有孤立的子表记录指向已经删除的任务SELECT COUNT(*) AS orphan_cnt FROM wri$_adv_objects o WHERE NOT EXISTS (SELECT 1 FROM wri$_adv_tasks t WHERE t.task_id o.task_id);这个数字应该是零。如果不是零说明要么删除顺序有问题要么当初就存在孤儿数据需要再跑一轮清理。第三项是收集统计信息内部表被大批量删除之后优化器对它的行数估算会严重失真进而影响数据字典相关查询的执行计划。对清理过的表补一次统计信息是必要的BEGIN DBMS_STATS.GATHER_TABLE_STATS( ownname SYS, tabname WRI$_ADV_OBJECTS, cascade TRUE, no_invalidate FALSE); END; /这里有个坑要提一下no_invalidate FALSE会让依赖该表的游标失效在业务高峰期执行可能引起短暂的硬解析飙升。所以统计信息收集最好放在维护窗口做别在业务高峰顺手跑。5. 表、LOB 和索引的物理空间回收5.1 SHRINK 与 MOVE 的取舍删除行只是把块标记为空闲空间还在段里DBA_SEGMENTS看到的数字不会变。要把空间还给 SYSAUX 表空间得做段收缩或者重建。两条路各有代价。SHRINK SPACE是在线操作对业务影响小但它只能回收高水位线以下、位于段尾部的空闲空间。如果删除的行集中在段的前部尾部还是满的shrink 的效果会非常有限。这也是很多人抱怨shrink 完没变小的原因——不是命令没生效是删除位置不凑巧。MOVE是重建段效果彻底但需要额外的表空间余量大约等于表当前大小执行期间表不可用还要重建索引。在 SYSAUX 已经告急的情况下往往凑不出这块额外空间所以现实中更多还是先 shrink 试试效果不理想再考虑维护窗口做 move。shrink 的标准步骤如下注意ENABLE ROW MOVEMENT是前提不加这句直接报错ALTER TABLE sys.wri$_adv_objects ENABLE ROW MOVEMENT; ALTER TABLE sys.wri$_adv_objects SHRINK SPACE CASCADE; ALTER TABLE sys.wri$_adv_objects DISABLE ROW MOVEMENT;CASCADE会连带处理依赖的索引和 LOB 段省去逐个处理。代价是执行时间长而且过程中会持有较多锁资源。在几十 GB 的表上这个操作跑上一两个小时很正常建议放到维护窗口并且提前确认没有长事务阻塞。5.2 LOB 段才是大头前面说过顾问对象的明细数据主要存在 LOB 列里。SHRINK SPACE CASCADE理论上会处理 LOB但实际效果不稳定尤其是当 LOB 段有大量空闲块分散在中间时。更可靠的做法是对 LOB 列单独执行一次收缩ALTER TABLE sys.wri$_adv_objects MODIFY LOB (other) (SHRINK SPACE);这里的列名要替换成DBA_LOBS里实际查到的列名不要照抄。单独收缩 LOB 的好处是粒度更细失败影响面小坏处是需要重复执行因为一次只能处理一列。如果表上有多个 LOB 列逐个来。判断 LOB 收缩是否有效看两个地方DBA_SEGMENTS里对应 LOB 段的大小以及DBA_LOBS关联出来的段名是否还在。另外 SYSAUX 表空间本身的空闲空间也要看DBA_FREE_SPACE里SYSAUX的空闲块应该明显增加。如果段变小了但表空间空闲没增加可能是数据文件没有开启自动扩展或者空间被其他段占用了需要单独排查。5.3 回收失败的典型原因实践中 shrink 失败或无效原因集中在这几个。一是没有开启行移动报错信息很明确加上就行。二是表空间不是 ASSM自动段空间管理shrink 根本不支持19c 的 SYSAUX 默认是 ASSM但如果是从老版本迁移过来的环境值得确认一下。三是表上有长时间运行的查询或事务持有锁导致 shrink 一直等待这种情况要看V$SESSION里的阻塞关系别硬等。四是 UNDO 或临时表空间不足。shrink 过程中会产生一定的 UNDO尤其是在处理 LOB 时。如果 UNDO 表空间本来就紧张操作会中途失败留下一个半收缩的状态。五是索引失效。SHRINK SPACE CASCADE之后部分索引可能变成不可用状态需要检查并重建SELECT index_name, status FROM dba_indexes WHERE table_name WRI$_ADV_OBJECTS AND status VALID;发现UNUSABLE的索引用ALTER INDEX ... REBUILD ONLINE重建ONLINE关键字保证重建期间不阻塞 DML。这一步别省索引失效对数据字典查询的性能影响是实打实的。6. 压住再增长参数、巡检和禁用策略6.1 EXECUTION_DAYS_TO_EXPIRE 与 AWR 保留期清理是一次性的参数才是长期起作用的。EXECUTION_DAYS_TO_EXPIRE控制自动调优任务执行记录的保留天数默认值在不少环境里偏长配合每天多次的自动执行累积速度很快。把它调到 15 天左右对绝大多数环境足够——真需要回溯历史建议的场景靠这个保留期也查不出什么有价值的东西不如把空间省下来。AWR 那部分同理。SM/AWR在 SYSAUX 里的占比通常也不小快照保留期默认 8 天间隔 60 分钟如果为了排查问题临时调大过事后记得改回来BEGIN DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS( retention 11520, -- 8 天单位分钟 interval 60); END; /统计信息历史也有一份保留期默认 31 天可以通过DBMS_STATS.ALTER_STATS_HISTORY_RETENTION调整。这三块是 SYSAUX 的三大常客一起看比单独盯一个更有效。6.2 一套每周跑一次的巡检 SQL与其等告警来了再救火不如把巡检固化成脚本。我常用的是一组查询跑一遍大概十几秒输出一张占用清单。-- 组件级 SELECT occupant_name, ROUND(space_usage_kbytes / 1024, 2) AS mb FROM v$sysaux_occupants WHERE space_usage_kbytes 102400 ORDER BY space_usage_kbytes DESC; -- 段级 Top 10 SELECT segment_name, segment_type, ROUND(bytes / 1024 / 1024, 2) AS mb FROM dba_segments WHERE tablespace_name SYSAUX ORDER BY bytes DESC FETCH FIRST 10 ROWS ONLY; -- 顾问对象增长趋势 SELECT TRUNC(created) AS day, COUNT(*) AS task_cnt FROM wri$_adv_tasks WHERE created SYSDATE - 30 GROUP BY TRUNC(created) ORDER BY day;第三条查询的意义在于看增长速度而不是绝对值。如果每天新增任务数量稳定在个位数说明参数正常如果某天突然冒出几百个那要查一下是不是有业务在批量调用调优接口这种情况靠调参数解决不了得从调用侧治理。6.3 什么时候该考虑直接关掉自动 SQL 调优如果确认环境里根本没人用自动 SQL 调优的结果保留期也调了、清理也做了空间还是在涨那就该考虑关掉这个自动任务。关闭之后不会再产生新的执行记录已有的按保留期自然过期。关掉的操作要在根容器执行BEGIN DBMS_AUTO_TASK_ADMIN.DISABLE( client_name sql tuning advisor, operation NULL, window_name NULL); END; /这个操作影响的是全局的自动维护任务做之前最好和业务方确认一遍因为有些性能问题的自动诊断确实依赖它。我的经验是小规模、SQL 模式稳定的库关掉问题不大如果业务 SQL 变化频繁、经常有执行计划走偏的情况自动调优还是有价值的那就把保留期压短配合定期清理而不是一刀切关掉。最后分享一个我踩过的坑早期做这类清理的时候我在 PDB 里删完数据就直接 shrink结果报了一堆错排查半天发现是索引在删除过程中变成了不可用状态shrink 卡在重建那一步。后来养成了习惯——删完先查索引状态再 shrink最后再查一遍索引状态两次检查加起来不到一分钟能省掉很多返工。另外清理脚本一定要留版本记录同一个环境隔半年再遇到同样的问题有脚本可查比重新推导一遍快得多。