一些可以預見的Oracle應用程式效能調優 （2）

藏寶圖

在Oracle效能調優級上，藏寶圖就是v$sqlarea檢視。如果我是一個IT管理者，我將會記住這個檢視的名字。並且，每當我在大廳遇見我的資料庫管理員時，我都會問他們這周他們查詢這個檢視的次數。

Metalink 註釋 235146.1給出了對這個檢視進行查詢的一些樣例。例如：

select sql_text, executions, buffer_gets, disk_reads, rows_processed,

sorts, address, first_load_time, HASH_VALUE, module

from v$sqlarea

where executions > 0

order by reads_per desc

最近，越來越多的Oracle 9i版本加入了模組（MODULE）這個列，該列揭示了Oracle應用程式的模組名稱。

統計包

在很多大型企業中，統計包的使用仍然被忽視。這可能是帶有脅迫性的報導。不要犯試圖僅僅讀取輸出結果，就能獲取所有資訊的錯誤，即使是第一頁就足以告訴你這份報導中剩下的你應該重視的10％在哪兒。Oracle 9.2版本的統計包，現在包含CPU和消耗時間列。以前，為了將長時間執行的SQL語句排序到最頂端，我們不得不開啟“追蹤”，連線追蹤檔案，並將它們交付程式tkprof來處理。對於那些一個簡單的“追蹤”就要處理多達10GB資料的大型企業而言，這是不現實的。

讓使用者參與到效能調優中去

將這條建議（即，讓使用者參與到效能調優中去）寫入書中的人應該因其創造性而得到讚譽。讓你的使用者也參與到效能診斷中去。購買一臺Oracle應用程式評測個人電腦，並把它給使用者使用。不要使用與個人電腦類似的配置好的筆記本，因為在同樣規範的情況下，筆記本沒有個人電腦的同樣效能特性。配置清單如下：

* 750 MB CPU

* 256 MB 記憶體

* Windows 2000 企業版（第四版）

* 使用獨立的邏輯磁碟

* Jinitiator－鎖定版

* 標準軟體，例如Office 2003

供評測用的個人電腦不需要以下配置：

* 牆紙

* 螢幕截圖

* 工具條

* 常駐程式

將評測用個人電腦送上使用者的桌面，帶著效能問題。將使用者的電腦接入區域網，讓使用者工作一段時間。然後，再將使用者的電腦放進計算機房間，並把它接入中間層，讓使用者在它上面進行更多的工作。評測用個人電腦消除了使用者方對Oracle應用程式效能的主觀性，同時也消除了面對使用者抱怨效能問題你們的主觀性。

索引計數和效能

回到70年代，開發者指南基本上說不要在一個表上建立4到5個索引。今天，開發者指南上的註釋如下：

Oracle不限制在一個表上建立索引的個數。儘管如此，你需要考慮索引所帶來的效能改善，以及你的資料庫應用程式的實際需要，從而決定需要對哪些列建立索引。

事實是：每個Oracle應用程式表可能包含30多個索引。如果我們加入一個索引能將經常需要的SQL語句的輸入輸出減少，我們會不考慮高索引計數的問題而加入這個索引。

CPU

減小併發管理池的寬度，至今我們還沒發現這會阻塞任務的進行。我們經常會看到的情景是：減小併發管理池的寬度實際上增加了批處理任務的吞吐量，它也使CPU不那麼忙碌。有許多包含對等程式的任務必須被完成。如果一個任務的池寬度過窄，所需的任務可能永遠也得不到處理，從而阻塞整體任務。

我們和Oracle應用程式安裝小組、培訓者打過交道，他們喜歡增加併發管理池的寬度，而無視對CPU的影響，這種設定一直保持到產品釋出時仍然存在。在訓練和測試環境中，安全問題的大門是開著的，並且安裝者增加併發管理池的寬度以期望他們的批處理任務可以儘早完成。他們這樣做或許根本沒有考慮到對CPU的影響，CPU可能會因此而被完全佔用。

CPU執行佇列不應該比你的CPU計數的兩倍還深。如果CPU在一天中被經常性完全佔用，就必須放棄某些設定。尋找這個需要被放棄的設定的第一位置就應該是併發管理池。

結論:

Oracle日常維護和效能調優,不是單純的技術,指定科學嚴謹的管理維護計劃更重要,一定要將調優,維護過程中的所有為難題記錄,形成文件,在知識經驗上得到積累,不至於同樣的錯誤犯兩次;

記錄執行日誌,什麼時候系統效能差,速度慢;然後分析找出原因,指定解決的辦法;

調優分兩部分:

一.應用層,包括邏輯資料庫結構,資料庫操作,訪問路徑（SQL）,記憶體分配等.優化的方法有,分解大表,修改關鍵表結構,分析應用層的sql語句,優化,使之達到最優執行;配置引數,恰當地分配記憶體;定期分析,重建索引,移動表,消除碎片;

二.系統層,包括輸入輸出和物理資料庫結構,資源競爭,底層作業系統平臺等;根據系統應用的規模,選擇恰當的檔案系統,這樣可以達到減少io操作的次數;作業系統是支撐大規模的吞吐量,window是微內河,linux/unix是單核心,造成了在系統內程式間通訊的速度和操作效能的差異等.

根據需求->指定運維計劃->分析執行日誌->更該執行計劃->分析執行日誌....這樣一個反覆的過程。