为什么以sys无法远程登录数据库

 今天通过pl/sql连接一个数据库，普通用户能连接上，但是sys就连接不上，告诉我用户名密码错误。之前其实遇到过这个问题，然后就开始查找原因。整个过程记录如下，结果是扎心的，过程也不是完全都懂。记下来权当备忘吧。

1、查看服务器监听器状态。

 1 $ lsnrctl status
 2 
 3 LSNRCTL for Linux: Version 11.2.0.1.0 - Production on 13-9月 -2017 18:07:36
 4 
 5 Copyright (c) 1991, 2009, Oracle.  All rights reserved.
 6 
 7 正在连接到 (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=oa-db-01)(PORT=1521)))
 8 LISTENER 的 STATUS
 9 ------------------------
10 别名                      LISTENER
11 版本                      TNSLSNR for Linux: Version 11.2.0.1.0 - Production
12 启动日期                  13-9月 -2017 17:25:29
13 正常运行时间              0 天 0 小时 42 分 7 秒
14 跟踪级别                  off
15 安全性                    ON: Local OS Authentication
16 SNMP                      OFF
17 监听程序参数文件          /oracle/app/oracle/product/11.2.0/dbhome_1/network/admin/listener.ora
18 监听程序日志文件          /oracle/app/diag/tnslsnr/oa-db-01/listener/alert/log.xml
19 监听端点概要...
20   (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=oa-db-01)(PORT=1521)))
21 服务摘要..
22 服务 "PLSExtProc" 包含 1 个实例。
23   实例 "PLSExtProc", 状态 UNKNOWN, 包含此服务的 1 个处理程序...
24 服务 "orcl" 包含 1 个实例。
25   实例 "orcl", 状态 READY, 包含此服务的 1 个处理程序...
26 服务 "orclXDB" 包含 1 个实例。
27   实例 "orcl", 状态 READY, 包含此服务的 1 个处理程序...
28 命令执行成功

View Code

可以看到监听器没有问题。

2、通过tnsping查看是否能够连通。

在服务器上做

 1 $ tnsping orcl
 2 
 3 TNS Ping Utility for Linux: Version 11.2.0.1.0 - Production on 13-9月 -2017 18:09:28
 4 
 5 Copyright (c) 1997, 2009, Oracle.  All rights reserved.
 6 
 7 已使用的参数文件:
 8 /oracle/app/oracle/product/11.2.0/dbhome_1/network/admin/sqlnet.ora
 9 
10 TNS-03505: 无法解析名称

View Code

这是因为服务器上没有tnsname.ora这个配置文件，无法解析名称。

在客户端上做

 1 tnsping oaproddb
 2 
 3 TNS Ping Utility for 32-bit Windows: Version 11.2.0.4.0 - Production on 13-9月 -2017 18:11:05
 4 
 5 Copyright (c) 1997, 2013, Oracle.  All rights reserved.
 6 
 7 已使用的参数文件:
 8 D:\app\JIAKAI\product\11.2.0\client_1\network\admin\sqlnet.ora
 9 
10 
11 已使用 TNSNAMES 适配器来解析别名
12 尝试连接 (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = **.**.**.**)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = orcl)))
13 OK (20 毫秒)
14 
15 C:\Users\JIAKAI>

View Code

没有问题。

3、查看数据库参数文件

登录到服务器，然后以sys用户登录到数据库

 1 $ sqlplus / as sysdba
 2 
 3 SQL*Plus: Release 11.2.0.1.0 Production on 星期三 9月 13 18:16:12 2017
 4 
 5 Copyright (c) 1982, 2009, Oracle.  All rights reserved.
 6 
 7 
 8 连接到: 
 9 Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
10 With the Partitioning, OLAP, Data Mining and Real Application Testing options
11 
12 SQL> show user
13 USER 为 "SYS"
14 SQL> 

View Code

4、查看spfile是否存在

1 SQL> show parameter spfile
2 
3 NAME                                 TYPE        VALUE
4 ------------------------------------ ----------- ------------------------------
5 spfile                               string      /oracle/app/oracle/product/11.2.0/dbhome_1/dbs/spfileorcl.ora

View Code

没有问题。

5、然后查看remote_login_pass参数

1 SQL> show parameter remote_login_pass
2 
3 NAME                                 TYPE        VALUE
4 ------------------------------------ ----------- ------------------------------
5 remote_login_passwordfile            string      EXCLUSIVE

View Code

也没有问题。

一直也没有怀疑过sys密码不正确，因为通过以下语句可以登录

 1 $ sqlplus sys/1234 as sysdba
 2 
 3 SQL*Plus: Release 11.2.0.1.0 Production on 星期三 9月 13 17:44:46 2017
 4 
 5 Copyright (c) 1982, 2009, Oracle.  All rights reserved.
 6 
 7 
 8 连接到: 
 9 Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
10 With the Partitioning, OLAP, Data Mining and Real Application Testing options

View Code

但还是试着抱一抱的态度，我更改了sys密码。然后居然登录成功了。（心里一万只草泥马奔过）

那么问题来了，为什么sqlplus sys/1234 as sysdba能够登录呢？我之后又试了其他的sqlplus sys/*** as sysdba都可以登录。（WTF）

在网上查阅了资料和oracle的官方文档（Database Administrator‘s Guide）得知，Linux系统下，在sqlnet.ora中没有进行任何关于认证方法的配置时，是同时支持数据库密码文件验证和操作系统验证的，并且操作系统验证要优先于数据库验证。所以，当我们采用sqlplus sys/*** as sysdba这种登录方式时，是采用的操作系统方式验证，数据库会自动忽略“/”两边的用户名和密码，其效果就如同sqlplus / as sysdba一样。

所以这次的问题就是sys密码没有写对，所以pl/sql登录不上去。

参考：

想了解sqlnet.ora，tnsname.ora，listener.ora作用的，请戳这里

想参考其他遇到该问题的情况，请戳这里

想了解oracle验证方式的，请戳这里

关于oracle官方文档，请戳这里

转载于:https://www.cnblogs.com/xidabei/p/7516675.html