今天突然发现线上一台oracle 数据库 servercpu 跑的非常高。感觉不是非常正常,细致看了下。发现是smon 进程吃掉了一个cpu。



那么这个smon 进程究竟在倒腾啥玩意

对smon 进程开启10046 跟下不就全明了了么



分析trace 文件就这么一个sql语句 ,这玩意在删smon_scn_time 

delete from smon_scn_time where thread=0 and scn =  (select min(scn) from smon_scn_time where thread=0)



SQL> select count (*) from sys.smon_scn_time; 

  COUNT(*)

----------

     57123





SQL> select object_id from dba_objects where object_name = 'SMON_SCN_TIME'; 

 OBJECT_ID

----------

       575





SQL> select * from v$locked_object where object_id = 575;

    XIDUSN    XIDSLOT     XIDSQN  OBJECT_ID SESSION_ID

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

ORACLE_USERNAME                OS_USER_NAME                   PROCESS

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

LOCKED_MODE

-----------

        27         15      33429        575        164

                               oracle                         30801

          3---行独占锁





查了下mos。找到一个文档 LOCK ON SYS.SMON_SCN_TIME (文档 ID 747745.1)

本故障的现象:

smon 进程在数据库一启动后就会对smon_scn_time 加一个锁。而且永远都不会释放

根本原因是表和索引不一致。每次删除记录为0条,因此删除操作会一直持续,为了保证表中记录小于

最大映射范围值。

With the Partitioning, OLAP and Data Mining options

[oracle@lixora adump]$ sqlplus "/as sysdba"

SQL*Plus: Release 10.2.0.3.0 - Production on Wed Jul 15 09:25:26 2015

Copyright (c) 1982, 2006, Oracle.  All Rights Reserved.

Connected to:

Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production

With the Partitioning, OLAP and Data Mining options



----限制smon更新 smon_scn_time 表

SQL> alter system set events '12500 trace name context forever, level 10 ';

System altered.



---手动清理表记录

SQL> delete from smon_scn_time;

2452 rows deleted.



SQL> commit;

Commit complete.



----关闭限制

SQL> alter system set events '12500 trace name context off ';

System altered.

这里留了一个疑惑?

为什么smon_scn_time 表和索引会不一致呢?

偶遇 smon 进程cpu 开销高异常分析的更多相关文章

  1. systemd --user进程CPU占用高问题分析

    1.问题由来 近期发现堡垒机环境有如下问题,systemd占用大量cpu: 原文链接:https://www.cnblogs.com/yaohong/p/16046670.html 2.问题定位 2. ...

  2. Java进程CPU使用率高排查

    Java进程CPU使用率高排查 生产java应用,CPU使用率一直很高,经常达到100%,通过以下步骤完美解决,分享一下.1.jps 获取Java进程的PID.2.jstack pid >> ...

  3. JVM进程cpu飙高分析

    在项目快速迭代中版本发布频繁  近期上线报错一个JVM导致服务器cpu飙高 但内存充足的原因现象.  对于耗内存的JVM程序来而言,  基本可以断定是线程僵死(死锁.死循环等)问题. 这里是纪录一下排 ...

  4. 性能分析 | Java进程CPU占用高导致的网页请求超时的故障排查

    一.发现问题的系统检查: 一个管理平台门户网页进统计页面提示请求超时,随进服务器操作系统检查load average超过4负载很大,PID为7163的进程占用到了800%多. 二.定位故障 根据这种故 ...

  5. Windows服务器java.exe占用CPU过高问题分析及解决

    最近在测试一个用java语言实现的数据采集接口时发现,接口一旦运行起来,CPU利用率瞬间飙升到85%-95%,一旦停止就恢复到40%以下,这让我不得不面对以前从未关注过的程序性能问题. 在硬着头皮查找 ...

  6. java进程CPU飙高

    因为这段时间一直在弄监控,但是工作还是在进行中 因为机器不多,所以今天早上巡检了一下,看到一台生产机器上的CPU飙高 top

  7. db2 cpu使用率高问题分析处理

    性能调优步骤 明确问题->收集数据->分析数据->细化.定位问题->优化 环境: db2 问题:%usr CPU高,大约99%,db2sysc进程使用的最多 收集数据 ---系 ...

  8. HBase Thrift2 CPU过高问题分析

    目录 目录 1 1. 现象描述 1 2. 问题定位 2 3. 解决方案 5 4. 相关代码 5 1. 现象描述 外界连接9090端口均超时,但telnet端口总是成功.使用top命令观察,发现单个线程 ...

  9. Linux 线程占用CPU过高定位分析

    今天朋友问我一个Linux程序CPU占用涨停了,该如何分析, CPU占用过高,模拟CPU占用过高的情况 先上一段代码: #include <iostream> #include <t ...

随机推荐

  1. Oracle 整理

    高效分页 select * from ( select rownum r,a from yourtable order by name ) --之所以没有把<=20放在最外面,也就是我一直用的写 ...

  2. Windows下安装Redis并注册为服务

    1.安装 下载地址:https://github.com/MSOpenTech/redis/releases. Redis 支持 32 位和 64 位.这个需要根据你系统平台的实际情况选择,这里我们下 ...

  3. 【linux高级程序设计】(第十一章)System V进程间通信 4

    共享内存 共享内存主要用于实现进程间大量数据传输. 共享内存的数据结构定义: 系统对共享内存的限制: 共享内存与管道的对比: 可以看到,共享内存的优势: 1.共享内存只需复制2次,而管道需要4次 2. ...

  4. poj 3026(BFS+最小生成树)

    Borg Maze Time Limit: 1000MS   Memory Limit: 65536K Total Submissions: 12032   Accepted: 3932 Descri ...

  5. 如何配置openjdk的 java home

    https://blog.csdn.net/redmoon729/article/details/51671354

  6. VS217下载码云服务器项目

    按下图打开VS2017团队资源管理器的管理连接 ,本地GIT存储库下面输入远程GIT存储库URL地址和保存到本地的地址即可将远程项目下载到本地,下载完成后,关闭VS2017重新打开这个项目就可以进行源 ...

  7. 01Trie树【p2420】 让我们异或吧

    Description 异或是一种神奇的运算,大部分人把它总结成不进位加法. 在生活中-xor运算也很常见.比如,对于一个问题的回答,是为1,否为0.那么: (A是否是男生 )xor( B是否是男生) ...

  8. shell spool

    If you wish to use SQL*Plus Command-line , you'll simply issue the sqlplus command from your shell: ...

  9. bzoj 5346: tree (其实是是某次雅礼集训的题)

    用prufer序列的公式直接dp,O(n^4)的算法简简单单就写出来了23333. 按理说 O(n^4)是需要优化成O(n^3)才能过的,然鹅我也不知道我怎么过了23333 (那就懒得优化了hhhhh ...

  10. La 4976 Defense lines

    蓝书紫书上都有的一道题...这里就懒得说题解了. 但是我竟然WA了6次!为什么呢??? 一开始没看见连续子序列..... 后来插入的时候忘判断了是不是比前驱大.... 所以我们只需要维护一个权值递增( ...