DB Name
|
DB Id
|
Instance
|
Inst num
|
Release
|
RAC
|
Host
|
TEST1212
|
3399531915
|
test1212
|
1
|
10.2.0.1.0
|
NO
|
DANDAN
|
Snap Id
|
Snap Time
|
Sessions
|
Cursors/Session
|
Begin Snap:
|
1
|
20-12月-10 21:01:03
|
15
|
2.5
|
End Snap:
|
2
|
20-12月-10 22:00:52
|
17
|
5.4
|
Elapsed:
|
|
59.81 (mins)
|
|
|
DB Time:
|
|
0.83 (mins)
|
|
|
DBid是唯一的數(shù)據(jù)庫的標(biāo)示,在rman中也能看到該值
C:"Documents and Settings"sure>rman target /
恢復(fù)管理器: Release 10.2.0.1.0 - Production on 星期一 12月 20 22:34:01 2010
Copyright (c) 1982, 2005, Oracle. All rights reserved.
連接到目標(biāo)數(shù)據(jù)庫: TEST1212 (DBID=3399531915)
RMAN>
DB Time不包括Oracle后臺(tái)進(jìn)程消耗的時(shí)間。如果DB Time遠(yuǎn)遠(yuǎn)小于Elapsed時(shí)間,說明數(shù)據(jù)庫比較空閑。計(jì)算公式:
在59分鐘里(其間收集了2次快照數(shù)據(jù)),數(shù)據(jù)庫耗時(shí)0.83分鐘,系統(tǒng)有1個(gè)CPU,平均CPU耗時(shí)0.83分鐘,CPU利用率只有大約1.38%(0.83/59.81)。說明系統(tǒng)壓力非常小(該系統(tǒng)啥都沒做J)。
對(duì)于批量系統(tǒng),數(shù)據(jù)庫的工作負(fù)載總是集中在一段時(shí)間內(nèi)。如果快照周期不在這一段時(shí)間內(nèi),或者快照周期跨度太長而包含了大量的數(shù)據(jù)庫空閑時(shí)間,所得出的分析結(jié)果是沒有意義的。這也說明選擇分析時(shí)間段很關(guān)鍵,要選擇能夠代表性能問題的時(shí)間段。
Cache Sizes
Begin
|
End
|
Buffer Cache:
|
412M
|
408M
|
Std Block Size:
|
8K
|
Shared Pool Size:
|
156M
|
160M
|
Log Buffer:
|
6,968K
|
顯示SGA中每個(gè)區(qū)域的大小,可用來與初始參數(shù)值比較。
shared pool主要包括library cache和dictionary cache。library cache用來存儲(chǔ)最近解析(或編譯)后SQL、PL/SQL。library cache用來存儲(chǔ)最近引用的數(shù)據(jù)字典。發(fā)生在library cache或dictionary cache的cache miss代價(jià)要比發(fā)生在buffer cache的代價(jià)高得多。因此shared pool的設(shè)置要確保最近使用的數(shù)據(jù)都能被cache,也就是盡可能的保持被命中(即傳說中的命中率)。
Load Profile
Per Second
|
Per Transaction
|
Redo size:
|
4,600.89
|
18,956.88
|
Logical reads:
|
427.08
|
1,759.70
|
Block changes:
|
29.02
|
119.57
|
Physical reads:
|
1.84
|
7.57
|
Physical writes:
|
0.37
|
1.52
|
User calls:
|
0.11
|
0.47
|
Parses:
|
5.13
|
21.14
|
Hard parses:
|
0.59
|
2.44
|
Sorts:
|
3.03
|
12.47
|
Logons:
|
0.03
|
0.14
|
Executes:
|
17.41
|
71.72
|
Transactions:
|
0.24
|
|
% Blocks changed per Read:
|
6.80
|
Recursive Call %:
|
99.93
|
Rollback per transaction %:
|
0.00
|
Rows per Sort:
|
189.64
|
顯示數(shù)據(jù)庫負(fù)載概況,將之與基線數(shù)據(jù)比較才具有更多的意義,如果每秒或每事務(wù)的負(fù)載變化不大,說明應(yīng)用運(yùn)行比較穩(wěn)定。單個(gè)的報(bào)告數(shù)據(jù)只說明應(yīng)用的負(fù)載情況,絕大多數(shù)據(jù)并沒有一個(gè)所謂“正確”的值,然而Logons大于每秒1~2個(gè)、Hard parses大于每秒100、全部parses超過每秒300表明可能有爭用問題。
Redo size:每秒/每事務(wù)產(chǎn)生的redo大小(單位字節(jié)),可標(biāo)志數(shù)據(jù)庫任務(wù)的繁重程序。
Logical reads:每秒/每事務(wù)邏輯讀的塊數(shù)
Block changes:每秒/每事務(wù)修改的塊數(shù)
Physical reads:每秒/每事務(wù)物理讀的塊數(shù)
Physical writes:每秒/每事務(wù)物理寫的塊數(shù)
User calls:每秒/每事務(wù)用戶call次數(shù)
Parses:SQL解析的次數(shù)
Hard parses:其中硬解析的次數(shù),硬解析太多,說明SQL重用率不高。
Sorts:每秒/每事務(wù)的排序次數(shù)
Logons:每秒/每事務(wù)登錄的次數(shù)
Executes:每秒/每事務(wù)SQL執(zhí)行次數(shù)
Transactions:每秒事務(wù)數(shù)
Blocks changed per Read:表示邏輯讀用于修改數(shù)據(jù)塊的比例
Recursive Call:遞歸調(diào)用占所有操作的比率
Rollback per transaction:每事務(wù)的回滾率
Rows per Sort:每次排序的行數(shù)
Instance Efficiency Percentages (Target 100%)
Buffer Nowait %:
|
100.00
|
Redo NoWait %:
|
100.00
|
Buffer Hit %:
|
99.57
|
In-memory Sort %:
|
100.00
|
Library Hit %:
|
92.37
|
Soft Parse %:
|
88.46
|
Execute to Parse %:
|
70.52
|
Latch Hit %:
|
99.99
|
Parse CPU to Parse Elapsd %:
|
84.03
|
% Non-Parse CPU:
|
80.34
|
這一段包含了Oracle關(guān)鍵指標(biāo)的內(nèi)存命中率及其它數(shù)據(jù)庫實(shí)例操作的效率。
Buffer Hit Ratio:也稱Cache Hit Ratio,Library Hit ratio也稱Library Cache Hit ratio。同Load Profile一節(jié)相同,這一節(jié)也沒有所謂“正確”的值,而只能根據(jù)應(yīng)用的特點(diǎn)判斷是否合適。在一個(gè)使用直接讀執(zhí)行大型并行查詢的DSS環(huán)境,20%的Buffer Hit Ratio是可以接受的,而這個(gè)值對(duì)于一個(gè)OLTP系統(tǒng)是完全不能接受的。根據(jù)Oracle的經(jīng)驗(yàn),對(duì)于OLTPT系統(tǒng),Buffer Hit Ratio理想應(yīng)該在90%以上。
Buffer Nowait:表示在內(nèi)存獲得數(shù)據(jù)的未等待比例。
buffer hit:表示進(jìn)程從內(nèi)存中找到數(shù)據(jù)塊的比率,監(jiān)視這個(gè)值是否發(fā)生重大變化比這個(gè)值本身更重要。對(duì)于一般的OLTP系統(tǒng),如果此值低于80%,應(yīng)該給數(shù)據(jù)庫分配更多的內(nèi)存。
Redo NoWait:表示在LOG緩沖區(qū)獲得BUFFER的未等待比例。如果太低(可參考90%閥值),考慮增加LOG BUFFER。
library hit:表示Oracle從Library Cache中檢索到一個(gè)解析過的SQL或PL/SQL語句的比率,當(dāng)應(yīng)用程序調(diào)用SQL或存儲(chǔ)過程時(shí),Oracle檢查Library Cache確定是否存在解析過的版本,如果存在,Oracle立即執(zhí)行語句;如果不存在,Oracle解析此語句,并在Library Cache中為它分配共享SQL區(qū)。低的library hit ratio會(huì)導(dǎo)致過多的解析,增加CPU消耗,降低性能。如果library hit ratio低于90%,可能需要調(diào)大shared pool區(qū)。
Latch Hit:Latch是一種保護(hù)內(nèi)存結(jié)構(gòu)的鎖,可以認(rèn)為是SERVER進(jìn)程獲取訪問內(nèi)存數(shù)據(jù)結(jié)構(gòu)的許可。要確保Latch Hit>99%,否則意味著Shared Pool latch爭用,可能由于未共享的SQL,或者Library Cache太小,可使用綁定變更或調(diào)大Shared Pool解決。
Parse CPU to Parse Elapsd:解析實(shí)際運(yùn)行時(shí)間/(解析實(shí)際運(yùn)行時(shí)間+解析中等待資源時(shí)間),越高越好。
Non-Parse CPU:SQL實(shí)際運(yùn)行時(shí)間/(SQL實(shí)際運(yùn)行時(shí)間+SQL解析時(shí)間),太低表示解析消耗時(shí)間過多。
Execute to Parse:是語句執(zhí)行與分析的比例,如果要SQL重用率高,則這個(gè)比例會(huì)很高。該值越高表示一次解析后被重復(fù)執(zhí)行的次數(shù)越多。
In-memory Sort:在內(nèi)存中排序的比率,如果過低說明有大量的排序在臨時(shí)表空間中進(jìn)行。考慮調(diào)大PGA。
Soft Parse:軟解析的百分比(softs/softs+hards),近似當(dāng)作sql在共享區(qū)的命中率,太低則需要調(diào)整應(yīng)用使用綁定變量。
Shared Pool Statistics
Begin
|
End
|
Memory Usage %:
|
45.69
|
56.15
|
% SQL with executions>1:
|
52.03
|
32.99
|
% Memory for SQL w/exec>1:
|
87.15
|
60.31
|
Memory Usage %:對(duì)于一個(gè)已經(jīng)運(yùn)行一段時(shí)間的數(shù)據(jù)庫來說,共享池內(nèi)存使用率,應(yīng)該穩(wěn)定在75%-90%間,如果太小,說明Shared Pool有浪費(fèi),而如果高于90,說明共享池中有爭用,內(nèi)存不足。
SQL with executions>1:執(zhí)行次數(shù)大于1的sql比率,如果此值太小,說明需要在應(yīng)用中更多使用綁定變量,避免過多SQL解析。
Memory for SQL w/exec>1:執(zhí)行次數(shù)大于1的SQL消耗內(nèi)存的占比。
Top 5 Timed Events
Event
|
Waits
|
Time(s)
|
Avg Wait(ms)
|
% Total Call Time
|
Wait Class
|
CPU time
|
|
37
|
|
74.1
|
|
db file sequential read
|
3,312
|
12
|
4
|
24.1
|
User I/O
|
control file parallel write
|
1,198
|
5
|
4
|
9.5
|
System I/O
|
os thread startup
|
58
|
2
|
33
|
3.9
|
Concurrency
|
db file scattered read
|
432
|
2
|
4
|
3.4
|
User I/O
|
posted on 2010-12-20 23:06
xrzp 閱讀(641)
評(píng)論(0) 編輯 收藏 所屬分類:
oracle-優(yōu)化