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 |