登录/ 注册
 找回密码
 立即注册
关闭

CSDN热搜

豆瓜网 精品问答 技术交流 资源下载
返回列表 发新帖
首页 › 业界区 › 业界 ›故障处理：Oracle 19.20未知BUG导致oraagent进程内存泄 ...

故障处理：Oracle 19.20未知BUG导致oraagent进程内存泄漏的案例处理

庾芷秋 2025-7-24 23:19:48
我们的文章会在微信公众号IT民工的龙马人生和博客网站( www.htz.pw )同步更新 ，欢迎关注收藏，也欢迎大家转载，但是请在文章开始地方标注文章出处，谢谢！
由于博客中有大量代码，通过页面浏览效果更佳。
今天朋友在做数据库巡检过程中发现一个19.20的备库环境中oraagent进程存在内存的异常，让帮忙分析一下原因。19.20的版本相对来说已经算19C非常新的，常见的内存的泄漏的BUG在这个版本中已经得到修复。让朋友开了一下远程，简单通过几个脚本和查看CRS的日志，大概定位到原因，但是目前在Mos中未搜到对应的BUG，怀疑是19C中未知的BUG，下面将整个分析过程简单的梳理一下：
故障现象

查询操作系统进程的使用排序，这里看到oraagent的物理内存达到16G，远远超过正常环境（正常环境在19.20大概就是100M多一点）
  1. [root@orastd tmp]# ./hmem|more
  2. PID      NAME                     VIRT(kB)   SHARED(kB)      RSS(kB)  PRIVATE(kB)
  3. 2102     oraagent.bin             18212328        47160     16215456     16215456
复制代码
数据库版本

获得数据库的版本为19.20
  1. [grid@orastd trace]$ $ORACLE_HOME/OPatch/opatch lspatches
  3. 35332537;ACFS RELEASE UPDATE 19.20.0.0.0 (35332537)
  4. 35320081;Database Release Update : 19.20.0.0.230718 (35320081)
  5. 33575402;DBWLM RELEASE UPDATE 19.0.0.0.0 (33575402)
复制代码
分析过程

获得内存使用详细信息

获得内存的详细信息
  1. [root@orastd tmp]# ./hmem -l|more
  2. PID      NAME                     VIRT(kB)   SHARED(kB)      RSS(kB)  PRIVATE(kB)    RssAnon    RssFile   RssShmem      VmRSS     VmData
  3. 2102     oraagent.bin             18212328        47160     16215456     16215456   16168296      47160          0   16215456   17850384
复制代码
RssAnon标识进程的私有内存，常住在内存中，其实可以理解为DATA部分的内存，这里可以肯定oraagent存在内存泄漏了。
查看oraagent日志

oraagent部分一直不断的在重复显示下面内容，这里面有个奇怪的现象就是ora.LISTENER.lsnr，但是我集群中并没有这个资源
  1. 2025-07-24 23:04:11.272 : USRTHRD:3858700032: [     INFO] {0:0:2} LsnrAgent::generateEndPoints 2040 Listener ResName:ora.LISTENER.lsnr
  2. 2025-07-24 23:04:11.272 : USRTHRD:3858700032: [     INFO] {0:0:2} LsnrAgent::generateHostName entry lsnrResName:ora.LISTENER.lsnr
  3. 2025-07-24 23:04:11.272 : USRTHRD:3858700032: [     INFO] {0:0:2} LsnrAgent::getLsnrResNameAddrType &s_lsnrResNametoAddrTypeXLock:0x55555a209718get resname:ora.LISTENER.lsnr addressType
  4. 2025-07-24 23:04:11.272 : USRTHRD:3858700032: [     INFO] {0:0:2} LsnrAgent::getAddressTypeValue 000 entry { actx:(nil) lsnrName:ora.LISTENER.lsnr
  5. 2025-07-24 23:04:11.277 : USRTHRD:3858700032: [     INFO] {0:0:2} Agent::getValueFromNetwork 000 { get netParam:ADDRESS_TYPE from vipResName: defaultNetRes: tag:
  6. 2025-07-24 23:04:11.277 : USRTHRD:3858700032: [     INFO] {0:0:2} Agent::getValueFromNetwork 999 } netParam:ADDRESS_TYPE vipResName: defaultNetRes: networkResName: netParamValue:IPV4
  7. 2025-07-24 23:04:11.277 : USRTHRD:3858700032: [     INFO] {0:0:2} LsnrAgent::getAddressTypeValue 220 lsnrResNametoAddrType lsnrNetworkMap lsnrName:ora.LISTENER.lsnr networkResName:
  8. 2025-07-24 23:04:11.277 : USRTHRD:3858700032: [     INFO] {0:0:2} LsnrAgent::getLsnrResNameAddrType &s_lsnrResNametoAddrTypeXLock:0x55555a209718lsnrNetworkMap[ora.LISTENER.lsnr]: networkAddressTypeMap[]:IPV4
  9. 2025-07-24 23:04:11.277 : USRTHRD:3858700032: [     INFO] {0:0:2} LsnrAgent::generateHostName getNodeName 1
  10. 2025-07-24 23:04:11.278 : USRTHRD:3858700032: [     INFO] {0:0:2} LsnrAgent::generateHostName exit hostIP:192.168.1.223  hostIPV6:
  11. 2025-07-24 23:04:11.281 : USRTHRD:3858700032: [     INFO] {0:0:2} checkCrsRet clscrsret: 5
  12. 2025-07-24 23:04:11.281 : USRTHRD:3858700032: [     INFO] {0:0:2} CrsCmd::ClscrsCmdData:statGetAttr 040 error getting attribute:ENDPOINTS@SERVERNAME(orastd)
  13. 2025-07-24 23:04:11.281 : USRTHRD:3858700032: [     INFO] {0:0:2} CrsCmd::statGetAttr 120 error
  14. 2025-07-24 23:04:11.284 : USRTHRD:3858700032: [     INFO] {0:0:2} LsnrAgent::generateEndPoints 2311 lsnrResName:ora.LISTENER.lsnr endpAttr:TCP:1521
  15. 2025-07-24 23:04:11.284 : USRTHRD:3858700032: [     INFO] {0:0:2} LsnrAgent::ifFirewallParam entry
  16. 2025-07-24 23:04:11.284 : USRTHRD:3858700032: [     INFO] {0:0:2} LsnrAgent::ifFirewallParam exit
  17. 2025-07-24 23:04:11.284 : USRTHRD:3858700032: [     INFO] {0:0:2} LsnrAgent::generateEndPoints 2511 type:2 vipVector endpString:(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.1.223)(PORT=1521))
  18. 2025-07-24 23:04:11.284 : USRTHRD:3858700032: [     INFO] {0:0:2} LsnrAgent::removeDuplicates
  19. 2025-07-24 23:04:11.284 : USRTHRD:3858700032: [     INFO] {0:0:2} LsnrAgent::generateEndPoints 1999 exit }
复制代码
因为是备库环境，监听用的1522端口，所以没有默认的ora.LISTENER.lsnr，难道跟这个有关系？
监控oraagent内存的变换

可以看到每个10分钟，大概新增加如下的物理内存的使用量。
  1. [root@orastd tmp]# sh ./count_diff_rss.sh  /tmp/ps_2102.log
  2. 2025-07-24 14:13:14: 164
  3. 2025-07-24 14:23:15: 96
  4. 2025-07-24 14:33:15: 272
  5. 2025-07-24 14:43:15: 164
  6. 2025-07-24 14:53:15: 184
  7. 2025-07-24 15:03:15: 72
  8. 2025-07-24 15:13:15: 180
  9. 2025-07-24 15:23:15: 140
  10. 2025-07-24 15:33:15: 192
  11. 2025-07-24 15:43:15: 156
  12. 2025-07-24 15:53:16: 184
  13. 2025-07-24 16:03:16: 196
  14. 2025-07-24 16:13:16: 164
  15. 2025-07-24 16:23:16: 148
  16. 2025-07-24 16:33:16: 228
  17. 2025-07-24 16:43:16: 164
  18. 2025-07-24 16:53:16: 196
  19. 2025-07-24 17:03:16: 92
  20. 2025-07-24 17:13:16: 264
  21. 2025-07-24 17:23:16: 176
  22. 2025-07-24 17:33:16: 180
  23. 2025-07-24 17:43:16: 160
  24. 2025-07-24 17:53:16: 200
  25. 2025-07-24 18:03:16: 164
  26. 2025-07-24 18:13:16: 76
  27. 2025-07-24 18:23:17: 292
  28. 2025-07-24 18:33:17: 48
  29. 2025-07-24 18:43:17: 184
  30. 2025-07-24 18:53:17: 168
  31. 2025-07-24 19:03:17: 128
  32. 2025-07-24 19:13:17: 196
  33. 2025-07-24 19:23:17: 192
  34. 2025-07-24 19:33:17: 144
  35. 2025-07-24 19:43:17: 220
  36. 2025-07-24 19:53:17: 164
  37. 2025-07-24 20:03:18: 200
  38. 2025-07-24 20:13:18: 112
  39. 2025-07-24 20:23:18: 232
  40. 2025-07-24 20:33:18: 192
  41. 2025-07-24 20:43:18: 184
  42. 2025-07-24 20:53:18: 160
  43. 2025-07-24 21:03:18: 192
  44. 2025-07-24 21:13:18: 164
  45. 2025-07-24 21:23:18: 84
复制代码
解决方案

从上面的日志中可以怀疑oraagent在不断判断对listener的资源时可能异常，导致申请的内存一直不释放，并且不断重复上述过程，所以使得内存不断增加。
新建监听

新建监听，并启动监听
  1. [grid@orastd ~]$ srvctl add listener
  2. [grid@orastd ~]$ srvctl start listener -l listener
复制代码
观察内存使用量

新建监听后，内存的使用未有明显变化，所以这里大概就猜测是的原因就是oraagent内部判断监听资源时异常，导致内存不释放
手动释放oraagent的内存资源

oraagent进程负责grid用户下面资源的启停，是一个可以手动kill的进程，所以这里采用手动的方式。
kill oragent进程
  1. [grid@orastd ~]$ ps -ef|grep oraagent
  2. grid      2102     1 18  2024 ?        102-00:56:17 /oracle/app/19.3.0/grid/bin/oraagent.bin
  3. grid     41122 40551  0 23:05 pts/0    00:00:00 tail -1000f ohasd_oraagent_grid.trc
  4. grid     41317 40748  0 23:06 pts/1    00:00:00 grep --color=auto oraagent
  5. [grid@orastd ~]$ kill -9 2102
复制代码
查看启动日志信息

ohasd进程负责oraagent进程的启动，有如下的信息：
  1. 2025-07-24 23:06:38.834 : CRSCOMM:3643938560: [     INFO]  IpcL: connection to member 4 has been removed
  2. 2025-07-24 23:06:38.834 :CLSFRAME:3643938560: [     INFO]  Removing IPC Member:{Relative|Node:0|Process:4|Type:3}
  3. 2025-07-24 23:06:38.834 :CLSFRAME:3643938560: [     INFO]  Disconnected from AGENT process: {Relative|Node:0|Process:4|Type:3}
  4. 2025-07-24 23:06:38.835 :    AGFW:3637634816: [     INFO] {0:0:23496} Agfw Proxy Server received process disconnected notification, count=1
  5. 2025-07-24 23:06:38.835 :    AGFW:3637634816: [     INFO] {0:0:23496} /oracle/app/19.3.0/grid/bin/oraagent_grid disconnected.
  6. 2025-07-24 23:06:38.835 :    AGFW:3637634816: [     INFO] {0:0:23496} Agent /oracle/app/19.3.0/grid/bin/oraagent_grid[2102] stopped!
  7. 2025-07-24 23:06:38.835 : CRSCOMM:3637634816: [     INFO] {0:0:23496} IpcL: removeConnection: Member 4 does not exist in pending or formed connections.
  8. 2025-07-24 23:06:38.835 : CRSCOMM:3637634816: [    ERROR] [FFAIL]{0:0:23496} IpcL: Failed to disconnect member 4 rc = 4
  9. 2025-07-24 23:06:38.835 :   CRSPE:1879045888: [     INFO] {0:0:23497} Disconnected from server:
  10. 2025-07-24 23:06:38.835 :    AGFW:3637634816: [     INFO] {0:0:23496} Restarting the agent /oracle/app/19.3.0/grid/bin/oraagent_grid
  11. 2025-07-24 23:06:38.835 :    AGFW:3637634816: [     INFO] {0:0:23496} Starting the agent: /oracle/app/19.3.0/grid/bin/oraagent with user id: grid and incarnation:3
  12. 2025-07-24 23:06:38.844 :    AGFW:3637634816: [     INFO] {0:0:23496} Starting the HB [Interval =  30000, misscount = 6kill allowed=1] for agent: /oracle/app/19.3.0/grid/bin/oraagent_grid
  13. 2025-07-24 23:06:38.930 : CRSCOMM:3643938560: [     INFO]  IpcL: Accepted connection 16497 from user grid member number 7
复制代码
oraagent进程自己的日志：
  1. 2025-07-24 23:06:30.319 :    AGFW:3846092544: [     INFO] {0:0:2} Agent received the message: AGENT_HB[Engine] ID 12293:687689824
  2. Trace file /oracle/app/grid/diag/crs/orastd/crs/trace/ohasd_oraagent_grid.trc
  3. Oracle Database 19c Clusterware Release 19.0.0.0.0 - Production
  4. Version 19.20.0.0.0 Copyright 1996, 2023 Oracle. All rights reserved.
  5.     CLSB:4160626432: [     INFO] Argument count (argc) for this daemon is 1
  6.     CLSB:4160626432: [     INFO] Argument 0 is: /oracle/app/19.3.0/grid/bin/oraagent.bin
  7. 2025-07-24 23:06:38.927 : default:4160626432: clsu_load_ENV_levels: Failure to retrieve ORA_DAEMON_LOGGING_LEVELS environment variable [-1] [21104].
  8. 2025-07-24 23:06:38.927 :   AGENT:4160626432: [     INFO]  Logging level for Module: clsdadr  2
  9. 2025-07-24 23:06:38.927 :   AGENT:4160626432: [     INFO]  Logging level for Module: clsdstat  2
  10. 2025-07-24 23:06:38.927 :   AGENT:4160626432: [     INFO]  Logging level for Module: clsdnreg  0
  11. 2025-07-24 23:06:38.927 :   AGENT:4160626432: [     INFO]  Logging level for Module: clsdynam  0
  12. 2025-07-24 23:06:38.927 :   AGENT:4160626432: [     INFO]  Logging level for Module: allcomp  0
  13. 2025-07-24 23:06:38.927 :   AGENT:4160626432: [     INFO]  Logging level for Module: default  0
  14. 2025-07-24 23:06:38.927 :   AGENT:4160626432: [     INFO]  Logging level for Module: clsdimt  0
  15. 2025-07-24 23:06:38.927 :   AGENT:4160626432: [     INFO]  Logging level for Module: CLSCAL  0
复制代码
crs的alet日志如下：
  1. 2024-01-06 20:37:59.966 [OCSSD(2281)]CRS-1720: Cluster Synchronization Services daemon (CSSD) is ready for operation.
  2. 2025-07-24 23:06:38.917 [ORAAGENT(41326)]CRS-8500: Oracle Clusterware ORAAGENT process is starting with operating system process ID 41326
复制代码
最新oraagent进程内存

这里看到内存使用量从16G降到了不到100M，需要进程使用物理内存会有少量增加，大体上不会超过200M。
  1. [root@orastd tmp]# ./hmem|grep oraagent
  2. 41326    oraagent.bin              2482880        46268        96284        96284
  5. [root@orastd tmp]# ./hmem -l |head -1 && ./hmem -l |grep oraagent
  6. PID      NAME                     VIRT(kB)   SHARED(kB)      RSS(kB)  PRIVATE(kB)    RssAnon    RssFile   RssShmem      VmRSS     VmData
  7. 41326    oraagent.bin              2482880        46268        96288        96288      50020      46268          0      96288    2120936
复制代码
总结

本案例展示了在Oracle 19.20环境下，oraagent进程出现内存泄漏的实际处理过程。通过对系统进程、内存使用、日志信息的细致排查，发现oraagent不断尝试处理一个并不存在的监听资源（ora.LISTENER.lsnr），导致内存持续增长，最终远超正常值。虽然尝试新建监听未能缓解问题，但通过手动重启oraagent进程，内存占用恢复正常，间接验证了进程本身存在异常分配和释放内存的问题。
提示：

  • 即使在较新版本的Oracle 19C中，依然可能遇到未被官方收录的BUG，遇到异常现象时要善于通过日志和系统工具定位问题根源。
  • oraagent进程的内存异常增长，往往与资源配置或内部异常循环有关，及时关注日志中的异常提示（如不存在的监听资源）有助于快速定位问题。
  • 对于oraagent等可安全重启的进程，适当的重启操作可以临时缓解内存泄漏带来的影响，但建议后续持续关注官方补丁和MOS文档，及时获取修复方案。
  • 日常巡检中，建议定期监控关键进程的内存使用情况，发现异常及时处理，避免影响数据库集群的稳定性。
  • 最重要的就是环境搭建的规范化，这次的内存泄漏，明显是由于在部署备库环境时，未完全按照Oracle环境的最佳实践来部署，最佳实践是一个永无休止的根据大量真实案例来不断的更新。
  • 建议将数据库版本升级到最新的补丁包，不要想到当前没有出现故障，就不升级。当前没有出现故障，并不代表着环境中不存在隐患，甚至有可能是已经出现了隐患，但是没有被发现，就如这个案例一样，如果不是朋友的细心，估计备库环境中oraagent泄漏的问题不会提前发现，等生产系统容灾切换到备库后，到时出现内存不足，影响数据库稳定性和性能，此时估计就是重大故障了。最新的补丁包其实都是在修复BUG，并没有引入新的功能，修复的BUG越多，也就意味着环境越稳定。
------------------作者介绍-----------------------
姓名：黄廷忠
现就职：Oracle中国高级服务团队
曾就职：OceanBase、云和恩墨、东方龙马等
电话、微信、QQ：18081072613
个人博客: (http://www.htz.pw)
CSDN地址: (https://blog.csdn.net/wwwhtzpw)
博客园地址: (https://www.cnblogs.com/www-htz-pw)
1.png


来源：豆瓜网用户自行投稿发布，如果侵权，请联系站长删除
处理故障Oracle未知BUG

使用道具 举报

相关推荐
B Color Image Link Quote Code Smilies
您需要登录后才可以回帖 登录 | 立即注册
发帖
庾芷秋
2025-7-24 23:19:48

0

粉丝关注

17

主题发布

板块介绍填写区域，请于后台编辑
微信扫一扫