性能優(yōu)化是一個(gè)永恒的話題,性能優(yōu)化也是最具有價(jià)值,最值得花費(fèi)精力深入研究的一個(gè)課題,因?yàn)橘Y源是有限的,時(shí)間是有限的。在Oracle數(shù)據(jù)庫(kù)中,隨著Oracle功能的不斷強(qiáng)大和完善,Oralce數(shù)據(jù)庫(kù)在性能方面實(shí)現(xiàn)自我診斷及優(yōu)化的功能也越來(lái)智能化,這大大的簡(jiǎn)花了人工優(yōu)化的腦力和體力的開銷,尤其是借助ADDM自動(dòng)診斷并給出調(diào)整建議。本文主要描述ADDM功能及特性。
ADDM全稱是Automatic Database Diagnostic Monitor,是Oracle一個(gè)實(shí)現(xiàn)性能自我診斷的最佳利器。它依賴于AWR,也就是說ADDM要診斷,必要要有診斷的依據(jù)。在Oracle中,這個(gè)診斷依據(jù)就是Oracle AWR,因?yàn)镺racle AWR會(huì)定期的收集整個(gè)數(shù)據(jù)庫(kù)在運(yùn)行期間的性能統(tǒng)計(jì)數(shù)據(jù)。ADDM可提供單實(shí)例以及Oracle RAC數(shù)據(jù)庫(kù)級(jí)別性能診斷,它主要實(shí)現(xiàn)以下功能:
??定期分析AWR數(shù)據(jù)(默認(rèn)情況下每小時(shí)自動(dòng)診斷診斷報(bào)告)
??診斷性能問題的根本原因
??提供糾正任何問題的建議
??標(biāo)識(shí)系統(tǒng)的非問題區(qū)域
ADDM分析特定時(shí)間段的性能數(shù)據(jù),也就是說需要為ADDM指定快照的范圍。ADDM總是分析實(shí)例模式指定的實(shí)例。對(duì)于非Oracle RAC或單實(shí)例環(huán)境,在實(shí)例模式中執(zhí)行的分析與數(shù)據(jù)庫(kù)范圍分析相同。如果你使用的是Oracle RAC,ADDM還將分析在數(shù)據(jù)庫(kù)模式的整個(gè)數(shù)據(jù)庫(kù)。ADDM按照DB Time,即數(shù)據(jù)庫(kù)時(shí)間模型統(tǒng)計(jì)自上而下進(jìn)行分析,將最消耗資源的問題(用占據(jù)整個(gè)DB Time的百分比排序)列出在首部,并給出建議辦法以及理由。所有的診斷結(jié)果都按此方式列出。
通過優(yōu)化后減少DB Time,在相同資源的前提下,使得數(shù)據(jù)庫(kù)能夠支持的更多用戶請(qǐng)求,從而增加吞吐量。
ADDM分析的主要范圍:
??CPU瓶頸:Oracle數(shù)據(jù)庫(kù)還是其他應(yīng)用程序?qū)е翪PU開銷過高?
??內(nèi)存瓶頸:Oracle數(shù)據(jù)庫(kù)的內(nèi)存結(jié)構(gòu),如SGA、PGA、和緩沖區(qū)高速緩存,足夠大嗎?
??I/O問題:I/O子系統(tǒng)執(zhí)行超預(yù)期?
??高負(fù)載SQL語(yǔ)句:是否有任何SQL語(yǔ)句正在消耗過多的系統(tǒng)資源?
??高負(fù)荷的PL/SQL的執(zhí)行和編譯,和高負(fù)荷的java使用?
??Oracle RAC問題:全局緩存熱塊和對(duì)象是什么;有任何互連延遲的問題?
??應(yīng)用程序最優(yōu)使用Oracle數(shù)據(jù)庫(kù):如糟糕的連接管理,過度解析析,或應(yīng)用程序級(jí)鎖爭(zhēng)的問題嗎?
??數(shù)據(jù)庫(kù)配置問題:是否有不正確的日志文件大小,歸檔問題,過多的檢查點(diǎn),或未經(jīng)優(yōu)化的參數(shù)設(shè)置?
??并發(fā)問題:是否存在緩沖區(qū)忙問題?
??熱對(duì)象和頂級(jí)SQL的各種問題領(lǐng)域
默認(rèn)情況下,Oracle數(shù)據(jù)庫(kù)服務(wù)器從SGA每60分鐘自動(dòng)收集統(tǒng)計(jì)信息,并以快照的形式將其存儲(chǔ)在自動(dòng)工作負(fù)載信息庫(kù)(AWR)。這些快照存儲(chǔ)在磁盤和類似于statspack快照。然而,它們含有比statspack快照更精確的信息。此外,ADDM被計(jì)劃為自動(dòng)運(yùn)行,主動(dòng)偵測(cè)每一個(gè)數(shù)據(jù)庫(kù)實(shí)例。每一次拍攝快照,ADDM觸發(fā)執(zhí)行相應(yīng)的最后兩個(gè)快照周期進(jìn)行分析。這種方法在數(shù)據(jù)庫(kù)產(chǎn)生重大異常前,主動(dòng)監(jiān)測(cè)實(shí)例,并檢測(cè)瓶頸,每個(gè)ADDM分析的結(jié)果存儲(chǔ)在自動(dòng)工作負(fù)載信息庫(kù),也可以通過OEM進(jìn)行管理。
注:雖然ADDM分析Oracle數(shù)據(jù)庫(kù)性能的最后兩個(gè)快照定義的時(shí)期,也可以手動(dòng)調(diào)用ADDM分析任何兩個(gè)時(shí)間間隔快照。
數(shù)據(jù)庫(kù)時(shí)間(Database Time)定義為在數(shù)據(jù)庫(kù)中處理用戶請(qǐng)求所花費(fèi)的時(shí)間的總和。圖中上半部分描述了單個(gè)用戶提交請(qǐng)求的簡(jiǎn)單場(chǎng)景。用戶的響應(yīng)時(shí)間是發(fā)送請(qǐng)求的瞬間和接收響應(yīng)的瞬間之間的時(shí)間間隔。該用戶請(qǐng)求所涉及的數(shù)據(jù)庫(kù)時(shí)間僅是該用戶在數(shù)據(jù)庫(kù)中所花費(fèi)的響應(yīng)時(shí)間的一部分。
圖中下半部分描述的數(shù)據(jù)庫(kù)時(shí)間,是多個(gè)用戶時(shí)間之和,即每個(gè)用戶正在執(zhí)行一系列操作,導(dǎo)致對(duì)數(shù)據(jù)庫(kù)產(chǎn)生一系列請(qǐng)求。圖中可以看出,數(shù)據(jù)庫(kù)時(shí)間與用戶請(qǐng)求的數(shù)量和持續(xù)時(shí)間成正比,并且可以高于或低于相應(yīng)的自然時(shí)間(經(jīng)過的時(shí)間)。使用數(shù)據(jù)庫(kù)時(shí)間作為度量,可以測(cè)量數(shù)據(jù)庫(kù)的任何實(shí)體的性能影響。例如,尺寸較小的緩沖區(qū)高速緩存的性能影響將作為在執(zhí)行其緩沖區(qū)緩存較大時(shí)可能避免的其他I/O請(qǐng)求所花費(fèi)的總數(shù)據(jù)庫(kù)時(shí)間。數(shù)據(jù)庫(kù)時(shí)間只是衡量數(shù)據(jù)庫(kù)服務(wù)器完成的工作量。 數(shù)據(jù)庫(kù)時(shí)間消耗的速率是數(shù)據(jù)庫(kù)負(fù)載平均值,以數(shù)據(jù)庫(kù)時(shí)間每秒計(jì)算。 ADDM的目標(biāo)是減少在給定工作負(fù)載上花費(fèi)的數(shù)據(jù)庫(kù)時(shí)間,這類似于耗費(fèi)較少的能量來(lái)執(zhí)行相同的任務(wù)。
ADDM基于兩個(gè)時(shí)間維度來(lái)查看數(shù)據(jù)庫(kù)時(shí)間開銷:
a、查看在處理用戶請(qǐng)求的各個(gè)階段花費(fèi)的數(shù)據(jù)庫(kù)時(shí)間。此維度包括諸如“連接到數(shù)據(jù)庫(kù)”,“優(yōu)化SQL語(yǔ)句”和“執(zhí)行SQL語(yǔ)句”之類等。
b、查看使用或等待用于處理用戶請(qǐng)求的各種數(shù)據(jù)庫(kù)資源所花費(fèi)的數(shù)據(jù)庫(kù)時(shí)間。在此維度中考慮的數(shù)據(jù)庫(kù)資源包括硬件資源(如CPU和I / O設(shè)備)以及軟件資源(如數(shù)據(jù)庫(kù)鎖和應(yīng)用程序鎖)。
為了執(zhí)行自動(dòng)診斷,ADDM會(huì)查看在這兩個(gè)維度下,在每個(gè)類別中花費(fèi)的數(shù)據(jù)庫(kù)時(shí)間,然后演練到消耗大量數(shù)據(jù)庫(kù)時(shí)間的類別。可以使用DBTime-graph來(lái)表示此二維向下鉆取過程。
性能問題通常會(huì)將數(shù)據(jù)庫(kù)時(shí)間分布在一個(gè)維度的多個(gè)類別中,而不是另一個(gè)維度。例如,CPU容量不足的數(shù)據(jù)庫(kù)會(huì)降低處理用戶請(qǐng)求的所有階段,這些都是ADDM分析的第一個(gè)維度。然而,從第二個(gè)維度來(lái)看,影響數(shù)據(jù)庫(kù)的最佳性能問題是CPU容量不足。確定數(shù)據(jù)庫(kù)時(shí)間消耗的二維視圖給ADDM在縮小更重要的性能問題方面做出了非常好的判斷。
ADDM在診斷問題后,并建議可能的解決方案。ADDM分析結(jié)果表示為一組一組的研究成果。每個(gè)ADDM研究結(jié)果包括下列類型之一:
??問題發(fā)現(xiàn):哪些問題導(dǎo)致了過高的DB Time 占用
??建議對(duì)象:列出需要調(diào)整的對(duì)象
??行為理由:列出這些對(duì)象的行為以及調(diào)整的理由
建議的類型通常包括:
??硬件更改:添加CPU或更改I/O子系統(tǒng)配置
??數(shù)據(jù)庫(kù)配置:更改初始化參數(shù)設(shè)置
??模式的變化:哈希分區(qū)表或索引,或使用自動(dòng)段空間管理(ASSM)
??應(yīng)用程序更改:使用序列的緩存選項(xiàng)或使用綁定變量
??使用其他顧問:在高負(fù)載SQL上運(yùn)行SQL調(diào)優(yōu)顧問或在熱對(duì)象上運(yùn)行段顧問
建議的列表可以包含各種選擇來(lái)解決同樣的問題;你不必應(yīng)用所有的建議來(lái)解決特定的問題。每個(gè)建議有一個(gè)好處,這是一個(gè)估計(jì)的DB時(shí)間的一部分,可以節(jié)省,如果建議實(shí)施。建議包括行動(dòng)和理由。您必須應(yīng)用推薦的所有操作以獲得估計(jì)的效益。
要使用ADDM,兩個(gè)重要的參數(shù)應(yīng)進(jìn)行正確的配置。
??statistics_level:該參數(shù)建議設(shè)置為TYPICAL
??control_management_pack_access:該參數(shù)建議設(shè)置為DIAGNOSTIC+TUNING,及診斷和優(yōu)化包都被使用。
SQL> show parameter statistics_level;NAME TYPE VALUE------------------------------------ ----------- ------------------------------statistics_level string TYPICALSQL> show parameter control_management_pack_access;NAME TYPE VALUE------------------------------------ ----------- ------------------------------control_management_pack_access string DIAGNOSTIC+TUNINGSQL> select 'Leshami' Author,'http://blog.csdn.net/leshami' Blog, 2 '645746311' QQ from dual;AUTHOR BLOG QQ------- ---------------------------- ---------Leshami http://blog.csdn.net/leshami 645746311
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
--RAC環(huán)境下生成指定實(shí)例的addm報(bào)告使用addmrpti.sql腳本--下面是單實(shí)例下生產(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
報(bào)告頭部
ADDM Report for Task 'TASK_552' -------------------------------Analysis Period---------------AWR snapshot range from 85 to 90.Time period starts at 24-APR-17 01.00.12 PMTime period ends at 24-APR-17 06.00.17 PM--以上部分為分析的時(shí)間范圍,用于限定特定的時(shí)間范圍有助于診斷特定故障--本addm報(bào)告的時(shí)間周期為24-APR-17 01.00.12 PM - 24-APR-17 06.00.17 PMAnalysis Target---------------Database 'ORA11G' with DB ID 42938845.Database version 11.2.0.3.0.ADDM performed an analysis of instance ora11g, numbered 1 and hosted atydq05.--以上信息為數(shù)據(jù)庫(kù)的版本,庫(kù)名,實(shí)例等信息Activity During the Analysis Period-----------------------------------Total database time was 73757 seconds.The average number of active sessions was 4.1.--以上部分為分析期間的總的數(shù)據(jù)庫(kù)耗用時(shí)間以及每個(gè)會(huì)話的平均時(shí)間--當(dāng)前分析的期間內(nèi),自然流逝的時(shí)間為5*3600=18000<<DB time(73757),數(shù)據(jù)庫(kù)異常繁忙--每秒平均的活動(dòng)會(huì)話數(shù)位4.1個(gè)Summary of Findings------------------- Description Active Sessions Recommendations Percent of Activity ------------------------- ------------------- ---------------1 Top SQL Statements 2.96 | 72.21 52 Free Buffer Waits 2.34 | 57.23 33 Buffer Busy - Hot Objects 1.21 | 29.64 54 Index Block Split .21 | 5.19 15 Commits and Rollbacks .12 | 2.98 1--以上部分是診斷結(jié)果的摘要部分,列出重要的診斷結(jié)果及百分比,建議條數(shù)--如第一行為TopSQL部分,受影響活動(dòng)會(huì)話數(shù)2.96,占據(jù)整個(gè)DB Time 72.21,,5條建議--第二行為Free Buffer Waits,受影響活動(dòng)會(huì)話數(shù)2.34,占整個(gè)DB Time 57.23,3條建議
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
診斷結(jié)果及建議部分
--這部分內(nèi)容主要有多個(gè)不同的Finding組成,且每個(gè)Finding均包含以下內(nèi)容:--1、在Finding標(biāo)題中列出相應(yīng)的Findings名稱,如TopSQL,或者相關(guān)等待事件如Free Buffer Waits--2、描述受影響的活動(dòng)會(huì)話數(shù),以及占用總活動(dòng)的百分比--3、給出優(yōu)化建議,采取的行動(dòng),以及理論依據(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個(gè)活動(dòng)會(huì)話,占用總活動(dòng)數(shù)目72.21%--并且描述通過SQL優(yōu)化能夠提升性能,可能會(huì)包含多條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ù)庫(kù)時(shí)間被分割為SQL 執(zhí)行占 100%, 語(yǔ)法分析占 0%, -- PL/SQL執(zhí)行占0%, Java執(zhí)行占0%,也就是全部為執(zhí)行時(shí)間,其他部分難以優(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; --上面是針對(duì)insert SQL語(yǔ)句(SQL_ID為f7rxuxzt64k87)給出的一些調(diào)整建議 --包含完整的SQL語(yǔ)句,執(zhí)行的次數(shù),以及執(zhí)行的平均時(shí)間 --同時(shí)也給出了該SQL相關(guān)的等待事件,如free buffer waits,write complete waits --最后還給出了一個(gè)頂級(jí)的調(diào)用為一個(gè)包調(diào)用了該SQL語(yǔ)句 --從上面的描述來(lái)看,SQL改進(jìn)的余地很小,可以通過減少等待事件等待時(shí)間來(lái)改善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.--上面的部分描述了第二個(gè)診斷結(jié)果,為Free Buffer Waits等待事件--DBWR無(wú)法跟上空閑緩沖區(qū)的需求,也就是說DBWR太慢,臟數(shù)據(jù)服務(wù)及時(shí)寫出到數(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. --建議采取的行動(dòng)是調(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/寫 --單塊讀的平均時(shí)間為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. --第三個(gè)建議是使用直接路徑插入方式替換現(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個(gè)診斷結(jié)果為存在熱對(duì)象,數(shù)據(jù)庫(kù)熱塊讀寫消耗了大量數(shù)據(jù)庫(kù)時(shí)間 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ū),以實(shí)現(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)) ) --這個(gè)建議是對(duì)索引進(jìn)行分區(qū),以實(shí)現(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
其他信息
Additional Information ----------------------Miscellaneous Information-------------------------Wait class 'Application' was not consuming significant database time.CPU was not a bottleneck for the instance.Wait class 'Network' was not consuming significant database time.Wait class 'User I/O' was not consuming significant database time.Session connect and disconnect calls were not consuming significant databasetime.Hard parsing of SQL statements was not consuming significant database time.The database's maintenance windows were active during 100% of the analysisperiod.--其它部分是一些額外的信息,用于說明哪些類別沒有消耗大量的數(shù)據(jù)庫(kù)時(shí)間。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
聯(lián)系客服