如何处理ORA-13509报错_AWR更新操作中遇到重复的快照ID冲突-Oracle-PHP中文网

ORA-13509 根本原因是 AWR 元数据不一致，典型表现为 WRM$_DATABASE_INSTANCE 表为空但 SGA 标志位显示“已就绪”，导致外键校验失败（ORA-02291）；应先验证该表数据及 _swrf_test_action 值，再执行 register_database 和 create_snapshot 恢复。

ORA-13509 报错本质是 AWR 元数据不一致，不是“重复快照ID”本身导致的

ora-13509 看似像主键冲突（比如插入已存在的 snap_id），但实际根本原因通常是 awr 相关表的元数据损坏或状态错位——尤其是 wrm$_database_instance 表为空、但 sga 中的标记位却认为“实例信息已加载”，导致后续写入 wrm$_snapshot 时因外键 wrm$_snapshot_fk 指向空父表而失败。你查 dba_hist_snapshot 返回空集，或者升级/刷新后 snapshot 停摆，基本都指向这个断层。

不要直接 delete 或 update WRM$_SNAPSHOT 表——它受内部包强管控，手工改大概率引发连锁报错
别急着重建 AWR：执行 catnoawr.sql + catawr.sql 会清空所有历史快照，且需数据库重启，属于高风险兜底操作
注意 ORA-02291 往往伴随出现，就是外键校验失败的明确信号，它比 ORA-13509 更值得盯住

先验证是否真由 WRM$_DATABASE_INSTANCE 缺失引发

运行这条语句看关键元数据是否存在：

SELECT dbid, instance_number, startup_time FROM dba_hist_database_instance;

如果返回空行，再查 SGA 标记：

SELECT ksppinm, ksppstvl FROM x$ksppi JOIN x$ksppcv USING (indx) WHERE ksppinm = '_swrf_test_action';

若 _swrf_test_action 值为非 0（如 16 或 32），说明内部逻辑已跳过初始化步骤，正是元数据空但标志位“已就绪”的典型表现。

该检查必须在数据库 OPEN 状态下执行；MOUNT 状态下 dba_hist_* 视图不可用
如果 dba_hist_database_instance 有数据，但 snapshot 仍失败，则要转向锁冲突排查（见下一条）

排查 ORA-00054：AWR 快照被阻塞的常见场景

ORA-13509 经常和 ORA-00054: resource busy 同时报出，说明 MMON 或 MMON slave 正在尝试更新快照表，却被其它会话锁住（比如未提交的 DML、DDL 操作或异常终止的 job）。

查当前阻塞链：

SELECT blocking_session, sid, serial#, event, sql_id FROM v$session WHERE blocking_session IS NOT NULL OR sid IN (SELECT blocking_session FROM v$session WHERE blocking_session IS NOT NULL);

重点关注持有 WRM$_SNAPSHOT 或 WRM$_DATABASE_INSTANCE 表锁的会话，特别是状态为 INACTIVE 但 last_call_et > 3600 的“僵尸会话”
临时释放可 kill 对应 session：ALTER SYSTEM KILL SESSION '<sid>,<serial>' IMMEDIATE;</serial></sid>，但务必确认不是正在跑的备份或导出任务

修复动作要按顺序做，跳步容易二次损坏

多数情况下，只需两步即可恢复，无需重建 AWR：

先手动触发一次实例注册：
```
EXEC DBMS_SWRF_INTERNAL.register_database;
```
—— 这会重新填充 WRM$_DATABASE_INSTANCE 并同步 SGA 标志位
再强制生成一个快照：
```
EXEC DBMS_WORKLOAD_REPOSITORY.create_snapshot;
```
，观察是否成功写入 WRM$_SNAPSHOT
如果报 ORA-12899（如字段 SUBNAME 超长），说明升级脚本 utlu122s.sql 执行中途失败，此时必须重跑该脚本，并确保 sysaux 表空间有足够空闲块（至少 200MB）