Oracle 12c始终使用100％CPU

Question

我在Java EE项目中使用Oracle 12c数据库。但是在每次安装Oracle数据库后，总是在确定的时间（大约1周）之后，在使用CPU 100％之后启动。我尝试使用Windows Server，之后又尝试将Suse Linux与oracle 12c Databse一起使用，但结果相同。这是我目前针对Oracle 12c和Suse Linux的CPU详细信息。

这是我的Java连接详细信息-

    String User = "X";
    String Pass = "123";
    String Url = "jdbc:oracle:thin:@localhost:1521:orcl";
    Class.forName("oracle.jdbc.driver.OracleDriver");
    conn = DriverManager.getConnection(Url, User, Pass);
    return conn;

还有我每次从那里调用数据库的数据访问文件过程-

String status="";
Connection conns= DB_Connection.getConnection();

try{
    ps = conn.prepareStatement("SELECT * FROM TABLE");
    rs = ps.executeQuery();
    if(rs.next()){
        status=rs.getInt("ID");
    }
} catch(Exception e){
    out.print("ERROR"+e);
} finally {
    try { rs.close(); } catch (Exception e) {}
    try { ps.close(); } catch (Exception e) {}
    try { conns.close(); } catch (Exception e) {}
}

所以您能建议问题出在哪里或者我可以怎么解决这个问题？

Answer 1

您可以通过以下SQL查找使用CPU最多的会话及其正在运行的SQL：

with sqlarea as (select inst_id , sql_text, hash_value
, CASE WHEN elapsed_time > 2*86399*1000000
THEN '2 ' || to_char(to_date(round((elapsed_time-(2*86399*1000000))/decode(executions, 0, 1, executions)/1000000) ,'SSSSS'), 'HH24:MI:SS') 
WHEN elapsed_time > 86399*1000000
THEN '1 ' || to_char(to_date(round((elapsed_time-(86399*1000000))/decode(executions, 0, 1, executions)/1000000) ,'SSSSS'), 'HH24:MI:SS') 
WHEN elapsed_time <= 86399*1000000
THEN to_char(to_date(round(elapsed_time/decode(executions, 0, 1, executions)/1000000) ,'SSSSS'), 'HH24:MI:SS') 
END
as time_per_execution
from gv$sqlarea a where 1=1 )
, scan as (select max('FULL SCAN') scan, sp.hash_value
from gv$sql_plan sp 
where (sp.operation like '%TABLE%' or sp.operation like '%MAT_VIEW%')
      and sp.options in ('FULL', 'ALL')
group by sp.hash_value
) 
, sess as
(
SELECT sess.sid, sess.serial#, sess.inst_id
     , sess.username
     , OSUSER
     , stat.value sess_CPU
     , sess.status
     , sess.sql_hash_value
     , sess.sql_id
     , sess.machine 
     , sess.logon_time
     , sess.terminal, sess.program, sess.last_call_et
FROM gv$sesstat stat, v$statname name, gv$session sess
WHERE stat.statistic# = name.statistic#
AND sess.sid = stat.sid
AND username is not null
AND sess.inst_id = stat.inst_id
AND name.name='CPU used by this session'
ORDER BY stat.value desc
)
SELECT sess.sid, sess.serial#, sess.inst_id
     , sess.username
     , OSUSER
     , sess.status
     , sess.sql_hash_value
     , sess.sql_id
     , sess.sess_CPU
, time_per_execution time_per_exec
, (select max(scan) from scan where scan.hash_value = sess.sql_hash_value) scan
, sql_text
     , sess.machine MACHINE_NAME
     , TO_CHAR(sess.logon_time,'DD-MON HH24:MI:SS') LOGON_TIME
     , sess.terminal, sess.program, sess.last_call_et
FROM sess, sqlarea
WHERE sess.sql_hash_value = sqlarea.hash_value and sess.inst_id = sqlarea.inst_id 
order by sess.sess_CPU desc
;

此外，根据您获得连接的方式，登录风暴**可能会占用大量CPU资源。

** Logon Storm：登录风暴的特征是客户端连接请求数量突然激增，或者客户端连接请求数量异常多连接。由于启动数据库会话的过程是CPU密集的登录风暴可能会导致意想不到的后果例如：连接错误，等待CPU的应用程序，超时，较差的响应时间，对同一台计算机上其他数据库的影响，等待时间在实例上运行的所有内容，…。根登录风暴的原因通常可以追溯到不当连接池设置或使用会话进行连接的应用程序，然后断开连接。