Oracle性能診斷不能不知的秘籍
Oracle性能診斷的方法有很多，下面就此講講常用的幾種方法。一般而言，如果需要進(jìn)行性能調(diào)整，那么，肯定是存在一些性能問題。所以，診斷，要從用戶所提出的性能問題開始著手，做到有的放矢。
用戶可能會(huì)羅列出一大堆的性能問題，你比如說：某個(gè)操作比較慢呀，或者說當(dāng)達(dá)到多少用戶的并發(fā)時(shí)CPU和內(nèi)存使用達(dá)到100%，死鎖等等。所以，我們要對(duì)用戶列出的這些性能問題進(jìn)行分析。當(dāng)然，首先得從用戶認(rèn)為最迫切的性能問題開始著手進(jìn)行分析。
明確了性能問題，這是系統(tǒng)調(diào)優(yōu)的***步，讓我們有一個(gè)出發(fā)點(diǎn)，但是分析性能問題，找到性能問題產(chǎn)生的原因，這是一個(gè)復(fù)雜的過程，并且是性能調(diào)優(yōu)的非常重要的一個(gè)過程。只有找到了產(chǎn)生性能問題的根源，你才好著手進(jìn)行調(diào)整。
在Orace性能診斷上，首先要有一個(gè)思路。從整體到局部，從面到點(diǎn)，逐步定位是一個(gè)不錯(cuò)的方法。那么，什么是從整體到局部呢？
Oracle數(shù)據(jù)庫本質(zhì)上是運(yùn)行于某一種計(jì)算機(jī)上的應(yīng)用軟件，所以，這個(gè)整體，我指的就是運(yùn)行Oracle的計(jì)算機(jī)（即服務(wù)器）。如果，性能診斷問題的根源是因?yàn)橛?jì)算機(jī)的性能低下所導(dǎo)致，那么，做其它的調(diào)整將不能根本改變Oracle的性能狀況，我們得從調(diào)整這個(gè)整體開始（即服務(wù)器的性能）。
服務(wù)器的性能我覺得由2個(gè)因素所組成：硬件和操作系統(tǒng)。
(1)硬件包括：CPU，內(nèi)存，存儲(chǔ)等。檢查的方法是我們可以登錄到服務(wù)器發(fā)布一些命令來查看服務(wù)器CPU,內(nèi)存,以及硬盤等的I/O速率，如UNIX下及類UNIX（LINUX）下可以發(fā)布：
Top,vmstat,iostat,free等等命令來檢查這些硬件資源的使用狀況。還可以使用一些第三方的測(cè)量工具。比如，有一些工具是專門用來測(cè)試硬盤的傳輸速率的，從中我們可以知道硬盤的平均帶寬是多少。
通過這些工具，如果檢查出來，發(fā)現(xiàn)是由于服務(wù)器的硬件資源所導(dǎo)致的性能問題，那么，我們就可以建議提升服務(wù)器的硬件。
(2)第二個(gè)因素是OS。因?yàn)镺racle是運(yùn)行于OS之上的，所以O(shè)S的一些設(shè)置，也會(huì)導(dǎo)致一些性能問題。特別是在LINUX下，一些參數(shù)的設(shè)置，如：內(nèi)核參數(shù)，交換空間(swap)等等，也能影響到整個(gè)系統(tǒng)的性能。所以，我們也可以在服務(wù)器上查看一下這些設(shè)置。如果是windows服務(wù)器，windows提供了一個(gè)性能測(cè)量工具，可以測(cè)量每秒的內(nèi)存頁交換（paging）等指標(biāo)，從這些指標(biāo)中我們也可以檢查出內(nèi)存是否足夠，以及虛擬內(nèi)存是否足夠等等一些問題。
檢查完服務(wù)器，就可以從Oracle本身開始進(jìn)行分析了。分析的思路，我也是從整體到局部，從面到點(diǎn)。
整體：首先，我們可以從了解一下Oracle數(shù)據(jù)庫的規(guī)劃開始，這些規(guī)劃具體包括：存儲(chǔ)的規(guī)劃，內(nèi)存的規(guī)劃，實(shí)例參數(shù)設(shè)置等等，下面我分別作一些簡單的介紹。
(1)存儲(chǔ)的規(guī)劃（storage planning）:實(shí)際上指的就是Oracle數(shù)據(jù)庫的磁盤規(guī)劃，這關(guān)系到Oracle的I/O性能。舉例：oracle的數(shù)據(jù)文件磁盤是否和oracle軟件磁盤分開？應(yīng)用系統(tǒng)是否有創(chuàng)建單獨(dú)的表空間？有沒有為索引和大對(duì)象創(chuàng)建單獨(dú)的表空間？多路復(fù)用(multiplexed)的控制文件是否分別存放于不同的磁盤？日志組的不同成員是否存放于不同磁盤？等等，這些都或多或少地影響到oracle的I/O性能。
(2)內(nèi)存規(guī)劃(memory planning)：實(shí)際上指的是oracle SGA和PGA的分配是否合理？以及組成SGA的各個(gè)內(nèi)存組件的內(nèi)存分配是否達(dá)到***？一般而言，對(duì)于排序操作（sort operation）比較多的系統(tǒng)，比如，我們的XPC系統(tǒng)，或者報(bào)表系統(tǒng)，就應(yīng)該適當(dāng)?shù)囟喾峙湟恍﹥?nèi)存給PGA。當(dāng)然，PGA總體目標(biāo)也要根據(jù)系統(tǒng)的連接數(shù)來確定。在SGA方面，總體原則是，盡量把大部分的內(nèi)存分配給數(shù)據(jù)庫高速緩存，以增加內(nèi)存的命中率。至于其它組件如：JAVA池，大池等分配幾十M就可以（32M一般就夠了）。而對(duì)于共享池，則要根據(jù)CPU的性能來決定。一般而言，如果CPU很強(qiáng)（如采用多路CPU），則共享池設(shè)小一點(diǎn)也無所謂。一般而言，設(shè)80M~300M都能滿足系統(tǒng)需求，再多設(shè)的話對(duì)系統(tǒng)性能增加不大，反而浪費(fèi)內(nèi)存。
(3)實(shí)例的參數(shù)：有些Oracle實(shí)例的參數(shù)能夠影響到整個(gè)系統(tǒng)的性能。你比如：與oracle優(yōu)化器相關(guān)的一些參數(shù)設(shè)置，與SQL共享和重用相關(guān)的參數(shù),與是否預(yù)先將SGA裝載到內(nèi)存相關(guān)的參數(shù)等等.我們都要檢查一些,這些參數(shù)設(shè)置是否合理.
那么,我們?cè)趺茨軌驒z查出這些整體的設(shè)置是否就是導(dǎo)致性能問題的根源呢?Oracle有提供一個(gè)用于診斷性能問題的工具包(statspack).當(dāng)然，可能也有一些第三方的用于oracle性能診斷的工具，但是我想沒有其它工具比ORACLE本身提供的工具更全面，更準(zhǔn)確了。
STATSPACK需要安裝。安裝后我們需要設(shè)置一下檢查的時(shí)間間隔，實(shí)際上就是創(chuàng)建一個(gè)oracle的JOB。Statspack或根據(jù)我們?cè)O(shè)定的時(shí)間間隔來從oracle的動(dòng)態(tài)性能視圖中捕捉一些與性能相關(guān)的數(shù)據(jù)，然后根據(jù)一定的公式進(jìn)行計(jì)算，生成一個(gè)有關(guān)于oracle各項(xiàng)性能指標(biāo)的報(bào)告。報(bào)告羅列了一些實(shí)際的活動(dòng)狀況（負(fù)載，內(nèi)存命中率等等），***等待事件，以及TOP SQL等內(nèi)容，是我們進(jìn)行Oracle性能診斷的一個(gè)比較綜合的一個(gè)工具。
局部：oracle的整體調(diào)整完畢后，我們就可能逐步逐步調(diào)整某個(gè)局部了。你比如，我們可以根據(jù)用戶反映出來的問題：比如說，在XPC中點(diǎn)擊某個(gè)BUTTON或進(jìn)行某項(xiàng)操作，系統(tǒng)響應(yīng)比較慢，這個(gè)時(shí)候，我們就可能針對(duì)這個(gè)問題，來進(jìn)行定位。導(dǎo)致這個(gè)操作慢有可能是由于這個(gè)操作執(zhí)行的SQL語句比較慢，也有可能是由于我們的JAVA代碼寫得不夠好，實(shí)現(xiàn)比較復(fù)雜，結(jié)構(gòu)不合理等等所導(dǎo)致。往往，這樣的性能診斷，要DBA和相關(guān)開發(fā)人員一起協(xié)同完成。在DB這一層，我們可以使用ORACLE的一些實(shí)用工具，如SQL TRACE等來捕捉這些SQL，然后對(duì)這個(gè)SQL的進(jìn)行分析，并進(jìn)行優(yōu)化，從而解決這些性能問題。根據(jù)實(shí)踐，相當(dāng)大一部分性能優(yōu)化是在SQL語句一級(jí)著手的。
除了上面我所描述的這些以外，其它與性能相關(guān)的情況也需要調(diào)查一下。如：Oracle是采用何種類型的優(yōu)化器？如果是采用基于成本的優(yōu)化器（CBO），是否有定期進(jìn)行統(tǒng)計(jì)（gather shema statistics）?統(tǒng)計(jì)的時(shí)間間隔設(shè)置是否合理？
另外一個(gè)跟SQL性能相關(guān)的因素就是索引。我們也可以檢查一下是否在相關(guān)表上有否建索引？這些索引建得是否合理？是否有存在從來沒有被使用過的索引（通過索引監(jiān)控工具來檢查）？
***一個(gè)檢查的項(xiàng)可能是和并發(fā)有關(guān)。假如用戶反映說系統(tǒng)有時(shí)會(huì)出現(xiàn)死鎖，這時(shí)，我們就要檢查一下導(dǎo)致死鎖的原因了，如捕獲相關(guān)的引起死鎖的SQL語句，分析是由于應(yīng)用的架構(gòu)設(shè)計(jì)所導(dǎo)致還是由于業(yè)務(wù)邏輯本身所導(dǎo)致。在DB這一級(jí)，我們可以檢查一下事務(wù)的隔離等級(jí)是否高置合理。
【編輯推薦】
