[原]记一次处理Oracle死会话的过程
2010-06-21 23:08
351 查看
今天检查Oracle的时候发现有一台Oracle的CPU占用率不太正常,现象是某一个进程会话占用很多CPU而且占用时间很长:
整个世界都安静了。
# top -u oracle top - 22:24:54 up 186 days, 6:50, 4 users, load average: 2.57, 2.53, 2.33 Tasks: 179 total, 2 running, 177 sleeping, 0 stopped, 0 zombie Cpu0 : 0.3% us, 0.0% sy, 0.0% ni, 98.3% id, 1.3% wa, 0.0% hi, 0.0% si Cpu1 : 16.9% us, 6.0% sy, 0.0% ni, 0.0% id, 77.1% wa, 0.0% hi, 0.0% si Cpu2 : 73.8% us, 24.5% sy, 0.0% ni, 1.7% id, 0.0% wa, 0.0% hi, 0.0% si Cpu3 : 2.7% us, 0.3% sy, 0.0% ni, 94.0% id, 3.0% wa, 0.0% hi, 0.0% si Mem: 8165004k total, 8124392k used, 40612k free, 7520k buffers Swap: 2031608k total, 113680k used, 1917928k free, 6181492k cached PID USER PR NI %CPU TIME+ %MEM VIRT RES SHR S COMMAND 21752 oracle 25 0 99 37633:19 12.2 2187m 970m 963m R oracle 27111 oracle 15 0 4 3720:27 4.1 2205m 324m 307m D oracle 2045 oracle 16 0 0 0:01.29 0.8 2184m 67m 61m S oracle 5456 oracle 16 0 0 0:00.04 0.2 2182m 16m 12m S oracle 6057 oracle 16 0 0 4:30.34 0.1 65188 9m 6236 S tnslsnr 从top可以看到PID为21752的进程占用了很多的CPU,而运行的时间很长了。 使用以下语句找出对应的会话:sys$mydb@mailserver SQL>]exec sys.dbms_system.set_sql_trace_in_session(129,12900,true); -- 等一段时间 exec sys.dbms_system.set_sql_trace_in_session(129,12900,false);
郁闷的是竟然没有生成一个trc文件。
再看看该会话正在跑的SQL:sys$mydb@mailserver SQL> alter system kill session '&sid,&serial' ; Enter value for sid: 129 Enter value for serial: 12900 old 1: alter system kill session '&sid,&serial' new 1: alter system kill session '129,12900' System altered. Elapsed: 00:00:01.02
再用top看一下:
[root@mailserver ~]# top -u oracle
top - 22:54:55 up 186 days, 7:20, 4 users, load average: 0.63, 0.96, 1.23
Tasks: 186 total, 1 running, 185 sleeping, 0 stopped, 0 zombie
Cpu0 : 0.0% us, 0.0% sy, 0.0% ni, 100.0% id, 0.0% wa, 0.0% hi, 0.0% si
Cpu1 : 1.7% us, 0.0% sy, 0.0% ni, 90.0% id, 8.3% wa, 0.0% hi, 0.0% si
Cpu2 : 0.0% us, 0.0% sy, 0.0% ni, 100.0% id, 0.0% wa, 0.0% hi, 0.0% si
Cpu3 : 0.0% us, 0.0% sy, 0.0% ni, 100.0% id, 0.0% wa, 0.0% hi, 0.0% si
Mem: 8165004k total, 8102144k used, 62860k free, 16052k buffers
Swap: 2031608k total, 113440k used, 1918168k free, 6208748k cached
PID USER PR NI %CPU TIME+ %MEM VIRT RES SHR S COMMAND
2045 oracle 16 0 0 0:01.29 0.8 2184m 67m 61m S oracle
5456 oracle 16 0 0 0:00.04 0.2 2182m 16m 12m S oracle
6057 oracle 16 0 0 4:30.39 0.1 65188 9m 6236 S tnslsnr
6652 oracle 16 0 0 0:59.26 0.1 7800 6224 1556 S perl
整个世界都安静了。
相关文章推荐
- 案例解决:一次oracle掉电的处理过程[转]
- 一次oracle无法启动处理过程
- 一次Oracle故障处理过程
- 一次Oracle宕机切换后产生ORA错误的处理过程
- [原]工欲善其事,必先利其器,记一次处理Oracle Listener挂掉的处理过程
- 一次oracle掉电的处理过程
- 一次Oracle启动失败的处理过程
- HTTP 之 一次完整的http请求处理过程
- 网上一次MySQL中文乱码问题的处理过程
- oracle存储过程中单引号及字符串拼接处理
- 可上局域网不能上互联网的一次处理过程
- Oracle 一次 锁表 处理小记
- 一次ARP攻击的处理过程
- Oracle 11.2.0.2.0 RAC环境一次内存溢出ORA-04031问题的处理
- ORACLE在存储过程中记录日志的处理包
- 记一次Oracle数据恢复过程
- Oracle SQL语句处理的过程(一)
- oracle表连接——处理连接过程中另外一张表没有相关数据不显示问题
- 一次网络严重丢包的故障处理过程 推荐
- 使用Oracle自带的系统包和过程监控其它会话SQL语句的执行计划等信息