ORA-07473报错，读sgadef.dbf文件失败，远程帮忙修复故障过程分享

ORA-07473报错，读sgadef.dbf文件失败，远程帮忙修复故障过程分享 来源：根据一次真实的Oracle数据库远程救援记录整理）

那天下午,我正准备下班，技术支持的手机突然响了起来，来电显示是一个外地的号码，接通后，那边传来一个非常焦急的声音，是一位企业的IT运维工程师，我们暂且叫他小王，小王上来就直接说：“老师，救命啊！我们核心的生产数据库突然连不上了，应用全瘫了，报一个ORA-07473的错误，说是找不到什么sgadef.dbf文件，这个文件是干嘛的？我们完全没动过服务器啊！”

我一听“ORA-07473”和“sgadef.dbf”，心里咯噔一下，这个错误不常见，但一旦出现，通常意味着Oracle数据库实例的核心内存结构（SGA）的定义文件出了问题，数据库基本上处于“植物人”状态，无法启动，我安抚小王说：“别慌，慢慢说，先把情况搞清楚，这个sgadef.dbf文件是数据库启动时用来重建SGA内存结构的关键文件，一般放在$ORACLE_HOME/dbs目录下，你先把服务器的情况详细告诉我。”

小王告诉我,他们的数据库是跑在一台Linux服务器上，版本是Oracle 11g，今天白天运行一直正常，就在半小时前，业务部门反映系统卡死，他们尝试重启数据库，结果就再也起不来了，一直报这个错，他确认没有人手动删除过任何文件，服务器磁盘空间也检查过，是充足的。

由于情况紧急,我决定通过远程方式协助他，小王那边打开了TeamViewer，我连接了上去，我让他切换到oracle用户，然后进入到$ORACLE_HOME/dbs目录，果然，原本应该存在的sgadef

. dbf文件不见了，我问他：“最近服务器有没有做过什么特殊操作？比如系统级备份、杀毒软件扫描、或者磁盘清理？”小王想了想，突然一拍大腿：“对了！今天上午我们配合安全部门做了一次全盘病毒扫描，是不是被误删了？”

这很有可能,一些过于“积极”的杀毒软件或安全扫描工具，有时会误判Oracle的某些内部文件为可疑对象并将其隔离或删除，现在首要任务不是追究原因，而是尽快恢复，我告诉小王：“文件大概率是被误删了，好在sgadef.dbf文件在数据库正常运行时并不是时刻需要的，它主要是在启动时使用，只要我们能有办法重新启动数据库实例，这个文件会被自动重建。”

“那我们现在怎么启动？”小王问，我解释道，常规的startup命令肯定不行了，因为它会去寻找这个文件，我们需要绕过这个步骤，强制实例进行内存清理和重建，我让他尝试以下步骤：

第一步,我让他先设置好Oracle的环境变量（ORACLE_SID, ORACLE_HOME等）。

第二步,尝试使用startup nomount命令，这个命令只会启动实例，但不加载控制文件和数据文件，果然，命令执行后，依然报ORA-07473错误，这说明问题就卡在实例启动的最初阶段。

第三步,看来只能用更底层的方法了，我让他先执行sqlplus / as sysdba连接到空闲进程，然后输入：create spfile from memory; 这个命令是尝试从当前（虽然不完整）的内存中创建一个服务器参数文件，但执行失败了，因为实例根本没起来，内存状态不对。

第四步,我们尝试清理可能存在的残留进程和共享内存，我让他退出sqlplus，然后使用ipcs -m命令查看是否有残留的Oracle共享内存段，并用ipcrm命令将其删除，用ps -ef | grep ora_检查是否有残留的Oracle后台进程，并用kill -9命令强制杀掉，这一步需要非常小心，确保杀掉的确实是当前出问题的数据库进程，不能杀错。

清理完残留项后,我们回到了最关键的一步，我让他再次执行sqlplus / as sysdba，然后输入一个特殊的命令：startup force nomount;。startup force会先尝试执行一个强制关闭（即使实例没起来），然后再启动，我们加上nomount是希望它只完成实例构建这一步。

屏幕上光标闪烁了几秒,然后出现了令人振奋的提示：“ORACLE instance started.”！实例终于成功启动了，小王在旁边激动地说：“起来了！实例起来了！”

我让他别急,继续输入alter database mount;，成功，再输入alter database open;，也成功了！数据库完全打开了，我们立刻连上应用用户，简单查询了一下业务表，数据访问正常，应用团队那边也反馈系统可以登录了。

我让小王再次检查$ORACLE_HOME/dbs目录，果然，那个丢失的sgadef.dbf文件已经被系统自动重新创建了出来，这次故障的根本原因，正如我们所料，是安全扫描软件误删了关键文件。

事后,我建议小王立即做两件事：第一，将Oracle的关键目录（如$ORACLE_HOME/dbs, $ORACLE_BASE/oradata）加入到杀毒软件的白名单中，避免类似事件再次发生，第二，虽然这次有惊无险，但再次强调了拥有有效、可用的数据库备份的重要性，因为万一损坏的不是sgadef.dbf而是控制文件或数据文件，恢复过程将复杂得多。

这次远程救援前后花了不到一小时,核心思路就是绕过缺失的文件，通过强制启动的方式让Oracle实例完成自我重建，这是一次惊心动魄的体验，也让他对Oracle的启动机制和应急处理有了更深的理解。