如何生成awr報告：
* 1：登陸對應的數據庫服務(wù)器
2：找到oracle磁盤(pán)空間（d:oracle\product\10.2.0\db_1\RDBMS\Admin)
3：執行cmd-cd d:回車(chē)
4: cd d:oracle\product\10.2.0\db_1\RDBMS\Admin 回車(chē)
5：sqlplus 用戶(hù)名/密碼@服務(wù)連接名(例：sqlplus carmot_esz_1/carmot@igrp)
6：執行@awrrpt.sql 回車(chē)
第一步輸入類(lèi)型： html
第二步輸入天數： 天數自定義（如1，代表當天，如果2，代表今天和昨天。。。）
第三步輸入開(kāi)始值與結束值：（你可以看到上面列出的數據，snap值）
這個(gè)值輸入開(kāi)始，與結束
第四步輸入導出表的名稱(chēng)：名稱(chēng)自定義 回車(chē)
第五步，由程序自動(dòng)導完。
第六：到d:oracle\product\10.2.0\db_1\RDBMS\Admin 目錄下。找到剛才生成的文件。 XXXX.LST文件
具體分析過(guò)程：
* 在分析awr報告之前，首先要確定我們的系統是屬于oltp，還是olap（數據庫在安裝的時(shí)候，選擇的時(shí)候，會(huì )有一個(gè)選項，是選擇oltp，還是olap）
對于不同的系統，性能指標的側重點(diǎn)是不一樣的，比如，library hit和buffer hit，在olap系統中幾乎可以忽略這倆個(gè)性能指標，而在oltp系統中，這倆個(gè)指標就非常關(guān)鍵了
* 首先要看倆個(gè)時(shí)間
Elapsed: 240.00 (mins) 表明采樣時(shí)間是240分鐘，任何數據都要通過(guò)這個(gè)時(shí)間來(lái)衡量，離開(kāi)了這個(gè)采樣時(shí)間，任何數據都毫無(wú)疑義
DB Time: 92,537.95 (mins) 表明用戶(hù)操作花費的時(shí)候，包括cpu時(shí)間喝等待時(shí)間，也許有人會(huì )覺(jué)得奇怪，為什么在采樣的240分鐘過(guò)程中，用戶(hù)操作時(shí)間竟然有92537分鐘呢，遠遠超過(guò)了
采樣時(shí)間，原因是awr報告是一個(gè)數據的集合，比如在一分鐘之內，一個(gè)用戶(hù)等待了30秒，那么10個(gè)用戶(hù)就等待了300秒，對于cpu的話(huà)，一個(gè)cpu處理了30秒，16個(gè)cpu就是4800秒，這些時(shí)間都是以累積的方式記錄在awr報告中的。
再看sessions，可以看出連接數非常多
* 為了對數據庫有個(gè)整體的認識，先看下面的性能指標
1. Buffer Nowait 說(shuō)明 在從內存取數據的時(shí)候，沒(méi)有經(jīng)歷等待的比例，期望值是100%
2. Buffer Hit 說(shuō)明從內存取數據的時(shí)候，buffer的命中率的比例，期望值是100%，但100%并不代表性能就好，因為這只是一個(gè)比例而已，舉個(gè)例子，執行一條 sql語(yǔ)句，# 執行計劃是需要取10000個(gè)數據塊，結果內存中還真有這10000個(gè)數據塊，那么比例是100%，表面上看是性能最高的，還有一個(gè)執行計劃是需要500 個(gè)數據塊，內存中有250個(gè)，另外250個(gè)需要在物理磁盤(pán)中取，
這種情況下，buffer hit是50%，結果呢，第二個(gè)執行計劃性能才是最高的，所以說(shuō)100%并不代表性能最好
3. Library Hit 說(shuō)明sql在Shared Pool的命中率，期望值是100%
4. Execute to Parse 說(shuō)明解析sql和執行sql之間的比例，越高越好，說(shuō)明一次解析，到處執行，如果parse多，execute少的話(huà)，還會(huì )出現負數，因為計算公式是100*（1-parse/execute）
5. Parse CPU to Parse Elapsd 說(shuō)明在解析sql語(yǔ)句過(guò)程中，cpu占整個(gè)的解析時(shí)間比例，，期望值是100%，說(shuō)明沒(méi)有產(chǎn)生等待，需要說(shuō)明的是，即使有硬解析，只要cpu沒(méi)有出現性能問(wèn)題，也是可以容忍的，比較硬解析也有它的好處的
6. Redo NoWait 說(shuō)明在產(chǎn)生日志的時(shí)候，沒(méi)有產(chǎn)生等待，期望值是100%
7. Soft Parse 說(shuō)明軟解析的比例，期望值是100%，有一點(diǎn)要說(shuō)明的是，不要單方面的追求軟解析的高比例，而去綁定變量，要看性能的瓶頸在哪里
8. Latch Hit 說(shuō)明latch的命中率，期望值是100%，latch類(lèi)似鎖，是一種內存鎖，但只會(huì )產(chǎn)生等待，不會(huì )產(chǎn)生阻塞，和lock還是有區別的，latch是在并發(fā)的情況下產(chǎn)生的
9. Non-Parse CPU 說(shuō)明非解析cpu的比例，越高越好，用100減去這個(gè)比例，可以看出解析sql所花費的cpu，100-99.30=0.7，說(shuō)明花費在解析sql上的cpu很少
* 結合Time Model Statistics
可以看出，在整個(gè)sql執行時(shí)間（sql execute elapsed time）時(shí)間為5552019秒中，解析時(shí)間（parse time elapsed）用了36秒，硬解析時(shí)間（hard parse elapsed time）用了34秒雖然硬解析時(shí)間占了整個(gè)解析時(shí)間的絕大部分，但解析時(shí)間是花的很少的，所以可以判斷出，sql的解析沒(méi)有成為性能的瓶 頸，進(jìn)一步推測，sql在獲取數據的過(guò)程中遇到了瓶 頸
* 繼續看Top 5 Timed Events，從這里可以看出等待時(shí)間在前五位的是什么事件，基本上就可以判斷出性能瓶頸在什么地方
1. buffer busy waits 說(shuō)明在獲取數據的過(guò)程中，頻繁的產(chǎn)生等待事件，很有可能產(chǎn)生了熱點(diǎn)塊，也就是說(shuō)，很多會(huì )話(huà)都去讀取同樣的數據塊，這一事件等待了5627394次，總共等待了5322924秒，平均等待時(shí)間為946毫秒，而且頻率也是最高的，有95.9%，等待類(lèi)別是并發(fā)
這里有一個(gè)概念：oracle操作的最小單位是塊，當一個(gè)會(huì )話(huà)要修改這個(gè)塊中的一條記錄，會(huì )讀取整個(gè)塊，如果另一個(gè)會(huì )話(huà)要修改的數據也正好在這個(gè)塊中，雖然這倆個(gè)
2. 會(huì )話(huà)修改的記錄不一樣，也會(huì )產(chǎn)生等待direct path write temp和direct path read temp 說(shuō)明用到了臨時(shí)表空間，那我們再看一下Tablespace IO Stats 
各項指標都是非常高的，再根據上面的In-memory Sort是100%，沒(méi)有產(chǎn)生磁盤(pán)排序，也就在排序的時(shí)候沒(méi)有用到臨時(shí)表空間，進(jìn)一步推測，多個(gè)session，每個(gè)session執行的sql語(yǔ)句中多表關(guān)聯(lián)，產(chǎn)生了很多中間數據，pga內存中放不下，
用到了臨時(shí)表空間，也有可能是用到了lob字段，在用lob字段的時(shí)候，也會(huì )用到臨時(shí)表
* 繼續看SQL Statistics
根據buffer busy waits等待次數，時(shí)間，頻率都是最高的，我們重點(diǎn)看邏輯讀，物理讀，和執行時(shí)間最長(cháng)的sql，把排在前幾位的拿出來(lái)優(yōu)化
優(yōu)化的原則為降低物理讀，邏輯讀，sql語(yǔ)句中的子操作執行次數盡量少，在看oracle估計出來(lái)的執行計劃是看不出子操作的執行次數的，要看運行時(shí)的執行計劃
* 有興趣的話(huà)還可以看一下Segment Statistics
列出了用到的索引和表的使用情況，從這里也能看出索引和表的使用頻率
* 也可以看一下Load Profile
里面列出了每秒，每個(gè)事務(wù)所產(chǎn)生的日志，邏輯讀和物理讀等指標
- 大小: 8 KB
- 大小: 11 KB
- 大小: 10.9 KB
- 大小: 13.2 KB
