記錄一次Oracle很卡事件

臨近下班時間點，突然被同事告知數據庫很卡，連查詢都無法使用，登陸也是各種慢。

遠程登陸到服務器（遠程過程中也是費勁九牛二虎之力才上來），檢查了服務器的各種資源，發現除了磁盤IO其他的資源一切正常，初步懷疑是IO問題導致的。

話不多說本地通過sqlplus命令連接到數據庫，手動生成一次快照，命令如下：

C:\Users\Administrator>sqlplus zjsjgxt/jgzdwffz

SQL*Plus: Release 11.2.0.1.0 Production on 星期三 9月 5 10:03:40 2018

Copyright (c) 1982, 2010, Oracle.  All rights reserved.


連接到:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> exec dbms_workload_repository.create_snapshot();   #手動生成一次快照

PL/SQL 過程已成功完成。  

SQL> @?\rdbms\admin\awrrpt.sql  #生成awr報告

生成報告花了近三分鍾，也是沒誰了。難道服務器性能到瓶頸了？

初步看了下awr報告，貼上部分圖片

BD TIME 2000多分鍾，這么繁忙！！！

等待事件中顯示，數據庫之所以這么繁忙，是由於數據庫做大量的全表掃描導致；看來問題應該出在sql語句上；

 

 上圖可以看出消耗IO最多的兩條SQL語句。既然找出來了sql語句，那就好說。提出sql語句扔個程序猿。

附加部分動態視圖的sql語句：

高資源消耗sql定位：

select sql_text,disk_reads,buffer_gets,parsing_scheme_name,executions From v$sqlarea Order by disk_reads desc;

排序較多的sql：

select sql_text,sorts,parsing_schema_nameFrom v$sqlarea Order by sorts desc;

消耗CPU較多的sql:

select * from (select v.sql_id,v.child_number,v.sql_text,v.elapsed_time,v.cpu_time,v.disk_reads,rank() over(order by v.cpu_time desc) elapsed_rank
from v$sql v) a where elapsed_rank <= 10;

消耗磁盤較多的sql:

select * from (select v.sql_id,v.child_number,v.sql_text,v.elapsed_time,v.cpu_time,v.disk_reads,
rank() over(order by v.disk_reads desc) elapsed_rank from v$sql v) a where elapsed_rank <= 10;

查詢當前等待事件，主要是direct path read

select event, count(1) from v$session_wait WHERE EVENT NOT IN (select E.NAME from V$EVENT_NAME E WHERE E.WAIT_CLASS = 'Idle') 
group by event order by 2 desc;

查找產生direct path read的SQL

select * from v$sql where sql_id in (select distinct sql_id from v$session where event = 'direct path read');

注：SQL語句來源於網絡資料，本人都已測試過，還是挺好用的！