Oracle 的 ORA-01012 这个报错干的年头久了基本都会碰到一次。尤其用 Navicat 连的时候体验特别“魔幻”——数据库好像没挂监听看着也活着结果一点“连接测试”啪一下弹出来ORA-01012: not logged on换密码、换连接方式、重启电脑都不一定管用。我最早遇到这个错的时候也差点走向“重装大法”后来把来龙去脉捋清楚才发现这错误背后的逻辑其实特别简单就是实例状态和监听状态“错位”了。这篇文章把我自己的排查过程和解决步骤完整写出来给同样被这个报错卡住的同学一个可以照抄的操作路径。1. 先说清楚ORA-01012 到底在抱怨什么1.1 错误信息与触发场景ORA-01012: not logged on这行字本身极容易误导人它最容易让人联想到“用户名/密码不对”但实际上密码错误报的是ORA-01017: invalid username/password; logon denied和 01012 完全两码事。Oracle 的官方文档对 01012 的解释是用户在 Oracle 实例中未被登录或该会话的逻辑连接已不存在。但放到实际生产环境里我们遇到的绝大多数 01012本质上是下面这样一个过程客户端Navicat向监听器发出连接请求监听器接受了这个请求并尝试在实例中为其创建一个专用的 Server Process这个 Server Process 在准备访问 SGA共享内存区时却发现实例当前并不处于正常的OPEN状态于是实例直接拒绝建立会话返回ORA-01012。换句话说监听器“接客”了但实例“没开门”。最典型的几种触发场景数据库执行了SHUTDOWN ABORT之后实例残留进程没有完全退场或者处于需要恢复的中间状态数据库实例被外部强制终止断电、服务器被硬重启、杀进程没有走正常关闭流程监听器是静态注册实例已经关了但监听器依然活跃并且继续接收连接请求数据库刚启动到一半还在STARTUP的恢复阶段此时连接同样可能报 01012。1.2 同样一台机器为什么 Navicat 报错、sqlplus 却没事很多人在 Server 本机上用 sqlplus 去连发现可以连上然后就会怀疑是不是 Navicat 配置有问题。这里有个关键机制差异。sqlplus 在本机执行sqlplus / as sysdba时默认走的是bequeath继承式本地连接不通过网络监听器而是直接继承当前操作系统用户上下文创建一个本地 Server Process。打个不恰当的比方这就好比你直接敲内部员工通道的门门卫认出你是内部员工哪怕公司大门监听那边挂着“暂停营业”你也能进到办公楼。而 Navicat 连接 Oracle 数据库时走的是标准的 TCP/IP 监听器路径。连接请求发给 1521 端口监听器进行调度再创建 Server Process。此时如果实例状态不对监听器这边就“一夫当关”直接把错误抛回来了。所以遇到这种情况第一步不是去怀疑密码或 Navicat 配置而是先确认实例到底活着没有监听器到底处于什么状态2. 排查五步走先别急着重启按这个顺序看2.1 第一步看监听器状态在数据库服务器上执行lsnrctl status看输出里的Services Summary服务摘要部分。这里有两种典型情况信息量完全不同。第一种动态注册Service ORCLPDB1 has 1 instance(s). Instance orcl, status READY, has 1 handler(s) for this service...status READY表示实例处于正常运行状态并且已把自己的服务动态注册到了监听器上。如果实例关掉了动态注册的服务会自动从监听器列表里消失。第二种静态注册Service ORCL has 1 instance(s). Instance orcl, status UNKNOWN, has 3 handler(s) for this service...status UNKNOWN是静态注册的典型标志。它表示监听器配置里手动写死了这个服务无论实例是否启动监听器都会把这个服务列出来。这是一个非常重要的信号如果你的lsnrctl status里服务状态是 UNKNOWN而 Navicat 连接又报 ORA-01012基本就可以锁定问题方向了。2.2 第二步看实例进程与 sqlplus 能不能进在服务器上用系统命令确认实例进程是否存在Linux / Unixps -ef | grep smon ps -ef | grep pmon正常情况下会看到类似ora_smon_orcl和ora_pmon_orcl的进程。如果这两个进程都没了说明实例确实没起来。Windows 上则打开“服务管理器”查看OracleServiceORCLSID 根据实际实例名替换这个服务是否为“已启动”状态。接着再用 sqlplus 做一次本地验证sqlplus / as sysdba如果能够进入 SQL 命令行执行SELECT STATUS FROM V$INSTANCE;看到OPEN说明实例正常看到STARTED或MOUNTED说明实例处于非正常状态如果 sqlplus 连接时也报 ORA-01012那说明实例正处于一种“半死不活”的中间状态尤其需要处理。2.3 第三步看 Alert 日志确认实例最近发生了什么这一步很多人会忽略但往往能直接给出结论。Oracle 实例的运行日志在$ORACLE_BASE/diag/rdbms/db_name/sid/trace/alert_sid.logWindows 下类似例如C:\app\oracle\diag\rdbms\orcl\orcl\trace\alert_orcl.log打开日志文件拉到最后重点看有没有这些关键信息Shutdown abort说明数据库是被强制关闭的重启后极可能需要实例恢复ORA-00600或ORA-07445说明遇到内部错误导致实例崩溃terminating instance说明实例被异常终止。我们手上碰到的大多数 01012日志最后往往就是一行Shutdown abort。看到这行基本上结论就清晰了实例残留了异常状态重启它即可。2.4 第四步检查 listener.ora 是动态还是静态注册找到监听配置文件listener.ora一般位于$ORACLE_HOME/network/admin/目录下。典型的静态注册配置长这样SID_LIST_LISTENER (SID_LIST (SID_DESC (GLOBAL_DBNAME ORCL) (ORACLE_HOME /u01/app/oracle/product/19.0.0/dbhome_1) (SID_NAME ORCL) ) ) LISTENER (DESCRIPTION (ADDRESS (PROTOCOL TCP)(HOST dbserver)(PORT 1521)) )注意这里写死了GLOBAL_DBNAME和SID_NAME只要监听器进程启动它就会一直把这个服务保留在注册列表里哪怕实例早已关闭。这就是为什么你lsnrctl status能看到服务但一点连接就报 01012 的直接原因——监听器以为服务还在实例却不在了于是两边脱节。2.5 第五步在 Navicat 侧做最小化验证服务端排查的同时客户端这边也别闲着做几个快速验证把变量减到最小。第一确认网络层通不通。在运行 Navicat 的机器上执行telnet 数据库服务器IP 1521如果端口不通说明问题根本不在 Oracle而在防火墙或监听器本身。第二检查 Navicat 连接配置里的“服务名”和“SID”。Navicat 里连接 Oracle 有两种模式一种填 SID数据库实例名一种填 Service Name服务名。很多实际环境里数据库的 Service Name 和 SID 并不相同填错会导致连接行为异常。建议两个都试一下并确保 Service Name 的大小写与数据库中SERVICE_NAMES参数一致。第三如果条件允许换一个客户端工具DBeaver、PL/SQL Developer在同一台机器上做同样连接测试。如果换工具之后报错信息变了比如变成ORA-12514或ORA-12170那说明问题可能和 Navicat 自带的 Oracle 客户端库有关这个问题我们后面单开一节说。3. 实操记录一个“shutdown abort 静态监听”引发的典型事故3.1 现场环境与现象有一次我接手了一个 Windows Server 2019 Oracle 19c 的环境业务方反馈 Navicat 连不上数据库客户端报的正是ORA-01012: not logged on。用他们的话说“上午还能用中午不知道谁动了什么下午就全连不上了”。我拿到现场信息之后先问了一句今天有没有人重启过服务器或者手动关过数据库业务方一顿查证结果是机房的同事在中午做了电源维护服务器被强制断电重启了。问题马上就指向了Oracle 实例没有正常关闭而是被硬生生断电了。3.2 排查过程实录我在服务器上先执行lsnrctl status输出显示监听器正常并且在服务摘要里能看到Service ORCL has 1 instance(s)Instance orcl, status UNKNOWN。注意这个 UNKNOWN它就是一个静态注册的典型信号。继续往下查发现listener.ora里确实配置了静态 SID_LIST这就能解释为什么监听器还坚挺。之后尝试本地 sqlplussqlplus / as sysdba结果连 sqlplus 也报 ORA-01012说明实例的“残留状态”已经严重到本地进程都无法建立新的会话了。再翻 alert 日志最后几行Shutdown abort initiated by user非常典型的强制断电后实例没有真正退出的痕迹。此时再去看进程Oracle 的相关后台进程其实已经不在了但共享内存段和信号量可能还有残留导致实例处于一种“存在又不存在”的诡异状态。3.3 解决步骤到了这一步处理思路就很明确了把实例强制收敛到干净状态然后重新启动。首先如果 sqlplus 直接sqlplus / as sysdba进不去就先sqlplus /nolog然后在 SQLPLUS 内部执行CONNECT / AS SYSDBA注意这一步是在操作系统用户具备 Oracle DBA 组权限的前提下。如果CONNECT时仍然报 ORA-01012说明连本地连接也无法建立会话那就换一个更“暴力”的方式直接清理残留的 Oracle 进程和共享内存。在 Windows 上先到任务管理器里确认没有oracle.exe进程如果有结束掉然后重新启动 Oracle 服务。清理干净之后再按正常顺序拉起数据库SQL STARTUP如果 STARTUP 报“实例已启动”则可以强制重启SQL STARTUP FORCE;STARTUP FORCE这个命令相当于先执行一次SHUTDOWN ABORT再立即 STARTUP非常省事很适合处理这种实例状态异常的情况。实例启动之后回到操作系统命令行重启一下监听器确保监听器里的实例状态从 UNKNOWN 更新成 READYlsnrctl stop lsnrctl start然后再次lsnrctl status确认服务摘要里已经变成status READY。此时我在 Navicat 里重新点击连接测试正常通过问题解决。3.4 这次排障里最坑的两个细节第一Oracle 服务启动比实例启动“滞后”。在 Windows 上OracleServiceORCL服务状态显示“已启动”并不等于实例已经 OPEN。服务进程可以启动但实例可能还处于恢复中所以看到服务已启动别急着下结论务必用sqlplus或lsnrctl status来验证实例本身的真实状态。第二动态注册有时间延迟。实例 STARTUP 成功之后PMON 进程需要一段时间短则十几秒长则一两分钟才能把服务信息动态注册到监听器上。如果你手太快刚 STARTUP 完就去lsnrctl status看到的可能依然是空的或 UNKNOWN。这时候可以手动触发注册SQL ALTER SYSTEM REGISTER;执行完再查lsnrctl status服务状态通常立刻就会变成 READY。这个小命令在实战中相当好用值得记一下。4. 如果常规步骤解决不了翻这几个“冷门角落”4.1 Windows 上 Oracle 服务的“假启动”有些 Windows 服务器上Oracle 服务显示“已启动”但实例根本没起来。这种情况最阴间的地方在于服务管理器里一切正常防火墙正常监听器正常但 Navicat 一连接就报 01012 或者 ORA-12514。出现这种现象多半是 Oracle 服务启动脚本出问题了或者上次实例异常关闭后服务本身虽然拉起了进程但实例没有完成自动恢复就一直卡在了一个不上不下的状态。建议做法在 Windows 服务管理器里先停止OracleServiceORCL再启动它。如果启动失败去 Windows 事件查看器里看 Oracle 相关的错误日志。有时候还需要检查ORACLE_HOME环境变量是否损坏——很多装错或迁移过 Oracle 的机器服务里指向的 ORACLE_HOME 已经不存在了服务当然只能“假启动”。我曾经遇到过一个案例服务路径指向的oradim.exe文件被杀毒软件隔离了导致实例一直无法真正启动但 Oracle 的监听器和其他组件又一切正常。最后是重新运行了 ORADIM 重建服务才解决问题。4.2 连接串SID、Service Name 和 TNS 别名Navicat 连接 Oracle 数据库时连接配置里有一个容易忽视的选项连接模式是选择 SID 还是 Service Name。很多人习惯性填 SID但实际上当前主流 Oracle 版本里大家更常使用的是 Service Name。SID 和 Service Name 的区别简单理解就是SID 是实例的“小名”Service Name 是数据库对外的“大名”。同一个数据库对外可能注册了多个 Service Name。在tnsnames.ora里我们看到的是这种形式ORCL (DESCRIPTION (ADDRESS (PROTOCOL TCP)(HOST 192.168.1.10)(PORT 1521)) (CONNECT_DATA (SERVICE_NAME ORCLPDB1) ) )这里填的是SERVICE_NAME不是 SID。如果你在 Navicat 里填的是 SIDORCL而实际服务名是 ORCLPDB1连接也会出问题但报错往往不是 01012而可能是 ORA-12514服务未找到。不过有些特殊配置下报错的表现形式就是 01012。所以排查时顺手把两种模式都试一下十秒钟的事但能排除一个大类问题。4.3 Navicat 自带的 Oracle 客户端与 OCI 版本不匹配Navicat 连接 Oracle 时默认使用它自带的 Oracle 客户端连接库OCIOracle Call Interface。如果数据库版本比较老比如 11g而 Navicat 默认使用的是高版本 OCI可能会出现兼容性问题表现就是连接过程中握手失败、会话被异常断开报错内容五花八门包括 ORA-01012。解决思路不复杂在 Navicat 的“选项”里找到“OCI 环境”设置把 OCI 库切换成和数据库版本匹配的 Oracle Instant Client。Navicat 里通常在“工具 - 选项 - 连接 - Oracle - OCI 环境”中设置选择对应版本如 11g 用 instantclient_11_219c 用 instantclient_19_x的 DLL 所在目录。换完 OCI 之后重启 Navicat很多时候问题会直接消失。这个点非常适合那种“数据库和监听都没问题但 Navicat 就是连不上”的场景。4.4 防火墙和杀毒软件导致的连接被“半路掐断”还有一种“伪装成 01012”的诡异情况其实不是 Oracle 报错而是网络链路在握手过程中被防火墙或杀毒软件中断。这类问题在 Windows 环境特别常见。Navicat 发出连接请求监听器接受并创建 Server Process但过程中某一次网络数据包被拦截导致 Server Process 以为客户端“消失了”于是终止会话。此时客户端服务端两边看到的错误都可能是 ORA-01012 或 ORA-03113。排查方式先在服务器本地用 sqlplus 连接确认实例和监听正常然后在客户端机器用 telnet 测试 1521 端口看看会不会出现“端口通但立即断开”的现象最后临时关闭杀毒软件/防火墙仅测试阶段再连接如果问题消失就是安全软件拦截无疑。5. 预防思路从根源上避免再次踩坑5.1 把规范关库流程变成肌肉记忆ORA-01012 这个错误的高发场景几乎都是数据库没有正常关闭留下的后遗症。所以最有效的“解药”不是出了问题怎么修而是从源头减少异常关闭。生产环境里尽量别用SHUTDOWN ABORT除非实例真的无法正常关闭。规范流程是SQL SHUTDOWN IMMEDIATE;IMMEDIATE会回滚未提交事务并强制断开会话速度已经很快了绝大部分场景都用它。SHUTDOWN TRANSACTIONAL和SHUTDOWN NORMAL适合更看重复用连接的环境但等待时间长日常维护没必要。如果你是在 Windows 服务器上还要注意别直接重启机器。重启之前务必先把 Oracle 服务停掉或者手动执行 SHUTDOWN 命令。否则等于反复给 Oracle 上“断电演练”早晚要出问题。5.2 精简 listener.ora能动态注册就别手动写死我见过太多的listener.ora是从老项目里复制过来的SID_LIST 一写就是好几年也不管实例还在不在。这种静态注册配置最大的问题就是实例已经关了监听器还在“装熟”导致客户端拿到的是莫名其妙的 01012而不是一个明确的一致的错误码。单实例环境其实完全没必要写静态 SID_LIST。把listener.ora做成最简形式LISTENER (DESCRIPTION (ADDRESS (PROTOCOL TCP)(HOST dbserver)(PORT 1521)) )然后让 PMON 自动把实例注册上去最省心。这样实例一关监听器自动不接这个服务的连接请求客户端会得到一个明确的“服务未找到”或“无监听”类的错误排查起来一目了然。当然RAC 环境或者需要远程访问共享监听的特殊场景静态注册还是必要的。这就是另外的话题了至少单实例环境动态注册才是更健康的状态。5.3 用脚本做常态巡检别等问题发生才想起来说得难听一点ORA-01012 这种问题大多发生在“没人盯着”的时间段。与其等业务方喊你不如提前做一点小工具。Linux 上可以用一个简单的 shell 脚本放到 crontab 里定时跑#!/bin/bash source ~/.bash_profile STATUS$(sqlplus -s / as sysdba EOF SET PAGESIZE 0 FEEDBACK OFF VERIFY OFF HEADING OFF ECHO OFF SELECT STATUS FROM V\$INSTANCE; EXIT; EOF ) if [ $STATUS ! OPEN ]; then echo Database is not OPEN, current status: $STATUS fiWindows 上用 PowerShell 也能实现类似逻辑定时检查lsnrctl status里有没有 READY 状态以及V$INSTANCE的 STATUS 是不是 OPEN。这样真出问题时报警信息能直接告诉你实例状态不用再去翻排查链路了。5.4 Navicat 侧的几个实用设置Navicat 里有两个设置值得顺手做掉一个是在连接属性里把“连接超时”和“执行超时”调到一个相对合理的值不要用默认的 0永久等待这样遇到实例状态不对时Navicat 能更快地报错退出而不是卡在等待状态。另一个是如果日常开发需要频繁连接可以开启动态刷新和自动重连机制。Navicat 的“连接属性”里有一个“保持连接”相关选项勾选之后它会定时发送一个心跳语句保活。这不能解决 ORA-01012但能避免因为连接闲置被数据库侧杀掉的问题整体上省心一些。写在最后的经验ORA-01012 这个错误根本上就是我开头那句话监听器接客了但实例没开门。把这句话理解透了排查方向就永远错不了。先看实例状态再看监听状态然后动手把实例拉起来路径非常清晰。我个人实际操作下来最有用的一个小习惯是在数据库服务器上备一个“一键体检”脚本把lsnrctl status、ps -ef | grep smon、sqlplus -s / as sysdba查 V$INSTANCE这几条命令打到同一个脚本文件里出问题先跑一遍十有八九能直接定位。这个习惯帮我省下了大量重复排查时间也从没让我在处理 ORA-01012 时陷入过“重装大法”的境地。如果你遇到同样的问题别慌先跑一遍上面的五步排查绝大多数情况都能用 STARTUP 或者 STARTUP FORCE 安全解决。做完这几步之后再回来看看这篇文章你会有一种“原来就这么点事”的顿悟感。