Oracle 12c 始终使用 100% CPU答案

【问题标题】：Oracle 12c Using 100% CPU AlltimeOracle 12c 始终使用 100% CPU
【发布时间】：2020-02-03 12:03:08
【问题描述】：

我在我的 Java EE 项目中使用 Oracle 12c 数据库。但是在每次安装 Oracle 数据库之后，它总是在安装后使用 CPU 100% 在一定时间（大约 1 周） 之后。我尝试使用 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) {}
}

那么您能否建议问题出在哪里或我可以做些什么来解决这个问题？

【问题讨论】：

您的表中有多少行，您多久调用一次，您是否使用连接池？
在某些表中大约有 8,00,000 行，我没有使用任何连接池。

标签： java oracle jsp servlets oracle12c

【解决方案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 消耗的来源。

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

【讨论】：