ORACLE占用大量系統CPU致使系統宕機該怎么辦

這篇文章給大家介紹ORACLE占用大量系統CPU致使系統宕機該怎么辦，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

Oracle數據庫經常會遇到CPU利用率很高的情況，這種時候大都是數據庫中存在著嚴重性能低下的SQL語句，這種SQL語句大大的消耗了CPU資源，導致整個系統性能低下。當然，引起嚴重性能低下的SQL語句的原因是多方面的，具體的原因要具體的來分析，下面通過一個實際的案例來說明如何來診斷和解決CPU利用率高的這類問題。

操作系統：Linux7.0

數據庫：Oracle11.2.0.4

問題描述：現場工程師匯報數據庫非常慢，幾乎所有應用操作均無法正常進行。不久后，系統斷開連接，宕機。

首先重啟系統后，啟動數據庫。執行top發現CPU資源幾乎消耗殆盡，存在很多占用CPU很高的進程，而內存和I/O都不高，具體如下：

last pid: 26136;  load averages:  8.89,  8.91,  8.12                                                                      

216 processes: 204 sleeping, 8 running, 4 on cpu

CPU states:  0.6% idle, 97.3% user,  1.8% kernel,  0.2% iowait,  0.0% swap

Memory: 8192M real, 1166M free, 14M swap in use, 8179M swap free

PID USERNAME THR PRI NICE  SIZE   RES STATE   TIME    CPU COMMAND

25725 oracle     1  50    0 4550M 4508M cpu2   12:23 11.23% oracle

25774 oracle     1  41    0 4550M 4508M run    14:25 10.66% oracle

26016 oracle     1  31    0 4550M 4508M run     5:41 10.37% oracle

26010 oracle     1  41    0 4550M 4508M run     4:40  9.81% oracle

26014 oracle     1  51    0 4550M 4506M cpu6    4:19  9.76% oracle

25873 oracle     1  41    0 4550M 4508M run    12:10  9.45% oracle

25723 oracle     1  50    0 4550M 4508M run    15:09  9.40% oracle

26121 oracle     1  41    0 4550M 4506M cpu0    1:13  9.28% oracle

25745 oracle     1  41    0 4551M 4512M run     9:33  9.28% oracle

26136 oracle     1  41    0 4550M 4506M run     0:06  5.61% oracle

  409 root      15  59    0 7168K 7008K sleep 173.1H  0.52% picld

25653 oracle     1  59    0 4550M 4508M sleep   1:01  0.46% oracle

25565 oracle     1  59    0 4550M 4508M sleep   0:07  0.24% oracle

25703 oracle     1  59    0 4550M 4506M sleep   0:08  0.13% oracle

25701 oracle     1  59    0 4550M 4509M sleep   0:23  0.10% oracle

于是先查看數據庫的告警日志ALERT文件，并沒有發現有什么錯誤存在，日志顯示數據庫運行正常，排除數據庫本身存在問題。

然后查看這些占用CPU資源很高的Oracle進程究竟是在做什么操作，使用如下SQL語句：

select sql_text,spid,v$session.program,process  from

v$sqlarea,v$session,v$process

where v$sqlarea.address=v$session.sql_address

and v$sqlarea.hash_value=v$session.sql_hash_value

and v$session.paddr=v$process.addr

and v$process.spid in (PID);

用top中占用CPU很高的進程的PID替換腳本中的PID,得到相應的Oracle進程所執行的SQL語句，發現占用CPU資源很高的進程都是執行同一個SQL語句：

select username "username", to_char(timestamp,'DD-MON-YYYY HH24:MI:SS') "time_stamp", action_name "statement", os_username "os_username", userhost "userhost", returncode||decode(returncode,'1004','-Wrong Connection','1005','-NULL Password','1017','-Wrong Password','1045','-Insufficient Priviledge','0','-Login Accepted','--') "returncode" from sys.dba_audit_session where (sysdate - timestamp)*24 < 1 and returncode <> 0 order by timestamp;

基本上可以肯定是這個SQL引起了系統CPU資源大量被占用，那究竟是什么原因造成這個SQL這么大量占用CPU資源呢，從上面的SQL語句中我們可以看到sys.dba_audit_session這張表，由此可以確定是由于審計的原因導致數據庫占用大量CPU。

查看數據庫審計信息：

SQL> show parameter audit

NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

audit_file_dest                      string      /u01/app/oracle/admin/orcl/adump

audit_sys_operations                 boolean     FALSE

audit_syslog_level                   string

audit_trail                          string      DB

可以看到數據庫審計為開啟狀態，并且將audited record的存放在數據庫里（sys.aud$）中。

問題處理方法：

1.如果審計不是必須的，可以關掉審計功能；

SQL> alter system set audit_trail=none scope=spfile;

SQL>showdown immediate;

SQL>startup

2.刪除已有的審計信息

可以直接truncate表aud$,

或者采取dbms_audit_mgmt來清除。

3.或者將aud$表移到另外一個表空間下，以減少system表空間的壓力和被撐爆的風險。

附：11g中有關audit_trail參數的設置說明：

AUDIT_TRAIL

AUDIT_TRAIL enables or disables database auditing.

Values:

• none

  Disables standard auditing. This value is the default if the AUDIT_TRAIL parameter was not set in the initialization parameter file or if you created the database using a method other than Database Configuration Assistant. If you created the database using Database Configuration Assistant, then the default is db.

• os

  Directs all audit records to an operating system file. Oracle recommends that you use the os setting, particularly if you are using an ultra-secure database configuration.

• db

  Directs audit records to the database audit trail (the SYS.AUD$ table), except for records that are always written to the operating system audit trail. Use this setting for a general database for manageability.

  If the database was started in read-only mode with AUDIT_TRAIL set to db, then Oracle Database internally sets AUDIT_TRAIL to os. Check the alert log for details.

• db, extended

  Performs all actions of AUDIT_TRAIL=db, and also populates the SQL bind and SQL text CLOB-type columns of the SYS.AUD$ table, when available. These two columns are populated only when this parameter is specified.

  If the database was started in read-only mode with AUDIT_TRAIL set to db, extended, then Oracle Database internally sets AUDIT_TRAIL to os. Check the alert log for details.

• xml

  Writes to the operating system audit record file in XML format. Records all elements of the AuditRecord node except Sql_Text and Sql_Bind to the operating system XML audit file.

• xml, extended

  Performs all actions of AUDIT_TRAIL=xml, and populates the SQL bind and SQL text CLOB-type columns of the SYS.AUD$table, wherever possible. These columns are populated only when this parameter is specified.

You can use the SQL AUDIT statement to set auditing options regardless of the setting of this parameter.

關于ORACLE占用大量系統CPU致使系統宕機該怎么辦就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。