在Oracle10g中，以前版本中比較難于獲取的響應(yīng)時(shí)間數(shù)據(jù)將會(huì)變得非常輕易獲取。 在以前看來，為了盡量獲得數(shù)據(jù)庫的最佳性能，Oracle的DBA們和性能分析專家一直很困難獲得系統(tǒng)以及用戶會(huì)話活動(dòng)的一致的響應(yīng)時(shí)間數(shù)據(jù)。DBA們面臨的問題一直以來包括兩個(gè)方面：第一個(gè)方面是準(zhǔn)確定位數(shù)據(jù)庫或者用戶會(huì)話究竟在哪里消耗了時(shí)間；第二個(gè)方面就是確定用戶體驗(yàn)的客觀性質(zhì)。 在數(shù)據(jù)庫中產(chǎn)生所有可能的行為和交互作用，這些任務(wù)都不是沒有價(jià)值的。Oracle等待接口，在之前的很早的Oracle數(shù)據(jù)庫版本中開始介紹的，對(duì)于那些知道如何使用等待接口的治理員來說這已經(jīng)成為一個(gè)偉大的開始，即使它仍然缺乏告訴DBA系統(tǒng)或者用戶會(huì)話是否有效的處理了事務(wù)或者查詢這個(gè)理想的能力。啟用和鉆研跟蹤文件能夠存儲(chǔ)這個(gè)級(jí)別上的具體信息，但是對(duì)于大多數(shù)超負(fù)荷工作治理大型數(shù)據(jù)庫的DBA們，這個(gè)鉆研是奢侈的而耗費(fèi)時(shí)間的。 幸運(yùn)的是，那些將數(shù)據(jù)庫升級(jí)到Oracle10g的DBA們將會(huì)發(fā)現(xiàn)找到主要的響應(yīng)時(shí)間變得很輕易，可以答應(yīng)一個(gè)非常好的圖表來顯示系統(tǒng)和會(huì)話級(jí)的響應(yīng)時(shí)間數(shù)據(jù)。很重要的一點(diǎn)，Oracle的ADDM提供了一個(gè)查看響應(yīng)時(shí)間的方法，通過自動(dòng)分析收集的統(tǒng)計(jì)信息，識(shí)別問題區(qū)域，甚至可以通過Oracle企業(yè)治理器網(wǎng)絡(luò)控制的圖形界面提供建議。 此外，與我們這里討論相關(guān)的是Oracle10g數(shù)據(jù)庫的歷史數(shù)據(jù)機(jī)制答應(yīng)DBA們按時(shí)查看對(duì)響應(yīng)時(shí)間趨勢(shì)的分析，這將有助于DBA們確定事務(wù)/系統(tǒng)的高峰時(shí)期，更好的定位那些拉長批處理周期和ETL作業(yè)的進(jìn)程和SQL語句。 這里主要討論用于系統(tǒng)、會(huì)話和SQL級(jí)別上那些歷史機(jī)制的用途。 系統(tǒng)層的響應(yīng)時(shí)間分析： 先來看看典型的幾個(gè)經(jīng)常問到DBA們的問題： 通常來說，數(shù)據(jù)庫運(yùn)行的狀況如何？ 用戶體驗(yàn)感覺的平均響應(yīng)時(shí)間是多少？ 什么行為是最影響整個(gè)響應(yīng)時(shí)間的？ 上述問題在Oracle10g數(shù)據(jù)庫之前對(duì)于DBA們來說是相當(dāng)不好回答的，但是假如使用了最新的Oracle10g數(shù)據(jù)庫之后，這些數(shù)據(jù)信息將會(huì)很輕易的被捕捉到。 首先，Oracle10g數(shù)據(jù)庫運(yùn)行的狀況如何這個(gè)問題可以通過下面的查詢來獲得： select METRIC_NAME，VALUE from SYS.V_$SYSMETRIC where METRIC_NAME IN （'Database CPU Time Ratio'，'Database Wait Time Ratio'） AND INTSIZE_CSEC = （select max（INTSIZE_CSEC） from SYS.V_$SYSMETRIC）； METRIC_NAME VALUE Database Wait Time Ratio 31.3499111 Database CPU Time Ratio 68.6500888Oracle10g數(shù)據(jù)庫中的V$SYSMETRIC視圖中存在一些非常有用的響應(yīng)時(shí)間數(shù)據(jù)，其中兩個(gè)比較重要的就是Wait Time Ratio 和Database CPU Time Ratio.上面的查詢顯示了數(shù)據(jù)庫中最新的關(guān)于這兩個(gè)統(tǒng)計(jì)數(shù)據(jù)的快照，這將有助于幫助我們確定是否數(shù)據(jù)庫正在經(jīng)歷著一個(gè)比較高的等待百分率和瓶頸。數(shù)據(jù)庫的CPU Time Ratio是由數(shù)據(jù)庫中的'database time'的數(shù)值除以CPU的數(shù)量，'database time'定義為數(shù)據(jù)庫消耗在用戶級(jí)別調(diào)用所花費(fèi)的時(shí)間（不包括實(shí)例的后臺(tái)進(jìn)程活動(dòng)所消耗的時(shí)間）。比較高的值（90%-95%以上）代表很少等待和瓶頸活動(dòng)，因?yàn)楦鱾€(gè)系統(tǒng)不同，這個(gè)閥值只能作為一個(gè)一般的規(guī)則來使用。 還可以使用如下的查詢來迅速查看最新一個(gè)小時(shí)的信息，看看數(shù)據(jù)庫的總性能如何： select end_time，value from sys.v_$sysmetric_history where metric_name = 'Database CPU Time Ratio' order by 1； END_TIME VALUE 2007-1-24 2 3.21949216 2007-1-24 2 3.01443414 2007-1-24 2 9.75636353 2007-1-24 2 9.28581409 2007-1-24 2 43.3490481 2007-1-24 2 38.8366361 2007-1-24 2 32.0272511 2007-1-24 2 0 2007-1-24 2 22.9580733 2007-1-24 2 33.0615102 2007-1-24 2 43.1294933可以從V$SYSMETRIC_SUMMARY視圖中獲得數(shù)據(jù)庫整體性能效率的最大、最小和平均值： 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 / 100），2） WHEN 'Response Time Per Txn' then ROUND（（MINVAL / 100），2） ELSE MINVAL END MININUM， CASE METRIC_NAME WHEN 'SQL Service Response Time' then ROUND（（MAXVAL / 100），2） WHEN 'Response Time Per Txn' then ROUND（（MAXVAL / 100），2） ELSE MAXVAL END MAXIMUM， CASE METRIC_NAME WHEN 'SQL Service Response Time' then ROUND（（AVERAGE / 100），2） WHEN 'Response Time Per Txn' then ROUND（（AVERAGE / 100），2） ELSE AVERAGE END AVERAGE from SYS.V_$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 1； METRIC_NAME MININUM MAXIMUM AVERAGE CPU Usage Per Sec 0 53.9947577 11.1603280 CPU Usage Per Txn 0 168.731666 24.8848615 Database CPU Time Ratio 0 87.1866295 35.8114730 Database Wait Time Ratio 0 90.7141859 64.1885269 Executions Per Sec 0 540.768348 114.852472 Executions Per Txn 0 1911 279.912779 Response Time Per Txn （secs） 0 3.88 0.66 SQL Service Response Time （secs） 0 0 0 User Transaction Per Sec 0 4.70183486 0.94469007上面的查詢包含了更多的具體的響應(yīng)時(shí)間數(shù)據(jù)。DBA們還需要收集在系統(tǒng)級(jí)別上的用戶通訊的平均響應(yīng)時(shí)間，上面的查詢給出了需要的結(jié)果。假如用戶抱怨響應(yīng)時(shí)間太慢，那么DBA就應(yīng)該查看Response Time Per Txn和SQL Service Response Time數(shù)據(jù)是否存在數(shù)據(jù)庫問題。 假如響應(yīng)時(shí)間不在是那么渴求，那么DBA就會(huì)想了解究竟是什么類型的用戶活動(dòng)讓數(shù)據(jù)庫的響應(yīng)變得如此的慢，在Oracle10g數(shù)據(jù)庫之前，這些信息 是比較難獲取的，但是現(xiàn)在就變得非常輕易，執(zhí)行如下查詢： 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（100 * （time_secs - plsql_time） / db_time，2） when 'parse time elapsed' then round（100 * （time_secs - hard_parse_time） / db_time，2） else round（100 * time_secs / db_time，2） end pct_time from （select stat_name db_stat_name， round（（value / 1000000），3） time_secs from sys.v_$sys_time_model where stat_name not in（'DB time'，'background elapsed time'， 'background cpu time'，'DB CPU'））， （select round（（value / 1000000），3） db_time from sys.v_$sys_time_model where stat_name = 'DB time'）， （select round（（value / 1000000），3） plsql_time from sys.v_$sys_time_model where stat_name = 'PL/SQL execution elapsed time'）， （select round（（value / 1000000），3） hard_parse_time from sys.v_$sys_time_model where stat_name = 'hard parse elapsed time'） order by 2 desc； DB_STAT_NAME TIME_SECS PCT_TIME sql execute elapsed time 65.644 89.7 hard parse elapsed time 26.661 36.43 PL/SQL execution elapsed time 12.766 17.44 PL/SQL compilation elapsed time 6.353 8.68 soft parse time 2.15 2.94 connection management call elapsed time 1.084 1.48 hard parse （sharing criteria） elapsed time 0.448 0.61 repeated bind elapsed time 0.026 0.04 failed parse elapsed time 0.009 0.01 hard parse （bind mismatch） elapsed time 0.002 0 RMAN cpu time （backup/restore） 0 0 inbound PL/SQL rpc elapsed time 0 0 sequence load elapsed time 0 0 Java execution elapsed time 0 0 failed parse （out of shared memory） elapsed time 0 0可以在V$SYS_TIME_MODEL視圖中找到相應(yīng)的主要花費(fèi)時(shí)間處理的部分，然后就可以根據(jù)這些來對(duì)數(shù)據(jù)庫進(jìn)行相應(yīng)的調(diào)整。 除了活動(dòng)時(shí)間，DBA也還想知道整體的等待時(shí)間。在Oracle10g數(shù)據(jù)庫之前，DBA必須查看單獨(dú)的等待事件來找出等待和瓶頸，現(xiàn)在Oracle10g數(shù)據(jù)庫提供一個(gè)等待的概要機(jī)制。 select WAIT_CLASS， TOTAL_WAITS， round（100 * （TOTAL_WAITS / SUM_WAITS），2） PCT_WAITS， ROUND（（TIME_WAITED / 100），2） TIME_WAITED_SECS， round（100 * （TIME_WAITED / SUM_TIME），2） 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 5 desc； WAIT_CLASS TOTAL_WAITS PCT_WAITS TIME_WAITED_SECS PCT_TIME User I/O 5748 61.71 67.57 65.79 Other 182 1.95 16.85 16.41 System I/O 2975 31.94 11.27 10.97 Concurrency 114 1.22 6.76 6.58 Commit 61 0.65 0.22 0.21 Network 233 2.5 0.03 0.03 Application 2 0.02 0 0這樣就能非常輕易的找出大部分的整體等待時(shí)間。如同響應(yīng)時(shí)間數(shù)據(jù)一樣，我們可以用下面的查詢來及時(shí)回顧最新的一個(gè)小時(shí)等待類型： select a.sid， b.username， a.wait_class， a.total_waits， round（（a.time_waited / 100），2） time_waited_secs from sys.v_$session_wait_class a， sys.v_$session b where b.sid = a.sid and b.username is not null and a.wait_class ！= 'Idle' order by 5 desc； SID USERNAME WAIT_CLASS TOTAL_WAITS TIME_WAITED_SECS 38 SYS User I/O 22 0.19 48 SYS User I/O 15 0.12 38 SYS Network 21 0.01 48 SYS Network 24 0 38 SYS Application 2 0這個(gè)時(shí)候，就可以檢查標(biāo)準(zhǔn)的單獨(dú)等待事件就如在以前版本的Oracle數(shù)據(jù)庫中查詢V$SESSION_WAIT和V$SESSION_EVENT視圖。在Oracle10g數(shù)據(jù)庫中DBA還將可以找出新的等待類型在這兩張視圖中。假如需要找出以前哪個(gè)會(huì)話登錄并且消耗了大部分的資源，你可以使用下面的查詢，下面的例子是查找午夜12點(diǎn)到5點(diǎn)的數(shù)據(jù)庫活動(dòng)，并且包括用戶的I/O等待。 select sess_id， username， program， wait_event， sess_time， round（100 * （sess_time / total_time），2） pct_time_waited from （select a.session_id sess_id， decode（session_type，'background'，session_type，c.username） username， a.program program， b.name wait_event， sum（a.time_waited） sess_time from sys.v_$active_session_history a， sys.v_$event_name b， sys.dba_users c where a.event# = b.event# and a.user_id = c.user_id and sample_time > '22-JAN-07 12：00：00 AM' and sample_time < '22-JAN-07 05：00：00 AM' and b.wait_class = 'User I/O' group by a.session_id， decode（session_type，'background'，session_type，c.username）， a.program， b.name），SQL語句響應(yīng)時(shí)間分析 在Oracle9i數(shù)據(jù)庫中查看SQL語句的響應(yīng)時(shí)間就變得比較輕易了，現(xiàn)在在Oracle10g中，DBA們擁有更多的工具可以幫助他們跟蹤效率低下的數(shù)據(jù)庫代碼。以前可以用來查詢的視圖是V$SQLAREA，從Oracle9i開始，這個(gè)視圖增加了ELAPSED_TIME和CPU_TIME兩個(gè)列，這極大的有助于去確定實(shí)際用戶的SQL語句的執(zhí)行經(jīng)歷。（假如除以執(zhí)行的次數(shù)列EXECUTIONS，那么將得到平均每次執(zhí)行這個(gè)SQL語句所用的平均時(shí)間）在Oracle10g數(shù)據(jù)庫中，V$SQLAREA視圖中增加了6個(gè)新的和等待以及時(shí)間相關(guān)的列： APPLICATION_WAIT_TIME CONCURRENCY_WAIT_TIME CLUSTER_WAIT_TIME USER_IO_WAIT_TIME PLSQL_EXEC_TIME JAVA_EXEC_TIME這些新的列有助于確定很多信息，例如：一個(gè)存儲(chǔ)過程中花費(fèi)在PL/SQL代碼和標(biāo)準(zhǔn)SQL執(zhí)行上的時(shí)間的對(duì)比，以及一個(gè)SQL語句經(jīng)歷的任何具體的用戶I/O等待。例如：下面的SQL語句能幫助找到前5位用戶I/O等待最高的SQL語句： select * from （select sql_text， sql_id， elapsed_time， cpu_time， user_io_wait_time from sys.v_$sqlarea order by 5 desc） where rownum < 6； SQL_TEXT SQL_ID ELAPSED_TIME CPU_TIME USER_IO_WAIT_TIME DECLARE job BINARY_INTEGER ：= ：job； next_date DATE ：= ：mydate； broken BOOLEAN ： 6gvch1xu9ca3g 11077912 747091 8593479 select /*+ index（idl_ub1$ i_idl_ub11） +*/ piece#， length，piece from idl_ub1 $ wher cvn54b7yz0s8u 6455976 220128 6427409 select s.synonym_name object_name， o.object_type from sys.all_synonyms s， s fqmpmkfr6pqyk 11814078 6958760 3189450 select /*+ rule */ bUCket， endpoint， col#， epvalue from histgrm$ where obj#=：1 a db78fxqxwxt7r 2737680 193937 2689611 select /*+ index（idl_ub2$ i_idl_ub21） +*/ piece#， length，piece from idl_ub2$ where 39m4sx9k63ba2 2322664 108100 2307700當(dāng)然，獲取最消耗時(shí)間或者等待時(shí)間最長的SQL語句非常不錯(cuò)，但是同時(shí)也需要抓住其要點(diǎn)——在V$ACTIVE_SESSION_HISTORY視圖中又一次出現(xiàn)的SQL語句。通過這個(gè)視圖，能夠找出具體什么等待時(shí)間延遲了SQL語句執(zhí)行，連同實(shí)際的文件，對(duì)象以及阻塞的對(duì)象導(dǎo)致等待。 例如：設(shè)想已經(jīng)找到一個(gè)非凡的SQL語句，看上去在用戶I/O等待時(shí)間方面極端的嚴(yán)重，那么可以執(zhí)行下面的查詢來得到等待時(shí)間中各個(gè)單獨(dú)的等待事件，等待的文件，等待的對(duì)象： select event， time_waited， owner， object_name， current_file#， current_block# from sys.v_$active_session_history a， sys.dba_objects b where sql_id = '6gvch1xu9ca3g' and a.current_obj# = b.object_id and time_waited <> 0； EVENT TIME_WAITED OWNER OBJECT_NAME file block db file sequential read 27665 SYSMAN MGMT_METRICS_1HOUR_PK 3 29438 db file sequential read 3985 SYSMAN SEVERITY_PRIMARY_KEY 3 52877當(dāng)然，也可以通過使用V$ACTIVE_SESSION_HISTORY視圖中的歷史數(shù)據(jù)的方式來限制一段非凡時(shí)間內(nèi)的沒有優(yōu)化的SQL語句。問題在于Oracle10g數(shù)據(jù)庫通過簡化的數(shù)據(jù)字典視圖把SQL語句的響應(yīng)時(shí)間分析變得非常的簡單，比起以前運(yùn)用消耗時(shí)間的trace方法來說。 總結(jié) DBA們和性能分析專家們治理Oracle10g數(shù)據(jù)庫的性能時(shí)會(huì)發(fā)現(xiàn)在最新的Oracle旗艦數(shù)據(jù)庫中已經(jīng)把許多的響應(yīng)時(shí)間數(shù)據(jù)做成了動(dòng)態(tài)性能視圖。這些統(tǒng)計(jì)信息將有助于迅速找出大型復(fù)雜數(shù)據(jù)庫中的性能瓶頸所在。