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

Oracle 19c 的 PDB 里SYSAUX 表空间报警是个挺常见的场景。我第一次遇到时DBA_SEGMENTS一查排在前面的不是业务表而是WRI$_ADV_OBJECTS和它拖家带口的 LOB、索引段加起来几十 GB。更让人上火的是照着网上脚本在 PDB 里执行DBMS_AUTO_TASK_ADMIN.DISABLE直接甩回来一个ORA-65040: operation not allowed from within a pluggable database。这篇内容就围绕这条清理链路展开先看清 SYSAUX 里谁在占地方再判断WRI$_ADV_OBJECTS是正常堆积还是已知缺陷然后按步骤停任务、删数据、收空间最后把 ORA-65040 和几个容易反复的坑一次说透。适合正在管 19c 多租户库的 DBA也适合刚接手 PDB 运维、想搞清楚“为什么不能直接在 PDB 里动手”的读者。1. 先把SYSAUX里的“住户”摸清楚1.1 SYSAUX不是杂物间每块空间都有主很多人把 SYSAUX 当成“系统自动用的表空间”觉得它涨就涨了反正不是用户数据。这个认知会让人在清理时下手没轻没重。SYSAUX 里住着一批有明确用途的组件AWR 的基线和工作负载仓库、ADDM 的顾问任务、SQL Plan Management 的基线、优化器统计信息历史、调度器日志、统一审计的部分落地数据还有 LogMiner 和 XStream 相关的字典表。每一类都有自己的保留策略和清理入口乱删基表轻则让 AWR 报告缺段重则让自动任务持续报错。我习惯先跑V$SYSAUX_OCCUPANTS这张视图会把当前容器里各个组件占了多少空间列出来。在 PDB 内执行时看到的是这个 PDB 自己的占用情况这点比直接查DBA_SEGMENTS更直观SELECT occupant_name, ROUND(space_usage_kbytes/1024/1024, 2) AS size_gb, schema_name, move_procedure FROM v$sysaux_occupants ORDER BY space_usage_kbytes DESC;如果SM/ADVISOR、AWR、SQL_MANAGEMENT这几项排在前列基本就能把范围缩小到工作负载仓库和顾问框架。WRI$_ADV_OBJECTS属于 ADDM 的对象存储归在顾问相关组件下面。它膨胀时DBA_SEGMENTS里看到的不只是这一张表还有以SYS_LOB开头的 LOB 段和一堆索引段这些都要一起统计否则你删完主表发现空间没降多少会怀疑人生。还有一个细节PDB 里的 SYSAUX 和 CDB$ROOT 的 SYSAUX 不是一回事。19c 的多租户架构下每个 PDB 有自己的 SYSAUX 表空间和数据文件但数据文件的管理动作往往要在 CDB$ROOT 完成。你在 PDB 里查DBA_DATA_FILES能看到文件却不代表你能在 PDB 里对它做RESIZE。这就是后面 ORA-65040 频繁出现的原因之一。1.2 WRI$_ADV_OBJECTS到底存了什么WRI$_ADV_OBJECTS是 ADDM 框架用来存放“被分析对象”的表。ADDM 在每个 AWR 快照之后自动跑一次分析这段时间内的性能问题生成任务、发现和建议。任务本身记录在WRI$_ADV_TASKS任务关联的对象、发现、建议、动作分别落在WRI$_ADV_OBJECTS、WRI$_ADV_FINDINGS、WRI$_ADV_RECOMMENDATIONS、WRI$_ADV_ACTIONS这些表里。它跟 AWR 的WRH$_、WRM$_基表是两套东西删 ADDM 的历史任务不会把 AWR 快照一起删掉这一点先记住能避免很多不必要的担心。正常情况下ADDM 任务会按照 AWR 保留期滚动清理。AWR 默认保留 8 天ADDM 任务也应该在这个窗口内被回收。但实际环境里任务可能因为执行失败、实例异常重启、MMON 进程异常、或者已知的元数据清理缺陷而残留下来。残留的任务不会被自动回收WRI$_ADV_OBJECTS就跟着越积越多。尤其是那些跑了几十秒就失败的任务每次失败都留一条记录日积月累能把一张字典表撑到几十 GB。这类表的特点是“单行不大行数吓人”。主表加上 LOB 段再叠加几个没有及时重建的索引SYSAUX 的使用率很快就上去了。更麻烦的是SYSAUX 满了会影响的不只是 ADDMAWR 快照、统计信息收集、调度器作业都可能跟着报错。所以清理的目标不是“把表清空”而是“把过期的顾问任务按依赖顺序删掉再把空间真正还给表空间”。1.3 ORA-65040的真相你站在了错误的容器里ORA-65040的完整提示是“operation not allowed from within a pluggable database”意思是这个操作不允许在 PDB 内执行。它不是一个“权限不够”的错误而是“容器位置不对”。19c 里有一批操作被限定在 CDB$ROOT 执行比如修改 SPFILE 级别的系统参数、对数据库级数据文件做 RESIZE、启用或禁用 CDB 级别的自动维护任务客户端。你在 PDB 里敲这些命令哪怕用的是 SYS也会被拦下来。清理WRI$_ADV_OBJECTS时最容易撞上它的两个动作一个是DBMS_AUTO_TASK_ADMIN.DISABLE另一个是ALTER DATABASE DATAFILE ... RESIZE。前者是因为 ADDM 自动任务客户端是 CDB 级别的后者是因为数据文件属于 CDB 的文件管理范畴。很多人看到 ORA-65040 第一反应是去查权限GRANT 了一圈还是报错其实是切错了容器。我一般的做法是先把容器关系理清楚CDB$ROOT负责全局任务开关和文件管理具体 PDB 负责查自己的段、删自己的顾问任务。需要跨容器时用ALTER SESSION SET CONTAINER ...显式切换别依赖连接串里带的服务名去猜。下面这条查询能确认当前站在哪个容器SELECT SYS_CONTEXT(USERENV,CON_NAME) AS current_container, SYS_CONTEXT(USERENV,DB_NAME) AS db_name FROM dual;如果返回的是 PDB 名而你要执行的是 CDB 级操作先切到 CDB$ROOT。反过来删WRI$_ADV_OBJECTS的数据要在目标 PDB 里做因为每个 PDB 的顾问任务数据是独立的。搞清楚这个边界后面的步骤就不会来回折腾。2. 清理前的定位、备份与风险评估2.1 用三条查询锁定“大块头”定位阶段我不喜欢一上来就查WRI$_ADV_OBJECTS的行数因为行数多不代表占空间大LOB 段和索引往往才是大头。先按段类型聚合把 SYSAUX 里排名前二十的段拉出来SELECT owner, segment_name, segment_type, ROUND(SUM(bytes)/1024/1024/1024, 2) AS size_gb FROM dba_segments WHERE tablespace_name SYSAUX GROUP BY owner, segment_name, segment_type ORDER BY SUM(bytes) DESC FETCH FIRST 20 ROWS ONLY;这条查询能直接告诉你WRI$_ADV_OBJECTS主表、它的 LOB 段、以及相关索引各占多少。接下来再单独看 ADDM 相关段SELECT segment_name, segment_type, ROUND(bytes/1024/1024/1024, 2) AS size_gb FROM dba_segments WHERE tablespace_name SYSAUX AND (segment_name LIKE WRI$_ADV% OR segment_name LIKE SYS_LOB%) ORDER BY bytes DESC;如果SYS_LOB段很大需要确认它属于哪张表、哪个列。DBA_LOBS能给出对应关系SELECT table_name, column_name, segment_name FROM dba_lobs WHERE table_name LIKE WRI$_ADV%;第三條查询是看任务分布判断该删哪些。WRI$_ADV_TASKS里记录任务名、状态、执行起止时间按结束时间排序找出明显过期的任务SELECT task_id, task_name, status, TO_CHAR(execution_start,YYYY-MM-DD HH24:MI) AS start_time, TO_CHAR(execution_end,YYYY-MM-DD HH24:MI) AS end_time FROM wri$_adv_tasks ORDER BY task_id DESC FETCH FIRST 30 ROWS ONLY;这三条查询跑完基本能判断出是“少量大任务”还是“大量失败的小任务”。前者可以用DBMS_ADDM.DELETE_ADDM_TASK逐个处理后者更适合按时间批量清理。定位阶段不要急着删先把任务数量、时间跨度、关联段大小记下来后面收缩空间时要用它做对比。2.2 判断是正常堆积还是已知缺陷WRI$_ADV_OBJECTS增长不一定是缺陷。如果 AWR 保留期设得很长比如 30 天甚至 60 天ADDM 任务自然会多占几十 GB 不算异常。判断方法很简单看任务是否在正常结束状态是不是COMPLETED以及最老的任务时间是否和 AWR 保留期对得上。如果任务状态大量是FAILED、INTERRUPTED或者最老任务停在几个月前不动那更像是清理机制出了问题。我在一个测试库里见过一种情况ADDM 任务每天生成但WRI$_ADV_OBJECTS里关联的对象只增不减任务表里的记录却已经被删了留下了一批“孤儿对象”。这种就是典型的清理不完整。判断孤儿对象可以用NOT EXISTS对任务表做反连接SELECT COUNT(*) FROM wri$_adv_objects o WHERE NOT EXISTS (SELECT 1 FROM wri$_adv_tasks t WHERE t.task_id o.task_id);如果这个数字很大说明主表里有大量没有任务归属的残留对象。这类数据删起来相对安全因为它们已经不对应任何可查询的 ADDM 任务。但也不要直接TRUNCATE先确认没有外键依赖和正在运行的 ADDM 作业。另一个判断维度是版本和补丁。19c 的不同 RU 对 ADDM 元数据清理有过修复某些早期版本里WRI$_ADV_OBJECTS膨胀是已知问题。我不建议在文章里背具体补丁号因为环境差异太大正确做法是拿任务状态、告警日志里的ORA-12012、ORA-12008报错去对照官方支持文档确认是不是命中已知缺陷。如果是临时清理只能止血最终还是要靠补丁或定期清理作业兜底。2.3 备份、回退与窗口选择删字典表数据之前至少要留一条回退路径。最轻量的做法是把待删除的任务 ID 清单落到一张普通表里万一删错了还能对着清单追溯。更稳妥的是用 Data Pump 导出相关表但 SYS 下的字典表导出需要额外参数操作成本高我不建议在紧急清理时现学。实际项目中我一般做两层保护第一层是把WRI$_ADV_TASKS和WRI$_ADV_OBJECTS中待删行的关键字段 CTAS 到临时表第二层是确认数据库有可用的全量备份或存储快照。CTAS 的写法要注意别在 SYSAUX 里再建一张大表把刚腾出来的空间又占回去。可以指定到其他表空间CREATE TABLE sys.wri_adv_task_bak TABLESPACE users AS SELECT task_id, task_name, status, execution_start, execution_end FROM sys.wri$_adv_tasks WHERE execution_end SYSDATE - 30;窗口选择上清理本身可以在线做但SHRINK SPACE和索引重建会产生较多 I/O 和 UNDO最好放在业务低峰。删除阶段如果分批提交对业务影响不大但也别在 AWR 快照刚生成、ADDM 正在跑的时候动手。可以先查一下自动任务客户端的当前状态确认 ADDM 没有在运行SELECT client_name, status, last_start_date, last_duration FROM dba_autotask_client WHERE client_name ADDM;还需要确认 UNDO 表空间够用。大批量删除会产生 UNDO如果 UNDO 表空间紧张删除事务可能拖很久甚至失败。我的经验是单次删除控制在几千行到一万行以内提交一次既能控制 UNDO又不会因为事务太小导致效率低得离谱。3. 手动清理WRI$_ADV_OBJECTS的完整过程3.1 切容器与停自动任务的正确姿势清理的第一步不是删数据而是把 ADDM 自动任务停掉避免你一边删、它一边生成新任务。这个动作必须在 CDB$ROOT 执行在 PDB 里执行就会碰到 ORA-65040。切换容器并禁用 ADDMALTER SESSION SET CONTAINER CDB$ROOT; BEGIN DBMS_AUTO_TASK_ADMIN.DISABLE( client_name ADDM, operation NULL, window_name NULL); END; /执行完确认状态SELECT client_name, status FROM dba_autotask_client WHERE client_name ADDM;STATUS显示DISABLED才算生效。这里有个容易被忽略的点DBMS_AUTO_TASK_ADMIN.DISABLE影响的是整个 CDB 的 ADDM 自动任务不是单个 PDB。如果你管的是多租户库停掉之后所有 PDB 的 ADDM 都不会再自动跑。所以清理窗口要尽量短清完立刻恢复。不要为了省事一直关着时间长了 AWR 报告里 ADDM 部分会缺失排查性能问题时少一个抓手。如果环境里配置了多个维护窗口window_name NULL表示对所有窗口生效。有些库自定义过维护窗口名称执行前可以先查DBA_AUTOTASK_WINDOW_CLIENTS确认 ADDM 挂在哪些窗口上。停任务这个动作本身很轻但它决定了后面删除时会不会有并发写入值得多花一分钟核对。3.2 优先用DBMS_ADDM删除失败再手工清理停掉自动任务后优先走 Oracle 提供的过程删除 ADDM 任务让数据库自己处理关联对象。DBMS_ADDM.DELETE_ADDM_TASK接收任务名删除任务及其关联数据。先查出一批过期任务再用 PL/SQL 循环处理ALTER SESSION SET CONTAINER PDB1; BEGIN FOR r IN (SELECT task_name FROM wri$_adv_tasks WHERE execution_end SYSDATE - 30 ORDER BY execution_end) LOOP BEGIN DBMS_ADDM.DELETE_ADDM_TASK(r.task_name); EXCEPTION WHEN OTHERS THEN DBMS_OUTPUT.PUT_LINE(skip || r.task_name || : || SQLERRM); END; END LOOP; END; /这段脚本的关键是异常处理。某些任务可能因为状态异常、依赖对象缺失或者正在被引用而删不掉直接让整个循环中断不划算捕获异常、记录任务名、继续下一个更稳妥。跑完之后再查一次任务表看看还剩多少SELECT COUNT(*) AS remain_tasks FROM wri$_adv_tasks WHERE execution_end SYSDATE - 30;如果DBMS_ADDM.DELETE_ADDM_TASK大面积失败或者任务表里已经没有记录、但WRI$_ADV_OBJECTS里还有大量孤儿对象就需要手工清理。手工清理的核心是“先子后父”按外键依赖顺序删。不要凭记忆猜表名先查一下 ADDM 相关表之间的外键关系SELECT c.table_name AS child_table, c.constraint_name, p.table_name AS parent_table, p.constraint_name AS parent_constraint FROM dba_constraints c JOIN dba_constraints p ON c.r_constraint_name p.constraint_name AND c.r_owner p.owner WHERE c.constraint_type R AND (c.table_name LIKE WRI$_ADV% OR p.table_name LIKE WRI$_ADV%);查出来的结果就是删除顺序的依据。通常WRI$_ADV_ACTIONS、WRI$_ADV_FINDINGS、WRI$_ADV_RECOMMENDATIONS、WRI$_ADV_OBJ_FINDINGS这些子表要先于WRI$_ADV_OBJECTS和WRI$_ADV_TASKS处理。不同版本的表结构可能有差异以实际查询结果为准别照搬网上的固定脚本。3.3 分批删除的PL/SQL模板与提交节奏手工删除最忌讳一条大 DELETE 跑到底。WRI$_ADV_OBJECTS数据量大时单事务会产生大量 UNDO回滚段撑不住就报ORA-01555事务回滚又要等很久。我一般用“临时表存 ID、循环分批删、每批提交”的模板。先把待删任务 ID 固定下来CREATE TABLE sys.wri_adv_task_bak TABLESPACE users AS SELECT task_id FROM sys.wri$_adv_tasks WHERE execution_end SYSDATE - 30;然后按子表到主表的顺序分批删除。下面以WRI$_ADV_ACTIONS为例其他子表替换表名即可DECLARE v_rows NUMBER : 1; BEGIN WHILE v_rows 0 LOOP DELETE FROM sys.wri$_adv_actions WHERE task_id IN (SELECT task_id FROM sys.wri_adv_task_bak) AND ROWNUM 5000; v_rows : SQL%ROWCOUNT; COMMIT; END LOOP; END; /每张子表都按这个方式清完最后处理WRI$_ADV_OBJECTS和WRI$_ADV_TASKS。提交频率我习惯每 5000 行一次数据量特别大时降到 2000 行。这个值没有绝对标准看 UNDO 表空间大小和 I/O 承受能力。提交太频繁会增加事务开销提交太少又容易撑爆 UNDO5000 行在多数环境里是个比较稳的折中。删除过程中可以观察进度查一下当前剩余行数SELECT COUNT(*) FROM sys.wri$_adv_objects WHERE task_id IN (SELECT task_id FROM sys.wri_adv_task_bak);如果发现某张子表删得特别慢先停下来看执行计划别硬跑。字典表上的索引可能因为统计信息过期走了全表扫描补一下统计信息或者换个驱动条件往往能快很多。还有一点删除期间不要开并行 DML字典表上的并行删除容易引发锁竞争反而拖慢整体进度。3.4 恢复任务并做一次完整性校验数据删完、提交确认后回到 CDB$ROOT 恢复 ADDM 自动任务ALTER SESSION SET CONTAINER CDB$ROOT; BEGIN DBMS_AUTO_TASK_ADMIN.ENABLE( client_name ADDM, operation NULL, window_name NULL); END; /确认状态回到ENABLED然后等下一个维护窗口观察 ADDM 是否能正常生成新任务。可以手动触发一次快照再查任务表有没有新记录ALTER SESSION SET CONTAINER PDB1; EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT(); SELECT task_id, task_name, status, execution_end FROM wri$_adv_tasks ORDER BY task_id DESC FETCH FIRST 5 ROWS ONLY;如果新任务能正常出现、状态正常说明清理没有破坏 ADDM 框架。接着查一下剩余对象数量和清理前做个对比SELECT COUNT(*) AS object_rows FROM wri$_adv_objects; SELECT COUNT(*) AS task_rows FROM wri$_adv_tasks;这里要提醒一句清理完不要立刻对表做TRUNCATE。WRI$_ADV_OBJECTS可能被其他顾问组件引用TRUNCATE会绕过外键和触发器风险比DELETE大得多。我见过有人为了图快直接TRUNCATE结果 ADDM 后续任务全部失败只能从备份恢复。按任务删除、按依赖清理慢一点但稳。4. 空间回收别让DELETE白干4.1 查询真实高水位与索引膨胀情况DELETE只释放数据块里的行不会降低高水位。你删了几十 GB 数据DBA_SEGMENTS里可能一点没变DBA_FREE_SPACE里倒是多出很多空闲块。这时候需要SHRINK或MOVE把高水位降下来空间才能真正被表空间复用。先确认表和索引的当前大小SELECT segment_name, segment_type, ROUND(bytes/1024/1024/1024, 2) AS size_gb, blocks FROM dba_segments WHERE tablespace_name SYSAUX AND (segment_name LIKE WRI$_ADV% OR segment_name LIKE SYS_LOB%) ORDER BY bytes DESC;再看索引状态删除大量数据后索引可能变得很稀疏甚至因为之前的MOVE操作变成UNUSABLESELECT i.table_name, i.index_name, i.status, ROUND(s.bytes/1024/1024, 2) AS size_mb FROM dba_indexes i JOIN dba_segments s ON s.owner i.owner AND s.segment_name i.index_name WHERE i.table_name LIKE WRI$_ADV% ORDER BY s.bytes DESC;如果索引大小和表差不多甚至比表还大说明索引膨胀严重重建的收益会很明显。还要注意 LOB 段SHRINK SPACE CASCADE会连带处理 LOB 和索引但前提是表启用了行移动。LOB 段的名字和表名不一样别看到SYS_LOB就以为是别人的东西。4.2 SHRINK、MOVE与索引重建的选择SYSAUX 默认是 ASSM 表空间支持SHRINK SPACE。对WRI$_ADV_OBJECTS这种字典表我优先用SHRINK SPACE CASCADE因为它在线操作不需要额外空间对业务影响小ALTER TABLE sys.wri$_adv_objects ENABLE ROW MOVEMENT; ALTER TABLE sys.wri$_adv_objects SHRINK SPACE CASCADE;CASCADE会把相关索引和 LOB 段一起收缩。执行时间取决于数据量和 I/O几十 GB 的表可能要跑一段时间放在低峰期做。如果SHRINK因为表结构限制失败比如表上有某些不支持在线收缩的对象再考虑MOVE。MOVE需要额外的表空间放新段执行完索引会变成UNUSABLE必须重建ALTER TABLE sys.wri$_adv_objects MOVE TABLESPACE SYSAUX; -- 查询需要重建的索引 SELECT index_name, status FROM dba_indexes WHERE table_name WRI$_ADV_OBJECTS; -- 逐个重建 ALTER INDEX sys.idx_name REBUILD TABLESPACE SYSAUX;MOVE的风险比SHRINK高一是需要额外空间二是索引重建期间相关查询可能变慢。字典表上的索引重建通常很快但如果 SYSAUX 已经快满了MOVE可能因为空间不足失败。所以顺序上先删数据、再SHRINKSHRINK不行才考虑MOVE别一上来就选重的方案。4.3 数据文件缩容的边界表空间里的空间释放了不代表数据文件会自动变小。如果 SYSAUX 数据文件当初为了应急扩得很大比如从 10G 自动扩到了 100G清理后可能想把文件缩回去。这个动作要在 CDB$ROOT 做在 PDB 里执行ALTER DATABASE DATAFILE ... RESIZE会报 ORA-65040。先查文件和高水位SELECT file_id, file_name, ROUND(bytes/1024/1024/1024, 2) AS size_gb, ROUND(maxbytes/1024/1024/1024, 2) AS max_gb, autoextensible FROM dba_data_files WHERE tablespace_name SYSAUX;计算可缩到的最小值看最后一个扩展块的位置SELECT ROUND(MAX(block_id blocks) * 8192 / 1024 / 1024 / 1024, 2) AS min_size_gb FROM dba_extents WHERE tablespace_name SYSAUX;这里的 8192 是块大小不同环境可能是 4K 或 16K用DBA_TABLESPACES.BLOCK_SIZE确认。缩容时留一点余量别贴着高水位缩否则下一次分配新扩展段又得扩容ALTER DATABASE DATAFILE /u01/app/oracle/oradata/CDB1/pdb1/sysaux01.dbf RESIZE 12G;缩之前确认文件属于哪个容器、有没有自动扩展。如果开了自动扩展缩完最好把MAXSIZE也调低不然它还会慢慢涨回去。但别把MAXSIZE设得太死SYSAUX 满了会导致数据库挂起留 20% 到 30% 的余量比较稳妥。5. 常见问题与排查速查表5.1 ORA-65040的几种典型触发场景ORA-65040 在清理过程中出现的频率很高但触发点就那么几个。下面这张表是我在实际环境里总结的对照触发动作所在容器正确做法DBMS_AUTO_TASK_ADMIN.DISABLE/ENABLEPDB切到 CDB$ROOT 执行ALTER DATABASE DATAFILE ... RESIZEPDB切到 CDB$ROOT 执行ALTER SYSTEM SET ... SCOPESPFILEPDB切到 CDB$ROOT或改用 PDB 级参数DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS传全局参数PDB在 CDB$ROOT 带CON_DBID执行CREATE PFILE/CREATE SPFILEPDB在 CDB$ROOT 执行排查思路很简单看到 ORA-65040先查当前容器再查这个操作在文档里属于 CDB 级还是 PDB 级。不要急着 GRANT权限解决不了容器错位。还有一种情况是脚本里写了ALTER SESSION SET CONTAINER但连接串本身已经连到 PDB切过去又切回来容易把自己绕晕。我习惯在每个脚本开头显式打印当前容器执行前确认一遍。5.2 删除后空间不释放或索引UNUSABLE删除完数据发现DBA_SEGMENTS没降先别怀疑删错了。DELETE不降高水位是正常现象查一下DBA_FREE_SPACE里 SYSAUX 的空闲块是不是变多了。如果空闲块很多但段大小不变做SHRINK就能解决。如果SHRINK报错看具体报错信息常见的是表没有启用行移动或者有 LOB 索引不支持在线收缩。索引UNUSABLE多半是MOVE表之后没有重建索引。DBA_INDEXES.STATUS显示UNUSABLE时相关查询会走全表扫描ADDM 任务可能因此变慢甚至失败。重建索引的语句不复杂但要注意表空间和并行度ALTER INDEX sys.idx_name REBUILD TABLESPACE SYSAUX ONLINE;ONLINE可以减少对业务的影响但会消耗更多资源。字典表上的索引不大普通重建通常几秒到几分钟没必要开并行。重建完再查一次状态确认全部VALID。5.3 WRI$_ADV_OBJECTS再次膨胀怎么防清理只是止血不解决根因的话几个月后还会涨回来。我一般从三个方向防第一确认 ADDM 任务状态如果大量失败查告警日志里的ORA-12012、ORA-12008定位是不是统计信息或权限问题第二确认 AWR 保留期别设得太长19c 默认 8 天对多数环境够用要保留更久就配套定期清理作业第三如果是已知缺陷跟进补丁或 RU别指望手工脚本长期兜底。定期清理作业可以用调度器实现每月跑一次只删 30 天以前的 ADDM 任务。作业里同样要先停 ADDM、再删、再恢复步骤不能省。作业执行前记日志记录删了多少任务、释放了多少空间方便后面排查。还有个小技巧清理前把WRI$_ADV_TASKS的任务数量和最老任务时间记下来下次对比就能判断增长速度是否正常。5.4 自动任务报错与AWR保留期调整清理过程中如果看到ORA-12012说明自动维护作业执行失败错误堆栈里通常会带具体的内部错误码。先查DBA_AUTOTASK_JOB_HISTORY和告警日志确认是 ADDM 任务本身失败还是统计信息收集、SQL 调优顾问之类的相邻组件出问题。不要一看到报错就删数据先定位是哪个客户端、哪个窗口、哪一步失败。AWR 保留期的调整要分清楚 CDB 级和 PDB 级。19c 支持 PDB 级 AWR设置时要在 CDB$ROOT 带CON_DBID或者确认当前 PDB 的配置是否独立。改保留期之前先查当前设置SELECT dbid, con_dbid, retention, interval, topnsql FROM dba_hist_wr_control;调整语句大概是这样具体参数按环境来EXEC DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS( retention 11520, interval 60, dbid NULL);保留期不是越长越好。AWR 快照本身也占 SYSAUX保留 30 天和保留 8 天空间差距可能是几倍。性能分析需要历史数据时可以导出 AWR 报告归档没必要把所有快照都留在库里。最后分享一个我在实际清理里养成的习惯每次动手前先把V$SYSAUX_OCCUPANTS、DBA_SEGMENTS的前二十名、WRI$_ADV_TASKS的任务数量这三份结果存成文本清理完再跑一遍对比。这样既能确认清理效果也能在下次告警时快速判断是正常增长还是异常膨胀。字典表清理不怕慢怕的是删完不知道有没有删对留下一堆索引碎片和空间空洞下次还得再来一遍。