ORA-09910报错，密码文件找不到用户入口，远程帮忙修复故障问题

ORA-09910报错，密码文件找不到用户入口，远程帮忙修复故障问题

用户那边打电话过来，说他们的数据库突然连不上了，应用也停了，屏幕上蹦出来一个ORA-09910的错误代码，后面还跟着一句“password file missing or disabled”，这可不是小事，数据库进不去，整个业务都得卡壳，用户那边急得团团转，他们自己的IT人员搞了半天没弄明白，只好请求远程支援,我们得赶紧通过远程桌面连过去看看怎么回事。

连上用户的服务器之后，第一件事就是打开命令行，试着用SQLplus以sysdba的身份登录一下数据库，果然，命令输进去，回车，直接就报错了：“ORA-09910: unable to open the password file”，紧接着是“SVR4 Error: 2: No such file or directory”，这个错误信息说得很直白了，就是数据库实例在启动或者进行特权用户认证的时候,找不到它需要的那个密码文件了。

这个密码文件是个什么东西呢？根据Oracle的官方文档，Oracle Database Administrator's Guide》里关于用户认证的部分就提到，密码文件（通常叫PWD<SID>.ora）是存储在数据库服务器本身的一个特殊文件，它里面存放着被授予了SYSDBA、SYSOPER等高级权限的用户的用户名和加密后的密码，当用户试图以AS SYSDBA这样的身份远程登录或者本地通过密码认证时，数据库就会去读取这个文件来验证权限，现在报错说找不到这个文件，那自然就拦住了所有试图用高级权限登录的操作,包括数据库自身的某些启动环节可能也会受影响。

接下来就是要找出文件到底怎么了，我得确定这个文件本来应该在哪，根据Oracle的惯例，密码文件通常放在$ORACLE_HOME/dbs目录下（在Windows上可能是%ORACLE_HOME%\database），我让用户的操作员在远程会话里打开文件浏览器，导航到这个目录，一看，果然，原本应该叫PWD<他们的数据库SID>.ora的那个文件不见了踪影，用户说他们最近确实做过一次服务器磁盘清理，怀疑是不是不小心把这个关键文件当垃圾给删掉了,这很有可能就是问题的根源。

既然文件没了，那解决办法就是重新创建一个，Oracle提供了一个很实用的命令行工具叫orapwd，就是专门用来干这个的，打开命令提示符，切换到Oracle软件安装用户（通常是oracle用户），然后执行创建命令，命令的格式大概是这样的：orapwd file=<完整的文件路径和文件名> password=<给sys用户设置的新密码> entries=<允许的最大特权用户数>，这里有几个关键点要注意，也是根据Oracle官方工具说明来的：一是文件路径必须正确，要放在ORACLE_HOME下的dbs目录；二是文件名必须严格按照PWD<SID>.ora的格式来，<SID>要替换成用户实际的数据实例名，一个字母都不能错，大小写在Windows上可能不敏感，但在Linux/Unix上必须完全匹配；三是这个新密码最好设得复杂点，并且要记录下来,因为以后用SYSDBA登录就得用这个新密码了。

创建命令执行成功后，我让用户再次确认dbs目录下，果然看到了新生成的密码文件，这时候，再尝试用SQLplus以sys as sysdba身份登录，输入刚设置的新密码，回车——这次成功了！顺利连接到了数据库的空闲实例，为了进一步验证权限恢复正常，可以执行一个show user命令，显示当前用户是SYS,说明SYSDBA权限已经生效。

光能登录还不够，得确保所有有特权权限的用户都还在，可以查询动态性能视图V$PWFILE_USERS，这个视图会列出密码文件中所有被授予了SYSDBA或SYSOPER权限的用户，执行查询后，看到除了SYS用户外，其他应有的管理用户也都在列表中，权限状态正常，这说明新建的密码文件已经可以正常工作，用户权限信息没有因为文件丢失而受损（因为权限信息主要存储在数据库内部，密码文件更像是一个钥匙清单）。

为了确保万无一失，建议用户那边重启一下数据库实例，模拟一个完整的启动过程，先正常关闭数据库，然后再启动，整个过程很顺利，没有出现任何错误，再次用应用账号测试连接，应用也能正常连上数据库了，至此，这个由密码文件意外丢失引起的ORA-09910故障就算彻底修复了。

事后，我提醒用户，一定要做好系统关键文件的定期备份，尤其是密码文件、参数文件（spfile或pfile）和控制文件这些，并且对服务器上的文件删除操作要建立严格的审批和复核流程，避免再发生类似误删导致业务中断的情况，这次远程支援虽然解决了问题,但根源还是在于运维管理上的疏忽。