AWR報表解讀

---awr
----------報表頭信息
報表的第一部門包含了數據庫本身的信息，包括數據庫的名稱，ID，版本號以及主機等信息。
隨後是快照的開始時間和結束時間，以及有多少活動會話的信息。
緩存尺寸部分顯示了緩衝區緩存的值（初始化文件中的db_cache_size）;共享池的尺寸（shared_pool_size）;標準數據塊的尺寸（db_block_size）;日誌緩衝區（log_buffer）

-------------負載簡檔

提供了負載簡檔每一秒和每一個事物的統計信息。這是一個監控您的系統的吞吐量和負載變化的重要部分。
當系統的負載增加時，您將看到每一秒的數字會增大。當您將系統調整爲最大效率時，每個事務的統計信息
中將顯示較低的數字。
負載簡檔可以幫助識別負載正在執行的活動類型。
1.重做數據塊的增加，快更改變得頻繁，以及每次讀操作%block的增加，這些意味這dml活動的增加。
2.當sql語句不是在共享池中運行時，就會出現硬分析。硬分析率超過100次/秒就意味這綁定變量的效率不高，應當使用cursor_sharing初始化參數，或者說明共享池的大小有問題。
3.當sql語句時在共享池中運行時，就會出現軟分析。軟分析率超過300次/秒就意味着應用程序的效率不高，語句被反覆地執行，而不是對每個會話應只分析語句一次，以保證高效率。

-----------------實例的效率

Instance Efficiency信息展示了許多通用的命中率的信息。dba經常檢測這些參數，以便可以通過和歷史數據的比較來預警系統行爲的顯著變化。命中率時一個用來預警最近引入系統的普通潛在問題和特定潛在問題的極佳方法。
1.Buffer Nowait %低於99%：這是一個對特定緩衝區的請求的命中率，在內存中的該緩衝區應當立即可用。如果命中率下降，在buffer wait部分中將發現當前存在（熱）數據塊爭用的現象。
2.Buffer Hit %:低於95%：這是一個對特定緩衝區的請求的命中率，並且緩衝區位於內存中，而無需物理磁盤的I/O操作。儘管原來時作爲測量內存效率的少數幾種方法之一，但它仍然時一個用於展示您所需的物理磁盤I/O效率的好方法，這將有益於進一步調查性能問題的原因。但是，如果您在訪問時經常使用非選擇性索引，
它將使您的命中率很高，這將導致有些dba作出認爲系統系能很好的錯誤判斷。當您有效地調整了您的sql語句，並在全系統範圍內使用了高校的索引，這個問題不會經常遇到，並且命中率將時一個更佳性能的指示器。
（1）命中率穩定在95%，但有一天上升到99%，這時就應該查找糟糕的sql或導致大量邏輯讀操作的索引（檢查負載簡檔和首要緩存gets sql）
（2）命中率穩定在95%,但突然下降到45%，這時就應該查找導致大量物理讀操作的糟糕的sql（檢查首要物理讀操作sql），這些物理讀操作沒有使用索引或索引被刪除。
3.Library Hit %低於95%:較低的庫命中率通常意味着sql語句被過早地推出了緩衝池（可能是因爲緩衝池太小了）。較低的命中率還意味着沒有使用綁定變量或者一些其他的問題造成sql沒有被重用（在這種情況下，較小的共享池時唯一的權宜之計或許可以修復所引發的庫閂鎖問題）。儘管聲稱始終降低共享池來解決庫緩存和共享池閂鎖問題，但哦見過的大多數千兆字節系統都有以十億字節爲單位的共享池，也沒有產生任何問題，因爲他們解決了sql問題。您必須解決這個問題（使用綁定變量或者cursor_sharing）並確定共享池的合適尺寸。
4.在OLTP中的In-memory Sort %低於95%：在一個OLTP系統中，您一定不想做磁盤排序。設置初始化參數pga_aggregate_target(或者sort_area_size)可有效地解決該問題
5.Soft Parse %低於95%，正如負載簡檔中所說的，軟分析低於80%意味着sql沒有被重用。並需要作進一步調查
6.Latch Hit %:低於99%通常是個大問題：找到特定的閂鎖可棒子您解決該問題

------------------共享池的統計信息

顯示了正使用的共享池的百分比以及重複執行多次（根據需要）的sql語句的百分比。將該數據與庫，分析和閂鎖數據相結合，將可幫助您確定共享池的大小。                            Begin    End
Memory Usage %:                    28.37    29.17
% SQL with executions>1:    27.77    30.45
% Memory for SQL w/exec>1:    56.64    67.74
根據上面列表中的數據，在第二次快照時，有29.17%的共享池內存在用。共享池中語句只有30%執行的次數多於一次。說明應用程序內的共享遊標需要進一步提高使用效率。

---------------5個首要等待事件
報表顯示了五個最重要的等待事件，等待事件的全部列表以及後臺的等待時間。標識主要等待事件將幫助您將調整的努力放在系統中最緊追的問題上。
1.db file scattered(分散的，散亂的) read
db file scattered read等待事件意味着等待與全表掃描或快速全索引掃描有關。因爲全表掃描時放入內存中進行的，通常情況下它不可能被放入連續的緩衝區中，所以就散步在緩衝區的緩存總。該指數的數量過大說明缺少索引或者限制使用索引。這種情況也可能是正常的，因爲執行全表掃描可能比索引掃描效率更高。當您看到這些等待時。需要通過檢查來確定全表掃描是否有必需的。嘗試將較小的表放入緩存中，避免反覆讀取他們。將數據定位在磁盤系統上，這些系統有更多磁盤緩存或由OS文件系統緩存緩衝。db_file_multilock_Read_count能夠讓 全表掃描更快（但它也會影響oracle完成更多掃描）。您也可以將表和索引分區，以便只掃描其中一部分。緩慢的文件I/O（緩慢的磁盤也會導致這些等待。）
2.db file sequential(連續讀) read
db file sequential read 等待時間通常時指單一的數據塊讀操作（例如，索引的讀取）該值過大說明表的連接順序很糟糕，或者使用了非選擇性索引。當然，在一個高事務量，做過較好調整的系統中，該數據應該時較大的（通常情況下）。應當將則中等待與statspack報表中其他已知的問題聯繫起來。例如效率不高的sql。通過檢查確保索引掃描時必須的，並確保多表連接的連接順序。db_Cache_size也是一個決定性因素，它將決定這些等待出現的頻率；散列區域的連接引起的問題應當體現在pga內存中，但他們會貪婪地侵佔內存，直至使順序讀操作有大量的等待出現，或者他們也能揭示直接路徑讀/寫操作出現的等待。如果數據分佈在許多不同塊裏，範圍掃描就要讀取許多塊（塊內的密度會導致範圍掃描問題，反轉鍵索引也會產生範圍掃描問題）。以排序的方式加載數據有助於範圍掃描，還可以減少塊讀取的數量。分區也很有幫助，因爲它可以排除一些塊。注意非選擇性索引，他們會導致許多塊讀取。將數據定位在磁盤系統上，這些系統有更多磁盤緩存和/或由OS文件系統緩存緩衝。
3.buffer busy waits IDs及其含義
當一個緩衝區以一種非共享方式被使用，或者正被讀入緩存時，就會出現這種等待。 buffer busy waits 不應該高於1%。檢查緩衝區等待的統計信息部分（或者是v$waitstat）來確認等待的位置。

（1）buffer busy segment header
（2）buffer busy undo header
（3）buffer busy undo block
（4）buffer busy data block
（5）buffer busy index block

4.latch free
閂鎖時底層的隊列機制（更加準確的名稱應當是互斥機制），用於保護系統全局區（sga）的共享內存結構。閂鎖就像內存上的鎖，它可以快速的獲取和釋放。閂鎖用於防止對共享內存結構的並行訪問。如果閂鎖
不可用，就會記錄一次空閒閂鎖丟失。絕大多數的閂鎖問題都與使用綁定變量失敗（庫緩存閂鎖和共享池閂鎖），生成重做問題（重做分配閂鎖），緩存的爭用問題（緩存lru鏈）以及緩存的熱數據塊（緩存鏈）有關。閂鎖與bug有關；如果您換衣時這個原因，就檢查metalink的不過報告。當閂鎖丟失率高於0.5%時，您應當調查一下這個問題。

5.enqueue
入列（enqueue）是保護共享資源的一種鎖機制。這種鎖保護共享資源。例如一條記錄中的數據，以防止兩個人同時更新相同的數據。它包含了一個隊列機制，即先進先出（FIFO）。需要注意的是，oracle的閂鎖機制不是FIFO。入列等待通常是指ST入列 HW入列  TX4入列
ST入列用於字典託管表空間的空間管理和分配。使用本地託管的表空間（LMT），或者設法預留空間，或者至少保證有問題的管理字典表空間有足夠大的擴展空間。

HW入列用於一個高容量的段；手工分配擴展空間可以迴避這種等待。

TX4是最常見的入列等待。TX4入列等待通常是3種問題中的某一種造成的結果。
第一個問題是唯一索引中的複製，您需要執行提交/回滾操作來釋放隊列。
第二種問題是對同一個位圖索引段的多個更新操作，因爲一個單一的位圖索引段可能包含多個rowids，當多個用戶試圖更新同一個段時，您需要提供一個提交或回滾操作以釋放入列
第三種也時最有可能的一種問題就是多個用戶同時更新同一個數據塊。當不同多個用戶要在相同數據塊的不同行上執行dml時，如果沒有空閒的ITL空間，就會出現數據塊級的鎖。您可以很簡單避免這種情況的出現，方法是通過增加initrans來創建更多的ITL空間，以及/或者通過增加表上的PCTFREE值來實現（這樣oracle就能夠創建所需的ITL空間）。您也可以使用更小的塊的尺寸，讓塊中的數據行更少，因此允許數據上更大的併發性。也有其他兩個不太普通的TX4等待：等待準備好的語句和索引（其中另外一個事務正在分裂索引塊）中插入一行。當用戶要改變塊中的相同記錄時，結果就是TX6鎖。最後，您不再獲得TM鎖（當您不將外鍵編入索引時，他們是表鎖）時，確保仍然將他們編入索引一面產生性能問題。


6.log file switch
所有的提交操作均要等待日誌文件切換（歸檔所需要的）或日誌文件切換（不完整的chkpt）。確保歸檔的磁盤未滿，並且速度足夠快。由於I/O的原因，DBWR可能很慢。您可能需要增加更多或更大的重做日誌，弄且如果DBWR存在問題，您可能需要增加數據庫的寫入器。

7.log buffer space
發生改變時，改變的塊被複制到日誌緩衝區。如果日誌緩衝區沒有足夠快地寫入重做日誌，就會導致log buffer space問題（備份）。當您一次提交大量數據時也會產生這個問題（讓它對於這些類型的事物而言太大）這種等待出現在您寫日誌緩衝區的速度快於LGWR寫重做日誌的速度，或者時日誌切換太慢了。但通常不是因爲日誌緩衝區太小（儘管有時這也時原因之一）。爲了解決這個問題，可以增加日誌文件的尺寸，或者使用更快的磁盤來寫數據，但最終手段可以增加日誌緩衝區的尺寸（在大型系統中，經常有好幾萬兆字節的日誌緩衝區）您甚至可以考慮使用高速的固態硬盤。


8.log file sync日誌文件同步
用戶改變記錄時，記錄被複制到日誌緩衝區。當發生提交或回滾時，LGWR將日誌緩衝區的內容寫入重做日誌。提交將改變後的數據從日誌緩衝區寫入重做日誌的操作，以及確認寫操作成功完成，這個過程稱爲日誌文件同步（log file sync）。爲了減少日誌文件的同步等待，應嘗試一次提交更多的記錄（如果可能的話一次提交50條記錄，而不是一次一條）。如果一次提交50個記錄，就需要產生50個日誌文件同步。將重做日誌放到更快的磁盤上，或者將重做日誌放在不同的物理磁盤上，以減少LGWR歸檔時的影響。不要使用raid5，因爲應用程序的寫操作很多時，它的速度太慢；可以考慮使用直接I/O的文件系統或裸設備，他們在寫信息時的速度很快。

9.global cache CR request
當使用多個實例（RAC）時，當一個實例等待另一個實例的緩存的數據塊時（通過互連發送）就會發生global cache CR request。這種等待說明，當前實例在局部緩存中沒有找到代碼塊的一致讀操作（CR）版本。如果數據塊不在遠程緩存中，那麼這種等待之後就是db file sequential read等待。

10.log file prarllel write
將重做日誌放在較快的磁盤上，不要使用raid5.將重做日誌與可能讓他們變慢的其他數據分離，確保在熱備份模式中沒有保留表空間。

11.db file parallel write
固定/或加速操作系統I/O或文件系統I/O數據庫寫入數據庫文件。

12.direct path read
oracle通常使用direct path reads直接將數據塊讀入PGA。它可用於排序，並行查詢和提前讀操作。這裏的時間並不總是反映實際等待時間。這通常時文件I/O的問題（使用OS哦能夠將查看一下是否有磁盤時I/Obound）。檢查磁盤上而不是內存中的排序。使用異步I/O可以減少消耗時間，儘管它不會減少等待時間。

13.direct path write
直接路徑寫操作通常用於直接加載操作，並行dml和寫入未緩存的LOB（大對象）。這裏的時間並不總是反映時間等待時間。這通常時文件I/O的問題。檢查磁盤上的排序。使用異步I/O可在減少消耗時間，儘管它不會減少等待時間。

14.Async disk I/O
oracle等待異步寫操作完成，或等待寫入的異步從屬。問題可能是與DBWR（數據庫寫入器）LGWR（日誌寫入器）ARCH（歸檔器）或CKPT（檢查點進程）有關的I/O問題，但通常是某個文件I/O問題。

15.idle event
閒置事件通常列在每一部分的底部，包括了一些像sql*net與客戶端的交互信息，以及其他的與後臺有關的計時信息。


------------------首要的sql語句

    SQL ordered by Elapsed Time      按Elapsed Time排序的SQL
    SQL ordered by CPU Time           按CPU Time排序的SQL
    SQL ordered by User I/O Wait Time  
    SQL ordered by Gets                    
    SQL ordered by Reads                        
    SQL ordered by Physical Reads (UnOptimized)
    SQL ordered by Executions                    
    SQL ordered by Parse Calls              
    SQL ordered by Sharable Memory      
    SQL ordered by Version Count       按Version Count排序的SQL
    Complete List of SQL Text             SQL TEXT的完整列表


------------------實例活動統計信息
比較在磁盤上執行的排序數量和在內存中執行的排序數量；增加pga_aggreagte_target(或者以前版本中的sort_area_size)的值來減少磁盤上的排序。
如果磁盤的讀操作數量很高，則表明您可能執行了全表掃描。如果目前存在對大量的對較大表的全表掃描，就應當評估最常用的查詢，並通過使用索引來減少這種低效率的事情發生。大量的一致性讀操作意味這使用了
過多的索引或使用了非選擇性索引。如果觀察到的髒讀緩衝區數量高於所請求的空閒緩衝區數量（超過5%），那麼說明db_cache_size可能太小，或者您沒有建立足夠多的檢查點。如果葉節點的分裂數量很高，可以考慮重建已增長或已碎片化的索引。

consistent gets 沒有使用select for update子句的查詢在緩存中訪問的數據塊數量。這個統計信息的值加上db block gets統計信息的值就是邏輯讀操作（內存中緩存的所有讀操作）。他們通常是數據塊的當前（current）版本，也可以是一致性讀操作（consistent read，CR）版本。
db block gets insert,update,delete 或者select for update 語句中緩存中訪問的數據塊數量。他們時數據塊的當前版本。發生改變時，他們反映在‘db block changes’值中。
physical reads  沒有從緩存讀取的數據塊數量。可以從磁盤，OS緩存或磁盤緩存讀取，以滿足select,select for update,insert,update,delete
dirty buffer inspected 從LRU列表中清除掉的髒讀（經過修改的）數據緩衝區的數量。這裏的值說明DBWR的數量不夠。您可以通過增加更多DBWR來獲得增益。
enqueue timeouts  請求入列的次數（鎖定）以及所請求的特定隊列不可用的次數。如果這個統計信息大於0，就需要調整鎖定的問題。
free buffer inspected 由於時髒讀數據，被固定或者正忙等原因而跳過的緩衝區數量。如果您從統計信息中減去這些值（觀察到的髒讀數據量和被固定的緩衝區數量），就將剩下由於閂鎖的爭用而無法重用的緩衝區數量。如果數量很大的話，就很好地說明緩衝區緩存太小了。
parse count 一條sql語句被解析的次數（總次數）
recursive calls 數據庫中遞歸調用的數量。有些原因將導致這種類型的調用，例如，字典緩存中的數據丟失，動態存儲的擴展以及pl/sql語句正在執行等原因。通常情況下，如果每個進程中的遞歸調用數量大於
4，您應當檢查數據字典緩存的命中率，以及是否有表或索引的範圍過大。除非大量使用了pl/sql，否則在用戶調用中，遞歸調用所佔的比例應當低於10%或更低。
redo size寫入重做日誌中，以字節爲單位的重做信息的數量。該信息將有助於確定重做日誌的大小。
sorts(disk)無法在內存中執行的排序的數量，必須在臨時表空間中創建一個臨時段以供排序使用。該統計信息除以內存中排序的數量不應高於5%。如果高於這個值，您應當增加init.ora文件中sort_area_size或者pga_aggregate_target的值。
sorts(memory)在內存中執行排序的數量
sort(rows)參加排序的數據行的數量
table fetch by rowid 通過使用rowid訪問的數據行的數量。rowid來自一個索引，或者一個where rowid=語句。該數值很高通常意味着就獲取數據的操作而言，應用程序調整得不錯。
table fetch continued row獲取的數據行的數量，可以是鏈化數據行，也可以時遷移的數據行。
如果時鏈化數據行，則應當儘可能快的解決掉這個問題。如果有大量的數據行相鏈接，會引起性能的嚴重劣化。
table scans (long tables)大於_small_table_threshold,並且沒有使用cache子句的表。_small_table_threshold的默認值是緩存的2%。如果不仔細評估它的影響，修改_small_table_threshold參數會非常危險，因爲它將引起數據塊失效得更快並降低您的命中率。早oracle中，這個參數時數據塊的數量，等於這個數量就認爲表太小了。這個閾值用來確定直接讀操作的切換點。
比它小的所有對象都不值得執行直接讀操作，因此會從緩衝區緩存中讀取。如果每個事務表掃描的數量都大於0，您可能要檢查應用程序sql語句，並試着增加索引的使用。
table scans（short tables）short table是比緩衝區緩存的2%更短的表。oracle更喜歡在short table上進行全表掃描。

---------------------表空間和文件I/O的統計數據

在init.ora中可以設置的參數db_file_multiblock_read_count將有助於提高讀取的時間。db_File_multiblock_read_count參數控制在全表掃描時，一次I/O中讀入的數據塊的數量。
這將減少掃描一張表所需的I/O數量，從而提高了全表掃描的性能，但是，設置db_File_multiblock_read_count參數的結果時優化器可能會執行更多的全表掃描，所以您也需要將
optimizer_index_cost_adj設置爲一個數值，例如10，來消除這個問題並驅動索引的使用。

Tablespace    Reads    Av Reads/s    Av Rd(ms)    Av Blks/Rd    Writes    Av Writes/s    Buffer Waits    Av Buf Wt(ms)
SYSTEM     2,104    0    8.76    1.38    153    0    1    10.00
SYSAUX     272    0    19.56    3.92    1,550    0    0    0.00
UNDOTBS1     405    0    0.74    1.00    583    0    3    3.33
TEMP     3    0    0.00    1.00    3    0    0    0.00
USERS     5    0    2.00    1.00    0    0    0    0.00
SALE     2    0    35.00    1.00    2    0    0    0.00

Tablespace  表空間名稱
Reads   從數據文件檢索數據的誤了讀取操作次數
Av Blks/Rd 從數據文件讀取數據塊的讀操作的平均次數
Writes  對數據文件執行寫操作的次數

Tablespace    Filename    Reads    Av Reads/s    Av Rd(ms)    Av Blks/Rd    Writes    Av Writes/s    Buffer Waits    Av Buf Wt(ms)
SALE    /u01/app/oracle/oradata/orcl11g/sale.dbf     2    0    35.00    1.00    2    0    0    0.00
SYSAUX    /u01/app/oracle/oradata/orcl11g/sysaux01.dbf     272    0    19.56    3.92    1,550    0    0    0.00
SYSTEM    /u01/app/oracle/oradata/orcl11g/system01.dbf     2,104    0    8.76    1.38    153    0    1    10.00
TEMP    /u01/app/oracle/oradata/orcl11g/temp01.dbf     3    0    0.00    1.00    3    0    0    
UNDOTBS1    /u01/app/oracle/oradata/orcl11g/undotbs01.dbf     405    0    0.74    1.00    583    0    3    3.33
USERS    /u01/app/oracle/oradata/orcl11g/users01.dbf     5    0    2.00    1.00    0    0    0    0.00
如果一個數據文件獲得了主要的讀和寫操作，那麼您就可以通過在分離的磁盤上創建多個文件，或者將數據文件強制分佈在多個磁盤上來提高性能。同樣，不要使用raid5，否則您的寫操作將顯得非常緩慢。
如果一個物理磁盤上的物理讀操作的數量很高，合理平衡數據將有可能提高性能。


--------------------------其他內存統計數據
Instance Recovery Stats  實例恢復統計數據
Buffer Pool Advisory   緩衝池顧問
PGA Aggr Summary   pga aggr概述
PGA Aggr Target Stats   pga aggr目標統計數據
PGA Aggr Target Histogram  pga aggr目標柱狀圖
PGA Memory Advisory   pga內存顧問
Shared Pool Advisory  共享池顧問
SGA Target Advisory   sga目標顧問
Streams Pool Advisory  streams池顧問
Java Pool Advisory   java池顧問
報表根據共享池（默認共享池，keep共享池以及recycle共享池）來列出緩存的統計數據，實例恢復統計數據
（重做數據塊數量），以及pga內存統計數據。

-----------------------撤銷統計數據

顯示撤銷表空間以及事務和整個表空間撤銷塊的數量。接着它提供了有關使用的撤銷塊數量信息，以及給定段（undostat行）發生的事物數量。

--------------------------閂鎖統計數據

latch free
libarary cache and shared pool
redo copy
redo allocation
row cache object
cache buffers chains(CBC)
for a given block
hot blocks
cache buffers LRU chain

--------------------------在塊級別的調整和查看

---------------------------段統計數據
    Segments by Logical Reads                 按邏輯讀分類的段
    Segments by Physical Reads                 按物理讀分類的段
    Segments by Physical Read Requests   
    Segments by UnOptimized Reads
    Segments by Optimized Reads
    Segments by Direct Physical Reads
    Segments by Physical Writes
    Segments by Physical Write Requests
    Segments by Direct Physical Writes
    Segments by Table Scans
    Segments by DB Blocks Changes
    Segments by Row Lock Waits         按Row Lock Waits分類的段
    Segments by ITL Waits              按ITL Waits分類的段
    Segments by Buffer Busy Waits      按Buffer Busy Waits分類的段
這對於查找哪個特定index或data段導致某種類型的瓶頸特別有用。但查找特定ITL（感興趣的事物列表）等待也很難，現在在段統計數據部分，您可以看到ITL等待的準確數量
按所有者，表空間名詞，對象名詞和子對象名詞（例如索引分區子對象名稱排列）
v$segment_statistics
 
---------------------數據字典和庫緩存的統計數據

數據字典的信息屬於數據庫中的所有對象。當sql語句分析和執行時，均要訪問這些信息。該區域的活動負載應當非常重，維持一個很好的命中率時非常重要的，可以阻止遞歸調用返回數據庫中進行權限驗證。也可以通過查詢v$rowcache視圖來評估數據字典緩存的效率。
Namespace    Get Requests    Pct Miss    Pin Requests    Pct Miss    Reloads    Invali- dations
BODY    3,187    0.35    4,313    0.30    0    0
CLUSTER    841    0.00    159    0.00    0    0
DBLINK    6    0.00    0         0    0
EDITION    250    0.00    453    0.00    0    0
INDEX    11    0.00    7    0.00    0    0
OBJECT ID    4    100.00    0         0    0
QUEUE    189    0.00    647    0.00    0    0
RULESET    2    0.00    2    0.00    0    0
SCHEMA    845    0.36    0         0    0
SQL AREA    5,181    21.98    57,366    2.36    1    5
SUBSCRIPTION    21    0.00    21    0.00    0    0
TABLE/PROCEDURE    6,922    3.89    11,917    6.41    4    0
TRIGGER    22    0.00    184    0.00    0    0
報表中該節處理庫緩存的性能情況。這些統計數據通常從v$librarycache視圖中得到。庫緩存包含了共享sql和pl/sql區域。這些區域的代表是booy,sqlarea,table/procedure以及trigger值。他們包含了緩存在內存中的所有sql和pl/sql語句。其他的區域由oracle使用。如果報表中
pct miss值過高，您應當提高應用程序中游標的共享程度或者增加共享池的尺寸。
Namespace庫命名空間名稱
Get Requests在該命名空間中系統請求對象句柄的次數
Pct Miss（get miss ratio）gethits的數量除以get的數量就是get命中率。gethits時發起對一個對象和已經在緩存中的對象的請求數。該命中率應當儘可能的接近99%。pct miss應當低於1%
Pin Requests緩存中的一個項執行的次數。您應當追求儘可能高的數字
Pct Miss（pin miss ratio）pinhits數量除以固定（pin）的數量就是固定命中率。pinhits是系統中已經存在於緩存中的對象被固定的次數。該點擊率應當儘可能的接近100%。丟失率應當低於1%
Reloads在一個執行步驟中庫緩存丟失的次數。重載的數量除以固定的數量應當接近於0.如果這個比率高於1%，您就應當增加共享池的尺寸
Invali- dations該命名空間中的對象因爲依賴的對象被修改過而被標記爲無效的次數

-------sga內存統計數據
sga用的的摘要信息（從v$sga中獲得），以及在快照間隔期間內存變化的列表，報表在開始和結束的地方列出了在用的數據庫初始化參數
從總體上看，報表產生了大量的數據，允許您來涉及數據庫以及使用狀況的簡檔。根據初始化過程，文件I/O以及SGA數據，您可以對數據庫配置中的主要組件有更好的理解。