在Oracleg中以前版本中比較難於獲取的響應時間數據將會變得非常容易獲取
在以前看來為了盡量獲得數據庫的最佳性能Oracle的DBA們和性能分析專家一直很困難獲得系統以及用戶會話活動的一致的響應時間數據DBA們面臨的問題一直以來包括兩個方面第一個方面是准確定位數據庫或者用戶會話究竟在哪裡消耗了時間第二個方面就是確定用戶體驗的客觀性質
在數據庫中產生所有可能的行為和交互作用這些任務都不是沒有價值的Oracle等待接口在之前的很早的Oracle數據庫版本中開始介紹的對於那些知道如何使用等待接口的管理員來說這已經成為一個偉大的開始即使它仍然缺乏告訴DBA系統或者用戶會話是否有效的處理了事務或者查詢這個理想的能力啟用和鑽研跟蹤文件能夠存儲這個級別上的詳細信息但是對於大多數超負荷工作管理大型數據庫的DBA們這個鑽研是奢侈的而耗費時間的
幸運的是那些將數據庫升級到Oracleg的DBA們將會發現找到主要的響應時間變得很容易可以允許一個非常好的圖表來顯示系統和會話級的響應時間數據很重要的一點Oracle的ADDM提供了一個查看響應時間的方法通過自動分析收集的統計信息識別問題區域甚至可以通過Oracle企業管理器網絡控制的圖形界面提供建議
此外與我們這裡討論相關的是Oracleg數據庫的歷史數據機制允許DBA們按時查看對響應時間趨勢的分析這將有助於DBA們確定事務/系統的高峰時期更好的定位那些拉長批處理周期和ETL作業的進程和SQL語句
這裡主要討論用於系統會話和SQL級別上那些歷史機制的用途
系統層的響應時間分析
先來看看典型的幾個經常問到DBA們的問題
通常來說數據庫運行的狀況如何？
用戶體驗感覺的平均響應時間是多少？
什麼行為是最影響整個響應時間的？
上述問題在Oracleg數據庫之前對於DBA們來說是相當不好回答的但是如果使用了最新的Oracleg數據庫之後這些數據信息將會很容易的被捕獲到
首先Oracleg數據庫運行的狀況如何這個問題可以通過下面的查詢來獲得
select METRIC_NAMEVALUE
from SYSV_$SYSMETRIC
where METRIC_NAME IN （Database CPU Time RatioDatabase Wait Time Ratio）
AND INTSIZE_CSEC = （select max（INTSIZE_CSEC） from SYSV_$SYSMETRIC）
METRIC_NAME VALUE
Database Wait Time Ratio
Database CPU Time Ratio
Oracleg數據庫中的V$SYSMETRIC視圖中存在一些非常有用的響應時間數據其中兩個比較重要的就是Wait Time Ratio 和Database CPU Time Ratio上面的查詢顯示了數據庫中最新的關於這兩個統計數據的快照這將有助於幫助我們確定是否數據庫正在經歷著一個比較高的等待百分率和瓶頸數據庫的CPU Time Ratio是由數據庫中的database time的數值除以CPU的數量database time定義為數據庫消耗在用戶級別調用所花費的時間（不包括實例的後台進程活動所消耗的時間）比較高的值（%%以上）代表很少等待和瓶頸活動因為各個系統不同這個閥值只能作為一個一般的規則來使用
還可以使用如下的查詢來迅速查看最新一個小時的信息看看數據庫的總性能如何
select end_timevalue
from sysv_$sysmetric_history
where metric_name = Database CPU Time Ratio
order by
END_TIME VALUE
可以從V$SYSMETRIC_SUMMARY視圖中獲得數據庫整體性能效率的最大最小和平均值
select CASE METRIC_NAME
WHEN SQL Service Response Time then SQL Service Response Time （secs）
WHEN Response Time Per Txn then Response Time Per Txn （secs）
ELSE METRIC_NAME
END METRIC_NAME
CASE METRIC_NAME
WHEN SQL Service Response Time then ROUND（（MINVAL / ））
WHEN Response Time Per Txn then ROUND（（MINVAL / ））
ELSE MINVAL
END MININUM
CASE METRIC_NAME
WHEN SQL Service Response Time then ROUND（（MAXVAL / ））
WHEN Response Time Per Txn then ROUND（（MAXVAL / ））
ELSE MAXVAL
END MAXIMUM
CASE METRIC_NAME
WHEN SQL Service Response Time then ROUND（（AVERAGE / ））
WHEN Response Time Per Txn then ROUND（（AVERAGE / ））
ELSE AVERAGE
END AVERAGE
from SYSV_$SYSMETRIC_SUMMARY
where METRIC_NAME in （CPU Usage Per Sec
CPU Usage Per Txn
Database CPU Time Ratio
Database Wait Time Ratio
Executions Per Sec
Executions Per Txn
Response Time Per Txn
SQL Service Response Time
User Transaction Per Sec）
ORDER BY
METRIC_NAME MININUM MAXIMUM AVERAGE
CPU Usage Per Sec
CPU Usage Per Txn
Database CPU Time Ratio
Database Wait Time Ratio
Executions Per Sec
Executions Per Txn
Response Time Per Txn （secs）
SQL Service Response Time （secs）
User Transaction Per Sec
上面的查詢包含了更多的詳細的響應時間數據DBA們還需要收集在系統級別上的用戶通訊的平均響應時間上面的查詢給出了需要的結果如果用戶抱怨響應時間太慢那麼DBA就應該查看Response Time Per Txn和SQL Service Response Time數據是否存在數據庫問題
如果響應時間不在是那麼渴求那麼DBA就會想了解究竟是什麼類型的用戶活動讓數據庫的響應變得如此的慢在Oracleg數據庫之前這些信息 是比較難獲取的但是現在就變得非常容易執行如下查詢
select case db_stat_name
when parse time elapsed then
soft parse time
else db_stat_name
end db_stat_name
case db_stat_name
when sql execute elapsed time then
time_secs plsql_time
when parse time elapsed then
time_secs hard_parse_time
else time_secs
end time_secs
case db_stat_name
when sql execute elapsed time then
round（ * （time_secs plsql_time） / db_time）
when parse time elapsed then
round（ * （time_secs hard_parse_time） / db_time）
else round（ * time_secs / db_time）
end pct_time
from
（select stat_name db_stat_name
round（（value / ）） time_secs
from sysv_$sys_time_model
where stat_name not in（DB timebackground elapsed time
background cpu timeDB CPU））
（select round（（value / ）） db_time
from sysv_$sys_time_model
where stat_name = DB time）
（select round（（value / ）） plsql_time
from sysv_$sys_time_model
where stat_name = PL/SQL execution elapsed time）
（select round（（value / ）） hard_parse_time
from sysv_$sys_time_model
where stat_name = hard parse elapsed time）
order by desc
DB_STAT_NAME TIME_SECS PCT_TIME
sql execute elapsed time
hard parse elapsed time
PL/SQL execution elapsed time
PL/SQL compilation elapsed time
soft parse time
connection management call elapsed time
hard parse （sharing criteria） elapsed time
repeated bind elapsed time
failed parse elapsed time
hard parse （bind mismatch） elapsed time
RMAN cpu time （backup/restore）
inbound PL/SQL rpc elapsed time
sequence load elapsed time
Java execution elapsed time
failed parse （out of shared memory） elapsed time
可以在V$SYS_TIME_MODEL視圖中找到相應的主要花費時間處理的部分然後就可以根據這些來對數據庫進行相應的調整
除了活動時間DBA也還想知道整體的等待時間在Oracleg數據庫之前DBA必須查看單獨的等待事件來找出等待和瓶頸現在Oracleg數據庫提供一個等待的概要機制
select WAIT_CLASS
TOTAL_WAITS
round（ * （TOTAL_WAITS / SUM_WAITS）） PCT_WAITS
ROUND（（TIME_WAITED / ）） TIME_WAITED_SECS
round（ * （TIME_WAITED / SUM_TIME）） PCT_TIME
from
（select WAIT_CLASS
TOTAL_WAITS
TIME_WAITED
from V$SYSTEM_WAIT_CLASS
where WAIT_CLASS ！= Idle）
（select sum（TOTAL_WAITS） SUM_WAITS
sum（TIME_WAITED） SUM_TIME
from V$SYSTEM_WAIT_CLASS
where WAIT_CLASS ！= Idle）
order by desc
WAIT_CLASS TOTAL_WAITS PCT_WAITS TIME_WAITED_SECS PCT_TIME
User I/O
Other
System I/O
Concurrency
Commit
Network
Application
這樣就能非常容易的找出大部分的整體等待時間如同響應時間數據一樣我們可以用下面的查詢來及時回顧最新的一個小時等待類型
select asid
busername
await_class
atotal_waits
round（（atime_waited / ）） time_waited_secs
from sysv_$session_wait_class a
sysv_$session b
where bsid = asid and
busername is not null and
await_class ！= Idle
order by desc
SID USERNAME WAIT_CLASS TOTAL_WAITS TIME_WAITED_SECS
SYS User I/O
SYS User I/O
SYS Network
SYS Network
SYS Application
這個時候就可以檢查標准的單獨等待事件就如在以前版本的Oracle數據庫中查詢V$SESSION_WAIT和V$SESSION_EVENT視圖在Oracleg數據庫中DBA還將可以找出新的等待類型在這兩張視圖中如果需要找出以前哪個會話登錄並且消耗了大部分的資源你可以使用下面的查詢下面的例子是查找午夜點到點的數據庫活動並且包括用戶的I/O等待
select sess_id
username
program
wait_event
sess_time
round（ * （sess_time / total_time）） pct_time_waited
from
（select asession_id sess_id
decode（session_typebackgroundsession_typecusername） username
aprogram program
bname wait_event
sum（atime_waited） sess_time
from sysv_$active_session_history a
sysv_$event_name b
sysdba_users c
where aevent# = bevent# and
auser_id = cuser_id and
sample_time > JAN AM and
sample_time < JAN AM and
bwait_class = User I/O
group by asession_id
decode（session_typebackgroundsession_typecusername）
aprogram
bname）
SQL語句響應時間分析
在Oraclei數據庫中查看SQL語句的響應時間就變得比較容易了現在在Oracleg中DBA們擁有更多的工具可以幫助他們跟蹤效率低下的數據庫代碼以前可以用來查詢的視圖是V$SQLAREA從Oraclei開始這個視圖增加了ELAPSED_TIME和CPU_TIME兩個列這極大的有助於去確定實際用戶的SQL語句的執行經歷（如果除以執行的次數列EXECUTIONS那麼將得到平均每次執行這個SQL語句所用的平均時間）在Oracleg數據庫中V$SQLAREA視圖中增加了個新的和等待以及時間相關的列
l APPLICATION_WAIT_TIME
l CONCURRENCY_WAIT_TIME
l CLUSTER_WAIT_TIME
l USER_IO_WAIT_TIME
l PLSQL_EXEC_TIME
l JAVA_EXEC_TIME
這些新的列有助於確定很多信息例如一個存儲過程中花費在PL/SQL代碼和標准SQL執行上的時間的對比以及一個SQL語句經歷的任何詳細的用戶I/O等待例如下面的SQL語句能幫助找到前位用戶I/O等待最高的SQL語句
select * from
（select sql_text
sql_id
elapsed_time
cpu_time
user_io_wait_time
from sysv_$sqlarea
order by desc）
where rownum <
SQL_TEXT SQL_ID ELAPSED_TIME CPU_TIME USER_IO_WAIT_TIME
DECLARE job BINARY_INTEGER = job next_date DATE = mydate broken BOOLEAN gvchxucag
select /*+ index（idl_ub$ i_idl_ub） +*/ piece#lengthpiece from idl_ub$ wher cvnbyzsu
select ssynonym_name object_name oobject_type from sysall_synonyms s s fqmpmkfrpqyk
select /*+ rule */ bucket endpoint col# epvalue from histgrm$ where obj#= a dbfxqxwxtr
select /*+ index（idl_ub$ i_idl_ub） +*/ piece#lengthpiece from idl_ub$ wher msxkba
當然獲取最消耗時間或者等待時間最長的SQL語句非常不錯但是同時也需要抓住其要點——在V$ACTIVE_SESSION_HISTORY視圖中又一次出現的SQL語句通過這個視圖能夠找出具體什麼等待時間延遲了SQL語句執行連同實際的文件對象以及阻塞的對象導致等待
例如設想已經找到一個特別的SQL語句看上去在用戶I/O等待時間方面極端的嚴重那麼可以執行下面的查詢來得到等待時間中各個單獨的等待事件等待的文件等待的對象
select event
time_waited
owner
object_name
current_file#
current_block#
from sysv_$active_session_history a
sysdba_objects b
where sql_id = gvchxucag and
acurrent_obj# = bobject_id and
time_waited <>
EVENT TIME_WAITED OWNER OBJECT_NAME file block
db file sequential read SYSMAN MGMT_METRICS_HOUR_PK
db file sequential read SYSMAN SEVERITY_PRIMARY_KEY
當然也可以通過使用V$ACTIVE_SESSION_HISTORY視圖中的歷史數據的方式來限制一段特殊時間內的沒有優化的SQL語句問題在於Oracleg數據庫通過簡化的數據字典視圖把SQL語句的響應時間分析變得非常的簡單比起以前運用消耗時間的trace方法來說
總結
DBA們和性能分析專家們管理Oracleg數據庫的性能時會發現在最新的Oracle旗艦數據庫中已經把許多的響應時間數據做成了動態性能視圖這些統計信息將有助於迅速找出大型復雜數據庫中的性能瓶頸所在
From:http://tw.wingwit.com/Article/program/Oracle/201311/16839.html
