Oracle数据库连不上了，咋排查问题和解决办法分享

前几天,我们公司测试环境的Oracle数据库突然连不上了，应用服务一直报错，搞得大家都很紧张，我花了一下午时间，总算把问题给解决了，现在我把这次排查问题的整个过程和想到的办法分享一下，万一你以后也遇到类似情况，可以参考一下，整个过程就像侦探破案一样，一步步缩小范围。

第一步：先别慌，检查最基本的“脉搏”和“心跳”

数据库连不上,首先得确认它是死是活，最直接的办法就是登录到存放数据库的那台服务器上（不管是物理机还是虚拟机），看看数据库的核心进程还在不在跑。

具体怎么做呢？打开服务器的命令行窗口（Linux的话用SSH连上去），输入命令：ps -ef | grep ora_ 然后回车，这个命令是查看所有名字里带“ora_”的进程，如果你看到有一大串名字像ora_dbw0_ORCL、ora_lgwr_ORCL这样的进程（ORCL是你的数据库名字），那说明数据库实例本身是启动着的，心脏还在跳，如果啥也看不到，那很可能数据库根本没启动。

如果数据库没启动,那就尝试启动一下，切换到一个有权限的Oracle用户（通常是oracle），然后输入：sqlplus / as sysdba 进入SQL命令行，再输入 startup，如果启动成功，问题可能就解决了，但很多时候会启动失败，并报错，那个错误信息就是最重要的线索，要记下来。

第二步：检查“门卫”——监听器是否在岗

数据库实例即使活着,它也不会直接接待外来的连接请求，它雇了一个“门卫”，叫做监听器，所有应用程序要想连接数据库，都得先经过这个门卫通报，门卫要是偷懒睡觉了，你数据库本身没事，但照样连不上。

检查监听器的命令是：lsnrctl status，同样在服务器命令行里输入，如果监听器正常运行，你会看到一大段信息，里面会写明它正在监听哪些协议地址（比如TCP端口1521），以及它服务了哪些数据库实例，如果提示“TNS-12541: TNS:no listener”之类的错误，那就说明监听器没启动。

解决办法就是启动它：lsnrctl start，启动成功后，再试一下连接，很可能就好了。

第三步：检查“门牌号”和“路线”——网络和连接字符串

如果数据库和监听器都确认是好的,但还是连不上，那问题可能出在“路上”，也就是网络层面，或者是应用程序用来找数据库的“地址条”（连接字符串）。

1. 网络通不通？ 从需要连接数据库的那台应用服务器上，试试能不能ping通数据库服务器的IP地址，如果ping不通，那就是网络故障，得找网络管理员了。
2. 端口开没开？ 光能ping通IP还不够，还得确认数据库监听器所在的端口（默认是1521）是开放的，可以用telnet 数据库IP 1521命令试试，如果窗口一片漆黑，只有一个光标在闪，说明端口是通的；如果马上提示连接失败，说明这个端口被防火墙挡住了，需要去开放端口。
3. 地址条写对了吗？ 这是非常常见的一个坑，检查你的应用程序配置文件里，连接数据库的字符串（比如JDBC URL）是不是写对了，主机名（或IP）、端口号、服务名（或SID），任何一个写错都连不上，最好直接拿一个能成功连接的配置，比如用SQLPlus在数据库本机连一下的命令，来和你的应用配置做对比。

第四步：查看“黑匣子”——日志文件

当以上步骤都查不出问题时,就要祭出终极武器了：看日志，Oracle数据库运行中的各种问题，无论是严重的错误还是警告，都会记录在日志文件里，这是最直接的问题真相来源。

日志文件通常放在一个叫$ORACLE_BASE/diag/rdbms/<数据库名>/<实例名>/trace/的目录下（来源：Oracle数据库管理常识），最重要的两个日志是：

• alert_<实例名>.log：这是数据库的警报日志，记录了数据库启动、关闭、错误、重要操作等所有核心事件，用文本编辑器打开它，直接拉到文件最后，从最新的记录往前看，很可能会发现红色的错误信息。
• listener.log：这是监听器的日志，记录了谁尝试连接、连接成功还是失败等详细信息。

我当时遇到的情况,就是在警报日志的最后，发现了一条错误，大意是某个重要的系统表空间空间不足了，导致数据库虽然进程在，但已经无法正常处理任何请求（来源：实际排查经验），这就是为什么实例进程还在，但死活连不上的原因，解决办法就是清理空间或者扩容表空间，然后重启数据库就好了。

总结一下

当Oracle数据库连不上时,别急着重装或干等，按照从简到繁的顺序来：

1. 查实例：数据库进程在不在？
2. 查监听：门卫监听器在不在？
3. 查网络：网络通不通？端口开没开？地址写没写错？
4. 查日志：最后的手段，也是最准确的手段，看警报日志和监听日志。

大部分问题都出在前三步,希望这个分享能帮到你。