1. Server Has 100% Of Cpu Because Of Dbresp.pl [ID 764140.1]
5. ________________________________________
6. Modified:07-Feb-2012 Type:PROBLEM Status:MODERATED Priority:3
7. Comments (0)
8. To Bottom
13. In this Document
14. Symptoms
15. Cause
16. Solution
17. References
18. ________________________________________
19. This document is being delivered to you via Oracle Support's Rapid Visibility (RaV) process and therefore has not been subject to an independent technical review.
20. Applies to:
21. Enterprise Manager Base Platform - Version: 10.2.0.1 and later [Release: 10.2 and later ]
22. Information in this document applies to any platform.
23. ***Checked for relevance on 07-Feb-2012***
24. Symptoms
25. Server has 100% of CPU because of dbresp.pl . There are more than 50 process from this script
27. emagent.trc shows:
28. 2009-01-21 10:19:50 Thread-4099931040 WARN engine: Missing Properties : [limitSwitch]
29. 2009-01-21 10:19:50 Thread-4099931040 ERROR engine: [oracle_database,orcl, alertLog] : nmeegd_GetMetricData failed : Missing Properties : [limitSwitch]
30. 2009-01-22 06:54:33 Thread-4105165728 ERROR fetchlets.oslinetok: Metric execution timed out in 600 seconds
31. 2009-01-22 06:54:33 Thread-4105165728 ERROR command: failed to kill process 4793 running perl: ( errno = 3 : No such process)
32. 2009-01-22 06:54:33 Thread-4105165728 ERROR engine: [oracle_database,orlc, Response] : nmeegd_GetMetricData failed : Metric execution timed out in 600 seconds
33. Cause
34. The Response metric is making a timed out then the Agent starts other process to take the Response metric. The process to kill the PID taking the Response metric is failing increasing the process running dbresp.pl
36. Before the Response metric starts to do the timed out there is other error:
37. 2009-01-21 10:19:50 Thread-4099931040 WARN engine: Missing Properties : [limitSwitch]
38. 2009-01-21 10:19:50 Thread-4099931040 ERROR engine: [oracle_database,orcl,alertLog] :
39. nmeegd_GetMetricData failed : Missing Properties : [limitSwitch]
40. Solution
41. 1. Stop DBConsole
43. emctl stop dbconsole
45. 2. Kill any running process.
47. ps -ef | grep /opt/app/oracle/ < hostname > _ < sid >
49. Kill any returned process.
51. 3. Follow fix
53. Note.361612.1 Ext/Mod Problem Performance Agent High CPU Consumption Gen
55. 4. Start DB Console
57. emctl start dbconsole

二、根据这个解决方法，我先关闭oem，关闭之前我先介绍一下我的系统与数据库的环境 系统版本为

1. oracleserver:~ # cat /etc/SuSE
2. SuSE-release  SuSEconfig/
3. oracleserver:~ # cat /etc/SuSE-release
4. SUSE Linux Enterprise Server 10 (x86_64)
5. VERSION = 10
6. PATCHLEVEL = 3

数据库版本为

1. SQL > select * from v$version;
3. BANNER
4. ----------------------------------------------------------------
5. Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bi
6. PL/SQL Release 10.2.0.1.0 - Production
7. CORE    10.2.0.1.0  Production
8. TNS for Linux: Version 10.2.0.1.0 - Production
9. NLSRTL Version 10.2.0.1.0 - Production

1、先登录oracle用户，然后关闭oem 这里需要注意的是，关闭oem的时候，刚开始什么提示都没有，查看系统的日志与oracle的报警日志也都没有任何的提示，但大家还是需要耐心 的等待，我这步操作在30分钟的时候才完成了，当你运行完命令的时候，如果发现没有提示，那我建议还是多等一会比较好，不用发现没有提示就ctrl+c终 止这个命令。 2、杀掉perl进程 oem关闭了，我们在查看一下内存与perl进程 perl进程 还是2726个，没有变化 55m空闲 下面我们杀掉perl进程，使用 kill -9 $(ps -ef|grep perl|grep -v grep|awk '{print $2}') 然后在查看perl进程 现在perl进程没有了 查看一下内存 现在内存已经有6673m了，恢复正常 查看一下负载 现在负载变为正常了，负载这1分钟的为3.15,5分钟的为242.76,15分钟的为1236.57， 虽然负载为3，但我的服务器内为16核，所有负载为3没有问题 服务器cpu核数 现在问题解决了，如果想开启oem监控oracle的话，在oracle用户下使用emctl start dbconsole就可以。 提示：很多数据库的故障，在解决的时候，我建议大家还是先确定问题是如何产生的，找到解决问题的思路与方法，如果有metalink账号的话， 最好登陆里面搜索问题产生的原因与解决方法，不太建议在百度或者谷歌里搜索问题解决方法，因为很多问题在百度或者谷歌里搜索的答案不一定准确或者适合你， 如果你的生产库出现了问题，你按照百度或者故障里的解决方法解决，同时你也不明白问题的产生原因与解决的思路、办法的话，那么你只能拼运气来解决问题，解 决了还好，皆大欢喜，如果没有解决甚至产生更坏的影响的话，估计你离走人不远了。

本文出自 “ 吟—技术交流 ” 博客，请务必保留此出处 http://dl528888.blog.51cto.com/2382721/911535

一、介绍   由于dba离职，所以公司所有的oracle数据库服务器我先兼职管理，今天登陆某省的数据库，发现ssh登陆30秒左右才进入，之后查看了一下负载与内存，具体情况如下图：负载：没有见过这样高的负载，以前见过最多的就是负责1000多，java的问题内存：连交换内存都使用完了，物理内存就剩下71m了，太危险了top：发现了6个僵尸进...