|
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是唯一的數據庫的標示,在rman中也能看到該值
C:"Documents and Settings"sure>rman target /
恢復管理器: Release 10.2.0.1.0 - Production on 星期一 12月 20 22:34:01 2010
Copyright (c) 1982, 2005, Oracle. All rights reserved.
連接到目標數據庫: TEST1212 (DBID=3399531915)
RMAN>
DB Time不包括Oracle后臺進程消耗的時間。如果DB Time遠遠小于Elapsed時間，說明數據庫比較空閑。計算公式:
在59分鐘里（其間收集了2次快照數據），數據庫耗時0.83分鐘，系統有1個CPU，平均CPU耗時0.83分鐘，CPU利用率只有大約1.38%（0.83/59.81）。說明系統壓力非常小(該系統啥都沒做J)。
對于批量系統，數據庫的工作負載總是集中在一段時間內。如果快照周期不在這一段時間內，或者快照周期跨度太長而包含了大量的數據庫空閑時間，所得出的分析結果是沒有意義的。這也說明選擇分析時間段很關鍵，要選擇能夠代表性能問題的時間段。
Cache Sizes
|
Begin
|
End
|
|
Buffer Cache:
|
412M
|
408M
|
Std Block Size:
|
8K
|
|
Shared Pool Size:
|
156M
|
160M
|
Log Buffer:
|
6,968K
|
顯示SGA中每個區域的大小,可用來與初始參數值比較。
shared pool主要包括library cache和dictionary cache。library cache用來存儲最近解析（或編譯）后SQL、PL/SQL。library cache用來存儲最近引用的數據字典。發生在library cache或dictionary cache的cache miss代價要比發生在buffer cache的代價高得多。因此shared pool的設置要確保最近使用的數據都能被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
|
顯示數據庫負載概況，將之與基線數據比較才具有更多的意義，如果每秒或每事務的負載變化不大，說明應用運行比較穩定。單個的報告數據只說明應用的負載情況，絕大多數據并沒有一個所謂“正確”的值，然而Logons大于每秒1~2個、Hard parses大于每秒100、全部parses超過每秒300表明可能有爭用問題。
Redo size：每秒/每事務產生的redo大小（單位字節），可標志數據庫任務的繁重程序。
Logical reads：每秒/每事務邏輯讀的塊數
Block changes：每秒/每事務修改的塊數
Physical reads：每秒/每事務物理讀的塊數
Physical writes：每秒/每事務物理寫的塊數
User calls：每秒/每事務用戶call次數
Parses：SQL解析的次數
Hard parses：其中硬解析的次數，硬解析太多，說明SQL重用率不高。
Sorts：每秒/每事務的排序次數
Logons：每秒/每事務登錄的次數
Executes：每秒/每事務SQL執行次數
Transactions：每秒事務數
Blocks changed per Read：表示邏輯讀用于修改數據塊的比例
Recursive Call：遞歸調用占所有操作的比率
Rollback per transaction：每事務的回滾率
Rows per Sort：每次排序的行數
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關鍵指標的內存命中率及其它數據庫實例操作的效率。
Buffer Hit Ratio:也稱Cache Hit Ratio，Library Hit ratio也稱Library Cache Hit ratio。同Load Profile一節相同，這一節也沒有所謂“正確”的值，而只能根據應用的特點判斷是否合適。在一個使用直接讀執行大型并行查詢的DSS環境，20%的Buffer Hit Ratio是可以接受的，而這個值對于一個OLTP系統是完全不能接受的。根據Oracle的經驗，對于OLTPT系統，Buffer Hit Ratio理想應該在90%以上。
Buffer Nowait:表示在內存獲得數據的未等待比例。
buffer hit:表示進程從內存中找到數據塊的比率，監視這個值是否發生重大變化比這個值本身更重要。對于一般的OLTP系統，如果此值低于80%，應該給數據庫分配更多的內存。
Redo NoWait:表示在LOG緩沖區獲得BUFFER的未等待比例。如果太低（可參考90%閥值），考慮增加LOG BUFFER。
library hit:表示Oracle從Library Cache中檢索到一個解析過的SQL或PL/SQL語句的比率，當應用程序調用SQL或存儲過程時，Oracle檢查Library Cache確定是否存在解析過的版本，如果存在，Oracle立即執行語句；如果不存在，Oracle解析此語句，并在Library Cache中為它分配共享SQL區。低的library hit ratio會導致過多的解析，增加CPU消耗，降低性能。如果library hit ratio低于90%，可能需要調大shared pool區。
Latch Hit：Latch是一種保護內存結構的鎖，可以認為是SERVER進程獲取訪問內存數據結構的許可。要確保Latch Hit>99%，否則意味著Shared Pool latch爭用，可能由于未共享的SQL，或者Library Cache太小，可使用綁定變更或調大Shared Pool解決。
Parse CPU to Parse Elapsd：解析實際運行時間/(解析實際運行時間+解析中等待資源時間)，越高越好。
Non-Parse CPU:SQL實際運行時間/(SQL實際運行時間+SQL解析時間)，太低表示解析消耗時間過多。
Execute to Parse:是語句執行與分析的比例，如果要SQL重用率高，則這個比例會很高。該值越高表示一次解析后被重復執行的次數越多。
In-memory Sort：在內存中排序的比率，如果過低說明有大量的排序在臨時表空間中進行。考慮調大PGA。
Soft Parse:軟解析的百分比（softs/softs+hards），近似當作sql在共享區的命中率，太低則需要調整應用使用綁定變量。
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 %：對于一個已經運行一段時間的數據庫來說，共享池內存使用率，應該穩定在75%-90%間，如果太小，說明Shared Pool有浪費，而如果高于90，說明共享池中有爭用，內存不足。
SQL with executions>1：執行次數大于1的sql比率，如果此值太小，說明需要在應用中更多使用綁定變量，避免過多SQL解析。
Memory for SQL w/exec>1：執行次數大于1的SQL消耗內存的占比。
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 閱讀(648)
評論(0) 編輯 收藏 所屬分類:
oracle-優化