熱點推薦:
您现在的位置: 電腦知識網 >> 編程 >> Oracle >> 正文

Oracle10g中如何分析響應時間

2013-11-13 15:30:48  來源: Oracle 

  在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
  • 上一篇文章:

  • 下一篇文章:
  • 推薦文章
    Copyright © 2005-2013 電腦知識網 Computer Knowledge   All rights reserved.