當(dāng)在調(diào)節(jié)system時(shí)，比較系統(tǒng)的CPU time 和wait time是十分重要的，從而確定在相應(yīng)時(shí)間中多少是用于有效的工作時(shí)間，多少是在等待由其他進(jìn)程占用的資源。

    從一般規(guī)律來看，wait time占主要部分的系統(tǒng)比CPU time占主要部分的系統(tǒng)更需要調(diào)節(jié)。另一方面，CPU的大量使用可能是由不好的SQL寫操作造成了。

    盡管CPU time與wait time的比率總是隨著系統(tǒng)裝載的增加而趨于減小的，wait time的急劇增加是存在沖突的表現(xiàn)，必須被有效的處理。

    給node增加更多的CPUs或是給cluster增加nodes，在資源競爭中提供的benefit是非常有限的。相反，當(dāng)加載系統(tǒng)裝載增加時(shí)，CPU time的比率沒有大幅下降的系統(tǒng)可能規(guī)模較好，更可能通過添加CPUs或是RAC Instances獲得更多的benefit。

    note：如果CPU time比率在前五個(gè)事件中，則automatic workload repository（AWR）報(bào)告在Top 5 Event段中顯示了CPU時(shí)間和wait 時(shí)間。

    2、RAC特有的調(diào)節(jié)

    盡管對(duì)于RAC有其特有的調(diào)節(jié)方法，例如互聯(lián)的傳輸，但通過對(duì)每個(gè)Instance進(jìn)行像single-Instance 系統(tǒng)那樣的調(diào)節(jié)會(huì)帶來較大的benefit。至少它應(yīng)該tuning的第一步。

    顯然，如果在single-Instance環(huán)境中存在序列化問題，在RAC中，該問題會(huì)更加嚴(yán)重。

    RAC-reactive調(diào)節(jié)工具主要有：特定的等待事件、系統(tǒng)和隊(duì)列統(tǒng)計(jì)、database control 性能頁面、statspack和AWR 報(bào)告

    RAC-proactive調(diào)節(jié)工具：AWR snapshots、ADDM（Automatic Database Diagnostic Monitor） 報(bào)告

    如上，RAC的調(diào)節(jié)工具和single-Instance系統(tǒng)的基本類似。但部分特殊等待事件和統(tǒng)計(jì)信息的結(jié)合是RAC比較關(guān)鍵的調(diào)節(jié)情況。

    3、分析在RAC中cache fusion（緩沖融合）的影響

    在全局緩沖中訪問blocks的影響和維護(hù)cache的相融合（coherency）是通過下面來表現(xiàn)的：

    *  對(duì)當(dāng)前和cr blocks的全局緩沖服務(wù)統(tǒng)計(jì)：例如，gc當(dāng)前的blocks received、gc cr blocks received等。

    *  全局緩沖服務(wù)等待事件（對(duì)gc 當(dāng)前 block  3-way、gc cr grant 2-way等）

    cache fusion傳輸?shù)捻憫?yīng)時(shí)間是由物理交換鏈接組件、IPC協(xié)議和GCS協(xié)議使用的messaging時(shí)間和processing 時(shí)間決定的。

    除了相關(guān)的log寫操作，它是不受磁盤I/O因素的影響的。cache fusion 協(xié)議不需要對(duì)data files進(jìn)行I/O，從而確保緩沖的coherency。并且RAC并不會(huì)引起比非clustered Instance更多的I/O操作。

    4、RAC操作特有的潛在因素

    在RAC AWR報(bào)告中，在RAC統(tǒng)計(jì)一章包含了一個(gè)表，用于記錄一些全局cache services和全局隊(duì)列services操作的平均時(shí)間。該表被稱作是Global cache and Enqueue services: workload characteristics。這些潛在因素應(yīng)該得到定期的監(jiān)控，并且應(yīng)該對(duì)部分值的重大增加進(jìn)行調(diào)查?；诮?jīng)驗(yàn)觀察，此表顯示了一些代表值。引起這些潛在因素變更的因素主要有：

    *  IPC協(xié)議的使用。用戶模式的IPC協(xié)議更快

    *  當(dāng)系統(tǒng)在CPU高效使用的情況下，時(shí)序安排的延遲

    *  對(duì)當(dāng)前blocks 服務(wù)的log flush

    其他在AWR報(bào)告中，RAC潛在因素多數(shù)是從V$GES_STATISTICS中獲得的，并可能對(duì)調(diào)試非常有效。但無需進(jìn)行頻繁的監(jiān)控。

    note：處理緩存中一致讀（consistent read CR）block的時(shí)間與（build time+flush time+send time）一致；處理緩存中當(dāng)前block請(qǐng)求的時(shí)間與（pin time+ flush time+ send time）一致。

    5、RAC的等待事件

    分析哪些sessions在等待是一個(gè)確定時(shí)間開銷在哪里的重要方法。在RAC中，等待時(shí)間主要?dú)w因于影響獲得實(shí)際請(qǐng)求結(jié)果的事件上。例如，當(dāng)在某Instance上的一個(gè)session在Global cache查詢某個(gè)block，并不知道是否將收到cache在其他Instance中的data或是是否將獲得從disk上讀取的消息。對(duì)于Global cache的等待事件反映了準(zhǔn)確信息并等待全局緩沖block或是messages。它們主要是按照下述進(jìn)行分類的：

    *  在較廣的分類的概括，被稱作是cluster wait class

    *  用占位符代表的臨時(shí)事件，主要出現(xiàn)在block的等待

    *  當(dāng)獲得請(qǐng)求結(jié)果的精確事件

    RAC的等待事件對(duì)性能分析是非常重要的。它們被應(yīng)用于ADDM中，從而獲得cache fusion方面的精確診斷。

    1）等待事件視圖

    對(duì)于一個(gè)事件的總的等待信息——V$SYSTEM_EVENT

    一個(gè)session的等待事件分類——V$SESSION_WAIT_CLASS

    一個(gè)session等待的事件——V$SESSION_EVENT

    這三個(gè)視圖匯集了等待時(shí)間、timeouts和特定事件等待次數(shù)。

    最近活動(dòng)的sessions的活動(dòng)行為——V$ACTIVE_SESSION_HISTORY

    每個(gè)活動(dòng)的session最近10個(gè)等待事件——V$SESSION_WAIT_HISTORY

    活動(dòng)的sessions正在等待的事件——V$SESSION_WAIT

    受到互聯(lián)因素影響的一致的SQL語句——V$SQLAREA

    這四個(gè)視圖用于實(shí)時(shí)監(jiān)控等待的sessions，包括最近的等待時(shí)間歷史信息。

    通過其name和假設(shè)的參數(shù)，來區(qū)分單個(gè)事件自己。對(duì)于多數(shù)Global cache等待事件，參數(shù)包括文件號(hào)、塊號(hào)、塊的類型和訪問模式的配置（如held和request模式）。在這些視圖中顯示并統(tǒng)計(jì)的等待時(shí)間在調(diào)試相應(yīng)時(shí)間時(shí)是非常有用的。注意，等待時(shí)間是累積計(jì)算的，有最大的該值的不一定就是問題所在。但可用的CPU被占盡或是一個(gè)Application的相應(yīng)時(shí)間過長，top 等待事件提供了有效的性能診斷信息。

    note：在V$SQLAREA中使用CLUSTER_WAIT_TIME字段辨別SQL語句受到互聯(lián)因素的影響程度，或是在AWR snapshot上執(zhí)行一個(gè)ADDM報(bào)告。

    2）Global cache wait event概覽

    Oracle Database 10g中主要的Global cache等待事件的簡要描述如下：

    *  gc current/cr request：當(dāng)一個(gè)進(jìn)程訪問需要一個(gè)或者多個(gè)塊時(shí)，oracle會(huì)首先檢查自己的CACHE是否存在該塊，如果發(fā)現(xiàn)沒有，就會(huì)先通過global cache賦予這些塊共享訪問的權(quán)限，然后再訪問。假如，通過global cache 發(fā)現(xiàn)這些塊已經(jīng)在另一個(gè)實(shí)例的CACHE里面，那么這些塊就會(huì)通過CACHE FUSION,在節(jié)點(diǎn)之間直接傳遞，同時(shí)出現(xiàn)global cache cr request等待事件。current 和cr的不同，如果是讀的話，那就是cr request，如果是更改的話，那就是current request。

    *  gc [current/cr] [2/3]-way：具體解釋見后面實(shí)例

    *  gc [current/cr] block busy：一個(gè)current 或是 cr block被請(qǐng)求并收到，但LMS并沒有立即發(fā)送，因?yàn)槟承┨囟ǖ耐七t發(fā)送的情況被發(fā)現(xiàn)。

    *  gc [current/cr] grant 2-way：當(dāng)請(qǐng)求一個(gè)block時(shí)，receive了一個(gè)message，該message應(yīng)該是賦予了requester instance可以訪問這個(gè)block。如果這個(gè)block沒有在local cache中，則隨后的動(dòng)作就是去磁盤上讀該block。（插一點(diǎn)別的，oracle的對(duì)數(shù)據(jù)的訪問的控制，是在row級(jí)別和object級(jí)別，但是實(shí)際操作的對(duì)象卻是block，傳遞的對(duì)象也是block，對(duì)于一個(gè)block，來說，會(huì)有一個(gè)master instance，也就是這個(gè)block的管理者，然后還有零到多個(gè)參與者，比如有的instance為了讀一致性，可能會(huì)在自己的local cache中存著該block的過去某個(gè)時(shí)間的image，有的instace為了修改該block，可能會(huì)在自己的local cache中存著該block的past image）

    *  gc current grant busy：當(dāng)請(qǐng)求一個(gè)current block時(shí)，收到grant message。該busy表示請(qǐng)求被阻塞，主要是其他請(qǐng)求在前面或是該請(qǐng)求不能馬上被處理。

    *  gc [current/cr] [block/grant] congested ：無論是對(duì)于current還是cr類型block的請(qǐng)求，block或者grant都獲得了，但是在過程中有擁堵。也就是在內(nèi)部的隊(duì)列中等待超過1msec（納秒）。

    *  gc [current/cr] [failure/retry]：一個(gè)block被請(qǐng)求，卻收到失敗的狀態(tài)或是有其他意外事件的發(fā)生。

    *  gc buffer busy：對(duì)此，我的理解就是gc的內(nèi)存不足，有大量的block請(qǐng)求，需要等待將剛剛被pin入內(nèi)存并使用的block unpin后再使用。（好像沒理解對(duì)，看后面實(shí)例吧）

    3）2-way block request實(shí)例

    上圖顯示了當(dāng)一個(gè)master Instance請(qǐng)求一個(gè)block，該block不在本地cache中時(shí)，具體的操作。這里假設(shè)master Instance為SGA1，SGA2中包含了請(qǐng)求的block。具體如下：

    ①SGA1向SGA2直接發(fā)送一個(gè)請(qǐng)求，此時(shí)，SGA1發(fā)生gc current block request等待事件

    ②當(dāng)SGA2接到請(qǐng)求，它的本地LGWR進(jìn)程需要flush 部分恢復(fù)信息到其本地redo log文件中。例如，如果緩沖的block被頻繁的修改，該修改尚未被寫入log中，LMS就需要在傳輸block前令LGWR對(duì)log進(jìn)行flush。這可能會(huì)增加一個(gè)延遲，可能在請(qǐng)求的node上顯示一個(gè)busy wait。

    ③隨后，SGA2發(fā)送請(qǐng)求的block給SGA1。當(dāng)該block到達(dá)SGA1，等待事件完成，這被反映為gs current block 2-way。

    note：如果R表示在請(qǐng)求者的time，W為消息傳輸?shù)膖ime延遲，S為在server的time。則整個(gè)來回的總時(shí)間為：R(send) + W(small msg) + S(process msg, pocess block, send) + W(block) + R(receive block)

    4）3-way block request的實(shí)例

    在此，與上一個(gè)實(shí)例不同的就是block的請(qǐng)求者與block的master、block的緩沖不在同一個(gè)node上。所以總體時(shí)間為：

    R(send) + W(small msg) + S(process msg, send) + W(small msg) + S(process msg, process block, send) + W(block) + R(receive block)

    當(dāng)遠(yuǎn)程讀被掛起，任何在請(qǐng)求Instance上的嘗試讀寫緩沖在buffer中的data 的進(jìn)程將等待gc buffer busy事件，直到block到達(dá)。

    5）2-way grant實(shí)例

    6）considered “Lost“ Blocks實(shí)例

    如圖，此情況為：在請(qǐng)求的block到達(dá)前先收到了side channel message。在普通環(huán)境中，這是不會(huì)發(fā)生的。多數(shù)情況下它是轉(zhuǎn)換問題的顯示或是缺少私有互聯(lián)。這常與OS或是網(wǎng)絡(luò)的配置問題有關(guān)。

    note：可嘗試避免此類現(xiàn)象的發(fā)生，通過減小參數(shù)DB_FILE_MULTIBLOCK_READ_COUNT的值，使其低于16 。

    7）Global 隊(duì)列等待overview

    隊(duì)列等待并不是RAC特有的，但是在RAC環(huán)境中涉及到Global lock的操作。多數(shù)對(duì)隊(duì)列的Global請(qǐng)求是同步的，并且有前臺(tái)進(jìn)程等待。因此，隊(duì)列沖突在RAC環(huán)境中更明顯。多數(shù)隊(duì)列等待發(fā)生在下列類型的隊(duì)列：

    *  TX：transaction 隊(duì)列，用于事務(wù)的劃分和追蹤

    *  TM：table或是partition隊(duì)列，用于保護(hù)DML執(zhí)行期間table的定義

    *  HW：高水位線隊(duì)列，取得用于新的block操作的同步

    *  SQ：sequence隊(duì)列，用于Oracle sequence number的序列化增加

    *  US：undo segment 隊(duì)列，主要用于自動(dòng)undo 管理（AUM）的特性

    *  TA：主要用于事務(wù)恢復(fù)的隊(duì)列

    上述情況下，等待是同時(shí)的，可能造成嚴(yán)重的序列化，從而導(dǎo)致RAC環(huán)境的惡化。


 

    6、session和system 統(tǒng)計(jì)

    使用基于V$SYSSTAT的系統(tǒng)統(tǒng)計(jì)使得基于平均的Database描述成為可能。它是很多通過各種工具和方法獲得Database的度量和比率的基礎(chǔ)，例如AWR、statspack和Database control。

    為了進(jìn)一步對(duì)sessions進(jìn)行深化的了解，V$SESSTAT視圖是非常有用的。此外，如果使用了MODULE、ACTION模式的統(tǒng)計(jì)，將更有效。

    V$SEGMENT_STATISTICS對(duì)于RAC環(huán)境也非常重要，因?yàn)樗櫫薈R的數(shù)量以及object當(dāng)前獲得的blocks

    RAC相關(guān)的統(tǒng)計(jì)可以被分為以下幾組：

    *  Global cache service 統(tǒng)計(jì)：gc cr blocks received, gc cr block recevie time等

    *  Global Enqueue service 統(tǒng)計(jì)：global enqueue gets等

    *  messages發(fā)送的統(tǒng)計(jì)：gcs messages sent和ges messages sent

    可以通過查詢V$ENQUEUE_STATISTICS確定哪個(gè)隊(duì)列對(duì)Database service時(shí)間和最終的響應(yīng)時(shí)間有最大的影響。

    V$INSTANCE_CACHE_TRANSFER顯示了每個(gè)block類中有多少current和CR blocks從Instance中接受，包括多少傳輸引起延遲。

    7、RAC tuning的tips

    首先，在RAC環(huán)境中，必須先利用傳統(tǒng)的調(diào)節(jié)技術(shù)對(duì)每個(gè)Instance進(jìn)行調(diào)節(jié)，此外，下面的內(nèi)容也很重要：

    *  盡量避免較長的全表掃描來縮小GCS的請(qǐng)求。由Global CR請(qǐng)求引起的開支主要是因?yàn)楫?dāng)所查詢的結(jié)果在本地cache中不存在，先嘗試在其他cache中嘗試找到相應(yīng)數(shù)據(jù)。

    *  自動(dòng)段空間管理可以給table blocks提供Instance 關(guān)聯(lián)（affinity）

    *  增加sequences的caches改善Instance關(guān)聯(lián)的通過sequences獲得索引關(guān)鍵字的值的性能。

    *  當(dāng)把range或是list類型的partitioning和data-dependent routing相結(jié)合，可以有效的提高性能。

    *  hash partitioning可有效降低buffer busy的沖突，使得buffer訪問分布格局松散，可以使buffers用于更多的并發(fā)訪問。

    *  在RAC中，library cache和row cache操作都是全局協(xié)調(diào)的。所以過度的解析意味著額外的互聯(lián)傳輸。當(dāng)packages或是procedure需要被重新編譯時(shí)，需要以排他模式獲得library cache locks。

    *  因?yàn)閠ransaction locks 是全局協(xié)調(diào)的，在RAC中，也應(yīng)的到特殊的對(duì)待。例如使用tables代替Oracle sequences產(chǎn)生唯一numbers是不推薦的，可能引起嚴(yán)重的沖突，即使是在single Instance系統(tǒng)中。

    *  選擇性不好的indexes不會(huì)提高查詢性能，反而會(huì)降低DML操作的性能。在RAC環(huán)境中，unselective index blocks可能導(dǎo)致Instance間的沖突，增加cache對(duì)indexes傳輸?shù)牡念l度。

    8、index block沖突的思考

    由于index多數(shù)是單調(diào)遞增的，往往造成熱塊爭用的問題；而且對(duì)于大量的insert操作，可能引起頻繁的splits；所有l(wèi)eaf block的訪問都是通過root block的。所以index可能造成性能的降低。對(duì)此：

    *  全局索引hash partitioning

    *  增加sequence cache，如果必要的話

    9、undo block 考慮

    當(dāng)index blocks包含了從多個(gè)Instances發(fā)起的事務(wù)被頻繁的讀，過度的undo block傳輸和undo buffers的爭用經(jīng)常會(huì)發(fā)生。當(dāng)一個(gè)select語句需要讀取一個(gè)block，該block正被一個(gè)active的事務(wù)使用，就不得不用undo來重建一個(gè)CR版本。如果block所在的active 事務(wù)屬于不只一個(gè)Instance，則需要結(jié)合本地和遠(yuǎn)程undo information用于一致讀，依據(jù)被多個(gè)Instances修改的index blocks的數(shù)量和transaction的并發(fā)，undo block的傳輸可能成為瓶頸。

    這多發(fā)生在頻繁讀取近期插入的數(shù)據(jù)但提交不頻繁的應(yīng)用中。對(duì)此應(yīng)：

    *  使用shorter transaction從而降低這樣的可能性：從cache中獲得的index block含有未提交的data，從而降低訪問undo information用于一致讀的可能

    *  增加sequence cache size，從而減少需要進(jìn)行遠(yuǎn)程undo 信息組合的需求。

    10、高水位線的考慮

    數(shù)據(jù)的insert操作是業(yè)務(wù)領(lǐng)域的主要功能，新的blocks需要頻繁的分配給segment。如果data的insert操作比率較高，如果沒有找到空閑空間時(shí)，需要申請(qǐng)新的blocks。這需要獲得相應(yīng)的high-water mark（HWM）隊(duì)列。

    因此，最為普遍的狀況為：

    *  較高比率的隊(duì)列等待時(shí)間 enq: HW – contention

    *  較高比率的等待時(shí)間對(duì)于 gc current grant events

    前者是HWM隊(duì)列序列化的結(jié)果，后者是由于當(dāng)前訪問新的data blocks是需要對(duì)新的blocks進(jìn)行操作。在RAC環(huán)境中，這個(gè)空間管理操作的時(shí)間長短是與獲得HW隊(duì)列和獲得所有新的blocks的Global locks所用的時(shí)間成比例的。這個(gè)時(shí)間在普通環(huán)境中比較小，因?yàn)樵谠L問新的blocks時(shí)是不存在任何沖突的。然而，這種沖突可能會(huì)出現(xiàn)在有大量data load的業(yè)務(wù)需求中。對(duì)此，建議在本地管理及自動(dòng)空間管理segments中定義一致的較大的extent size，從而適當(dāng)解決相應(yīng)的問題。

    11、automatic workload repository

    1）overview

    AWR是Oracle Database 10g提供的基礎(chǔ)服務(wù)工具，用于收集、維護(hù)和應(yīng)用統(tǒng)計(jì)信息來檢測問題并進(jìn)行自我的調(diào)節(jié)。

    AWR主要由兩部分組成：

    *  一個(gè)在內(nèi)存的統(tǒng)計(jì)收集設(shè)施，由Oracle Database 10g使用并收集統(tǒng)計(jì)信息。這些統(tǒng)計(jì)被存儲(chǔ)在內(nèi)存中，可以通過動(dòng)態(tài)性能視圖查看到（V$）

    *  AWR snapshots 代表了設(shè)備的持久部分?？梢酝ㄟ^data dictionary視圖和Database control來訪問。

    處于以下幾個(gè)原因，統(tǒng)計(jì)需要保存在永久的設(shè)備中：

    *  統(tǒng)計(jì)需要用于激活I(lǐng)nstance crashes

    *  一些分析需要?dú)v史數(shù)據(jù)作為基線的比較

    *  內(nèi)存的溢出：當(dāng)由于內(nèi)存不足，舊的統(tǒng)計(jì)數(shù)據(jù)需要被新的統(tǒng)計(jì)數(shù)據(jù)替換時(shí)，可以將舊的統(tǒng)計(jì)數(shù)據(jù)存儲(chǔ)在磁盤上以備后用

    統(tǒng)計(jì)的內(nèi)存版本由新的后臺(tái)進(jìn)程manageability monitor（MMON）定期的傳輸?shù)膁isk上。通過AWR，Oracle Database提供了自動(dòng)捕獲歷史統(tǒng)計(jì)data的方法，無需DBA干涉。

    2）AWR tables

    AWR包括兩類表：

    *  元數(shù)據(jù)表：用于控制、處理、描述AWR 表。例如，Oracle Database 使用元數(shù)據(jù)表來確定何時(shí)執(zhí)行snapshots，并將什么數(shù)據(jù)捕獲到disk上。此外，元數(shù)據(jù)包含了snapshots_id和相應(yīng)通訊時(shí)間之間的映射。

    *  歷史統(tǒng)計(jì)表：存儲(chǔ)了Oracle Database的歷史統(tǒng)計(jì)信息。每個(gè)snapshots就是在特定時(shí)間點(diǎn)捕獲的內(nèi)存中的Database 統(tǒng)計(jì)數(shù)據(jù)。
AWR表的names都有 一個(gè)WRx$前綴，其中x指明了tables的種類：
    
    *  WRM$ 表存儲(chǔ)了AWR中的元數(shù)據(jù)

    *  WRH$表中存儲(chǔ)了歷史數(shù)據(jù)和snapshots

    可以是使用字典視圖來查詢AWR數(shù)據(jù)。在AWR中任何相關(guān)的歷史信息有DBA_HIST_的前綴

    AWR使用分區(qū)用于有效的查詢和數(shù)據(jù)的清理。snapshots tables是按照以下分類組織的：file 統(tǒng)計(jì)、一般系統(tǒng)統(tǒng)計(jì)、并發(fā)統(tǒng)計(jì)、Instance調(diào)節(jié)統(tǒng)計(jì)、SQL 統(tǒng)計(jì)、segment 統(tǒng)計(jì)、 undo 統(tǒng)計(jì)、time-model 統(tǒng)計(jì)、恢復(fù)統(tǒng)計(jì)和RAC統(tǒng)計(jì)。

    3）在RAC中的AWR snapshots

    在RAC環(huán)境中，每個(gè)AWR snapshot是從所有的活動(dòng)的Instances獲得data的。從每個(gè)活動(dòng)的Instances獲得的每個(gè)snapshot數(shù)據(jù)集合是大致來自相同的時(shí)間點(diǎn)的。此外，每個(gè)Instance的數(shù)據(jù)是單獨(dú)存儲(chǔ)的，是以Instance的標(biāo)識(shí)符來區(qū)分的。例如，buffer_busy_wait統(tǒng)計(jì)顯示了在每個(gè)Instance上buffer waits的次數(shù)。AWR不會(huì)存儲(chǔ)cluster中的合計(jì)數(shù)據(jù)。換句話說，data是存放在各自的Instance上的。

    由AWR產(chǎn)生的統(tǒng)計(jì)snapshots可以用于評(píng)估、產(chǎn)生報(bào)告顯示data 摘要。

    12、statspack 和AWR

    可以通過手工的對(duì)statspack操作獲得歷史統(tǒng)計(jì)數(shù)據(jù)。但是將statspack獲得的數(shù)據(jù)遷移到AWR中是不支持的，也不存在為其創(chuàng)建的視圖

    13、Automatic Database diagnosis monitor

    默認(rèn)下，Database每隔60分鐘，會(huì)自動(dòng)的從SGA中捕獲相應(yīng)的統(tǒng)計(jì)信息，并將其以snapshots的形式存儲(chǔ)在AWR中。這些snapshots被存儲(chǔ)在disk上，和statspack snapshots是一致的，但比statspack的信息更精確。此外，ADDM是通過在每個(gè)Database Instance中的新的MMON進(jìn)程自動(dòng)運(yùn)行相應(yīng)的計(jì)劃，來主動(dòng)找到問題的所在。每次獲得一個(gè)snapshot。ADDM會(huì)被觸發(fā)執(zhí)行一個(gè)與上一個(gè)snapshots進(jìn)行階段一致性比較的操作。

    每個(gè)ADDM分析被存儲(chǔ)在AWR中（WRI$表）也可通過EM訪問。

    1）ADDM問題分類

    ADDM使用樹形結(jié)構(gòu)代表所有可能需要調(diào)節(jié)的問題。該tree是基于新的等待和時(shí)間統(tǒng)計(jì)模式的。樹根代表的是Database當(dāng)前的癥狀。