从ORA-01031报错看密码文件故障

登录连接错误是我们在环境配置、更改和新客户端安装时候最经常遇到的问题。登录过程涉及到客户端网络、操作系统、TNS配置、监听器

登录连接错误是我们在环境配置、更改和新客户端安装时候最经常遇到的问题。登录过程涉及到客户端网络、操作系统、TNS配置、监听器工作状态、服务器远程本地登录模式和各种参数配置。应该说，只要有一个环节有问题，，就会导致Oracle用户登录错误，而且故障报错信息可能会误导用户。
 
下面介绍笔者解决的一个连接错误问题，由于涉及到实际环境，所以采用了事后模拟的策略。

 

1、问题概述

 

同事实验使用“非标准”方法安装数据库，发现在本地连接和远程连接过程中有异常问题。安装数据库版本是11gR2。

 

SQL> select * from v$version;

BANNER

--------------------------------------------------

Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production

PL/SQL Release 11.2.0.1.0 - Production

CORE    11.2.0.1.0      Production

TNS for Linux: Version 11.2.0.1.0 - Production

NLSRTL Version 11.2.0.1.0 – Production

 

同事在服务器端已经配置了连接本地数据库的TNS名称。

 

[oracle@bspdev ~]$ tnsping wilson

TNS Ping Utility for Linux: Version 11.2.0.1.0 - Production on 06-MAR-2014 05:19:23
 
 

Copyright (c) 1997, 2009, Oracle.  All rights reserved.

 

Used parameter files:

/u01/oracle/network/admin/sqlnet.ora

 

Used TNSNAMES adapter to resolve the alias

Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 127.0.0.1)(PORT = 1521))) (CONNECT_DATA = (SERVICE_NAME = wilson)))
 
OK (10 msec)

 

由于是测试，通过ssh客户端登录主机后进行各种配置操作。使用匿名/登录是可以的。

 

SQL> conn / as sysdba

Connected.

SQL> conn sys/oracle as sysdba

Connected.

SQL> conn sys/xxx as sysdba

Connected.

 

但是，无论是从远程还是本地，如果加入@wilson服务名，就不能实现登录。

 

--本地使用登录

SQL> conn sys/oracle@wilson as sysdba

ERROR:

ORA-01031: insufficient privileges

 

 

--远程登录

C:\Users\51ibm>sqlplus /nolog

 

SQL*Plus: Release 11.2.0.1.0 Production on 星期三 3月 5 21:36:43 2014

 

Copyright (c) 1982, 2010, Oracle.  All rights reserved.

 

SQL> conn sys/oracle@wilson as sysdba

ERROR:

ORA-01031: insufficient privileges

 

用户sys的密码是oracle，为什么会报错说“权限不足”？

 

2、问题分析

 

默认情况下，无论是Windows还是Linux，操作系统用户都是在系统级别的dba组中（名称可能有差异）。而且，服务器一般都是选择操作系统级别的验证方式进行登录。
 
这就是说，只要我们通过了操作系统层面的用户名/密码验证，就可以直接登录到Oracle里面。而且，如果能够进行这样的登录方式，用户名/密码即使输入也不会进行验证。
 
这也就是为什么我们输入错误的密码xxx，也可以进行登录的原因。

 

SQL> conn sys/oracle as sysdba

Connected.

SQL> conn sys/xxx as sysdba

Connected.

 

那么，问题就转化为，Oracle作为一个运行在操作系统层面上的软件程序。是怎么判断说这次进行的是操作系统级别验证，还是密码验证？

答案就是：监听器程序。下面两个在本机上运行的语句告诉我们端倪。

 

SQL> conn sys/mmm as sysdba

Connected.

SQL> conn sys/mmm@wilson as sysdba

ERROR:

ORA-01017: invalid username/password; logon denied

 

Warning: You are no longer connected to ORACLE.

 

监听程序listener是我们连接客户端进程和服务器进程过程中的一个重要组件。注意是“连接过程中”，而不是连接之后。当监听器收到请求之后，按照实例Instance注册列表查找请求的实例名称，请求相应实例分出Server Process。用户名密码验证不在监听器中进行。
 
在之前的文章中，笔者讨论过是否经过监听器的判断标准就是连接串中是否带@。如果有@，无论连到本地实例还是远程实例，都需要访问监听器。

所以，对于连接是否进行的操作系统层面验证，关键点其实不在我们是否远程登录主机，而是我们是否经过监听器！

如果不经过监听器，首先就可以保证连接的是本机，不会是到其他服务器host上。如果经过监听器，都会被判定为远程登录，都不会应用上操作系统层面验证。

回到问题本身，同事不使用@连接的时候，是正常的。只要通过监听器，就出现错误，无论本地还是远程连入。

另一线索是针对sys用户，在进行登录的时候出错。

综合各种要素，当Oracle不使用本地登录，而且是sys这类sysdba用户登陆的时候，采用什么样的验证方法？答案就是密码文件。

怀疑密码文件之后，我们可以到$ORACLE_HOME/dbs目录中找寻前缀为orapw的文件去看。

 

 

[oracle@bspdev dbs]$ cd $ORACLE_HOME/dbs

[oracle@bspdev dbs]$ ls -l | grep orapw

 

密码文件不存在，也没有被创建。尝试手工创建文件：

 

[oracle@bspdev dbs]$ orapwd password=oracle file=orapwWILSON

[oracle@bspdev dbs]$ ls -l | grep orapw

-rw-r----- 1 oracle oinstall    1536 Mar  6 05:51 orapwWILSON

 

尝试连接数据库。

 

[oracle@bspdev dbs]$ sqlplus /nolog

 

SQL*Plus: Release 11.2.0.1.0 Production on Thu Mar 6 05:54:24 2014

Copyright (c) 1982, 2009, Oracle.  All rights reserved.

 

SQL> conn sys/oracle@wilson as sysdba

ERROR:

ORA-01031: insufficient privileges

 

依然错误。看来需要进一步分析。

更多详情见请继续阅读下一页的精彩内容：