欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  数据库

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

程序员文章站 2022-06-17 13:05:55
...

登录连接错误是我们在环境配置、更改和新客户端安装时候最经常遇到的问题。登录过程涉及到客户端网络、操作系统、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

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

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

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