干数据库运维这些年登录异常是我遇到过最频繁的“小问题”。说它小是因为绝大多数情况下不涉及数据损坏、性能瓶颈这种大故障说它麻烦是因为从网络到服务器再到数据库实例任何一个环节出问题都可能让你连不进去而且报错信息五花八门从ORA-12541、ORA-01017到ORA-28000光记错误码就够喝一壶。这篇文章我就按实际排查的思路来写从建立排查顺序到逐步定位把每一个环节可能出现的坑都拆开讲清楚。无论你是开发同学偶尔连库报错还是刚接手运维、DBA的新手看完以后应该都能建立一套自己的排查路径遇到类似的登录异常至少不会慌。1. 登录异常排查前先建立整体排查框架很多人一看到数据库登录不上就急着改密码、重启监听这种操作很容易把小问题搞成大故障。我自己的习惯是先理清楚登录这个过程到底经历了哪些环节再逐段定位。1.1 一次数据库登录请求经过的环节客户端连数据库表面上是一条命令的事实际过程可以拆成四段链路客户端发起连接叫上网络层到达服务器后由监听程序接单叫监听层然后数据库实例校验服务名和会话资源叫实例层最后校验身份和权限叫认证层。任何一段出问题结果都是登录失败但报错特征完全不同这决定了排查方向的差异。我常用一个生活化类比来解释登录数据库就像去银行办业务。网络层决定了你到不到得了银行门口监听层决定了有没有大堂经理接待你实例层决定了窗口有没有开认证层决定了柜员认不认为你是本人。到了哪个环节被拦下来体现出来的“说辞”都不一样对应的处理方式也完全不同。1.2 排查登录异常要收集的信息在动手之前我建议先收集三样东西完整报错信息、操作环境和近期变更。很多同事只记了一个错误码就来找我比如“ORA-12541”但ORA-12541只是表示监听无法接收连接具体是监听没起来、端口被占还是防火墙拦截完全可能是三种不同的原因。操作环境指的是你用什么方式连sqlplus命令行、PL/SQL Developer、JDBC应用还是通过连接池。不同的客户端对错误的表现不一样JDBC连接可能只报IO异常而sqlplus会给出明确的ORA错误码。近期变更也很关键比如数据库版本做过升级、监听配置文件被改过、密码策略刚调整这些往往就是异常的根源。我见过不少次排查了半天最后发现是同事前一天改了防火墙规则没吭声。1.3 几条最常用的排查命令工欲善其事必先利其器。登录异常排查最常用的就是tnsping、telnet、lsnrctl status以及数据库端的sqlplus / as sysdba。其中tnsping测试的是别名解析和网络连通性telnet测试的是端口通不通lsnrctl status看的是监听服务状态sqlplus / as sysdba则能直接在数据库主机上绕过网络层检查实例和认证层面。这四条命令从外到内、从网络到数据库基本可以覆盖登录链路的每一个环节。排查时按这个顺序走很少会漏掉问题。2. 网络层排查能ping通不等于能连库网络层是登录链路的“第一道门”也是很多开发同学忽略的地方。第一反应可能是数据库有问题实际不过是防火墙或网络策略挡住了一台机器。2.1 从ping、telnet到tnsping的逐级定位第一步先ping主机地址确认目标服务器的网络可达性。但要注意ping通只能说明ICMP能通不能代表TCP端口畅通。第二步是关键用telnet 服务器IP 端口号检查监听端口默认1521是否可达这一步能直接验证从你所在的位置到数据库监听端口是不是通的。端口通了你再执行tnsping 服务名确认TNS别名解析和目标服务有没有问题。tnsping的结果可以有三种返回OK表示解析和网络都没问题卡住不动多半是防火墙丢弃了包而不是拒绝了报错则可能是tnsnames.ora配置问题或监听故障。我经常跟团队的人说tnsping就像打前哨的电话通了不保证后面一定顺利但不通就一定进不去。2.2 防火墙与安全组的隐形拦截在云环境或公司内网里最常见的问题就是安全组规则把端口禁了表现为telnet一直卡住直到超时。有时候ping主机是通的telnet 1521却卡住原因可能是防火墙拦了TCP也可能是数据库监听器只绑定了localhost。确认监听绑定地址可以用lsnrctl status看监听端口的“主机”那一项。如果显示的是127.0.0.1或者::1那就说明监听只在本机回环地址上外部机器当然连不进。此时需要修改listener.ora把HOST改为服务器实际IP或者用0.0.0.0表示监听所有地址改完重启监听即可。2.3 容易被忽视的DNS反向解析DNS导致的登录异常往往很隐蔽。客户端连接时把主机名发出去数据库服务器对源IP做反向解析如果DNS解析慢或者解析不到连接就会一直处于“正在连接”的状态最后超时。这类问题最常见于新搭建的环境或者改过网络配置、换了DNS服务器的系统。排查方法是在数据库服务器上手动执行nslookup IP地址看能不能返回正常主机名。如果解析很慢或者失败就可以考虑在sqlnet.ora里加上SQLNET.INBOUND_CONNECT_TIMEOUT参数控制连接超时时间但这只是缓解方案根治还是要理顺DNS的解析配置。3. 监听器排查连接被拒收时先看这里如果说网络层是“道路”监听器就是“收发室”。就算网络全通收发室不加班也没人签收你的连接请求。监听器问题是登录异常里最典型的一类OUI错误码里25段之前的错误大部分都跟监听器有关。3.1 监听器状态检查与启动收到ORA-12541无监听程序时很多人会马上跑过去启动监听但先别急着重启建议按顺序检查先用lsnrctl status看监听的状态如果显示“The listener supports no services”或“Listener is not running”再做处理。启动监听用lsnrctl start启动后再看状态确认服务是否注册。如果监听启动时报TNS-12545: Connect failed because target host or object does not exist多半是listener.ora或hosts文件里的主机名解析有问题。另外端口被占用也常见比如WEB中间件把1521端口占了可以用netstat -an | grep 1521检查端口归属必要时把listener.ora端口改成别的再试。3.2 动态注册与静态注册的坑服务注册分为静态注册和动态注册。静态注册是手动在listener.ora里配置SID_LIST动态注册是实例启动时自动向监听器注册服务。很多人会忽略动态注册的条件数据库实例启动时会根据db_domain和service_name把服务自动注册给本机监听。如果监听先启动时数据库还没起来实例启动后会自动补注册但如果LOCAL_LISTENER参数配置不对动态注册就可能失败。一个很典型的现象是lsnrctl status显示的监听正常但服务列表为空远端连接报ORA-12514或ORA-12505。这时候用数据库本机登录在init.ora或spfile里检查LOCAL_LISTENER和SERVICE_NAMES参数。大多数情况下把LOCAL_LISTENER设置为正确的地址再alter system register手动触发一次注册就能解决。3.3 监听日志里的有效线索监听器的日志文件通常位于$ORACLE_HOME/network/log/listener.log排查疑难杂症时很有用。日志里记录了每一次连接请求的来源IP、协议、服务名和处理结果能帮你看出到底是有人在反复尝试错误的服务名还是某个IP在疯狂地连但都没成功又或者连接请求根本就没到达监听端口。有一次遇到一个间歇性的登录超时问题业务方一口咬定是数据库卡了结果日志显示个别连接在establish之后要等很久才发送认证数据实际是应用连接池配置的重连间隔太长。这类结论如果没有监听日志做依据根本没法说服业务方。4. 认证阶段排查密码、锁定与登录权限网络和监听都通了接下来就是身份校验了。认证阶段的报错最直观常见的就是ORA-01017、ORA-28000、ORA-28001这些也是大多数开发人员最常遇到的登录异常。4.1 ORA-01017与密码问题的处理ORA-01017表示用户名或密码错误。第一次见到时先检查有没有输错密码这是最基础的排错。但要注意这里有个“坑”sqlplus命令行里密码含特殊字符时不加引号会被解析出问题比如密码里有、#、$这些字符时很容易被截断或转义。所以用命令行登录时习惯把密码用双引号括起来或者用sqlplus /nolog再connect的方式避免掉进坑里。如果是应用连接报ORA-01017马上想到的可能是密码被人改了。但还有一个很容易漏掉的情况服务器的配置文件里存的密码有不可见字符比如换行符、制表符复制粘贴时悄悄带上去了。处理方式是先在数据库里确认密码比如select username,account_status from dba_users where usernameXXX再用客户端工具清理掉特殊字符重新配置。4.2 账户锁定与连续失败次数限制ORA-28000是账户被锁定ORA-28002提示密码即将过期。账户锁定绝大多数是因为连续登录失败次数超过了FAILED_LOGIN_ATTEMPTS限制。产生这种情况的原因可能是某个服务的密码被改了却没同步应用还在拿旧密码疯狂重试也可能是存在恶意尝试。处理锁定第一步是确认状态select username,account_status,lock_date from dba_users where usernameXXX然后手动解锁alter user XXX account unlock。但锁定的根源通常不是锁本身而是为什么会有这么多失败尝试。如果找到是哪个应用在重试优先去改应用端的配置否则解了不到半天又会被锁上。4.3 SYSDBA登录与口令文件的关联SYSDBA登录失败是另一类很典型的认证问题。如果你用sys as sysdba登录报ORA-01017密码明明是对的多半跟口令文件有关。Oracle在安装时会生成一个口令文件通常叫orapw实例名里面保存着SYSDBA角色的密码。如果这个文件丢失、损坏或者因为调整过REMOTE_LOGIN_PASSWORDFILE参数远程SYSDBA登录很大概率会失败。处理方法是重新生成口令文件。在数据库主机上执行orapwd file$ORACLE_HOME/dbs/orapw实例名 password新密码 entries10 forcey然后重启数据库再试登录。这个操作直接影响数据库安全性一定要确认是在数据库主机本地执行而且保证新密码强度足够。4.4 操作系统认证的绕过路径如果所有密码层面的排查都没结果还有一个“大杀器”操作系统认证。在数据库主机上以oracle系统用户身份执行sqlplus / as sysdba是不需要输密码的因为它走的是操作系统认证前提是sqlnet.ora里配置了SQLNET.AUTHENTICATION_SERVICESALL或NTS。这个机制的实用性在于你忘了SYS密码进不去库但只要能登录数据库服务器主机、有oracle用户的权限就能通过这个方式进入数据库再重置密码。但要注意如果sqlnet.ora里设置的是NONE操作系统认证会被禁用这时候就只能用口令文件了。这个绕过路径经常被拿来“救急”但不能当着常规方案一直用否则数据库等于对主机用户完全不设防。5. 密码过期与资源限制生产环境最常见登录异常如果说前面那些问题都算“偶发”那密码过期和资源限制就是生产环境的“流行病”。这个我单独拎出来说因为它在实际工作中实在太高频了。5.1 DEFAULT Profile的密码有效期陷阱Oracle安装后的默认Profile里有一个参数PASSWORD_LIFE_TIME默认值是180天。意思是密码最长使用180天就必须改否则第181天开始用户登录就会收到ORA-28001或ORA-28002。在测试、生产环境里DBA接手几个月后经常会突然发现大量账号都到期了晚上业务就报“登录不了”。记得有一次处理“生产库大量账号登录失败”的告警排查到凌晨才发现不是数据库故障、不是网络堵塞纯粹是密码到期时间集中在同一天。因为之前有同事批量初始化了一批账号大家都用同一个初始密码创建时间也接近所以到期时间也挤在一起。5.2 批量排查与统一处理过期账号遇到这种集中过期的情况可以用一条SQL扫出状态select username,account_status,expiry_date from dba_users where account_status not in (OPEN,EXPIRED) order by expiry_date;把过期时间最近的账号列出来。处理方式有两种如果业务允许直接把密码重置成一个新值alter user username identified by 新密码;账号会自动打开且过期时间重新计算。如果不想改密码也可以把Profile的密码有效期调大或改成无限期alter profile default limit password_life_time unlimited;。但这么做前一定要考虑安全合规的要求内部系统可能不在乎但涉及银、政等强监管场景“无限期不换密码”这条经不起审计。折中的做法是把有效期改成180天或90天这样的合理区间同时设置一个提前提醒期比如过期前7天开始给警告让相关责任人来得及改。5.3 资源限制导致的“有密码也登不上”Profile里除了密码有效期还有连接资源限制比如IDLE_TIME会话空闲超时、CONNECT_TIME连接时长上限等。很多应用使用连接池时连接空闲时间一长数据库发现超过了IDLE_TIME限制就会主动断开会话。应用端如果再拿这个断掉的空闲会话去执行SQL就会报连接失效之类的错误。排查这类问题时重点检查应用连接池配置和Profile参数是否匹配。如果业务确实需要长连接且安全要求没那么高可以把IDLE_TIME调大或设为UNLIMITED。但这也要权衡设置太大会导致数据库会话数膨胀挤占资源。6. 登录异常常见问题速查表把这些年的排查经验整理成下面这张速查表遇到问题时先根据报错信息定位到大概率方向再动手验证效率会高很多。报错或现象常见原因优先排查方向ORA-12541监听未启动lsnrctl status启动监听ORA-12514/12505服务名未注册或错误lsnrctl services检查SERVICE_NAMEORA-12545主机或地址不存在检查hosts文件、监听地址连接超时、卡在登录界面防火墙拦截或网络问题telnet端口检查安全组规则ORA-01017用户名或密码错误核对密码注意特殊字符ORA-28000账户锁定解锁账户找出失败原因ORA-28001/28002密码过期重置密码或调整ProfileORA-12560实例未启动或服务不可用主机上sqlplus / as sysdba检查实例状态SYSDBA远程登录失败口令文件问题重新生成orapw文件这张表仅供参考实际报错可能嵌套多层比如ORA-12541的底层原因可能是监听端口被防火墙改成拒绝连接也可能是监听器崩了以后没有自动拉起。所以速查表的作用只是帮你找到第一站后面还得顺着链路一层层验证。7. 个人运维中的几点经验总结登录异常属于“简单但烦人”的问题排查多了以后我慢慢养成了几个习惯在这里分享一下。第一是多看“最近变更”。别看这是一个不起眼的原则真正常见的登录异常都是“某个东西被动过”之后出现的。无论是应用服务器重启、防火墙规则调整、数据库补丁升级还是有人改了密码都可能是异常的直接导火索比对着错误码翻文档有效得多。第二是善用临时日志。监听日志和数据库告警日志配合起来看能还原出异常期间的完整时间线。有一次排查持续了几天的登录偶发失败就是靠监听日志发现某个IP频繁在建连后立即断开顺着IP找到了一个配置错误的应用节点。第三是处理完问题之后一定顺手做两件事在密码管理记录里更新本次变更把报错现象和处置过程整理成一两句话的说明。时间久了这些记录就是自己的排错手册能省很多重复排查的时间。最后想提醒一句登录异常无论多小都不要在有把握之前直接在生产库上执行修改语句。每次动手前想清楚“改了会有什么影响、能不能回滚”这永远是DBA最值得养成的工作习惯。