偶遇 smon 進程cpu 開銷高異常分析，smoncpu

偶遇 smon 進程cpu 開銷高異常分析，smoncpu
今天突然發現線上一台oracle 資料庫 伺服器cpu 跑的很高，感覺不是很正常，仔細看了下；發現是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 表和索引會不一致呢？

著作權聲明：本文為博主原創文章，未經博主允許不得轉載。