程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 數據庫知識 >> Oracle數據庫 >> Oracle數據庫基礎 >> Oracle性能診斷方法

Oracle性能診斷方法

編輯:Oracle數據庫基礎

性能優化是數據庫DBA不可缺少的工作之一,對於性能優化來說,每個有經驗的DBA都各自有著自己的一套方法,和自己熟悉的一套過程。我這裡主要談談我自己在性能診斷和優化這塊的心得,有經驗的看過以後可以相互交流,咩有經驗的看到後可以指導著試試。以免走更多的彎路。

對於我們的性能優化來說,最壞的一種情況,就是在架構,需求,設計和實現的過程中都沒有發現問題,而直到了上線或者是使用一段時間以後才發現性能問題。這個我已經也多次的提及過,和系統的問題和人生病一樣,小病不看,到大病拖不下去了,來到醫生動手術的時候,這裡的解決方案是最局限的,解決成本也是最高額的,而且可以解決的問題也是最有局限性的。所以性能方面的考慮是每個生命周期都值得進行的,都是非常有意義的。對於上面的問題而已,到了DBA這裡,基本上也就存在著或大或小的一些性能問題。

對於性能優化而言,我們應該從瓶頸處的分析著手,問題由大至小,由全面到具體。根據整體的性能報告先找到最嚴重的地方開始,有目標的進行,根據我們的針對性的目標,我們可能已經找到了一些需要分析的問題了。比如說,CPU和內存的使用過高,dead lock,IO的性能低下等大該的問題叻 。有了這個大概的方向,我們就可以針對性的開始我們的優化之舉了,分析瓶頸的目的,就是找到正真的最大的性能發生問題的關鍵點,根據這個關鍵點進去,我們落實到每個具體的環節。對於一個性能的問題而言,最終的因素無非是 硬件和操作系統的局限,應用錯誤和數據庫管理上的失誤。 性能底下的原因無非就是這三個方面的組合而已,我們需要做的就是根據自己的經驗,配合上適當的工具對這三個方面的原因進行甄別,找到正真的罪魁禍首。然後針對著進行調配和修改,從而達到優化的目的。

我們下面來具體看看這影響我們的性能的三個方面,以及我們用到的方法

1. 硬件和操作系統的局限  數據庫安裝在操作系統上.操作系統架構在硬件上,所以硬件直接的對我們的軟件的性能造成影響。比如CPU的處理能力,物理內存的大小,網絡的拓撲結構,存儲的媒介,IO的讀寫能力這些對我們的整個的Oracle的數據庫性能都有著相當大的影響。對於以上的一些硬件設備的狀態,操作系統都提供了一定的系統工具,使我們能夠行而有效的對之進行監控和管理。在Linux和unix下,使用top,iOStat,sysstat,vmstat,sar,df等一些系統監控的工具,我們可以很方便的對數據庫的硬件狀況進行監控和排查。除開硬件,我們操作系統的一些設置也會有一些影響,比如Linux的一些內核參數,進程線程的控制參數,swap空間的大小,這些都一樣對我們的性能造成影響。我們也可以根據針對性的工具進行排查和診斷。

2. 應用上的錯誤,對於應用上的錯誤,包括很多的方面,比如說,sql性能的低劣,大量的硬解析的消耗,過多的長事務,死鎖,沒有使用批處理等等,這些應用上的錯誤,多半是我們的設計者和程序員在自己的設計和實現的過程中,對性能的考慮過少導致的,對於這樣的錯誤。我們可以直接的落實到點上,對發生性能低劣的地方進行優化。

3. 數據庫管理上的失誤 這裡就是DBA本身的問題叻,缺少對數據庫優化的經驗,在數據庫維護和管理的時候,沒有進行有針對性的管理,比如分開IO,條帶化,大表的分區,內存性能參數的設置。發現這樣的問題的話,我們需要對數據庫整體上進行rebuild,重新規劃存儲,重新規劃內存和啟動參數,規劃出更好性能的結構。

 

對於甄別上面不同原因造成的性能問題,Oracle提供了一個強大的性能分析工具,statspack,這個性能分析工具,提供時間段的監控手段,達到對指定的時間段的Oracle數據庫服務器的一個整體上的性能監控的目的,在statspack提供出來的性能報告裡,能夠找到很多重要的性能好壞的指標數據,,比如說數據庫內存狀況,負載情況,數據庫的內存的命中率,sql的解析率,以及top sql,wait event等信息。根據這些信息,我們不僅有一個很全面的性能狀況的了解,而且還可以根據其中的每個性能數據,深入下去,還是對上面提到的三個方面進行排查的依據和參考點。

 

在statspack報告裡,包含了以上我們提到的很多影響數據庫性能的因素的數據庫統計,

 

比如我們可以在statspack裡的順著看到

引用:
DB Name DB Id Instance Inst Num Release Cluster Host
------------ ----------- ------------ -------- ----------- ------- ------------
TOOWELL 3651869694 toowell 1 9.2.0.1.0 NO COMPUTERHJH

Snap Id Snap Time Sessions Curs/Sess Comment
------- ------------------ -------- --------- -------------------
Begin Snap: 1 09-4月 -09 01:19:29 11 4.8
End Snap: 3 09-4月 -09 01:38:29 11 5.4
Elapsed: 19.00 (mins)


這裡記載了整個監控時間的實例信息

引用:

Cache Sizes (end)
~~~~~~~~~~~~~~~~~
Buffer Cache: 1,000M Std Block Size: 8K
Shared Pool Size: 80M Log Buffer: 512K

Load Profile
~~~~~~~~~~~~ Per Second Per Transaction
--------------- ---------------
Redo size: 2,597.53 296,118.80
Logical reads: 13,379.84 1,525,301.30
Block changes: 11.10 1,265.50
Physical reads: 401.24 45,741.60
Physical writes: 0.81 92.30
User calls: 146.20 16,666.50
Parses: 29.77 3,394.30
Hard parses: 8.81 1,003.90
Sorts: 18.58 2,118.40
Logons: 1.60 182.60
Executes: 32.00 3,647.50
Transactions: 0.01

% Blocks changed per Read: 0.08 Recursive Call %: 49.97
Rollback per transaction %: 0.00 Rows per Sort: 14.14

Instance EfficIEncy Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 99.96 Redo NoWait %: 100.00
Buffer Hit %: 97.00 In-memory Sort %: 100.00
Library Hit %: 87.28 Soft Parse %: 70.42
Execute to Parse %: 6.94 Latch Hit %: 99.68
Parse CPU to Parse Elapsd %: 90.63 % Non-Parse CPU: 94.21

Shared Pool Statistics Begin End
------ ------
Memory Usage %: 86.41 87.01
% SQL with executions>1: 58.56 45.56
% Memory for SQL w/exec>1: 53.48 45.47

 

這裡記載了所有的內存狀況的信息以及概要性的信息,這裡我們可以看到命中率和內存的一些信息。

引用:


Top 5 Timed Events
~~~~~~~~~~~~~~~~~~ % Total
Event Waits Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
db file sequential read 271,910 587 64.06
db file scattered read 12,428 163 17.82
CPU time 99 10.75
buffer busy waits 6,024 59 6.45
control file sequential read 248 2 .25
-------------------------------------------------------------
Wait Events for DB: TOOWELL Instance: toowell Snaps: 1 -3
-> s - second
-> cs - centisecond - 100th of a second
-> ms - millisecond - 1000th of a second
-> us - microsecond - 1000000th of a second
-> ordered by wait time desc, waits desc (idle events last)

Avg
Total Wait wait Waits
Event Waits Timeouts Time (s) (ms) /txn
---------------------------- ------------ ---------- ---------- ------ --------
db file sequential read 271,910 0 587 2 ########
db file scattered read 12,428 0 163 13 1,242.8
log file parallel write 1,090 790 2 1 109.0

LGWR wait for redo copy 26 0 0 0 2.6
SQL*Net message from clIEnt 168,451 0 2,199 13 ########
virtual circuit status 38 38 1,135 29860 3.8
wakeup time manager 36 36 1,088 30218 3.6
SQL*Net message to clIEnt 168,451 0 0 0 ########
-------------------------------------------------------------
Background Wait Events for DB: TOOWELL Instance: toowell Snaps: 1 -3
-> ordered by wait time desc, waits desc (idle events last)

Avg
Total Wait wait Waits
Event Waits Timeouts Time (s) (ms) /txn
---------------------------- ------------ ---------- ---------- ------ --------
control file parallel write 369 0 2 6 36.9
control file sequential read 148 0 2 15 14.8
log file parallel write 1,090 790 2 1 109.0
db file scattered read 4 0 1 212 0.4
........
rdbms ipc message 3,234 2,424 5,145 1591 323.4
smon timer 4 4 984 ###### 0.4
-------------------------------------------------------------


以上我們可以看到我們的數據庫的一些重要的等待事件,這些等待事件也是影響我們數據庫性能的因素之一。

引用:


SQL ordered by Gets for DB: TOOWELL Instance: toowell Snaps: 1 -3
-> End Buffer Gets Threshold: 10000
-> Note that resources reported for PL/SQL includes the resources used by
all SQL statements called within the PL/SQL code. As individual SQL
statements are also reported, it is possible and valid for the summed
total % to exceed 100

CPU Elapsd
Buffer Gets Executions Gets per Exec %Total Time (s) Time (s) Hash Value
--------------- ------------ -------------- ------ -------- --------- ----------
1,271,286 2 635,643.0 8.3 7.22 272.59 3380648538
Module: PL/SQL Developer
--m=2 --SELECT /*+ FIRST_ROWS */ * FROM ( SELECT A.*, rownum r F
ROM ( SELECT a.* FROM md_info_reg a, md_member_company b where a
.username=b.username and length(imageurl1)>5 and hits>-1 order
by a.id) A WHERE rownum <= 5 ) B WHERE r > 0 --m=1 SELECT /*+ F
IRST_ROWS */ * FROM ( SELECT A.*, rownum r FROM ( SELECT a.* FRO

.........

這裡是我們的性能低劣的sql的信息叻


Instance Activity Stats for DB: TOOWELL Instance: toowell Snaps: 1 -3

Statistic Total per Second per Trans
--------------------------------- ------------------ -------------- ------------
index fast full scans (full) 1,229 1.1 122.9
index fetch by key 1,216,953 1,067.5 121,695.3
index scans kdiixs1 75,366 66.1 7,536.6
leaf node 90-10 splits 8 0.0 0.8
leaf node splits 39 0.0 3.9
logons cumulative 1,826 1.6 182.6
......


Instance Activity Stats for DB: TOOWELL Instance: toowell Snaps: 1 -3

Statistic Total per Second per Trans
--------------------------------- ------------------ -------------- ------------
table scan rows gotten 579,397 508.2 57,939.7
table scans (long tables) 15 0.0 1.5
table scans (short tables) 1,366 1.2 136.6
transaction rol lbacks 0 0.0 0.0
transaction tables consistent rea 0 0.0 0.0
transaction tables consistent rea 0 0.0 0.0
user calls 166,665 146.2 16,666.5
........
-------------------------------------------------------------

引用:


Tablespace IO Stats for DB: TOOWELL Instance: toowell Snaps: 1 -3
->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)
-------------- ------- ------ ------- ------------ -------- ---------- ------
ECCHNFILE
284,200 249 2.6 1.6 15 0 6,024 9.8
UNDOTBS1
5 0 16.0 1.0 408 0 0 0.0
SYSTEM
61 0 26.4 1.1 257 0 0 0.0
PERFSTAT
60 0 6.7 1.0 243 0 0 0.0
-------------------------------------------------------------
File IO Stats for DB: TOOWELL Instance: toowell Snaps: 1 -3
->ordered by Tablespace, File

Tablespace Filename
------------------------ ----------------------------------------------------
Av Av Av Av Buffer Av Buf
Reads Reads/s Rd(ms) Blks/Rd Writes Writes/s Waits Wt(ms)
-------------- ------- ------ ------- ------------ -------- ---------- ------
ECCHNFILE D:\Oracle\ORADATA\TOOWELL\ECCHNFILE.ORA
284,200 249 2.6 1.6 15 0 6,024 9.8

PERFSTAT D:\Oracle\USERDATA\PRESTAT.PHP
60 0 6.7 1.0 243 0 0

SYSTEM D:\Oracle\ORADATA\TOOWELL\SYSTEM01.DBF
61 0 26.4 1.1 257 0 0

UNDOTBS1 D:\Oracle\ORADATA\TOOWELL\UNDOTBS01.DBF
5 0 16.0 1.0 408 0 0

-------------------------------------------------------------

 

這裡是物理和邏輯存儲的IO狀況

 

我們還可以在裡面找到

Rollback Segment Stats for DB

Rollback Segment Storage for DB

Undo Segment Summary for DB

Latch Activity for DB

Dictionary Cache Stats for DB

Shared Pool Advisory for DB

SGA Memory Summary for DB

Resource Limit Stats for DB
這些方面的信息,statspack裡的信息都是來自於數據庫裡的動態性能視圖的,都是對性能反應的一些數據。對這些信息的分析,完全是可以給我們的性能針對提供很充分的依據的。
這篇文章僅僅給大家介紹的性能分析的方法和statspack的作用,還咩有涉及到具體的診斷手段,有關具體的診斷手段,歡迎大家繼續關注inthirtIEs的Oracle數據庫性能優化專欄。

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved