Oracle 12 c Использование 100% CPU все время

Question

Я использую Oracle 12 c База данных с моим Java EE проектом. Но после установки Oracle База данных каждый раз, когда она запускается с использованием ЦП 100% через определенное время (около 1 недели) всегда после установки. Я попытался использовать Windows Server , а после также я попытался Suse Linux в качестве операции с oracle 12 c Databse, но тот же результат. Вот мои В настоящее время используются детали процессора для Oracle 12 c и Suse Linux ..

Вот мои 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 они выполняются со следующими 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
;

Кроме того, в зависимости от того, как вы получаете свои соединения, штормы входа ** может быть источником высокой загрузки ЦП.

** Шторм при входе в систему: Шторм при входе в систему характеризуется внезапным скачком числа запросов клиентских подключений или необычно большим числом подключений. Поскольку процесс запуска сеанса базы данных требует интенсивной загрузки ЦП, шторм при входе в систему, вероятно, приведет к непредвиденным последствиям, таким как: ошибки соединения, приложения, ожидающие загрузки на ЦП, тайм-ауты, плохое время отклика, влияние на другие БД на том же компьютере, увеличение времени ожидания для все работает по инстансу,… Причины штормов входа в систему root часто связаны с неправильными настройками пула соединений или приложениями, которые подключаются, используя сеанс, а затем отключаются.