這篇技巧性文章是由
國際Oracle用戶組
（IOUG）提供的
它是一個由用戶組成的組織
這個組織通過提供高質量的信息
培訓
網絡和支持
來提高Oracle數據庫專家和數據庫開發者的水平
這篇文章摘自由David Welch所寫的論文《可預見的Oracle應用程序性能調優》
點擊這裡成為
國際Oracle用戶組
的一員
從而獲得成千上萬的由Oracle用戶寫的技巧性文章和科技文獻
引言
我們見到過很多帶有巨大性能問題的Oracle應用程序和電子商務套件安裝我們得出的結論是這些安裝都可以在性能方面取得進一步的提升換句話說性能已經很高幾乎不能得到再得到改善的安裝是很少見的
有爭議的問題
針對產品系統堆棧而言我們的底部端對端性能調優方法總是很快產生成果比我們認為的遵循廣泛的備忘列表要快我提出以下一些問題共討論
大部分性能改善的可能性都是在應用程序級上這條結論來自Metalink上關於性能調優的一個顯著的注釋這條結論和我們的經驗性能調優系統堆棧沒有統計意義上的關系
平均需要兩天的時間這是書上做出的結論但我們的經驗不支持這個結論我認為得出一個Oracle應用程序性能改善的策略最少應該需要天第一天早晨開會是很常見的事最後兩天主要用來完成行政方面和技術級上的有關發現勝利和緊接著的推薦的文檔工作可以誇張地說如果一個性能改善不被記錄下來形成文檔那麼以後很難再重復類似的性能改善如果對出現的問題不記錄下來形成文檔那麼很可能它會再次發生如果一個問題及其解決方法不被記錄下來形成文檔的話對它的監測將非常困難
擴展碎片對於聯機事務處理系統這應該不是一個問題我們聽過很多有關聯機事務處理系統對碎片嚴重的表（這些表完全是鍵值惟一的）進行事務處理不會影響性能的說法但是我們應該經常性地重組以消除碎片這會帶來性能上的巨大改善Oracle存儲管理改善正在向將碎片帶來的影響最小化大踏步地邁進
由於緩沖輸入輸出不是大問題所以需要對磁盤輸入輸出進行性能調優這裡有兩點需要說明磁盤輸入輸出的實際開銷並不是內存緩沖輸入輸出的一萬倍真實的比值接近即使你的CPU似乎正在抵銷這個代價並且不帶來任何顯著的性能問題但是這個問題顯然會限制你的系統的可伸縮性隨著時間的流逝我們越來越重視過高的內存緩沖輸入輸出同時找尋性能改善的機會
OATablespace模型和遷移工具集已發布的Metalink注釋（/）聲稱這個新模型帶來了實時性能改善這個模型的概念是將多個Oracle應用程序表空間合並成一個以計數的表空間這會帶來潛在的存儲空間節省麼？或許這會帶來更高的操作效率麼？它依賴於其他東西我們還沒有講解這個工具集但是我們已經理解了在白板級上的表空間合並是如何改善性能的
對你的個人電腦客戶端進行磁盤碎片整理在這本書中有關這個問題的討論很多這或許是正確的因為在寫作本書時正流行胖客戶端但是現在Oracle應用程序客戶端是一個瘦客戶端（從Oracle廢除Jinitiator開始我們稱浏覽器為瘦客戶端）不要期待能從對你的個人電腦客戶端硬盤驅動器進行磁盤碎片整理中得到性能提升
載入模塊補丁這是Oracle技術支持對於性能問題經常給出的對策其實在很多情況下它並不合適原因是打補丁經常會帶來不穩定性如果對於補丁的依賴性沒有給予充分考慮你可能會發現你不得不載入整個補丁包而你根本就沒打算載入它們結果就是對你系統的堆棧穩定性產生了影響
項目管理
項目管理是很關鍵的Oracle應用程序性能實施即是技術上的也是行政上的某個人必須出來做掌舵者即項目管理者必須按功能區分出不同的優先次序如果有可能可以按照以下方式商業單位先計算他們選拔人才的時間延遲帶來的財政開支然後乘上用戶的數量及其每分鐘的收入獲得應用程序性能改善的開銷之一就是要記錄文檔同時也需要記錄大量的紙質文檔用戶的欲望必須被管理起來因為並不是所有的區域都會產生同樣戲劇性的結果必須有一個管理者來劃分不同的優先次序有些時候甚至需要對性能團隊的訪問進行過濾一方面用戶會頻繁地提出會導致底層性能問題的主意和要求另一方面和用戶進行交互可能會妨礙你的工作進度成功也會導致暴露下一層性能問題的出現
什麼是用戶不能告訴你的
針對某個用戶的從底向上的方法揭示了一個單獨的包消耗的輸入輸出資源占全部的％左右對另一個用戶而言一個單獨的查詢可能會引起每周TB的緩沖輸入輸出性能調優使得緩沖開銷降至原先的％問題是它會耗盡CPU資源同時在那種情況下是否對CPU進行擴充還需慎重考慮沒有人知道系統堆棧正在抵銷這個代價
關於性能調優保守最嚴密的一個秘密在Oracle性能調優指南中被發現的作為一個團隊我們發現這個秘密已經多年了對於beta級或產品系統的性能問題你應該從系統的最底層堆棧開始診斷不幸的是性能診斷經常僅僅集中在系統堆棧中間的四個部分它們是
* 邏輯數據庫結構
* 數據庫操作
* 訪問路徑（SQL）
* 內存分配
但是我們經常可以在Oracle底層的幾個級別上發現很大的性能問題如下所示
* 輸入輸出和物理數據庫結構
* 資源競爭
* 底層操作系統平台
藏寶圖
在Oracle性能調優級上藏寶圖就是v$sqlarea視圖如果我是一個IT管理者我將會記住這個視圖的名字並且每當我在大廳遇見我的數據庫管理員時我都會問他們這周他們查詢這個視圖的次數
Metalink 注釋 給出了對這個視圖進行查詢的一些樣例例如
select sql_text executions buffer_gets disk_reads rows_processed
sorts address first_load_time HASH_VALUE module
from v$sqlarea
where executions >
order by reads_per desc
最近越來越多的Oracle i版本加入了模塊（MODULE）這個列該列揭示了Oracle應用程序的模塊名稱
統計包
在很多大型企業中統計包的使用仍然被忽視這可能是帶有脅迫性的報道不要犯試圖僅僅讀取輸出結果就能獲取所有信息的錯誤即使是第一頁就足以告訴你這份報道中剩下的你應該重視的％在哪兒Oracle 版本的統計包現在包含CPU和消耗時間列以前為了將長時間運行的SQL語句排序到最頂端我們不得不開啟追蹤連接追蹤文件並將它們交付程序tkprof來處理對於那些一個簡單的追蹤就要處理多達GB數據的大型企業而言這是不現實的
讓用戶參與到性能調優中去
將這條建議（即讓用戶參與到性能調優中去）寫入書中的人應該因其創造性而得到贊譽讓你的用戶也參與到性能診斷中去購買一台Oracle應用程序評測個人電腦並把它給用戶使用不要使用與個人電腦類似的配置好的筆記本因為在同樣規范的情況下筆記本沒有個人電腦的同樣性能特性配置清單如下
* MB CPU
* MB 內存
* Windows 企業版（第四版）
* 使用獨立的邏輯磁盤
* Jinitiator－鎖定版
* 標准軟件例如Office
供評測用的個人電腦不需要以下配置
* 牆紙
* 屏幕截圖
* 工具條
* 常駐程序
將評測用個人電腦送上用戶的桌面帶著性能問題將用戶的電腦接入局域網讓用戶工作一段時間然後再將用戶的電腦放進計算機房間並把它接入中間層讓用戶在它上面進行更多的工作評測用個人電腦消除了用戶方對Oracle應用程序性能的主觀性同時也消除了面對用戶抱怨性能問題你們的主觀性
索引計數和性能
回到年代開發者指南基本上說不要在一個表上建立到個索引今天開發者指南上的注釋如下
Oracle不限制在一個表上建立索引的個數盡管如此你需要考慮索引所帶來的性能改善以及你的數據庫應用程序的實際需要從而決定需要對哪些列建立索引
事實是每個Oracle應用程序表可能包含多個索引如果我們加入一個索引能將經常需要的SQL語句的輸入輸出減少我們會不考慮高索引計數的問題而加入這個索引
CPU
減小並發管理池的寬度至今我們還沒發現這會阻塞任務的進行我們經常會看到的情景是減小並發管理池的寬度實際上增加了批處理任務的吞吐量它也使CPU不那麼忙碌有許多包含對等進程的任務必須被完成如果一個任務的池寬度過窄所需的任務可能永遠也得不到處理從而阻塞整體任務
我們和Oracle應用程序安裝小組培訓者打過交道他們喜歡增加並發管理池的寬度而無視對CPU的影響這種設置一直保持到產品發布時仍然存在在訓練和測試環境中安全問題的大門是開著的並且安裝者增加並發管理池的寬度以期望他們的批處理任務可以盡早完成他們這樣做或許根本沒有考慮到對CPU的影響CPU可能會因此而被完全占用
CPU運行隊列不應該比你的CPU計數的兩倍還深如果CPU在一天中被經常性完全占用就必須放棄某些設置尋找這個需要被放棄的設置的第一位置就應該是並發管理池
From:http://tw.wingwit.com/Article/program/Oracle/201311/18339.html
