DBid是唯一的數(shù)據(jù)庫的標示,在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.

連接到目標數(shù)據(jù)庫: TEST1212 (DBID=3399531915)

RMAN>

DB Time不包括Oracle后臺進程消耗的時間。如果DB Time遠遠小于Elapsed時間，說明數(shù)據(jù)庫比較空閑。計算公式:

在59分鐘里（其間收集了2次快照數(shù)據(jù)），數(shù)據(jù)庫耗時0.83分鐘，系統(tǒng)有1個CPU，平均CPU耗時0.83分鐘，CPU利用率只有大約1.38%（0.83/59.81）。說明系統(tǒng)壓力非常小(該系統(tǒng)啥都沒做J)。

對于批量系統(tǒng)，數(shù)據(jù)庫的工作負載總是集中在一段時間內(nèi)。如果快照周期不在這一段時間內(nèi)，或者快照周期跨度太長而包含了大量的數(shù)據(jù)庫空閑時間，所得出的分析結(jié)果是沒有意義的。這也說明選擇分析時間段很關(guān)鍵，要選擇能夠代表性能問題的時間段。

Cache Sizes

顯示SGA中每個區(qū)域的大小,可用來與初始參數(shù)值比較。

shared pool主要包括library cache和dictionary cache。library cache用來存儲最近解析（或編譯）后SQL、PL/SQL。library cache用來存儲最近引用的數(shù)據(jù)字典。發(fā)生在library cache或dictionary cache的cache miss代價要比發(fā)生在buffer cache的代價高得多。因此shared pool的設(shè)置要確保最近使用的數(shù)據(jù)都能被cache,也就是盡可能的保持被命中(即傳說中的命中率)。

Load Profile

顯示數(shù)據(jù)庫負載概況，將之與基線數(shù)據(jù)比較才具有更多的意義，如果每秒或每事務(wù)的負載變化不大，說明應(yīng)用運行比較穩(wěn)定。單個的報告數(shù)據(jù)只說明應(yīng)用的負載情況，絕大多數(shù)據(jù)并沒有一個所謂“正確”的值，然而Logons大于每秒1~2個、Hard parses大于每秒100、全部parses超過每秒300表明可能有爭用問題。

Redo size：每秒/每事務(wù)產(chǎn)生的redo大小（單位字節(jié)），可標志數(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%)

這一段包含了Oracle關(guān)鍵指標的內(nèi)存命中率及其它數(shù)據(jù)庫實例操作的效率。

Buffer Hit Ratio:也稱Cache Hit Ratio，Library Hit ratio也稱Library Cache Hit ratio。同Load Profile一節(jié)相同，這一節(jié)也沒有所謂“正確”的值，而只能根據(jù)應(yīng)用的特點判斷是否合適。在一個使用直接讀執(zhí)行大型并行查詢的DSS環(huán)境，20%的Buffer Hit Ratio是可以接受的，而這個值對于一個OLTP系統(tǒng)是完全不能接受的。根據(jù)Oracle的經(jīng)驗，對于OLTPT系統(tǒng)，Buffer Hit Ratio理想應(yīng)該在90%以上。

Buffer Nowait:表示在內(nèi)存獲得數(shù)據(jù)的未等待比例。

buffer hit:表示進程從內(nèi)存中找到數(shù)據(jù)塊的比率，監(jiān)視這個值是否發(fā)生重大變化比這個值本身更重要。對于一般的OLTP系統(tǒng)，如果此值低于80%，應(yīng)該給數(shù)據(jù)庫分配更多的內(nèi)存。

Redo NoWait:表示在LOG緩沖區(qū)獲得BUFFER的未等待比例。如果太低（可參考90%閥值），考慮增加LOG BUFFER。

library hit:表示Oracle從Library Cache中檢索到一個解析過的SQL或PL/SQL語句的比率，當應(yīng)用程序調(diào)用SQL或存儲過程時，Oracle檢查Library Cache確定是否存在解析過的版本，如果存在，Oracle立即執(zhí)行語句；如果不存在，Oracle解析此語句，并在Library Cache中為它分配共享SQL區(qū)。低的library hit ratio會導(dǎo)致過多的解析，增加CPU消耗，降低性能。如果library hit ratio低于90%，可能需要調(diào)大shared pool區(qū)。

Latch Hit：Latch是一種保護內(nèi)存結(jié)構(gòu)的鎖，可以認為是SERVER進程獲取訪問內(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：解析實際運行時間/(解析實際運行時間+解析中等待資源時間)，越高越好。

Non-Parse CPU:SQL實際運行時間/(SQL實際運行時間+SQL解析時間)，太低表示解析消耗時間過多。

Execute to Parse:是語句執(zhí)行與分析的比例，如果要SQL重用率高，則這個比例會很高。該值越高表示一次解析后被重復(fù)執(zhí)行的次數(shù)越多。

In-memory Sort：在內(nèi)存中排序的比率，如果過低說明有大量的排序在臨時表空間中進行。考慮調(diào)大PGA。

Soft Parse:軟解析的百分比（softs/softs+hards），近似當作sql在共享區(qū)的命中率，太低則需要調(diào)整應(yīng)用使用綁定變量。

Shared Pool Statistics

Memory Usage %：對于一個已經(jīng)運行一段時間的數(shù)據(jù)庫來說，共享池內(nèi)存使用率，應(yīng)該穩(wěn)定在75%-90%間，如果太小，說明Shared Pool有浪費，而如果高于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