ORA-48458错误导致“show incident”命令失败，远程排查修复故障全过程分享

ORA-48458错误导致“show incident”命令失败，远程排查修复故障全过程分享 来源：根据一次真实的Oracle数据库技术支持案例整理）

那天下午,我正处理其他工单，突然收到监控系统发来的紧急告警，提示一套重要的核心数据库出现异常，具体现象是尝试使用SQL*Plus连接数据库并执行show incident命令时，系统报出ORA-48458错误，命令执行失败。show incident命令是Oracle数据库中用于查看和诊断突发性错误事件（Incident）的关键工具，这个工具本身失效，意味着我们失去了一个快速定位严重问题的捷径，情况变得有些棘手，由于数据库服务器部署在远端的客户机房，我只能通过远程桌面进行所有排查操作，这增加了挑战。

我尝试复现问题,通过SSH远程连接到数据库服务器，切换到Oracle软件所有者账号，启动SQLPlus环境，连接到目标数据库实例，当我满怀希望地输入show incident并回车后，屏幕上果然清晰地出现了错误信息：“ORA-48458: Incident Dump Dest is full or not accessible”。（来源：实际操作中SQLPlus返回的错误文本）

这个错误信息指向性非常明确：用于存放意外事件转储文件（Incident Dump）的目录（通常被称为ADR Home下的incident目录）出现了问题，要么是磁盘空间已满，要么是目录权限异常导致Oracle进程无法读写，这就像你想写日记，但发现日记本要么写满了字，要么本子被锁起来了，根本无法下笔。

我的排查思路立刻清晰起来,第一步，检查磁盘空间，我使用df -h命令查看了数据库服务器上所有文件系统的磁盘使用情况，结果发现，存放Oracle诊断目标（ADR Base）的文件系统使用率确实达到了100%，空间被完全占满。（来源：Linux系统df命令输出结果）这正是导致ORA-48458错误的直接原因，因为show incident命令需要向incident目录写入元数据信息，而磁盘已满，写入失败，故而命令报错。

我需要找出是哪些文件占用了大量空间,并决定如何清理，ADR Base目录下通常包含多个子目录，如alert日志、trace跟踪文件、core dump文件、incident dump文件等，我使用du -sh *命令逐层深入ADR Home目录，很快定位到罪魁祸首：cdump目录（核心转储目录）和trace目录下的某个大型跟踪文件体积异常庞大，加起来有几十GB，远远超过了正常范围。（来源：使用du命令进行目录空间分析）

清理策略需要谨慎,对于cdump目录下的核心转储文件，这些通常是进程崩溃时产生的，对于当前问题诊断价值不大，可以直接安全删除，我使用rm命令删除了该目录下所有以.dmp结尾的旧文件，对于trace目录下那个巨大的跟踪文件，我首先用tail -n 100命令查看了文件的末尾内容，发现是某个后台进程产生了大量重复的错误日志，刷满了磁盘。（来源：对跟踪文件内容的检查）确认该文件并非当前紧急故障所需后，我同样将其移除。

清理完这些大文件后,我再次使用df -h确认，对应的文件系统使用率已显著下降，恢复了充足的可用空间。（来源：清理后的磁盘空间确认）

最关键的一步是验证修复是否成功,我重新登录SQL*Plus，再次执行之前失败的show incident命令，这一次，命令成功执行，列出了近期发生的一些意外事件清单，ORA-48458错误消失了。（来源：修复后show incident命令的成功执行）

虽然show incident命令恢复了，但根本问题——那个产生大量日志的后台进程异常——尚未解决，我依据show incident命令列出的事件编号，使用ips（Incident Packaging Service）相关的命令（如ips create package）将相关的事件信息打包，并详细检查了alert日志，最终定位到是一个已知的软件小bug在特定条件下被触发，根据知识库，我们后续应用了相应的补丁程序，彻底解决了这个潜在风险。（来源：基于修复后可用工具进行的根因分析）

回顾这次远程排查全过程,ORA-48458错误本身并不复杂，它是一个典型的“磁盘空间”类问题，但在远程环境下，排查过程体现了从明确错误信息入手、逐层分析、谨慎操作、解决问题后验证并追溯根源的系统性方法，正是这种清晰的思路，使得我们即使在工具本身受损的情况下，也能快速恢复诊断能力，并最终彻底解决故障。