指定dbid的awr删除易出错，因drop_snapshot_range默认仅操作当前实例dbid，传入其他dbid可能静默失败或报ora-13516；且该过程走dml路径，产生大量redo、不释放sysaux物理空间，真正有效清理须定位并drop对应dbid的wrh$分区。
不能直接用 dbms_workload_repository.drop_snapshot_range 删除非当前 DBID 的快照——它会报错或静默失败，且不清理底层分区。
为什么指定 DBID 的 AWR 删除容易出错
Oracle 的 drop_snapshot_range 在未显式传入 dbid 时，默认只操作当前实例的 DBID；即使你传了别的 dbid，函数仍可能跳过校验、不生效，或者抛出 ORA-13516: Invalid database ID specified。更麻烦的是：该过程走的是 DML 删除路径（DELETE FROM WRH$_XXX），会产生大量 redo、锁表、执行慢，且无法释放 SYSAUX 表空间物理空间。
- 常见错误现象：
PL/SQL procedure successfully completed但WRH$_ACTIVE_SESSION_HISTORY分区没变、SYSAUX 空间没下降 - 根本原因：AWR 数据按
DBID + SNAP_ID分区存储，跨 DBID 的快照实际存于不同分区段，DML 不跨分区生效 - 真正有效的清理必须落到分区级别，而非快照 ID 范围
查清目标 DBID 对应的 AWR 分区范围
先确认你要删的 DBID 是否真有数据、哪些表/分区属于它：
SELECT owner, table_name, partition_name, high_value FROM dba_tab_partitions WHERE table_name LIKE 'WRH$%' AND table_owner = 'SYS' AND high_value LIKE '%4059638244%'; -- 替换为你的真实 DBID
注意：high_value 是 RAW 字符串，DBID 以十进制形式嵌入其中（如 TO_NUMBER('4059638244')）。若查不到结果，说明该 DBID 在当前库中无 AWR 分区数据，无需操作。
- 关键表包括：
WRH$_ACTIVE_SESSION_HISTORY、WRH$_EVENT_HISTOGRAM、WRH$_SQLSTAT等 - 不要依赖
dba_hist_wr_control——它只显示当前 DBID 的策略，不反映其他 DBID 的分区存在状态 - 务必在
sys用户下执行，普通用户查不到WRH$分区元数据
安全删除指定 DBID 的 AWR 分区（推荐方式）
对每个匹配的分区执行 ALTER TABLE ... DROP PARTITION，这是唯一能立即释放空间、不产 redo、不锁全表的方法：
-- 示例：删除 WRH$_ACTIVE_SESSION_HISTORY 中属于 DBID 4059638244 的一个分区 ALTER TABLE sys.WRH$_ACTIVE_SESSION_HISTORY DROP PARTITION P_4059638244_6770;
- 分区名格式通常是
P_<dbid>_<snap_id></snap_id></dbid>或WRH$_<tablename>_DBID_SNAPID</tablename>，需从上一步查询结果中提取 - 一次只删一个分区，避免误操作；可写 PL/SQL 循环批量处理，但必须加
DBMS_OUTPUT.PUT_LINE日志确认 - 执行前确保已备份：分区删除不可逆，且影响该 DBID 后续 AWR 报告生成（若该 DBID 未来还会导入数据）
- 执行后运行
EXEC DBMS_STATS.GATHER_TABLE_STATS('SYS', 'WRH$_ACTIVE_SESSION_HISTORY')更新统计信息
别碰的红线：WRH$ 表不能 TRUNCATE 或 DROP
TRUNCATE TABLE sys.WRH$_XXX 或 DROP TABLE 会破坏 AWR 内部一致性，导致后续快照采集失败、awrrpt.sql 报错 ORA-00942: table or view does not exist，甚至使 DBA_HIST_* 视图失效。
- WRH$ 表是 Oracle 内部管理对象，结构与约束受严格保护，手工删表等于挖掉 AWR 的地基
- 哪怕看到
WRH$_表占了几十 GB，也绝不能TRUNCATE——只能删分区 - 如果 SYSAUX 已满且分区删不动（比如分区被其他会话持有锁），优先检查是否有长事务或未提交的 AWR 导入任务
最易被忽略的一点：删除分区后，dba_hist_wr_control 里仍显示旧的 retention 和 snap_interval，但这只是当前 DBID 的策略，不影响已删分区的数据。别试图用 MODIFY_SNAPSHOT_SETTINGS 去“修复”跨 DBID 的残留——它管不了别的 DBID。
