Chensq's BLOG 简洁，高效

从主机上看，CPU长时间消耗怠尽：

load averages:  18.5,  18.8,  14.8;        up 78+23:47:12  09:47:41
241 processes: 224 sleeping, 12 running, 5 on cpu
CPU states:  0.0% idle, 89.8% user, 10.2% kernel,  0.0% iowait,  0.0% swap
Memory: 8192M phys mem, 3283M free mem, 10G swap, 10G free swap
 
   PID USERNAME LWP PRI NICE  SIZE   RES STATE    TIME    CPU COMMAND
 20743 oracle    11  13    0 4293M 2261M run      8:57 18.09% oracle
 21041 oracle    11  13    0 4292M 2260M run      4:36 17.69% oracle
 21853 oracle    11  12    0 4292M 2260M run      0:33 17.30% oracle
 21547 oracle    11  13    0 4292M 2261M cpu      1:13 16.70% oracle
 21261 oracle    11  12    0 4293M 2261M run      1:53 16.50% oracle
 21673 oracle    11  12    0 4291M 2259M run      1:06 16.30% oracle
 21712 oracle    11  13    0 4292M 2260M run      1:03 16.10% oracle
 21848 oracle    11  12    0 4293M 2260M run      0:23 15.90% oracle
 21766 oracle    11  22    0 4304M 2273M cpu      0:26 15.51% oracle
 21732 oracle    11  12    0 4291M 2259M run      1:22 15.11% oracle
 21143 oracle    11  13    0 4293M 2262M run      3:54 13.92% oracle
 21835 oracle    11  42    0 4292M 2260M cpu      0:39 13.92% oracle
 21807 oracle    11  43    0 4291M 2258M sleep    0:50 12.52% oracle
 21869 oracle    11  42    0 4291M 2258M sleep    0:14 12.33% oracle
 21785 oracle    11  14    0 4291M 2259M cpu      0:50 11.73% oracle
 

 从数据库的活动会话中发现有不同会话执行相同的更改操作：

UPDATE PROCESS SET STATUS=’已办结’,END_DATE=SYSDATE,OUT_DATE=SYSDATE   WHERE EVENT_ID=53967 AND ID=636669

 通过分析会话所执行的查询发现，有很多会话执行的查询相同，根据与熟悉应用的相关开发、管理人员交流发现，这部分操作主要是用于统计用户的未办公文及新邮件等，其刷新间隔太短，这给系统带来了额外的性能负担。经协商确认，这个间隔时间可以延长。经开发人员更改应用、重新发布后，CPU负载恢复正常：

load averages:  9.74,  16.4,  14.2;         up 78+23:48:02  09:48:31
241 processes: 238 sleeping, 3 on cpu
CPU states: 46.5% idle, 47.3% user,  4.0% kernel,  2.2% iowait,  0.0% swap
Memory: 8192M phys mem, 3295M free mem, 10G swap, 10G free swap
 
   PID USERNAME LWP PRI NICE  SIZE   RES STATE    TIME    CPU COMMAND
 21807 oracle    11  22    0 4292M 2260M cpu      0:54 24.45% oracle
 21876 oracle    11  40    0 4293M 2261M sleep    0:09 23.06% oracle
 20743 oracle    11  49    0 4293M 2261M sleep    9:05 14.51% oracle
 21653 oracle    11  49    0 4292M 2260M sleep    1:33 11.73% oracle
 21848 oracle    11  60    0 4294M 2262M sleep    0:27 11.73% oracle
 21547 oracle    11  49    0 4292M 2261M sleep    1:18 10.93% oracle
 21673 oracle    11  30    0 4292M 2260M sleep    1:11 10.93% oracle
 21853 oracle    11  49    0 4292M 2260M sleep    0:38 10.74% oracle
 21797 oracle    11  21    0 4294M 2263M cpu      0:29 10.74% oracle
 21732 oracle    11  49    0 4291M 2259M sleep    1:27 10.54% oracle
 21770 oracle    11  49    0 4291M 2258M sleep    1:11  9.34% oracle
 21781 oracle    11  41    0 4292M 2261M sleep    0:54  6.76% oracle
 21785 oracle    11  49    0 4291M 2259M sleep    0:54  6.36% oracle
 21846 oracle    11  49    0 4291M 2259M sleep    0:33  5.77% oracle
 21840 oracle    11  49    0 4291M 2260M sleep    0:12  5.77% oracle

• 2009 年 10 月 24 日 -- Placing a Database into a Quiesced State
• 2009 年 10 月 17 日 -- 某省联通公司CRM系统ORA-04031错误的处理(一)
• 2009 年 11 月 6 日 -- Trace Archivelog Process
• 2010 年 7 月 26 日 -- Encrypting data sent across TCP/IP
• 2011 年 9 月 3 日 -- Linux系统调用列表
• 2010 年 6 月 13 日 -- ORA-600 [KCBGCUR_3] When Running Stored Procedure With Concatenate and Insert
• 2009 年 11 月 14 日 -- VALIDATE STRUCTURE CASCADE ONLINE
• 2011 年 9 月 3 日 -- Aix 6L JFS2 Snapshot
• 2010 年 6 月 13 日 -- ORA-600[kcbgcur_9] With FET$ Table INSERT
• 2010 年 6 月 13 日 -- ORA-00600[kcbgcur]