Oracle监听程序在哪个服务器？Oracle监听怎么查看？

Oracle监听程序运行在数据库服务器上，也就是你安装Oracle数据库软件的那台机器。监听程序不是独立软件，它附着于数据库主机的进程体系，下面把它的位置、判断方法和常见配置场景拆开讲清楚。

oracle监听程序默认配置在哪个服务器

监听程序（Listener）是Oracle数据库对外提供连接服务的“守门员”，它负责接收客户端发来的连接请求，验证后转发给对应的数据库实例，从这个职责就能判断，它必须和数据库实例在同一台物理机或虚拟机上,否则无法完成本地转发。

监听程序与数据库实例的绑定关系

监听程序通过listener.ora文件定义服务端口和协议地址，该文件默认存放在$ORACLE_HOME/network/admin目录下，而$ORACLE_HOME就是数据库软件的安装路径，自然在数据库服务器上，如果你在一台只装了客户端的机器上执行lsnrctl status，系统会直接提示找不到监听程序,因为客户端不包含监听组件。

如何快速定位监听所在的服务器

• 在数据库服务器上执行lsnrctl status，如果返回监听运行信息，说明监听就在本机
• 在客户端机器上执行tnsping 数据库IP，能通说明监听在对应IP的服务器上运行
• 查看tnsnames.ora中的HOST字段，这个地址指向的就是监听程序所在的服务器

监听程序的物理位置特征

行业共识认为，一个数据库环境中的监听进程数通常非常有限绝大多数场景下只有1个，监听1521端口，如果需要多个端口或协议支持，你可以在同一台服务器上配置多个监听名称，但位置不变,仍然在数据库主机上运行。

oracle监听1521端口在哪台服务器上确认方法

实际运维中，确认监听在哪台服务器这件事，比想象中容易踩坑,下面给出几条可落地的排查路径。

使用netstat检查端口归属

在数据库服务器上执行：

netstat -an | grep 1521

如果看到LISTEN状态且IP地址为0.0.0或具体网卡地址，说明监听在该主机上工作正常，如果你在另一台机器上执行同样命令，通常什么都查不到,这就反过来印证了监听的归属。

通过lsnrctl命令查看监听详情

lsnrctl status listener

返回信息中有一项Listener Log File，上面直接写明日志文件的绝对路径，比如/u01/app/oracle/diag/tnsnames/listener.log，这个路径本身就是服务器本机的文件系统结构,看到这个路径等同确认了监听的物理位置。

多网卡环境下的服务器判断

数据库服务器可能配置了多个网卡IP，监听默认监听所有可用地址，此时在客户端执行tnsping 192.168.1.10如果能通，但tnsping 192.168.2.10不通，说明监听在这台服务器的第一张网卡上正常工作,第二张网卡的地址没有被监听绑定。

监听程序配置在服务器上的标准工作流程

理解了监听所在位置，接下来看它在服务器上是如何完成连接接入的，这一部分帮助你从“知道在哪”升级到“知道怎么回事”。

监听的工作流程细节

1. 客户端发起连接请求，携带目标服务的SERVICE_NAME或SID
2. 监听进程接收请求，检查该服务是否已注册到自身
3. 若服务已注册，监听告诉客户端数据库实例的地址，同时建立转发通道
4. 连接建立后，监听退出双方的通信链路，后续数据交互由客户端和实例直接完成

服务注册机制决定监听可见性

数据库实例启动时，PMON进程会自动向本机监听注册服务名和实例名，这就是为什么监听和实例必须在同一台服务器上跨机器的服务注册需要额外配置REMOTE_LISTENER参数，属于RAC或Data Guard等高级环境,不在常规范围内。

本地监听和远程监听的本质差异

远程监听并不改变监听程序的常规位置，它只出现在Oracle RAC架构中，监听程序可以运行在独立服务器上，但生产环境中更常见的是每个节点各跑一个监听,实现负载均衡。

linux oracle数据库监听启动命令在服务器上怎么执行

真正上手操作时，容易遇到的第一个坎就是：你在客户端机器上找不到可用的监听命令，因为lsnrctl是服务器端工具,客户端环境默认不安装。

服务器端监听操作全流程

以Linux环境为例：

su - oracle
cd $ORACLE_HOME/bin
./lsnrctl start
./lsnrctl status

注意这里必须以oracle系统用户执行，用root会报权限错误。lsnrctl start默认启动名为LISTENER的监听,如果需要启动自定义名称的监听：

./lsnrctl start listener_1522

监听日志的位置判断

日志默认写在$ORACLE_HOME/network/log/listener.log，这个文件能帮你确认监听重启次数、来自哪些IP的连接请求、失败原因，排查远程用户连接报错时,先看日志再猜配置。

防火墙对监听访问的限制

即使监听程序已经在服务器上正常启动，操作系统防火墙也会拦截外部访问,需要在数据库服务器上放行1521端口的TCP入站流量：

firewall-cmd --add-port=1521/tcp --permanent
firewall-cmd --reload

不改防火墙，客户端用tnsping能通但sqlplus连接超时的情况,多半是端口没放行。

监听被恶意占用它还在原来服务器上吗

安全事件中偶尔出现监听端口被其他进程冒名顶替的情况，这时候端口还在,但监听程序已经不在你原来的服务器上了。

判断端口上运行的进程身份

在数据库服务器上执行：

lsof -i:1521

正常情况下返回的是tnslsnr进程，路径指向$ORACLE_HOME/bin/tnslsnr，如果返回的是其他进程名，比如nc、python、perl，说明端口被恶意程序占用,主动连接监听会落入攻击者设置的陷阱。

攻击行为的服务器痕迹

该类攻击通常发生在数据库服务器被弱口令爆破后，攻击者在目标服务器上植入后门工具，替换原监听进程或直接抢占1521端口，排查时除了检查监听进程，还要查看/tmp、/var/tmp下是否有近期创建的可疑文件，同时检查crontab中是否有陌生定时任务。

恢复步骤简述

• 终止恶意进程：kill -9 恶意PID
• 重启原监听：lsnrctl start
• 修改数据库账号口令：alter user system identified by 新口令
• 检查网络连接：排查外部何处IP在持续连接1521端口

oracle监听程序启动失败排查正确服务器位置

启动监听报错TNS-12541: TNS:no listener或TNS-01103，不少人第一反应是配置写错,但相当一部分根源在于监听程序和配置文件的位置不对应。

配置文件与监听进程错位场景

管理员在/home/oracle/network/admin下手动创建了listener.ora，而实际监听程序默认读取的是$ORACLE_HOME/network/admin/listener.ora，两个文件错位导致启动异常,但看起来配置文件又真实存在。

正确操作是在服务器上查看环境变量确认读取路径：

echo $ORACLE_HOME

然后对比$ORACLE_HOME/network/admin是否与预期一致。

主机名解析失败导致监听地址无效

listener.ora中如果写HOST=数据库主机名，而服务器上/etc/hosts没有该主机名的解析条目，监听会启动失败或仅监听在回环地址上，此时修改listener.ora中的HOST为服务器实际IP地址，或补全/etc/hosts条目,再重启监听。

oracle监听配置适合在哪个服务器环境实践

不同规模环境中，监听程序的部署位置有细微差异，结合数据库架构的演进速度,这一部分帮你判断自己当前环境该按什么思路来看待监听位置问题。

传统物理机环境

监听程序在数据库主机上运行，直接使用主机网卡对外提供连接服务，延迟最低，中小型企业使用这种架构的比例相当大，维护简单,排查链路短。

云数据库环境

云厂商提供的RDS数据库服务中，监听程序由云平台统一管理，用户看不到监听进程，也不允许自行启停监听，这时候“监听在哪个服务器”这个问题的答案是：在云厂商管理面内部的数据库节点上,不向用户暴露。

容器化部署环境

Oracle官方建议在容器中运行数据库时，监听程序与数据库实例位于同一个Pod内，容器重建后监听随之重建，外部通过服务暴露端口接入，这个场景中监听程序所在“服务器”是容器本身,而非宿主机直连。

Q&A：关于oracle监听程序在哪个服务器的常见疑问

客户端机器上的oracle安装包带了监听程序吗？

不带，Oracle客户端软件只包含连接工具和驱动，不包含监听组件，在客户端机器上执行lsnrctl会提示命令不存在,监听程序只存在于数据库服务器端的Oracle软件安装中。

oracle监听程序在哪个服务器上配置listener.ora更合适？

必须在数据库服务器上配置，把listener.ora放在客户端或跳板机上没有任何实际意义，因为监听进程不会在那些机器上运行,配置文件的位置和监听进程的启动必须保持在同一个服务器上。

如何从客户端确认监听程序所在服务器的IP地址？

查看tnsnames.ora中连接描述符的HOST字段，该字段记录的就是监听程序所在服务器的IP或主机名，执行tnsping 该地址能收到响应,即可确认监听程序正在该服务器的1521端口上运行。