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

前言

我們見到過很多帶有巨大效能問題的Oracle應用程式和電子商務套件安裝。我們得出的結論是：這些安裝都可以在效能方面取得進一步的提升。換句話說，效能已經很高，幾乎不能得到再得到改善的安裝是很少見的。

有爭議的問題

針對產品系統堆疊而言，我們的底部端對端效能調優方法總是很快產生成果，比我們認為的遵循廣泛的備忘列表要快。我提出以下一些問題共討論：

大部分效能改善的可能性都是在應用程式級上：這條結論來自Metalink上關於效能調優的一個顯著的註釋。這條結論和我們的經驗效能調優系統堆疊沒有統計意義上的關係。

平均需要兩天的時間：這是書上做出的結論。但我們的經驗不支援這個結論。我認為得出一個Oracle應用程式效能改善的策略最少應該需要12天。第一天早晨開會是很常見的事。最後兩天主要用來完成行政方面和技術級上的有關發現、勝利和緊接著的推薦的文件工作。可以誇張地說，如果一個效能改善不被記錄下來形成文件，那麼以後很難再重複類似的效能改善。如果對出現的問題不記錄下來形成文件，那麼很可能它會再次發生。如果一個問題及其解決方法不被記錄下來形成文件的話，對它的監測將非常困難。

擴充套件碎片：對於聯機事務處理系統，這應該不是一個問題。我們聽過很多有關“聯機事務處理系統”對碎片嚴重的表（這些表完全是鍵值惟一的）進行事務處理不會影響效能的說法。但是，我們應該經常性地重組以消除碎片，這會帶來效能上的巨大改善。Oracle儲存管理改善正在向將碎片帶來的影響最小化大踏步地邁進。

由於緩衝輸入輸出不是大問題，所以需要對磁碟輸入輸出進行效能調優：這裡有兩點需要說明。磁碟輸入輸出的實際開銷並不是記憶體緩衝輸入輸出的一萬倍。真實的比值接近70。即使你的CPU似乎正在抵銷這個代價，並且不帶來任何顯著的效能問題，但是這個問題顯然會限制你的系統的可伸縮性。隨著時間的流逝，我們越來越重視過高的記憶體緩衝輸入輸出，同時找尋效能改善的機會。

OATablespace模型和遷移工具集：已釋出的Metalink註釋（10/03）聲稱“這個新模型帶來了實時效能改善。”這個模型的概念是將100多個Oracle應用程式表空間合併成一個以10計數的表空間。這會帶來潛在的儲存空間節省麼？或許。這會帶來更高的操作效率麼？它依賴於其他東西。我們還沒有講解這個工具集。但是我們已經理解了在白板級上的表空間合併是如何改善效能的。

對你的個人電腦客戶端進行磁碟碎片整理：在這本書中有關這個問題的討論很多。這或許是正確的，因為在寫作本書時正流行“胖客戶端”。但是現在，Oracle應用程式客戶端是一個“瘦客戶端”（從Oracle廢除Jinitiator開始，我們稱瀏覽器為瘦客戶端），不要期待能從對你的個人電腦客戶端硬碟驅動器進行磁碟碎片整理中得到效能提升。

載入模組補丁：這是Oracle技術支援對於效能問題經常給出的對策，其實在很多情況下，它並不合適。原因是打補丁經常會帶來不穩定性。如果對於補丁的依賴性沒有給予充分考慮，你可能會發現你不得不載入整個補丁包，而你根本就沒打算載入它們，結果就是對你係統的堆疊穩定性產生了影響。

專案管理

專案管理是很關鍵的。Oracle應用程式效能實施即是技術上的也是行政上的。某個人必須出來做掌舵者，即專案管理者。必須按功能區分出不同的優先次序。如果有可能，可以按照以下方式：商業單位先計算他們選拔人才的時間延遲帶來的財政開支，然後乘上使用者的數量及其每分鐘的收入。獲得應用程式效能改善的開銷之一就是要記錄文件。同時，也需要記錄大量的紙質文件。使用者的慾望必須被管理起來，因為並不是所有的區域都會產生同樣戲劇性的結果。必須有一個管理者來劃分不同的優先次序，有些時候甚至需要對效能團隊的訪問進行過濾。一方面，使用者會頻繁地提出會導致底層效能問題的主意和要求。另一方面，和使用者進行互動可能會妨礙你的工作進度。成功也會導致暴露下一層效能問題的出現。

什麼是使用者不能告訴你的

針對某個使用者的從底向上的方法揭示了一個單獨的包消耗的輸入輸出資源佔全部的25％左右。對另一個使用者而言，一個單獨的查詢可能會引起每週4.3TB的緩衝輸入輸出。效能調優使得緩衝開銷降至原先的0.06％。問題是它會耗盡CPU資源，同時，在那種情況下，是否對CPU進行擴充還需慎重考慮。沒有人知道系統堆疊正在抵銷這個代價。

關於效能調優保守最嚴密的一個祕密在Oracle效能調優指南中被發現的。作為一個團隊，我們發現這個祕密已經多年了。對於beta級或產品系統的效能問題，你應該從系統的最底層堆疊開始診斷。不幸的是，效能診斷經常僅僅集中在系統堆疊中間的四個部分。它們是：

* 邏輯資料庫結構

* 資料庫操作

* 訪問路徑（SQL）

* 記憶體分配

但是，我們經常可以在Oracle底層的幾個級別上發現很大的效能問題，如下所示：

* 輸入輸出和物理資料庫結構

* 資源競爭

* 底層作業系統平臺