oracle awr ash

dawn009發表於2014-07-31
AWR基礎知識
1、自動工作負荷倉庫
Oracle收集了大量與效能和動作相關的統計資訊。這些資訊在記憶體中累加,並且有規律地寫入磁碟(也就是寫入構成AWR的表)。最終,這些資訊會過期並被重寫。
1.1、收集統計量
統計量收集的級別由例項引數STATISTICS_LEVEL控制。這個引數可能被設定為BASIC、TYPICAL或ALL。(預設TYPICAL)

  • TYPICAL:允許收集正常調整所需的所有統計量,同時不會收集對效能有不良影響的統計量集合。
  • BASIC:事實上禁止收集統計量,並且不存在可評估的效能優勢。
  • ALL:收集與SQL執行相關的、極其詳細的統計量。進行高階的SQL語句調整,就可以使用ALL級別,不過在收集統計量時會導致效能稍有退化。
統計量在記憶體中(SGA內的資料結構中)累積。統計量只反映例項所作的動作,所以並不影響例項的效能。統計量被定時(預設每小時一次)寫入磁碟,也就是寫入AWR。這被稱為一次“快照(snapshot)”。統計量被寫入磁碟的操作由後臺程式(可管理的監視器或MMON程式)完成。
MMON程式直接訪問構成SGA的記憶體結構,從而也可以訪問這些記憶體結構中的統計量。這個程式可以在不需要透過會話的情況下從SGA內抽取資料。此時唯一的系統開銷是將資料實際寫入AWR。在預設情況下,這個操作每小時執行一次,因此應當不會對執行時效能產生明顯的影響。
1.2、AWR的大小與位置
AWR是位於SYSAUX表空間內的一組表。這些表不能被重新定位,並且存在於SYSMAN模式中。雖然我們可以作為使用者SYSMAN登入資料庫,但是無法檢視AWR。訪問AWR最簡單的方式是Database Control。
快照預設在AWR中儲存7天,這個時間週期是可配置的。作為一條用於分配儲存空間大小的大致原則,如果每小時進行一次快照收集並且快照保留時間為7天,那麼AWR在SYSAUX表空間內可能需要200~300的空間。不過,這個資料總是會變化,根據會話數會被大幅提高。
1.3、快照的儲存
快照會在特定時間週期後被清除,在預設情況下,這個時間週期為7天。為了進行長期的調整,就必須在更長的時間週期內儲存快照。在預設情況下,AWR快照儲存7天,ADDM報告儲存30天。
2、診斷與調整顧問程式
7個顧問程式:

  • Automatic Database Diagnostic Monitor(資料庫自動診斷監視程式,簡寫為ADDM)
  • SQL Tuning Advisor(SQL調整顧問程式)
  • SQL Access Advisor(SQL訪問顧問程式)
  • Memory Advisor(記憶體顧問程式)
  • Mean Time to Recover(MTTR)Advisor(平均恢復時間顧問程式)
  • Segment Advisor(段顧問程式)
  • Undo Advisor(撤銷顧問程式)
2.1、ADDM顧問程式
只要生成快照,MMON程式就會自動執行ADDM。
檢視報告
[img=500,404 alt=em1 src=]http://www.itpub.net/[/img] 
[img=500,266 alt=em2 src=]http://www.itpub.net/[/img]  
這裡會顯示所有顧問程式的最近執行情況。
2.2、SQL Tuning Advisor與SQL Access Advisor
SQL Tuning Advisor將一條或多條SQL語句作為輸入,並且研究這些語句的結構與執行方式。這些SQL語句被稱為SQL Tuning Set,這個顧問程式涉及下列內容:

  • 收集所涉及物件的最佳化器統計量
  • 使用與語句執行相關的統計量生成SQL配置檔案
  • 修改程式碼,從而更有效地使用SQL構造
  • 重寫程式碼,從而去除可能的設計錯誤
SQL Access Advisor也將SQL Tuning Set作為其輸入。這個顧問程式研究透過新增索引或物化檢視是否能夠改善SQL執行效能,此外還研究某些索引與物化檢視實際上是否會妨礙改善效能以及是否應當被刪除。
2.3、Memory Advisor
記憶體顧問程式通常能實現:如果為SGA結構或PGA分配更多的記憶體,那麼效能會得到進一步改善,不過效益會遞減。如果可能因為交換系統而需要減少記憶體的使用,那麼就能夠節約記憶體。但是,如果節省的記憶體過多,那麼效能將會退化。
2.4、 MTTR Advisor
某個例項在崩潰之後必須被恢復,因此可能耗費相當長的時間,這個時間就是平均恢復時間(Mean Time to Recover,簡寫為MTTR)。
以秒為單位進行設定的例項引數FAST_START_RECOVERY_TARGET能夠控制MTTR。這個引數設定的時間越短,在例項崩潰後就越能更快地開啟資料庫,不過聯機效能會更差。
2.5、Segment Advisor
Segment Advisor會檢視段,並且能夠確定為未被使用的段所分配的空間大小是否足夠用於執行SHRINK SPACE操作。
2.6、Undo Advisor
所有DML命令都會生成撤銷資料。撤銷資料的保留時間至少是事務的時間長度,通常需要事務結束後相當長的時間內仍然儲存撤銷資料。
決定撤銷表空間大小的演算法基於下列方面:每秒鐘生成撤銷的速度,儲存滿足查詢執行時間最長需求的資料的秒數,並且可能使用閃回查詢。
3、伺服器生成的告警
3.1、告警系統體系結構
10G版本的Oracle資料庫能夠監視自身。MMON後臺程式是一個易管理的監視器,該程式可以觀察例項與資料庫。如果某種指標過於偏離期望值,那麼MMON程式就會生成一個告警。MMON程式生成的所有告警都被置入SYS模式中的佇列ALERT_QUE。
告警有兩種形式:閾值(有狀態的)或無閾值(無狀態的)。配置閾值告警時,必須設定某些要監視的指示值(例如表空間中所用空間的百分比)。當越過閾值時,就會引發一個告警,並且這個告警在採用使指標值低於觸發值的某些動作(例如為表空間新增更多的空間)之前會一直持續。無閾值告警由某個發生後並不持久的事件觸發,例如一個“ORA-1555:snapshot too old”錯誤。
3.2、設定閾值
某些告警被預配置了閾值,其他告警則必須在啟用之前進行設定。例如,對於“Tablespace percent full”告警來說,預設是在85%的表空間被填滿時傳送一個警告告警以及在97%的表空間被填滿時傳送一個臨界告警。但是,“Average File Read Time”告警沒有預設的配置。
3.3、使用基線
在不比較指標值與手動選定值的情況下,允許Oracle在效能上可接受的效能產生偏差時引發告警,這樣可以不必計算出準確的閾值。為了完成上述操作,需要建立一個“基線”。



ASH 基礎知識
作者:

效能調整和問題診斷是任何資料庫管理人員必須面臨的最大挑戰和必須完成的重要管理任務。基於管理上的簡化和易用性的努力,Oracle推出了Autometic Database Diagnostic Monitor (ADDM) ,透過ADDM,Oracle試圖使資料庫的維護工作變得更簡單更容易。

AWR是新的管理體系結構的中心元素,它為了發現問題和自我調整,為oracle內部服務元件提供了採集,處理,維護和訪問效能統計資料.
AWR每60分鐘就進行一次快照,所以最近的一次快照可能在一小時之前,這樣AWR就沒有足夠的資訊來進行當前的分析.典型的情況下,當前的分析需要最近的五到十分鐘的詳細資訊.ASH(Active Session History)因此被引入用以保留最近的會話活動的歷史資訊.

因為記錄會話的活動是非常昂貴的,ASH每秒取樣V$session,記錄會話等待的事件.不活動的會話不會被取樣.這個取樣工具是非常有效的,因為它直接訪問oracle10g內部結構.
ASH設計為在記憶體中的滾動的,在需要的時候早期的資訊是會被覆蓋的.ASH可以透過v$active_session_history檢視來訪問.這個例項每個樣本的每個活動會話有一行.
由於資料量巨大,把所有的ASH資料寫到磁碟上是不可接受的。一般是在寫到磁碟的時候過濾這個資料。這是透過MMON和MMNL自動完成的。
SQL> select * from v$sgastat where name like '%ASH%';POOL         NAME                            BYTES------------ -------------------------- ----------shared pool  ASH buffers                   6291456

注意,ASH buffers的大小按照以下演算法分配:
Min(shared_pool_size*5%,2M*cpu_count)
SQL> select name,value,display_value from v$parameter  2  where name in ('shared_pool_size','cpu_count');NAME                           VALUE                DISPLAY_VALUE------------------------------ -------------------- --------------------cpu_count                      4                    4shared_pool_size               125829120            120M

根據這個演算法,系統分配的ASH Buffers為6M. 這些歷史資訊記錄在資料庫中,可以透過v$session_wait_history進行查詢:
SQL> desc v$session_wait_historyName       Type         Nullable Default Comments ---------- ------------ -------- ------- -------- SID        NUMBER       Y                         SEQ#       NUMBER       Y                         EVENT#     NUMBER       Y                         EVENT      VARCHAR2(64) Y                         P1TEXT     VARCHAR2(64) Y                         P1         NUMBER       Y                         P2TEXT     VARCHAR2(64) Y                         P2         NUMBER       Y                         P3TEXT     VARCHAR2(64) Y                         P3         NUMBER       Y                         WAIT_TIME  NUMBER       Y                         WAIT_COUNT NUMBER       Y   

顯然ASH/ADDM是Oracle在管理上的又一巨大提高




生成AWR ASH報告

@?rdbms/admin/awrrpt.sql是以前statspack的擴充套件,收集資訊更詳細,檢視長期的資料庫情況,相對ash而言。

@?rdbms/admin/ashrpt.sql檢視當前的資料庫情況,因為ash是每秒從v$session進行進行取樣,awr收集的資料要比ash多得多。 
一般收集資料庫資訊的話要結合awr和ash。 
@?rdbms/admin/addmrpt .sql相當於是駐留在oracle裡的一位專家,是一個自我診斷引擎。產生symptom,problem,infomation,提供解決問題的建議,並自動修復一些具體的故障。 @?rdbms/admin/awrinfo.sql顯示的都是awr的相關資訊,包括快照資訊、sysaux空間使用、awr元件、ash等資訊。
--&gt>轉載於:http://elliptic.blog.163.com/blog/static/34344822201011794448386/

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/29119536/viewspace-1242930/,如需轉載,請註明出處,否則將追究法律責任。

相關文章