你在嘗試提升你的數(shù)據(jù)庫(kù)性能么？那么，這十個(gè)性能指標(biāo)你必須要了解。

在評(píng)估你的Oracle數(shù)據(jù)庫(kù)的KPI指標(biāo)之前，你需要驗(yàn)證你的設(shè)想是否正確。這一點(diǎn)是最重要的。否則，你會(huì)像一個(gè)無頭蒼蠅，永遠(yuǎn)都找不到提升數(shù)據(jù)庫(kù)性能的方法。因?yàn)槟愕脑O(shè)想本身就是錯(cuò)誤的。你需要時(shí)刻關(guān)注哪些假設(shè)是錯(cuò)誤的。這有有助于幫你了解Oracle是如何工作的，在哪些地方發(fā)生了改變。

如今，數(shù)據(jù)庫(kù)是應(yīng)用程序的靈魂。成千上萬的企業(yè)都在使用Oracle當(dāng)做本地?cái)?shù)據(jù)的核心，基于云和混合的架構(gòu)也是如此。從后臺(tái)應(yīng)用到日常商業(yè)數(shù)據(jù)統(tǒng)計(jì)，從戰(zhàn)略分析報(bào)告到預(yù)測(cè)，都能看見數(shù)據(jù)庫(kù)的身影。

隨著Oracle數(shù)據(jù)庫(kù)被大規(guī)模使用，你需要仔細(xì)監(jiān)控性能水平，看是否還需要資源來支持部署。大家都不希望為了防止數(shù)據(jù)庫(kù)的崩潰，而大量更改數(shù)據(jù)庫(kù)配置或增加大量的服務(wù)器。那么，就需要經(jīng)常留意整個(gè)數(shù)據(jù)庫(kù)的KPI指標(biāo)，找到它潛在的瓶頸和一些崩潰的跡象。

這里就來介紹一下我們需要知道的十個(gè)性能指標(biāo)。

分配不足的RAM區(qū)域

大多數(shù)情況下，你可以依靠Oracle推薦的自動(dòng)內(nèi)存管理流程。有時(shí)候，你可以通過增加RAM使磁盤訪問速度顯著提升。但如果你不分配足夠的內(nèi)存用于SHARED_POOL_SIZE，PGA_AGGREGATE_TARGET和DB_CACHE_SIZE，那么你的數(shù)據(jù)庫(kù)的物理I / O將會(huì)進(jìn)度緩慢。

內(nèi)存排序率

數(shù)據(jù)庫(kù)運(yùn)行緩慢是一個(gè)很讓大家困擾的問題。因?yàn)榇疟P排序必須在表空間，這遠(yuǎn)比在內(nèi)存中排序要慢得多。

執(zhí)行率分析

他們第一次執(zhí)行時(shí)，必須解析SQL。其中包括語(yǔ)法檢查，語(yǔ)義檢查，決策樹和執(zhí)行計(jì)劃，以便可以高效率的執(zhí)行。執(zhí)行計(jì)劃會(huì)儲(chǔ)存在緩存庫(kù)中，下一次執(zhí)行時(shí)會(huì)節(jié)省時(shí)間。解析包括硬解析和軟解析，你需要同時(shí)簡(jiǎn)化這兩個(gè)。硬解析是在運(yùn)行初始時(shí)將全部SQL進(jìn)行解析。軟解析只解析變量。為了更好的執(zhí)行解析比例，你需要增加session cache cursors（默認(rèn)為50）。在100至1000的值中找到最佳的性能。

多余的嵌套循環(huán)聯(lián)接

當(dāng)你對(duì)迭代循環(huán)緩慢束手無策的時(shí)候，你需要深入到代碼中找到更快的解決方案，而不是盡可能的使用嵌套循環(huán)聯(lián)接。若還是沒法解決，64位Oracle系統(tǒng)應(yīng)該更適合你，因?yàn)樗麄冇星д?字節(jié)的RAM排序和散列連接。要確保你有足夠的RAM來讓CBO通過設(shè)置PGA_AGGREGATE_TARGET參數(shù)選擇散列連接，使其周轉(zhuǎn)更快。

Page清除率

這個(gè)指標(biāo)對(duì)于在線出版商和電子商務(wù)網(wǎng)頁(yè)來說越來越重要。Page清除人員將舊的Page寫入disk asynchronously中，以便新的Page可以被讀入緩沖池。一個(gè)好的Page清除率是在95%左右。

緩沖池I / O的平均響應(yīng)時(shí)間

這時(shí)最終用戶最感興趣的一個(gè)東西。人們可以迅速的感覺到I / O響應(yīng)瓶頸并進(jìn)行抱怨。需要將緩沖池的平均讀/寫時(shí)間控制在10毫秒左右。

全表掃描

如果你看到全表掃描一致在持續(xù)進(jìn)行著，那一定發(fā)生了嚴(yán)重的錯(cuò)誤。網(wǎng)上交易和高容量操作都需要更高的工作效率。看看你的事務(wù)設(shè)計(jì)。搜索要命的索引和全面優(yōu)化的SQL。如果你的全表掃描帶回不到20％的表行，很可能有索引丟失。

事務(wù)日志響應(yīng)時(shí)間

付款延遲，這是一個(gè)嚴(yán)重的問題。記錄響應(yīng)時(shí)間會(huì)對(duì)延遲產(chǎn)生很大的影響。需要使日志響應(yīng)時(shí)間不超過10毫秒，就像緩沖池的I / O那樣。

行讀取/行選擇的比例

這可以節(jié)省你的研究時(shí)間。它會(huì)告訴你在返回指定行之前數(shù)據(jù)庫(kù)讀取了多少行。如果這個(gè)比例高于20，則可能是創(chuàng)建索引的問題。你需要詳細(xì)研究哪里的比例高于一般值。

人為錯(cuò)誤

你沒有看錯(cuò)，造成數(shù)據(jù)庫(kù)問題的最大可能其實(shí)來自數(shù)據(jù)庫(kù)管理者本身。例如，你可能忽略了監(jiān)控?cái)?shù)據(jù)庫(kù)的STATSPACK/ AWR。還可能，你忘了在OEM業(yè)績(jī)屏幕上設(shè)置自定義異常報(bào)告警報(bào)。一位智者曾經(jīng)說過，“Man is the measure of all things.”不要忘了自檢。