性能優(yōu)化是一個永恒的話題，性能優(yōu)化也是最具有價值，最值得花費(fèi)精力深入研究的一個課題，因為資源是有限的，時間是有限的。在Oracle數(shù)據(jù)庫中，隨著Oracle功能的不斷強(qiáng)大和完善，Oralce數(shù)據(jù)庫在性能方面實現(xiàn)自我診斷及優(yōu)化的功能也越來智能化，這大大的簡花了人工優(yōu)化的腦力和體力的開銷，尤其是借助ADDM自動診斷并給出調(diào)整建議。本文主要描述ADDM功能及特性。

一、ADDM的主要功能

ADDM全稱是Automatic Database Diagnostic Monitor，是Oracle一個實現(xiàn)性能自我診斷的最佳利器。它依賴于AWR，也就是說ADDM要診斷，必要要有診斷的依據(jù)。在Oracle中，這個診斷依據(jù)就是Oracle AWR，因為Oracle AWR會定期的收集整個數(shù)據(jù)庫在運(yùn)行期間的性能統(tǒng)計數(shù)據(jù)。ADDM可提供單實例以及Oracle RAC數(shù)據(jù)庫級別性能診斷，它主要實現(xiàn)以下功能：

??定期分析AWR數(shù)據(jù)(默認(rèn)情況下每小時自動診斷診斷報告)

??診斷性能問題的根本原因

??提供糾正任何問題的建議

??標(biāo)識系統(tǒng)的非問題區(qū)域

ADDM分析特定時間段的性能數(shù)據(jù)，也就是說需要為ADDM指定快照的范圍。ADDM總是分析實例模式指定的實例。對于非Oracle RAC或單實例環(huán)境，在實例模式中執(zhí)行的分析與數(shù)據(jù)庫范圍分析相同。如果你使用的是Oracle RAC，ADDM還將分析在數(shù)據(jù)庫模式的整個數(shù)據(jù)庫。ADDM按照DB Time，即數(shù)據(jù)庫時間模型統(tǒng)計自上而下進(jìn)行分析，將最消耗資源的問題(用占據(jù)整個DB Time的百分比排序)列出在首部，并給出建議辦法以及理由。所有的診斷結(jié)果都按此方式列出。

通過優(yōu)化后減少DB Time，在相同資源的前提下，使得數(shù)據(jù)庫能夠支持的更多用戶請求，從而增加吞吐量。

ADDM分析的主要范圍：

??CPU瓶頸：Oracle數(shù)據(jù)庫還是其他應(yīng)用程序?qū)е翪PU開銷過高？

??內(nèi)存瓶頸：Oracle數(shù)據(jù)庫的內(nèi)存結(jié)構(gòu)，如SGA、PGA、和緩沖區(qū)高速緩存，足夠大嗎？

??I/O問題：I/O子系統(tǒng)執(zhí)行超預(yù)期？

??高負(fù)載SQL語句：是否有任何SQL語句正在消耗過多的系統(tǒng)資源？

??高負(fù)荷的PL/SQL的執(zhí)行和編譯，和高負(fù)荷的java使用？

??Oracle RAC問題：全局緩存熱塊和對象是什么；有任何互連延遲的問題？

??應(yīng)用程序最優(yōu)使用Oracle數(shù)據(jù)庫：如糟糕的連接管理，過度解析析，或應(yīng)用程序級鎖爭的問題嗎？

??數(shù)據(jù)庫配置問題：是否有不正確的日志文件大小，歸檔問題，過多的檢查點，或未經(jīng)優(yōu)化的參數(shù)設(shè)置？

??并發(fā)問題：是否存在緩沖區(qū)忙問題？

??熱對象和頂級SQL的各種問題領(lǐng)域

三、ADDM邏輯結(jié)構(gòu)圖及診斷方法

1、邏輯結(jié)構(gòu)

默認(rèn)情況下，Oracle數(shù)據(jù)庫服務(wù)器從SGA每60分鐘自動收集統(tǒng)計信息，并以快照的形式將其存儲在自動工作負(fù)載信息庫（AWR）。這些快照存儲在磁盤和類似于statspack快照。然而，它們含有比statspack快照更精確的信息。此外，ADDM被計劃為自動運(yùn)行，主動偵測每一個數(shù)據(jù)庫實例。每一次拍攝快照，ADDM觸發(fā)執(zhí)行相應(yīng)的最后兩個快照周期進(jìn)行分析。這種方法在數(shù)據(jù)庫產(chǎn)生重大異常前，主動監(jiān)測實例，并檢測瓶頸，每個ADDM分析的結(jié)果存儲在自動工作負(fù)載信息庫，也可以通過OEM進(jìn)行管理。

注：雖然ADDM分析Oracle數(shù)據(jù)庫性能的最后兩個快照定義的時期，也可以手動調(diào)用ADDM分析任何兩個時間間隔快照。

2、ADDM與Database Time

數(shù)據(jù)庫時間(Database Time)定義為在數(shù)據(jù)庫中處理用戶請求所花費(fèi)的時間的總和。圖中上半部分描述了單個用戶提交請求的簡單場景。用戶的響應(yīng)時間是發(fā)送請求的瞬間和接收響應(yīng)的瞬間之間的時間間隔。該用戶請求所涉及的數(shù)據(jù)庫時間僅是該用戶在數(shù)據(jù)庫中所花費(fèi)的響應(yīng)時間的一部分。

圖中下半部分描述的數(shù)據(jù)庫時間，是多個用戶時間之和，即每個用戶正在執(zhí)行一系列操作，導(dǎo)致對數(shù)據(jù)庫產(chǎn)生一系列請求。圖中可以看出，數(shù)據(jù)庫時間與用戶請求的數(shù)量和持續(xù)時間成正比，并且可以高于或低于相應(yīng)的自然時間（經(jīng)過的時間）。使用數(shù)據(jù)庫時間作為度量，可以測量數(shù)據(jù)庫的任何實體的性能影響。例如，尺寸較小的緩沖區(qū)高速緩存的性能影響將作為在執(zhí)行其緩沖區(qū)緩存較大時可能避免的其他I/O請求所花費(fèi)的總數(shù)據(jù)庫時間。數(shù)據(jù)庫時間只是衡量數(shù)據(jù)庫服務(wù)器完成的工作量。 數(shù)據(jù)庫時間消耗的速率是數(shù)據(jù)庫負(fù)載平均值，以數(shù)據(jù)庫時間每秒計算。 ADDM的目標(biāo)是減少在給定工作負(fù)載上花費(fèi)的數(shù)據(jù)庫時間，這類似于耗費(fèi)較少的能量來執(zhí)行相同的任務(wù)。

3、ADDM診斷方法

識別最大數(shù)據(jù)庫時間開銷的組件，并優(yōu)化該組件，即可獲得最大收益。也就是ADDM可以量化性能瓶頸。自動性能調(diào)優(yōu)的第一步是正確識別性能問題的根本原因。只有當(dāng)正確識別性能問題的根本原因時，才有可能探索有效的調(diào)整建議來解決或優(yōu)化這個問題。

ADDM基于兩個時間維度來查看數(shù)據(jù)庫時間開銷：
a、查看在處理用戶請求的各個階段花費(fèi)的數(shù)據(jù)庫時間。此維度包括諸如“連接到數(shù)據(jù)庫”，“優(yōu)化SQL語句”和“執(zhí)行SQL語句”之類等。
b、查看使用或等待用于處理用戶請求的各種數(shù)據(jù)庫資源所花費(fèi)的數(shù)據(jù)庫時間。在此維度中考慮的數(shù)據(jù)庫資源包括硬件資源（如CPU和I / O設(shè)備）以及軟件資源（如數(shù)據(jù)庫鎖和應(yīng)用程序鎖）。

為了執(zhí)行自動診斷，ADDM會查看在這兩個維度下，在每個類別中花費(fèi)的數(shù)據(jù)庫時間，然后演練到消耗大量數(shù)據(jù)庫時間的類別?？梢允褂肈BTime-graph來表示此二維向下鉆取過程。
性能問題通常會將數(shù)據(jù)庫時間分布在一個維度的多個類別中，而不是另一個維度。例如，CPU容量不足的數(shù)據(jù)庫會降低處理用戶請求的所有階段，這些都是ADDM分析的第一個維度。然而，從第二個維度來看，影響數(shù)據(jù)庫的最佳性能問題是CPU容量不足。確定數(shù)據(jù)庫時間消耗的二維視圖給ADDM在縮小更重要的性能問題方面做出了非常好的判斷。

三、ADDM診斷結(jié)果

ADDM在診斷問題后，并建議可能的解決方案。ADDM分析結(jié)果表示為一組一組的研究成果。每個ADDM研究結(jié)果包括下列類型之一：

??問題發(fā)現(xiàn)：哪些問題導(dǎo)致了過高的DB Time 占用

??建議對象：列出需要調(diào)整的對象

??行為理由：列出這些對象的行為以及調(diào)整的理由

建議的類型通常包括：

??硬件更改：添加CPU或更改I/O子系統(tǒng)配置

??數(shù)據(jù)庫配置：更改初始化參數(shù)設(shè)置

??模式的變化：哈希分區(qū)表或索引，或使用自動段空間管理（ASSM）

??應(yīng)用程序更改：使用序列的緩存選項或使用綁定變量

??使用其他顧問：在高負(fù)載SQL上運(yùn)行SQL調(diào)優(yōu)顧問或在熱對象上運(yùn)行段顧問

建議的列表可以包含各種選擇來解決同樣的問題；你不必應(yīng)用所有的建議來解決特定的問題。每個建議有一個好處，這是一個估計的DB時間的一部分，可以節(jié)省，如果建議實施。建議包括行動和理由。您必須應(yīng)用推薦的所有操作以獲得估計的效益。

四、配置ADDM

要使用ADDM，兩個重要的參數(shù)應(yīng)進(jìn)行正確的配置。

??statistics_level：該參數(shù)建議設(shè)置為TYPICAL

??control_management_pack_access：該參數(shù)建議設(shè)置為DIAGNOSTIC+TUNING，及診斷和優(yōu)化包都被使用。

五、生成ADDM報告

--RAC環(huán)境下生成指定實例的addm報告使用addmrpti.sql腳本--下面是單實例下生產(chǎn)addmSQL> @?/rdbms/admin/addmrpt.sqlCurrent Instance~~~~~~~~~~~~~~~~   DB Id    DB Name      Inst Num Instance----------- ------------ -------- ------------   42938845 ORA11G              1 ora11gInstances in this Workload Repository schema~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~   DB Id     Inst Num DB Name      Instance     Host------------ -------- ------------ ------------ ------------* 42938845          1 ORA11G       ora11g       ydq05Specify the Begin and End Snapshot Ids~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Enter value for begin_snap: 85Begin Snapshot Id specified: 85Enter value for end_snap: 90End   Snapshot Id specified: 90-- Author : Leshami-- Blog   : http://blog.csdn.net/leshami-- QQ     : 645746311Specify the Report Name~~~~~~~~~~~~~~~~~~~~~~~The default report file name is addmrpt_1_85_90.txt.  To use this name,press <return> to continue, otherwise enter an alternative.Enter value for report_name:Using the report name addmrpt_1_85_90.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

六、分析ADDM報告

• 報告頭部

• 診斷結(jié)果及建議部分

--這部分內(nèi)容主要有多個不同的Finding組成，且每個Finding均包含以下內(nèi)容：--1、在Finding標(biāo)題中列出相應(yīng)的Findings名稱，如TopSQL，或者相關(guān)等待事件如Free Buffer Waits--2、描述受影響的活動會話數(shù)，以及占用總活動的百分比--3、給出優(yōu)化建議，采取的行動，以及理論依據(jù)Finding 1: Top SQL StatementsImpact is 2.96 active sessions, 72.21% of total activity.---------------------------------------------------------SQL statements consuming significant database time were found. Thesestatements offer a good opportunity for performance improvement.--上面部分描述了Top SQL影響了2.96個活動會話，占用總活動數(shù)目72.21%--并且描述通過SQL優(yōu)化能夠提升性能，可能會包含多條SQL   Recommendation 1: SQL Tuning   Estimated benefit is .79 active sessions, 19.17% of total activity.   -------------------------------------------------------------------   Action      Investigate the INSERT statement with SQL_ID 'f7rxuxzt64k87' for      possible performance improvements. You can supplement the information      given here with an ASH report for this SQL_ID.      Related Object         SQL statement with SQL_ID f7rxuxzt64k87.         INSERT INTO ORDER_ITEMS ( ORDER_ID, LINE_ITEM_ID, PRODUCT_ID,         UNIT_PRICE, QUANTITY, GIFT_WRAP, CONDITION, ESTIMATED_DELIVERY )         VALUES ( :B4 , :B3 , :B2 , :B1 , 1, 'None', 'New', (SYSDATE + 3) )   Rationale      The SQL spent only 0% of its database time on CPU, I/O and Cluster      waits. Therefore, the SQL Tuning Advisor is not applicable in this case.      Look at performance data for the SQL to find potential improvements.   Rationale      Database time for this SQL was divided as follows: 100% for SQL      execution, 0% for parsing, 0% for PL/SQL execution and 0% for Java      execution.      -- 此SQL數(shù)據(jù)庫時間被分割為SQL 執(zhí)行占 100%, 語法分析占 0%,      -- PL/SQL執(zhí)行占0%, Java執(zhí)行占0%，也就是全部為執(zhí)行時間，其他部分難以優(yōu)化   Rationale      SQL statement with SQL_ID 'f7rxuxzt64k87' was executed 55962 times and      had an average elapsed time of 0.25 seconds.   Rationale      Waiting for event 'free buffer waits' in wait class 'Configuration'      accounted for 43% of the database time spent in processing the SQL      statement with SQL_ID 'f7rxuxzt64k87'.   Rationale      Waiting for event 'write complete waits' in wait class 'Configuration'      accounted for 25% of the database time spent in processing the SQL      statement with SQL_ID 'f7rxuxzt64k87'.   Rationale      Waiting for event 'buffer busy waits' in wait class 'Concurrency'      accounted for 23% of the database time spent in processing the SQL      statement with SQL_ID 'f7rxuxzt64k87'.   Rationale      Top level calls to execute the PL/SQL statement with SQL_ID      '0w2qpuc6u2zsp' are responsible for 100% of the database time spent on      the INSERT statement with SQL_ID 'f7rxuxzt64k87'.      Related Object         SQL statement with SQL_ID 0w2qpuc6u2zsp.         BEGIN :1 := orderentry.neworder(:2 ,:3 ,:4 ); END;    --上面是針對insert SQL語句(SQL_ID為f7rxuxzt64k87)給出的一些調(diào)整建議    --包含完整的SQL語句，執(zhí)行的次數(shù)，以及執(zhí)行的平均時間    --同時也給出了該SQL相關(guān)的等待事件，如free buffer waits,write complete waits    --最后還給出了一個頂級的調(diào)用為一個包調(diào)用了該SQL語句    --從上面的描述來看，SQL改進(jìn)的余地很小，可以通過減少等待事件等待時間來改善Finding 2: Free Buffer WaitsImpact is 2.34 active sessions, 57.23% of total activity.---------------------------------------------------------Database writers (DBWR) were unable to keep up with the demand for freebuffers.--上面的部分描述了第二個診斷結(jié)果，為Free Buffer Waits等待事件--DBWR無法跟上空閑緩沖區(qū)的需求，也就是說DBWR太慢，臟數(shù)據(jù)服務(wù)及時寫出到數(shù)據(jù)文件   Recommendation 1: Database Configuration   Estimated benefit is 2.34 active sessions, 57.23% of total activity.   --------------------------------------------------------------------   Action      Consider increasing the number of database writers (DBWR) by setting the      parameter 'db_writer_processes'. Also consider if asynchronous I/O is      appropriate for your architecture.   Rationale      The value of parameter 'db_writer_processes' was '1' during the analysis      period.   Rationale      The value of parameter 'disk_asynch_io' was 'TRUE' during the analysis      period.   --建議采取的行動是調(diào)整db_writer_processes參數(shù)值，加快寫入   --建議調(diào)查參數(shù)磁盤異步IO參數(shù)，disk_asynch_io   Recommendation 2: Host Configuration   Estimated benefit is 2.34 active sessions, 57.23% of total activity.   --------------------------------------------------------------------   Action      Investigate the I/O subsystem's write performance.   Rationale      During the analysis period, the average data files' I/O throughput was      663 K per second for reads and 237 K per second for writes. The average      response time for single block reads was 0.02 milliseconds.   --建議調(diào)查I/O子系統(tǒng)寫入性能，在分析診斷期間，平均的I/O吞吐為663k/讀，273k/寫   --單塊讀的平均時間為0.02毫秒   Recommendation 3: Application Analysis   Estimated benefit is 2.34 active sessions, 57.23% of total activity.   --------------------------------------------------------------------   Action      Investigate application logic for possible use of direct path inserts as      an alternative for multiple INSERT operations.   Symptoms That Led to the Finding:   ---------------------------------      Wait class 'Configuration' was consuming significant database time.      Impact is 2.41 active sessions, 58.74% of total activity.   --第三個建議是使用直接路徑插入方式替換現(xiàn)有的走緩沖區(qū)的方式Finding 3: Buffer Busy - Hot ObjectsImpact is 1.21 active sessions, 29.64% of total activity.---------------------------------------------------------Read and write contention on database blocks was consuming significantdatabase time.--第3個診斷結(jié)果為存在熱對象，數(shù)據(jù)庫熱塊讀寫消耗了大量數(shù)據(jù)庫時間   Recommendation 1: Schema Changes   Estimated benefit is .5 active sessions, 12.18% of total activity.   ------------------------------------------------------------------   Action      Consider partitioning the TABLE 'SOE.LOGON' with object ID 77203 in a      manner that will evenly distribute concurrent DML across multiple      partitions.      Related Object         Database object with ID 77203.   Rationale      The INSERT statement with SQL_ID 'gzhkw1qu6fwxm' was significantly      affected by 'buffer busy' waits.      Related Object         SQL statement with SQL_ID gzhkw1qu6fwxm.         INSERT INTO LOGON (LOGON_ID,CUSTOMER_ID, LOGON_DATE) VALUES         (LOGON_SEQ.NEXTVAL, :B2 , :B1 )   --上面的建議是建議將logon表進(jìn)行分區(qū)，以實現(xiàn)離散IO   Recommendation 2: Schema Changes   Estimated benefit is .2 active sessions, 4.77% of total activity.   -----------------------------------------------------------------   Action      Consider partitioning the INDEX 'SOE.CARDDETAILS_CUST_IX' with object ID      77261 in a manner that will evenly distribute concurrent DML across      multiple partitions.      Related Object         Database object with ID 77261.   Rationale      The INSERT statement with SQL_ID 'budtrjayjnvw3' was significantly      affected by 'buffer busy' waits.      Related Object         SQL statement with SQL_ID budtrjayjnvw3.         INSERT INTO CARD_DETAILS ( CARD_ID, CUSTOMER_ID, CARD_TYPE,         CARD_NUMBER, EXPIRY_DATE, IS_VALID, SECURITY_CODE ) VALUES ( :B2 ,         :B1 , 'Visa(Debit)', FLOOR(DBMS_RANDOM.VALUE(1111111111,         9999999999)), TRUNC(SYSDATE + (DBMS_RANDOM.VALUE(365, 1460))), 'Y',         FLOOR(DBMS_RANDOM.VALUE(1111, 9999)) )   --這個建議是對索引進(jìn)行分區(qū)，以實現(xiàn)離散IO--其他部分省略
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170

• 其他信息