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

顯示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

顯示數據庫負載概況，將之與基線數據比較才具有更多的意義，如果每秒或每事務的負載變化不大，說明應用運行比較穩定。單個的報告數據只說明應用的負載情況，絕大多數據并沒有一個所謂“正確”的值，然而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%)

這一段包含了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

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