ORA-13526报错说baseline和string没找到，远程帮忙修复故障经验分享

（引用来源：根据一次真实的Oracle数据库性能问题远程支持案例整理）

那天下午,我接到一个紧急电话，是一位合作公司的数据库管理员小李打来的，声音听起来很焦急，他说他们的一套重要业务数据库突然变得非常慢，应用程序已经出现了超时告警，他们尝试使用Oracle的自动工作负载仓库（AWR）报告来分析问题，但在生成指定时间段的报告时，数据库报错了，错误代码就是ORA-13526，这个错误信息的大意是说，指定的基线不存在，因为没有AWR报告，他们就像失去了眼睛一样，无法快速定位性能瓶颈，所以急需远程协助。

我首先让他保持冷静,然后让他把完整的错误信息截图发给我，错误信息清晰地显示：ORA-13526: 基线 “基线名称” 不存在，这里的“基线名称”就是小李他们自己命名的一个性能基线，看到这个错误，我心里初步有了几个判断方向，所谓的“基线”，在Oracle里可以理解为一个“性能快照”，它把一段时间内的数据库运行情况，比如哪些SQL慢、系统资源消耗等，打包保存下来，方便以后出问题时拿来和正常时候做对比。

我让小李先做一个最简单的检查：列出当前数据库里所有存在的基线，我让他登录到数据库服务器，使用SQL命令行工具，执行了一个简单的查询命令：SELECT baseline_name FROM dba_hist_baseline;，他执行后反馈说，列表是空的，没有任何记录，这说明了一个最直接的问题：他们想要使用的那个基线，确实不存在于数据库中。

为什么他们会认为有这个基线呢？我让小李回忆一下操作过程，他解释说，他们之前为了监控一个每晚的批处理任务，确实创建了一个基线，名字就是报错里提到的那个，但现在看来，这个基线莫名其妙地消失了，基线消失通常有几个常见原因：可能是基线被某个管理员手动删除了；或者是设置了一个过期时间，系统自动清理掉了；还有一种较小概率的可能性是数据库的AWR快照本身出了问题，因为基线是基于快照创建的。

为了验证,我让他扩大查询范围，看看数据库里是否还存在任何AWR快照，我让他执行了另一个查询：SELECT snap_id, begin_interval_time FROM dba_hist_snapshot ORDER BY snap_id DESC;，他反馈说，快照是存在的，而且数据量很大，看起来AWR的自动采集功能是正常的，这就排除了AWR底层数据损坏的可能性，问题基本锁定在基线本身的管理上。

既然目标基线不见了,而他们又急需分析当前性能问题，我们决定采取一个更直接有效的办法：创建一个新的、临时的基线来捕获“这个有问题的时间段，我指导他如下操作：

1. 确定一个时间范围,我让他大概估计一下数据库开始变慢的时间点，比如从下午2点开始，到现在。
2. 使用DBMS_WORKLOAD_REPOSITORY包里的一个过程来创建基线,我给了他具体的命令格式：EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_BASINE(start_snap_id => X, end_snap_id => Y, baseline_name => 'TROUBLESHOOTING_2024XXXX');，这里的X和Y需要替换成具体时间点对应的快照编号，我教他如何根据之前查询到的快照列表，找到下午2点左右和当前时间的快照ID，然后填进去，基线名字我们起了一个一看就知道是用于临时排障的。
3. 他执行完命令后,系统提示基线创建成功。

基线创建好后,最关键的一步来了：生成AWR报告，我让他使用这个新创建的临时基线来生成报告，他按照我的指导，运行了生成基线的AWR报告的脚本，这一次，没有再报ORA-13526错误，报告成功生成了一个HTML文件。

他下载报告文件并打开,我们开始一起分析，报告里清晰地显示了在问题时间段内，有一条之前优化过的SQL语句由于数据量变化等原因，执行计划发生了恶化，全表扫描了上千万条记录，导致了大量的磁盘读写，从而拖慢了整个系统，找到根因后，他们立即采取了措施，比如使用SQL概要暂时固定执行计划，数据库的性能很快就恢复了正常。

事后复盘,我们推测最初那个基线消失的原因，很可能是他们在进行日常维护时，运行了清理过旧AWR数据的脚本，而那个脚本的设置可能意外地将那个手动创建的基线也一并删除了，我建议他们后续要仔细检查自动维护任务的配置，确保重要的性能基线不会被误清理。

这次远程处理ORA-13526故障的经验告诉我，面对这类“找不到对象”的错误，不要慌，首先要亲自确认对象是否存在；其次要理解对象之间的依赖关系（比如基线依赖快照）；最重要的是，如果原路走不通，要灵活变通，寻找替代方案（比如创建新基线）来达到最终目的——快速解决问题，整个过程中，清晰的沟通和一步步的验证是成功的关键。