解决ORA-3136(二)——找出货源

本文针对ORA-12516错误进行排查,通过定位问题源头机器并获取其IP地址,最终确定解决方案。

    修改过以后先好点,过一段时间还是报错ORA-12516:TNS: 监听程序找不到符合协议堆栈要求的可用处理程,看一下session数,又快要满了,看来要仔细查查看了。

首先,我们看一下哪台机器搞鬼。

SQL> select MACHINE,count(*)fromv$session groupby MACHINE



我们发现tvmall这台机器在搞什么飞机啊,怎么多连接,问了一下是谁的机器,都说不知道。想想看利用TERMINAL字段能不能把ip查出来。

SQL> selectutl_inaddr.get_host_address(terminal)fromv$session where machine='tvmall';

 

UTL_INADDR.GET_HOST_ADDRESS(TERMINAL)

--------------------------------------------------------------------------------

202.102.110.206

202.102.110.206

202.102.110.206

202.102.110.206

202.102.110.206

202.102.110.206

不行,那我们可以利用其它方法了。


1)我们利用v$session和v$process视图把进程id拿出来

SELECT s.machine,p.*

  FROMv$session s,v$process p

 WHERE s.PADDR =p.ADDR AND S.MACHINE ='tvmall';

2)通过netstat-natp |grep $PID在linux里把ip找出来

[oracle@SHOW-100-12 admin]$ netstat-natp|grep 86

(Not all processes could be identified,non-owned process info

 willnot be shown, you would have to be root to see it all.)

tcp       0      0 192.168.100.12:1521         192.168.8.41:55654          ESTABLISHED 16186/oraclejscn

3)让这家伙把程序里面的连接重新修改。


<think> 嗯,用户这次是专门来查询ORA-3136错误的解决方案啊。从ta引用的四份材料来看,应该是个Oracle DBA或者运维人员,正在处理生产环境中的连接超时问题。用户特意强调了“不是真正需求”,说明ta需要的是经过整合的、可直接操作的解决方案。 翻看之前对话历史,系统要求用$...$格式标注数学公式,不过这次问题纯粹是Oracle错误代码解析,基本用不到数学符号。倒是要注意把引用标记[^n]自然地融入解答中。 用户引用的四份材料很有价值: 1)Metalink指出三大主因:恶意连接、认证超时、服务器过载 2)补充说明要检查本地连接和网络延迟 3)提到客户端会收到不同错误代码 4)虽然提到ORA-445但和当前问题关联不大 用户可能真正着急的是:生产环境正在不断报错,需要立刻止损。所以要把解决方案按优先级排序: - 先给临时解决措施(调整超时参数) - 再给根本解决路径(性能分析) - 最后给出诊断工具链(日志检查顺序) 特别注意引用[2]提到的排查链条:本地连接→网络延迟→数据库性能→关键错误。这个思路要整合到解决方案里,形成递进式排查步骤。另外客户端错误代码(ORA-12547/12637)的对应关系也要说明,用户可能在排查时遇到。 最后考虑用户可能需要预防措施,补充监控建议。不过引用里没提RAC环境,这点暂时保留。如果用户后续追问再展开为好。 </think> 基于引用内容,ORA-3136错误("WARNING: inbound connection timed out")主要发生在客户端连接数据库时认证超时。以下是原因分析与解决方案整理: --- ### **错误原因** 1. **恶意连接攻击** 非授权客户端尝试连接数据库,服务器主动终止连接[^1]。 2. **认证过程超时** - 默认认证超时时间为 **60秒** - 可能原因: - 网络延迟过高(如跨地域连接)[^2] - 客户端身份验证信息复杂(如LDAP集成) - 数据库性能严重下降(CPU/IO资源耗尽)[^1][^2] 3. **数据库服务器高负载** - 资源竞争导致无法及时处理连接请求 - 常见诱因: - 低效SQL语句或长时间运行的事务[^1] - 系统级错误(如ORA-600、ORA-7445)[^2] --- ### **解决方案** #### **1. 紧急缓解措施(临时方案)** ```sql -- 修改sqlnet.ora参数(需重启监听) SQLNET.INBOUND_CONNECT_TIMEOUT = 120 -- 单位:秒(建议阶梯式增加) INBOUND_CONNECT_TIMEOUT_<listener_name> = 120 -- 指定监听器名称[^2] ``` > **注意**:此操作仅延长超时阈值,需同步排查根本原因。 #### **2. 根因分析与修复** - **检查网络延迟** - 在数据库服务器执行 `tnsping <客户端IP>` 或 `ping` 测试[^2] - 若延迟>100ms,需协同网络团队优化路由。 - **验证本地连接速度** ```bash sqlplus / as sysdba # 本地连接测试响应时间[^2] ``` - 若本地连接慢 → 检查数据库实例状态(`top`、`vmstat`) - **分析数据库负载** - 生成报错时段的AWR报告: ```sql exec dbms_workload_repository.create_snapshot(); ``` - 重点关注: - `LOAD PROFILE` 中的硬解析/事务数 - `Top 5 Timed Events`(等待事件) - 高CPU消耗的SQL(`SQL ordered by CPU Time`)[^1] - **检查关键错误日志** - 排查 `alert_<SID>.log` 中的 **ORA-600**、**ORA-7445** 等致命错误[^2] - 检查 `sqlnet.log` 定位触发ORA-3136的客户端IP[^1][^3] #### **3. 安全加固(针对恶意连接)** - 配置防火墙规则,限制访问源IP - 启用数据库访问控制列表(ACL) - 监控无效连接尝试频率 --- ### **关键诊断文件** | 文件类型 | 路径示例 | 关键信息 | |-------------------|-----------------------------|--------------------------| | `sqlnet.log` | `$ORACLE_BASE/diag/rdbms/...` | 触发错误的客户端IP [^1][^3] | | `alert_<SID>.log` | `$ORACLE_BASE/diag/rdbms/...` | ORA-600/ORA-7445等错误 [^2] | | AWR报告 | `@?/rdbms/admin/awrrpt.sql` | 数据库负载峰值详情 [^1] | --- ### **补充说明** - 客户端表现:连接超时后可能返回 **ORA-12547**(连接中断)或 **ORA-12637**(数据包接收失败)[^3] - **ORA-445(共享内存冲突)** 与此错误无关,多为ASLR(地址空间随机化)引起[^4],需单独处理。 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值