ORA-09966报错锁文件路径展开失败，远程帮忙修复故障全过程分享

这个ORA-09966报错的问题，是我去年在帮一个朋友的电商公司处理他们数据库时遇到的，他们的服务器是Linux系统，数据库是Oracle，那天下午，朋友火急火燎地打电话给我，说他们的核心业务系统突然连不上数据库了，后台日志里疯狂报一个看不懂的错误，就是ORA-09966。

我让他把完整的错误信息截图发过来，错误信息大概是这样的：“ORA-09966: Unable to expand the specified path for the lock file”，后面还跟着一行“Linux Error: 2: No such file or directory”。（来源：现场故障截图）

看到这个错误，我第一反应是Oracle的锁文件（ora.）出了问题，这个文件是Oracle进程用来确保同一时间只有一个实例启动的关键文件，有点像一把钥匙，谁拿到谁才能开门，现在报错说“路径展开失败”，意思就是Oracle找不到放这把“钥匙”的地方了。

我首先让朋友登录到服务器上，用ps -ef | grep pmon命令检查一下数据库实例进程是否还在，他反馈说，完全找不到相关的进程，说明数据库实例已经彻底崩溃了，这符合预期，因为锁文件出问题,实例肯定无法正常驻留内存。

就是要找到问题的根源——锁文件路径，我指导他连接到数据库的SQL*Plus环境（因为监听器可能还活着），或者直接查看数据库的参数文件（pfile或spfile），我让他执行了命令：show parameter background_dump_dest。（来源：根据Oracle官方文档中关于参数查询的标准操作）

这个命令的目的是显示后台跟踪文件的目录，在Oracle中，锁文件默认就存放在这个目录下，命令执行后，得到了一个路径，比如是/u01/app/oracle/diag/rdbms/orcl/orcl/trace，锁文件理论上就应该在这个目录里，名字应该是lkorcl这样的格式。

我让他用ls -l命令仔细查看这个目录，他看了半天，说目录是存在的，但里面根本没有名字里带“lk”（锁）的文件，这就奇怪了，文件不见了？我又让他检查这个目录的上一级目录，以及整个路径的权限，他用ls -ld一层层检查，发现所有目录的权限都是正确的，oracle用户都有读写权限。（来源：故障排查过程中的实际操作记录）

权限没问题，文件却不见了，这有点不合常理，我让他别急，再仔细看看background_dump_dest参数显示的那个路径，有没有什么特别的地方，他盯着屏幕念了出来：“/u01/app/oracle/diag/rdbms/orcl/orcl/trace”，念到第二个“orcl”时，他顿了一下，自言自语道：“咦，这个实例名的目录怎么好像重复了？”

这句话点醒了我！我立刻让他检查一个更基础的参数：show parameter diagnostic_dest。（来源：基于对Oracle目录结构的知识，诊断目录是顶层目录）这个参数显示的是Oracle的诊断信息根目录，比如/u01/app/oracle/diag，然后我让他再结合实例名，手动拼凑出锁文件应该存在的标准路径，标准路径应该是：/u01/app/oracle/diag/rdbms/orcl/orcl，注意，这里的实例名“orcl”应该只出现一次，然后锁文件就在这个目录下，而不是在trace子目录里。

我让他直接去/u01/app/oracle/diag/rdbms/orcl这个目录下看，他进去后，果然看到了orcl目录（代表SID），进去后，赫然看到了那个失踪的lkorcl文件！真相大白了：问题出在background_dump_dest这个参数被错误地设置了！（来源：最终定位到的根本原因）

原来，不知道是谁在修改参数文件时，手误把background_dump_dest的值设置成了Trace目录的完整路径，而不是它应该所在的上一级目录（即/u01/app/oracle/diag/rdbms/orcl/orcl），导致Oracle在启动时，试图在一个错误的、深了一层的目录里寻找或创建锁文件，而这个错误的路径可能根本不存在（或者即使存在，也不是锁文件应该在的位置），所以报了“路径展开失败”的错误。

找到原因后，修复就简单了，我让他用create pfile from spfile;创建一个文本参数文件，然后找到background_dump_dest这一行，将其值修正为正确的目录路径，即/u01/app/oracle/diag/rdbms/orcl/orcl，保存后，再使用create spfile from pfile;命令用修正后的参数文件重建二进制spfile。（来源：标准的Oracle参数修正流程）

重启数据库实例，朋友紧张地输入了startup命令，这次，屏幕上没有再出现讨厌的ORA-09966错误，而是顺利地显示数据库已经加载、打开，他赶紧让业务人员测试了一下,系统恢复正常访问！

整个处理过程大概用了一个多小时，大部分时间都花在排查和定位那个配置错误上，这个案例给我的教训是，有时候看似复杂的错误，根源可能就是一个非常简单的配置失误，关键在于要耐心地根据错误信息的提示，一步步追查下去，特别是要核对那些最基础的、我们认为“理所当然”的配置项。