㈠ 如何使用AWR報告來診斷資料庫性能問題
一般來說，當檢測到性能問題時，我們會收集覆蓋了發生問題的時間段的AWR報告-但是最好只收集覆蓋1個小時時間段的AWR報告-如果時間過長，那麼AWR報告就不能很好的反映出問題所在。還應該收集一份沒有性能問題的時間段的AWR報告，作為一個參照物來對比有問題的時間段的AWR報告。這兩個AWR報告的時間段應該是一致的，比如都是半個小時的，或者都是一個小時的。
Interpretation
在處理性能問題時，我們最關注的是資料庫正在等待什麼。
當進程因為某些原因不能進行操作時，它需要等待。花費時間最多的等待事件是我們最需要關注的，因為降低它，我們能夠獲得最大的好處。
AWR報告中的"Top 5 Timed Events"部分就提供了這樣的信息，可以讓我們只關注主要的問題。
Top 5 Timed Events
正如前面提到的，"Top 5 Timed Events"是AWR報告中最重要的部分。它指出了資料庫的sessions花費時間最多的等待事件，如下：
Top 5 Timed Events Avg %Total
~~~~~~~~~~~~~~~~~~ wait Call
Event Waits Time (s) (ms) Time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
db file scattered read 10,152,564 81,327 8 29.6 User I/O
db file sequential read 10,327,231 75,878 7 27.6 User I/O
CPU time 56,207 20.5
read by other session 4,397,330 33,455 8 12.2 User I/O
PX Deq Credit: send blkd 31,398 26,576 846 9.7 Other
-------------------------------------------------------------
Top 5 Events部分包含了一些跟Events（事件）相關的信息。它記錄了這期間遇到的等待的總次數，等待所花費的總時間，每次等待的平均時間；這一部分是按照每個Event占總體call time的百分比來進行排序的。
根 據Top 5 Events部分的信息的不同，接下來我們需要檢查AWR報告的其他部分，來驗證發現的問題或者做定量分析。等待事件需要根據報告期的持續時間和當時數據 庫中的並發用戶數進行評估。如：10分鍾內1000萬次的等待事件比10個小時內的1000萬等待更有問題；10個用戶引起的1000萬次的等待事件比 10,000個用戶引起的相同的等待要更有問題。
就像上面的例子，將近60%的時間是在等待IO相關的事件。
其他20%的時間是花在使用或等待CPU time上。過高的CPU使用經常是性能不佳的sql引起的（或者這些SQL有可能用更少的資源完成同樣的操作）；對於這樣的SQL，過多的IO操作也是一個症狀。關於CPU使用方面，我們會在之後討論。
在以上基礎上，我們將調查是否這個等待事件是有問題的。若有問題，解決它；若是正常的，檢查下個等待事件。
過多的IO相關的等待一般會有兩個主要的原因：
Top 5 Events部分的顯示的信息會幫助我們檢查：
需要注意，接下來的分析步驟取決於我們在TOP 5部分的發現。在上面的例子里，3個top wait event表明問題可能與SQL語句執行計劃不好有關，所以接下來我們要去分析"SQL Statistics"部分。
同樣的，因為我們並沒有看到latch相關的等待，latch在我們這個例子里並沒有引發嚴重的性能問題；那麼我們接下來就完全不需要分析latch相關的信息。
一 般來講，如果資料庫性能很慢，TOP 5等待事件里"CPU"， "db file sequential read" 和"db file scattered read" 比較明顯（不管它們之間的順序如何），我們總是需要檢查Top SQL (by logical and physical reads)部分；調用SQL Tuning Advisor或者手工調優這些SQL來確保它們是有效率的運行。
是否資料庫做了大量的讀操作：
上面的圖顯示了在這段時間里兩類讀操作都分別大於1000萬，這些操作是否過多取決於報告的時間是1小時或1分鍾。我們可以檢查AWR報告的elapsed time如果這些讀操作確實是太多了，接下來我們需要檢查AWR報告中 SQL Statistics 部分的信息，因為讀操作都是由SQL語句發起的。
是否是每次的IO讀操作都很慢：
上面的圖顯示了在這段時間里兩類讀操作平均的等待時間是小於8ms的
至於8ms是快還是慢取決於底層的硬體設備；一般來講小於20ms的都可以認為是可以接受的。
我們還可以在AWR報告"Tablespace IO Stats"部分得到更詳細的信息
Tablespace IO Stats DB/Inst: VMWREP/VMWREP Snaps: 1-15
-> ordered by IOs (Reads + Writes) desc
Tablespace
------------------------------
Av Av Av Av Buffer Av Buf
Reads Reads/s Rd(ms) Blks/Rd Writes Writes/s Waits Wt(ms)
-------------- ------- ------ ------- ------------ -------- ---------- ------
TS_TX_DATA
14,246,367 283 7.6 4.6 145,263,880 2,883 3,844,161 8.3
USER
204,834 4 10.7 1.0 17,849,021 354 15,249 9.8
UNDOTS1
19,725 0 3.0 1.0 10,064,086 200 1,964 4.9
AE_TS
4,287,567 85 5.4 6.7 932 0 465,793 3.7
TEMP
2,022,883 40 0.0 5.8 878,049 17 0 0.0
UNDOTS3
1,310,493 26 4.6 1.0 941,675 19 43 0.0
TS_TX_IDX
1,884,478 37 7.3 1.0 23,695 0 73,703 8.3
>SYSAUX
346,094 7 5.6 3.9 112,744 2 0 0.0
SYSTEM
101,771 2 7.9 3.5 25,098 0 653 2.7
如上圖，我們關心Av Rd(ms)的指標。如果它高於20ms並且同時有很多讀操作的，我們可能要開始從OS的角度調查是否有潛在的IO問題。
註：對於一些比較空閑的tablespace/files,我們可能會得到一個比較大的Av Rd(ms)值；對於這樣的情況，我們應該忽略這樣的tablespace/files;因為這個很大的值可能是由於硬碟自旋(spin)引起的，沒有太大的參考意義。比如對
於一個有1000萬次讀操作而且很慢的系統，引起問題的基本不可能是一個只有10次read的tablespace/file.
雖 然高"db file scattered read"和"db file sequential read"等待可以是I / O相關的問題，但是很多時候這些等待也可能是正常的；實際上，對一個已經性能很好的資料庫系統，這些等待事件往往在top 5等待事件里，因為這意味著您的資料庫沒有那些真正的「問題」。
訣竅是能夠評估引起這些等待的語句是否使用了最優的訪問路徑。如果"db file scattered read"比較高，那麼相關的SQL語句可能使用了全表掃描而沒有使用索引（也許是沒有創建索引，也許是沒有合適的索引）；相應的，如果"db file sequential read"過多，則表明也許是這些SQL語句使用了selectivity不高的索引從而導致訪問了過多不必要的索引塊或者使用了錯誤的索引。這些等待可 能說明SQL語句的執行計劃不是最優的。
接下來就需要通過AWR來檢查這些top SQL是否可以進一步的調優，我們可以查看AWR報告中 SQL Statistics 的部分.
上面的例子顯示了20%的時間花在了等待或者使用CPU上，我們也需要檢查 SQL statistics 部分來進一步的分析。
資料庫做了太多的讀操作
每次的IO讀操作都很慢
事件"db file scattered read"一般表明正在做由全表掃描或者index fast full scan引起的多塊讀。
事件"db file sequential read"一般是由不能做多塊讀的操作引起的單塊讀（如讀索引）
SQL Statistics
AWR包含了一些不同的SQL統計值：
根據Top 5 部分的Top Wait Event不同，我們需要檢查不同的SQL statistic。
在我們這個例子里，Top Wait Event是"db file scattered read"，"db file sequential read"和CPU；我們最需要關心的是SQL ordered by CPU Time, Gets and Reads。
我們會從"SQL ordered by gets"入手，因為引起高buffer gets的SQL語句一般是需要調優的對象。
SQL ordered by Gets
-> Resources reported for PL/SQL code includes the resources used by all SQL
statements called by the code.
-> Total Buffer Gets: 4,745,943,815
-> Captured SQL account for 122.2% of Total
Gets CPU Elapsed
Buffer Gets Executions per Exec %Total Time (s) Time (s) SQL Id
-------------- ------------ ------------ ------ -------- --------- -------------
1,228,753,877 168 7,314,011.2 25.9 8022.46 8404.73 5t1y1nvmwp2
SELECT ADDRESSID",CURRENT$."ADDRESSTYPEID",CURRENT$URRENT$."ADDRESS3",
CURRENT$."CITY",CURRENT$."ZIP",CURRENT$."STATE",CURRENT$."PHONECOUNTRYCODE",
CURRENT$."PHONENUMBER",CURRENT$."PHONEEXTENSION",CURRENT$."FAXCOU
1,039,875,759 62,959,363 16.5 21.9 5320.27 5618.96 grr4mg7ms81
Mole: DBMS_SCHEDULER
INSERT INTO "ADDRESS_RDONLY" ("ADDRESSID","ADDRESSTYPEID","CUSTOMERID","
ADDRESS1","ADDRESS2","ADDRESS3","CITY","ZIP","STATE","PHONECOUNTRYCODE","PHONENU
854,035,223 168 5,083,543.0 18.0 5713.50 7458.95 4at7cbx8hnz
SELECT "CUSTOMERID",CURRENT$."ISACTIVE",CURRENT$."FIRSTNAME",CURRENT$."LASTNAME",CU<
RRENT$."ORGANIZATION",CURRENT$."DATEREGISTERED",CURRENT$."CUSTOMERSTATUSID",CURR
ENT$."LASTMODIFIEDDATE",CURRENT$."SOURCE",CURRENT$."EMPLOYEEDEPT",CURRENT$.
對這些Top SQL,可以手工調優，也可以調用SQL Tuning Advisor。
分析：
Other SQL Statistic Sections
就像之前提到的那樣，AWR報告中有很多不同的部分用來分析各種不同的問題。如果特定的問題並沒有出現，那麼分析AWR報告的這些部分並不能有很大的幫助。
下面提到了一些可能的問題：
Waits for 'Cursor: mutex/pin' 如 果發現了一些像"Cursor: pin S wait on X" 或"Cursor: mutex X" 類的mutex等待，那麼可能是由於parsing引起的問題。檢查"SQL ordered by Parse Calls" 和"SQL ordered by Version Count"部分的Top SQL，這些SQL可能引起這類的問題。
單次執行buffer gets過多
SQL_ID為'5t1y1nvmwp2'和'4at7cbx8hnz'的SQL語句總共被執行了168次，但是每次執行引起的buffer gets超過500萬。這兩個SQL應該是主要的需要調優的候選者。
執行次數過多
SQL_ID 'grr4mg7ms81' 每次執行只是引起16次buffer gets,減少這條SQL每次執行的buffer get可能並不能顯著減少總共的buffer gets。這條語句的問題是它執行的太頻繁了，6500萬次。
改變這條SQL的執行次數可能會更有意義。這個SQL看起來是在一個循環裡面被調用，如果可以讓它一次處理的數據更多也許可以減少它執行的次數。
-> Total Buffer Gets: 4,745,943,815
假設這是一個一個小時的AWR報告，4,745,943,815是一個很大的值；所以需要進一步分析這個SQL是否使用了最優的執行計劃
Indivial Buffer Gets
上面的例子里單個的SQL的buffer get非常多，最少的那個都是8億5千萬。這三個SQL指向了兩個不同的引起過多buffers的原因：
注意：對於某些非常繁忙的系統來講，以上的數字可能都是正常的。這時候我們需要把這些數字跟正常時段的數字作對比，如果沒有什麼太大差別，那麼這些SQL並不是引起問題的元兇（雖然通過調優這些SQL我們仍然可以受益）
Load Profile
根據Top 5等待事件的不同，"Load Profile"可以提供一些有用的背景資料或潛在問題的細節信息。
Load Profile
~~~~~~~~~~~~ Per Second Per Transaction
--------------- ---------------
Redo size: 4,585,414.80 3,165,883.14
Logical reads: 94,185.63 65,028.07
Block changes: 40,028.57 27,636.71
Physical reads: 2,206.12 1,523.16
Physical writes: 3,939.97 2,720.25
User calls: 50.08 34.58
Parses: 26.96 18.61
Hard parses: 1.49 1.03
Sorts: 18.36 12.68
Logons: 0.13 0.09
Executes: 4,925.89 3,400.96
Transactions: 1.45
% Blocks changed per Read: 42.50 Recursive Call %: 99.19
Rollback per transaction %: 59.69 Rows per Sort: 1922.64
在這個例子里，Top 5 Events部分顯示問題可能跟SQL的執行有關，那麼我們接下來檢查load profile部分。
如果您檢查AWR report是為了一般性的性能調優，那麼可以看到有比較多的redo activity和比較高的physical writes. Physical writes比physical read要高，並且有42%的塊被更改了.
此外，hard parse的次數要少於soft parse.
如果mutex等待事件比較嚴重，如"library cache: mutex X"，那麼查看所有parse的比率會更有用。
當然，如果把Load Profile部分跟正常時候的AWR報告做比較會更有用，比如，比較redo size, users calls, 和 parsing這些性能指標。
Instance Efficiency
Instance Efficiency部分更適用於一般性的調優，而不是解決某個具體問題（除非等待事件直接指向這些指標）。
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 99.91 Redo NoWait %: 100.00
Buffer Hit %: 98.14 In-memory Sort %: 99.98
Library Hit %: 99.91 Soft Parse %: 94.48
Execute to Parse %: 99.45 Latch Hit %: 99.97
Parse CPU to Parse Elapsd %: 71.23 % Non-Parse CPU: 99.00
從我們的這個例子來看，最有用的信息是%Non-Parse CPU，它表明幾乎所有的CPU都消耗在了Execution而不是Parse上，所以調優SQL會對性能有改善。
㈡ 如何進行資料庫性能分析
使用RichAPM可以直接針對不同類型的資料庫性能進行分析，包括MySQL、Oracle、SQL Server三類關系型資料庫及Memcache、redis兩類非關系型資料庫。
㈢ 如何使用AWR報告來診斷資料庫性能問題 第3頁
當進程因為某些原因不能進行操作時，它需要等待。花費時間最多的等待事件是我們最需要關注的，因為降低它，我們能夠獲得最大的好處。
AWR報告中的"Top 5 Timed Events"部分就提供了這樣的信息，可以讓我們只關注主要的問題。
㈣ 如何使用awr報告來診斷資料庫性能問題
您好，很高興為您解答。
過程參考：http://blog.itpub.net/12798004/viewspace-1262538/
如若滿意，請點擊右側【採納答案】，如若還有問題，請點擊【追問】
希望我的回答對您有所幫助，望採納！
~ O(∩_∩)O~
㈤ 如何檢查oracle資料庫性能
這種問題要回答好要求知識比較全面。
1 從操作系統層次上看
看CPU 內存 swqp（交換分區）等使用率
2 從磁碟上看
主要看磁碟讀寫。可以用dd測磁碟讀寫的速度 也可以在業務高峰期檢測磁碟的速率。
3 從資料庫本身來看。
先要看資料庫各個參數的值 。 如sga的大小，process的大小，redo日誌的個數與大小等這些關繫到性能的參數是否設置合理。
長期觀察的方式就是看各個時期的AWR報告。裡面有各種性能指標，以及按執行時間或資源排列的sql ，以及各種等待時間的排名。從這裡面可以掌握資料庫的長期的性能變化。
即時觀察的方式就是利用各種sql 查詢 資料庫在當前時間的各個性能指標(AWR報告裡面的各種指標也都是通過sql查詢出來的)
還有對資料庫整體的一個檢查：
如 表的大小，表是否需要分區而沒有分區，索引是否創建，索引是否失效，開發人員寫的sql是否正確使用到了索引，頻繁使用的sql是否有綁定變數，有頻繁大批量增刪改的表是否存在高水位。。。
額 總之，這個話題涉及的知識非常多，盡可能多的學習一些東西，祝你好運。
㈥ mysql 性能測試報告怎麼寫
給你看個範例：
測試環境：
DELL2.4Gmemory512M
RH9.0MySQL3.23.54
測試使用的是mysql預設參數，用mysql提供的API用C編寫測試程序
測試程序共啟動40個線程進行資料庫操作，查找、插入、修改、刪除各10個，每個線程獨立與SqlServer連接。
資料庫結構，單表，表結構如下：
toheader100byte主鍵
contactheader100byte
called50byte
cseq100byte
hashvalint
timestampint次鍵
對主次鍵分別建了索引。分別在5萬、10萬、50萬用戶環境做測試，結果如下：
查找100次
插入100次
修改100次
刪除100次
5萬
100－300ms
100－300ms
100－300ms
100－300ms
10萬
500ms-1s
500ms-1s
500ms-1s
500ms-1s
50萬
3s-5s
3s-5s
3s-5s
3s-5s
從此數據看性能是很不錯的，因為mysql能保證每個操作是原子的，所以不用考慮線程間的同步。
但有一個問題：即mysql的每個操作是原子的，所以做每個操作時，其它線程是阻塞的，在大數據量查詢時，花的時間較長，會對其它線程有影響。我在保持其它線程工作不變的情況下，將每個查找線程改為做一次對所有記錄的查詢，在5萬和10萬記錄時表現不錯，分別為250ms和450ms，但在50萬記錄時，這個數值達到了22秒。而且在50萬用戶時，通過條件查找部分數據也很慢，如查詢結果為10萬記錄時用11秒。
懷疑是sqlserver的參數影響，按資料庫說明修改了幾個緩沖區的參數，但沒有效果。
由於首次同步發生的頻率很低，象250ms和450ms這樣的數據還是可以接受的，但22秒太離譜了。支持50萬用戶在線，需要考慮一個解決辦法，現在有一個辦法是建一個備份表，寫備份表的請求放到一個隊列里由一個單獨線程處理，這樣阻塞不會影響正常業務處理了。但這個線程的緩沖區要足夠容納30秒內發生的操作。
本來擔心數據量大了mysql的緩沖區不夠會出錯或丟數據，但測試發現，一次查詢最多讀了50M數據，沒有出現問題，經測算我們首次同步的數據不會超過10M。
在MySQL中啟動了innoDB引擎後，可以實現真正的行級鎖，select和update操作可以並發，這樣在全表查詢進行中間可以進行其它的select和update操作，但insert和delete不行。
性能也有很大提高，50萬記錄時100次操作300ms，全表查詢11秒多
常用參數[options]詳細說明：--auto-generate-sql,
-a自動生成測試表和數據，表示用mysqlslap工具自己生成的SQL腳本來測試並發壓力。
--auto-generate-sql-load-type=type測試語句的類型。代表要測試的環境是讀操作還是寫操作還是兩者混合的。取值包括：read，key，write，update和mixed(默認)。
--auto-generate-sql-add-auto-increment代表對生成的表自動添加auto_increment列，從5.1.18版本開始支持。--number-char-cols=N,
-xN自動生成的測試表中包含多少個字元類型的列，默認1--number-int-cols=N,-yN自動生成的測試表中包含多少個數字類型的列，默認1--number-of-queries=N總的測試查詢次數(並發客戶數×每客戶查詢次數)
--query=name,-q使用自定義腳本執行測試，例如可以調用自定義的一個存儲過程或者sql語句來執行測試。--create-schema代表自定義的測試庫名稱，測試的schema，MySQL中schema也就是database。--commint=N多少條DML後提交一次。
--compress,-C如果伺服器和客戶端支持都壓縮，則壓縮信息傳遞。--concurrency=N,-cN表示並發量，也就是模擬多少個客戶端同時執行select。可指定多個值，以逗號或者--delimiter參數指定的值做為分隔符。例如：
--concurrency=100,200,500。
--engine=engine_name,-eengine_name代表要測試的引擎，可以有多個，用分隔符隔開。例如：--engines=myisam,innodb。--iterations=N,-iN測試執行的迭代次數，代表要在不同並發環境下，各自運行測試多少次。
--only-print只列印測試語句而不實際執行。--detach=N執行N條語句後斷開重連。--debug-info,-T列印內存和CPU的相關信息。說明：測試的過程需要生成測試表，插入測試數據，這個mysqlslap可以自動生成，默認生成一個mysqlslap的schema，如果已經存在則先刪除。可以用--only-print來列印實際的測試過程，整個測試完成後不會在資料庫中留下痕跡。各種測試參數實例（-p後面跟的是mysql的root密碼）：單線程測試。測試做了什麼。
#mysqlslap-a-uroot-p123456多線程測試。使用–concurrency來模擬並發連接。#mysqlslap-a-c100-uroot-p123456迭代測試。用於需要多次執行測試得到平均值。#mysqlslap-a-i10-uroot-p123456#mysqlslap---auto-generate-sql-add-autoincrement-a-uroot-p123456#mysqlslap-a--auto-generate-sql-load-type=read-uroot-p123456#mysqlslap-a--auto-generate-secondary-indexes=3-uroot-p123456#mysqlslap-a--auto-generate-sql-write-number=1000-uroot-p123456#mysqlslap--create-schemaworld-q"selectcount(*)fromCity"-uroot-p123456#mysqlslap-a-einnodb-uroot-p123456#mysqlslap-a--number-of-queries=10-uroot-p123456測試同時不同的存儲引擎的性能進行對比：#mysqlslap-a--concurrency=50,100--number-of-queries1000--iterations=5--engine=myisam,innodb--debug-info-uroot-p123456執行一次測試，分別50和100個並發，執行1000次總查詢：#mysqlslap-a--concurrency=50,100--number-of-queries1000--debug-info-uroot-p12345650和100個並發分別得到一次測試結果(Benchmark)，並發數越多，執行完所有查詢的時間越長。為了准確起見，可以多迭代測試幾次:#mysqlslap-a--concurrency=50,100--number-of-queries1000--iterations=5--debug-info-uroot-p123456
㈦ 如何在性能測試中手工生成AWR報告完成資料庫性能分析
如何在性能測試中手工生成AWR報告完成資料庫性能分析
網路文庫：http://wenku..com/link?url=_X91Ua_9wnwZJ42hazbEDNOtAocN8GFsN-
㈧ 如何使用AWR報告來診斷資料庫性能問題
Interpretation
在處理性能問題時，我們最關注的是資料庫正在等待什麼。
當進程因為某些原因不能進行操作時，它需要等待。花費時間最多的等待事件是我們最需要關注的，因為降低它，我們能夠獲得最大的好處。
AWR報告中的"Top 5 Timed Events"部分就提供了這樣的信息，可以讓我們只關注主要的問題。
•
Top 5 Timed Events
正如前面提到的，"Top 5 Timed Events"是AWR報告中最重要的部分。它指出了資料庫的sessions花費時間最多的等待事件，如下：
Top 5 Timed Events Avg %Total
~~~~~~~~~~~~~~~~~~ wait Call
Event Waits Time (s) (ms) Time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
db file scattered read 10,152,564 81,327 8 29.6 User I/O
db file sequential read 10,327,231 75,878 7 27.6 User I/O
CPU time 56,207 20.5
read by other session 4,397,330 33,455 8 12.2 User I/O
PX Deq Credit: send blkd 31,398 26,576 846 9.7 Other
-------------------------------------------------------------
Top 5 Events部分包含了一些跟Events（事件）相關的信息。它記錄了這期間遇到的等待的總次數，等待所花費的總時間，每次等待的平均時間；這一部分是按照每個Event占總體call time的百分比來進行排序的。
根 據Top 5
Events部分的信息的不同，接下來我們需要檢查AWR報告的其他部分，來驗證發現的問題或者做定量分析。等待事件需要根據報告期的持續時間和當時數據
庫中的並發用戶數進行評估。如：10分鍾內1000萬次的等待事件比10個小時內的1000萬等待更有問題；10個用戶引起的1000萬次的等待事件比
10,000個用戶引起的相同的等待要更有問題。
就像上面的例子，將近60%的時間是在等待IO相關的事件。
• 事件"db file scattered read"一般表明正在做由全表掃描或者index fast full scan引起的多塊讀。
• 事件"db file sequential read"一般是由不能做多塊讀的操作引起的單塊讀（如讀索引）
其他20%的時間是花在使用或等待CPU time上。過高的CPU使用經常是性能不佳的SQL引起的（或者這些SQL有可能用更少的資源完成同樣的操作）；對於這樣的SQL，過多的IO操作也是一個症狀。關於CPU使用方面，我們會在之後討論。
在以上基礎上，我們將調查是否這個等待事件是有問題的。若有問題，解決它；若是正常的，檢查下個等待事件。
過多的IO相關的等待一般會有兩個主要的原因：
• 資料庫做了太多的讀操作
• 每次的IO讀操作都很慢
Top 5 Events部分的顯示的信息會幫助我們檢查：
• 是否資料庫做了大量的讀操作：
上面的圖顯示了在這段時間里兩類讀操作都分別大於1000萬，這些操作是否過多取決於報告的時間是1小
時或1分鍾。我們可以檢查AWR報告的elapsed time如果這些讀操作確實是太多了，接下來我們需要檢查AWR報告中 SQL
Statistics 部分的信息，因為讀操作都是由SQL語句發起的。
• 是否是每次的IO讀操作都很慢：
上面的圖顯示了在這段時間里兩類讀操作平均的等待時間是小於8ms的
至於8ms是快還是慢取決於底層的硬體設備；一般來講小於20ms的都可以認為是可以接受的。
我們還可以在AWR報告"Tablespace IO Stats"部分得到更詳細的信息
Tablespace IO Stats DB/Inst: VMWREP/VMWREP Snaps: 1-15
-> ordered by IOs (Reads + Writes) desc
Tablespace
------------------------------
Av Av Av Av Buffer Av Buf
Reads Reads/s Rd(ms) Blks/Rd Writes Writes/s Waits Wt(ms)
-------------- ------- ------ ------- ------------ -------- ---------- ------
TS_TX_DATA
14,246,367 283 7.6 4.6 145,263,880 2,883 3,844,161 8.3
USER
204,834 4 10.7 1.0 17,849,021 354 15,249 9.8
UNDOTS1
19,725 0 3.0 1.0 10,064,086 200 1,964 4.9
AE_TS
4,287,567 85 5.4 6.7 932 0 465,793 3.7
TEMP
2,022,883 40 0.0 5.8 878,049 17 0 0.0
UNDOTS3
1,310,493 26 4.6 1.0 941,675 19 43 0.0
TS_TX_IDX
1,884,478 37 7.3 1.0 23,695 0 73,703 8.3
>SYSAUX
346,094 7 5.6 3.9 112,744 2 0 0.0
SYSTEM
101,771 2 7.9 3.5 25,098 0 653 2.7
如上圖，我們關心Av Rd(ms)的指標。如果它高於20ms並且同時有很多讀操作的，我們可能要開始從OS的角度調查是否有潛在的IO問題。
㈨ 衡量資料庫性能的重要指標
具體來說，本文包括以下內容:
事務
查詢性能
用戶和查詢沖突
容量
配置
NoSQL 資料庫
- 圖1-基於基線評估當前事務響應時間
事務
事務可以觀察真實用戶的行為：能夠在應用交互時捕獲實時性能。眾所周知，測量事務的性能包括獲取整個事務的響應時間和組成事務的各個部分的響應時間。通常我們可以用這些響應時間與滿足事務需求的基線對比，來確定當前事務是否處於正常狀態。
如果你只想衡量應用的某個方面，那麼可以評估事務的行為。所以，盡管容器指標能夠提供更豐富的信息，並且幫助你決定何時對當前環境進行自動測量，但你的事務就足以確定應用性能。無需向應用程序伺服器獲取 CPU 的使用情況，你更應該關心用戶是否完成了事務，以及該事務是否得到了優化。
補充一個小知識點，事務是由入口點決定的，通過該入口點可以啟動事務與應用進行交互。
一旦定義了事務，會在整個應用生態系統中對其性能進行測量，並將每個事務與基線進行比對。例如，我們可能會決定當事務的響應時間與基線相比，一旦慢於平均響應時間的兩個標准差是否就應該判定為異常，如圖1所示。
用於評估事務的基線與正在進行的事務活動在時間上是一致的，但事務會由每個事務執行來完善。例如，當你選定一個基線，在當前事務結束之後，將事務與平均響應時間按每天的小時數和每周的天數進行對比，所有在那段時間內執行的事務都將會被納入下周的基線中。通過這種機制，應用程序可以隨時間而變化，而無需每次都重建原始基線；你可以將其看作是一個隨時間移動的窗口。
總之，事務最能反映用戶體驗的測量方法，所以也是衡量性能狀況最重要的指標。
查詢性能
最容易檢測到查詢性能是否正常的指標就是查詢本身。由查詢引起的問題可能會導致時間太長而無法識別所需數據或返回數據。所以不妨在查詢中排查以下問題。
1. 選擇過多冗餘數據
編寫查詢語句來返回適當的數據是遠遠不夠的，很可能你的查詢語句會返回太多列，從而導致選擇行和檢索數據變得異常緩慢。所以，最好是列出所需的列，而不是直接用 SELECT*。當需要在特定欄位中查詢時，該計劃可能會確定一個覆蓋索引從而加快結果返回。覆蓋索引通常會包含查詢中使用的所有欄位。這意味著資料庫可以僅從索引中產生結果，而不需要通過底層表來構建。
另外，列出結果中所需的列不僅可以減少傳輸的數據，還能進一步提高性能。
2. 表之間的低效聯接
聯接會導致資料庫將多組數據帶到內存中進行比較，這會產生多個資料庫讀取和大量 CPU。根據表的索引，聯接還可能需要掃描兩個表的所有行。如果寫不好兩個大型表之間的聯接，就需要對每個表進行完整掃描，這樣的計算量將會非常大。其他會拖慢聯接的因素包括聯接列之間存在不同的數據類型、需要轉換或加入包含 LIKE 的條件，這樣就會阻止使用索引。另外，還需注意避免使用全外聯接；在恰當的時候使用內部聯接只返回所需數據。
3. 索引過多或過少
如果查詢優化沒有可用的索引時，資料庫會重新掃描表來產生查詢結果，這個過程會生成大量的磁碟輸入/輸出（I/O）。適當的索引可以減少排序結果的需要。雖然非唯一值的索引在生成結果時，不能像唯一索引那樣方便。如果鍵越大，索引也會變大，並通過它們創建更多的磁碟 I/O。大多數索引是為了提高數據檢索的性能，但也需要明白索引本身也會影響數據的插入和更新，因為所有相關聯的指標都必須更新。
4. 太多的SQL導致爭用解析資源
任何 SQL 查詢在執行之前都必須被解析，在生成執行計劃之前需要對語法和許可權進行檢查。由於解析非常耗時，資料庫會保存已解析的 SQL 來重復利用，從而減少解析的耗時。因為 WHERE 語句不同，所以使用文本值的查詢語句不能被共享。這將導致每個查詢都會被解析並添加到共享池中，由於池的空間有限，一些已保存的查詢會被舍棄。當這些查詢再次出現時，則需要重新解析。
用戶和查詢沖突
資料庫支持多用戶，但多用戶活動也可能造成沖突。
1. 由慢查詢導致的頁/行鎖定
為了確保查詢產生精確的結果，資料庫必須鎖定表以防止在運行讀取查詢時再發生其他的插入和更新行為。如果報告或查詢相當緩慢，需要修改值的用戶可能需要等待至更新完成。鎖提示能幫助資料庫使用最小破壞性的鎖。從事務資料庫中分離報表也是一種可靠的解決方法。
2. 事務鎖和死鎖
當兩個事務被阻塞時會出現死鎖，因為每一個都需要使用被另一個佔用的資源。當出現一個普通鎖時，事務會被阻塞直到資源被釋放。但卻沒有解決死鎖的方案。資料庫會監控死鎖並選擇終止其中一個事務，釋放資源並允許該事務繼續進行，而另一個事務則回滾。
3. 批處理操作造成資源爭奪
批處理過程通常會執行批量操作，如大量的數據載入或生成復雜的分析報告。這些操作是資源密集型的，但可能影響在線用戶的訪問應用的性能。針對此問題最好的解決辦法是確保批處理在系統使用率較低時運行，比如晚上，或用單獨的資料庫進行事務處理和分析報告。
容量
並不是所有的資料庫性能問題都是資料庫問題。有些問題也是硬體不合適造成的。
1. CPU 不足或 CPU 速度太慢
更多 CPU 可以分擔伺服器負載，進一步提高性能。資料庫的性能不僅是資料庫的原因，還受到伺服器上運行其他進程的影響。因此，對資料庫負載及使用進行審查也是必不可少的。由於 CPU 的利用率時時在變，在低使用率、平均使用率和峰值使用率的時間段分別檢查該指標可以更好地評估增加額外的 CPU 資源是否有益。
2. IOPS 不足的慢磁碟
磁碟性能通常以每秒輸入/輸出操作（IOPS）來計。結合 I/O 大小，該指標可以衡量每秒的磁碟吞吐量是多少兆。同時，吞吐量也受磁碟的延遲影響，比如需要多久才能完成請求，這些指標主要是針對磁碟存儲技術而言。傳統的硬碟驅動器（HDD）有一個旋轉磁碟，通常比固態硬碟（SSD）或快閃記憶體更慢。直到近期，SSD 雖然仍比 HDD 貴，但成本已經降了下來，所以在市場上也更具競爭力。
3. 全部或錯誤配置的磁碟
眾所周知，資料庫會被大量磁碟訪問，所以不正確配置的磁碟可能帶來嚴重的性能缺陷。磁碟應該適當分區，將系統數據目錄和用戶數據日誌分開。高度活躍的表應該區分以避免爭用，通過在不同磁碟上存放資料庫和索引增加並行放置，但不要將操作系統和資料庫交換空間放置在同一磁碟上。
4. 內存不足
有限或不恰當的物理內存分配會影響資料庫性能。通常我們認為可用的內存更多，性能就越好。監控分頁和交換,在多個非繁忙磁碟中建立多頁面空間，進一步確保分頁空間分配足夠滿足資料庫要求；每個資料庫供應商也可以在這個問題上提供指導。
5. 網速慢
網路速度會影響到如何快速檢索數據並返回給終端用戶或調用過程。使用寬頻連接到遠程資料庫。在某些情況下，選擇 TCP/IP 協議而不是命名管道可顯著提高資料庫性能。
配置
每個資料庫都需設置大量的配置項。通常情況下，默認值可能不足以滿足資料庫所需的性能。所以，檢查所有的參數設置，包括以下問題。
1. 緩沖區緩存太小
通過將數據存儲在內核內存，緩沖區緩存可以進一步提高性能同時減少磁碟 I/O。當緩存太小時，緩存中的數據會更頻繁地刷新。如果它再次被請求，就必須從磁碟重讀。除了磁碟讀取緩慢之外，還給 I/O 設備增添了負擔從而成為瓶頸。除了給緩沖區緩存分配足夠的空間，調優 SQL 查詢可以幫助其更有效地利用緩沖區緩存。
2. 沒有查詢緩存
查詢緩存會存儲資料庫查詢和結果集。當執行相同的查詢時，數據會在緩存中被迅速檢索，而不需要再次執行查詢。數據會更新失效結果，所以查詢緩存是唯一有效的靜態數據。但在某些情況下，查詢緩存卻可能成為性能瓶頸。比如當鎖定為更新時，巨大的緩存可能導致爭用沖突。
3. 磁碟上臨時表創建導致的 I/O 爭用
在執行特定的查詢操作時，資料庫需要創建臨時表，如執行一個 GROUP BY 子句。如果可能，在內存中創建臨時表。但是，在某些情況下，在內存中創建臨時表並不可行，比如當數據包含 BLOB 或 TEXT 對象時。在這些情況下，會在磁碟上創建臨時表。大量的磁碟 I / O 都需要創建臨時表、填充記錄、從表中選擇所需數據並在查詢完成後舍棄。為了避免影響性能，臨時資料庫應該從主資料庫中分離出來。重寫查詢還可以通過創建派生表來減少對臨時表的需求。使用派生表直接從另一個 SELECT 語句的結果中選擇，允許將數據加到內存中而不是當前磁碟上。
NoSQL 資料庫
NoSQL 的優勢在於它處理大數據的能力非常迅速。但是在實際使用中，也應該綜合參考 NoSQL 的缺點，從而決定是否適合你的用例場景。這就是為什麼NoSQL通常被理解為 「不僅僅是 SQL」，說明了 NoSQL 並不總是正確的解決方案，也沒必要完全取代 SQL，以下分別列舉出五大主要原因。
1. 挑剔事務
難以保持 NoSQL 條目的一致性。當訪問結構化數據時，它並不能完全確保同一時間對不同表的更改都生效。如果某個過程發生崩潰，表可能會不一致。一致事務的典型代表是復式記賬法。相應的信貸必須平衡每個借方，反之亦然。如果雙方數據不一致則不能輸入。NoSQL 則可能無法保證「收支平衡」。
2. 復雜資料庫
NoSQL 的支持者往往以高效代碼、簡單性和 NoSQL 的速度為傲。當資料庫任務很簡單時，所有這些因素都是優勢。但當資料庫變得復雜，NoSQL 會開始分解。此時，SQL 則比 NoSQL 更好地處理復雜需求，因為 SQL 已經成熟，有符合行業標準的介面。而每個 NoSQL 設置都有一個唯一的介面。
3. 一致聯接
當執行 SQL 的聯接時，由於系統必須從不同的表中提取數據進行鍵對齊，所以有一個巨大的開銷。而 NoSQL 似乎是一個空想，因為缺乏聯接功能。所有的數據都在同一個表的一個地方。當檢索數據時，它會同時提取所有的鍵值對。問題在於這會創建同一數據的多個副本。這些副本也必須更新，而這種情況下，NoSQL 沒有功能來確保更新。
4. Schema設計的靈活性
由於 NoSQL 不需要 schema，所以在某些情況下也是獨一無二的。在以前的資料庫模型中，程序員必須考慮所有需要的列能夠擴展，能夠適應每行的數據條目。在 NoSQL 下，條目可以有多種字元串或者完全沒有。這種靈活性允許程序員迅速增加數據。但是，也可能存在問題，比如當有多個團體在同一項目上工作時，或者新的開發團隊接手一個項目時。開發人員能夠自由地修改資料庫，也可能會不斷實現各種各樣的密鑰對。
5. 資源密集型
NoSQL 資料庫通常比關系資料庫更加資源密集。他們需要更多的 CPU 儲備和 RAM 分配。出於這個原因，大多數共享主機公司都不提供 NoSQL。你必須注冊一個 VPS 或運行自己的專用伺服器。另一方面，SQL 主要是在伺服器上運行。初期的工作都很順利，但隨著資料庫需求的增加，硬體必須擴大。單個大型伺服器比多個小型伺服器昂貴得多，價格呈指數增長。所以在這種企業計算場景下，使用 NoSQL 更為劃算，例如那些由谷歌和 Facebook 使用的伺服器。
㈩ 如何檢查oracle資料庫性能
oracle的性能判斷需要綜合資料庫的多個運行指標來判斷：
1、進程數量和佔用cpu：這個主要看有沒有長時間佔用cpu的進行。通常會判斷大出sql，需要優化；這個可以用執行計劃或者awr報告查看；
2、內存佔用：主要用系統命令查看ora_佔用和系統總內存的比例，swap的使用率；通常swap使用率低就沒事；這個主要使用系統命令；
3、磁碟佔用率：防止磁碟空間不足，需要的主要在系統和用戶表空間、RMAN等操作上；這個主要使用系統命令；RMAN命令查看