昨天發文后有朋友問能否把文中所說的文章共享一下。雖然文章寫于2006年，快20年了，我想其中的某些觀點和案例可能對現在的您也還有些幫助。就發出來分享一下吧。文章有點長，6000多字，感興趣的可以先收藏一下慢慢看吧。

應用系統生命周期和Oracle數據庫優化

Oracle數據庫優化是Oracle管理工作中的最重要和最復雜的工作之一。由于數據庫不是孤立的數據庫，而是和一些應用具有緊密關系的，數據庫往往是應用系統中最關鍵的部分，因此數據庫的優化不能完全脫離應用而進行。實踐證明，數據庫管理維護人員與應用開發者的合作越好，數據庫的優化越成功。

另外，數據庫優化是從應用系統開始規劃到應用系統退役整個過程中都在不斷進行的，因此，數據庫優化是一個長期的工作。很多用戶會希望通過一次優化就達到一勞永逸的效果，而沒有樹立數據庫優化工作長期性的觀念，這樣往往會導致數據庫在長期的系統運行過程中沒有得到必要的維護，以至于一旦發生問題，將會造成很大的損失。

很多人認為數據庫優化是系統投入使用后DBA的主要工作，其實數據庫優化是一個貫穿于應用系統整個生命周期的長期工作，數據庫優化應該從需求調研和需求分析開始。從另一個方面講，數據庫優化也不僅僅是DBA的工作，而是需要全員參與的（業務人員、開發人員、DBA甚至項目和用戶的領導層）。

數據庫優化需要全員參與和貫穿整個開發過程，很多沒有應用開發經驗的DBA可能很難理解這一點，而這一點是數據庫優化工作中最關鍵的一點。比如說，具有豐富開發經驗的項目管理者都清楚，改變用戶的操作習慣是一種十分困難的事情，而在用戶沒有形成習慣之前灌輸一種操作方法要容易得多。因此在需求調研的時候說服用戶不要使用那些對數據庫開銷十分大的操作方式，可以大大減少用戶不適當操作而引起的對系統的開銷。在需求調研和分析階段要實現這一點，僅僅依靠應用開發人員是不夠的，這就要求DBA或者有數據庫優化經驗的開發者在這個階段就介入系統的開發工作，在必要的時候，甚至需要得到高層領導的支持。在軟件開發和應用的各個階段中，應該注意以下的問題：    

l在需求開發階段，數據庫優化的目的是說服業務人員接受對數據庫影響比較小的操作習慣，而放棄那些對數據庫性能有致命影響的操作習慣

l在系統應用架構設計階段，采用對數據庫優化比較有利的應用體系架構。采用2層還是三層架構，使用B/S方式還是C/S方式，采用瘦客戶端還是胖客戶端，客戶端和服務器之間數據交換的報文的格式和內容組織方式等都會影響數據庫訪問的性能

• 在系統邏輯設計階段，定義合理的數據結構和數據操作方式
• 在物理設計階段，設計合理的表和索引的物理存儲結構
• 在編碼階段，編寫效率比較高的SQL和PL/SQL
• 在系統測試階段，對于關鍵業務進行完整的壓力測試和系統性能評估，找出系統的瓶頸，盡快改進應用
• 在系統試運行階段，DBA實時監控數據庫的情況，及時發現數據庫存在的問題，及時進行調整。對于應用中存在的性能問題，及時發現，并及時通知開發人員改進，并對改進后的應用進行測試評估

l在系統運行階段：系統投入正式運行后，數據庫的優化工作還是十分艱巨的工作。DBA需要定期對數據庫進行分析，找出目前系統消耗資源最大的對象，并找出改進的方法，進行改進。DBA還需要定期進行行鏈消除、索引重建、表空間碎片整理、歷史數據備份整理和系統分析等工作    

需求開發階段的數據庫優化

需求開發分為客戶需求獲取、需求分析兩個階段，最終產品為軟件需求規格書（SRS）。在傳統的概念中，這個需求開發和數據庫優化是風馬牛不相及的事情，而這個階段往往是對系統性能優化最為關鍵的階段。在這個階段主要考慮的是軟件的功能需求，而這些需求中，可能存在一些對系統性能影響極大的需求。操作習慣、界面風格、統計方法等都會影響數據庫的性能。

以下是一個真實的案例，某個系統在顯示主菜單的時候，需要顯示一些復雜的實時統計分析結果，而這個統計分析結果只有很少數的人會真正關心，由于這個系統有幾百個用戶在使用，而主菜單是進入每個模塊的必經之路，因此系統運行一段時間后，就出現了CPU方面的瓶頸。為了解決這個問題，DBA想盡了一切方法對SQL進行優化，但是收效甚微。最后深圳九鼎云州新創科技有限公司的優化專家提出了一個方案，重新修改了主菜單的界面，缺省情況下不顯示實時統計結果，而只是提供一個顯示實時統計結果的鏈接。而對于需要每次顯示主菜單都顯示實時統計結果的用戶，只需要在自己的PROFILE中設置該選項就可以了。主菜單修改后，使用實時統計的用戶只有1％左右，CPU的瓶頸問題也就迎刃而解了。

上述這種優化如果在需求分析階段就能夠完成，那么可以避免很多問題，而事實上類似的故事在不停的重演。究其原因，主要是參與需求開發的人員往往是業務人員和軟件開發人員，這些人員缺乏數據庫優化的基本知識和經驗，無法從需求中發現隱含的性能問題。因此在需求開發階段，專業的數據庫優化人員的介入是十分重要的，具有數據庫優化經驗和軟件開發經驗的DBA可以在這個階段就及時發現對于性能影響較大的需求，并且尋求解決方案，引導客戶采用比較優化的操作模式。因此在需求開發階段，“需求性能分析服務”是十分關鍵的服務。    

需求性能分析服務是一種項目前期咨詢服務，在需求獲取階段或者需求設計階段，都可以使用。但是在不同的階段，對服務提供者的要求不同。能夠在需求獲取階段提供咨詢服務的服務提供者，需要既是Oracle的專家，又是應用開發的專家，同時還是業務方面的專家。對于在需求設計階段的咨詢服務提供者，在業務方面的要求略低。咨詢專家可以針對客戶需求，從數據庫性能的角度進行分析，對可能嚴重影響數據庫性能的需求，提出解決方案，甚至否決需求。咨詢專家的介入，會提高需求階段的工程質量，為整個工程的最終順利實施提供保障。

系統設計階段的數據庫優化   

系統設計階段包括系統架構設計、邏輯設計、物理設計等子階段。系統架構對于數據庫的性能影響也是十分巨大的，采用不同的系統架構，對后續的設計和應用開發都具有十分大的影響，不合理的系統架構甚至會造成項目的失敗。架構設計人員往往缺乏數據庫優化方面的經驗，他們設計架構的原則是根據業務和應用軟件開發來制定的，因此往往僅僅考慮了業務的拓展性以及應用開發的可控性，而過于靈活的應用架構可能會最終導致嚴重的性能問題，甚至導致項目失敗。

加拿大某公司的供應鏈管理系統是全球排名前10名的供應鏈管理系統，在中小型供應鏈管理系統中，十分具有競爭力。但是由于其架構方面的原因，在大型企業和超大型企業中，一直無法得到很好的應用，其主要原因是架構方面局限性，導致了在并發量較大的環境下，產生了嚴重的性能瓶頸。而這種性能瓶頸是無法調優的，除非重新構造整個系統。    

在邏輯設計階段，需要進行數據模型的邏輯建模。作為一個具有十分豐富的邏輯設計經驗的系統設計師來說，創建一套完美的符合第三范式的邏輯模型不是什么難事。但是從數據庫的性能角度來考慮，第三范式不一定是最佳的選擇，有時候為了避免性能問題，設計一定的冗余數據，也是十分必要的。不幸的是系統設計師往往都不具有足夠的數據庫優化經驗，因此在這個階段也存在形成性能瓶頸的風險。

在物理設計階段，需要對數據庫進行物理建模。物理建模是決定系統性能的關鍵，IO負載如何均衡、如何避免行鏈、如何避免表空間碎片、如何創建合理的索引，等等，都需要在這個階段設計完成。在這個階段需要經驗十分豐富的Oracle DBA和系統設計人員共同來完成。而事實上，在這個階段，往往缺乏有經驗的DBA參與，普通應用軟件開發商的DBA是無法勝任這項工作的。

由于系統設計階段對最終系統的性能影響如此巨大，因此在系統設計階段需要一種綜合性的咨詢服務，也就是我們常說的“系統模型優化服務”。

系統模型優化服務是一種綜合性的服務，服務提供商需要對應用體系架構、邏輯模型、物理模型進行綜合的分析，找出性能瓶頸，并根據系統要求，提出解決方案。為了更好地進行系統設計，系統模型優化服務應該貫穿系統設計的全過程，包括：

• 數據庫性能優化與系統設計培訓課程
• 應用系統架構設計評審    
• 應用系統邏輯模型評審
• 應用系統物理模型評審

軟件開發階段的數據庫優化  

如果在需求和設計階段避免了各種性能瓶頸，那么應用軟件開發階段的性能優化工作就會輕松很多。但是由于軟件開發階段涉及的人員較多，并且每個開發人員的能力有所不同，因此在這個階段也是容易造成性能問題擴散的主要階段。這個階段產生的性能問題往往是分散的，集中于某些不夠優化的SQL代碼。其修復的代價也低于前面兩個階段。在應用軟件開發階段，“應用開發性能優化套餐”可以幫助應用開發商避免性能問題，套餐內容包括：

• SQL與數據庫性能培訓課程
• PL/SQL性能優化培訓課程
• 專職DBA服務

專職DBA服務的主要內容是派遣專職的DBA參與開發，該DBA的主要任務是幫助開發人員分析SQL的性能并協助進行SQL優化。專職DBA的另外一個職能是對大型SQL進行審核，沒有通過審核的SQL必須在開發階段進行優化改造。有了專職DBA的參與，可以在開發階段減少大量的性能瓶頸。

系統測試階段的數據庫優化

如果在前面的各個階段，都已經對數據庫的性能進行了優化，那么系統測試階段是解決遺留系統性能問題的最佳階段，由于系統開發已經完成，因此集成測試和系統測試成為可能，很多在系統測試階段才可能暴露出來的性能問題可以得到充分的暴露，而且由于系統還沒有正式上線，因此系統調整和優化的代價也很小。    

在實際情況中，測試階段大家的主要精力都集中在解決軟件BUG方面，往往忽視了對系統性能和數據庫性能的測試。由于開發隊伍缺乏壓力測試的能力，因此壓力測試往往被省略了。這些省略的后果往往就是系統上線后產生嚴重的性能問題。在系統測試階段，“壓力測試服務”和“系統性能評估服務”是兩種十分重要的服務。

壓力測試服務是服務公司為客戶提供的專業的測試服務，可以根據客戶應用的特點，建立一套模擬的數據和模擬的業務運行環境，并在這個環境中獲得第一手的系統性能參數，找到隱藏的性能瓶頸。以便于客戶在上線前解決存在的性能隱患。

系統性能評估服務的目的是為客戶進行系統生命周期中的性能預估，可以根據目前的情況，估算幾年后系統運行的情況，以及可能出現的系統瓶頸。評估報告可以讓客戶做出系統是否能夠上線的決策。也可以使客戶在系統運行生命周期內進行系統升級和擴容的規劃。

某移動公司在開通彩鈴業務1年后，由于業務量發展十分迅速，導致系統性能出現嚴重的瓶頸，客戶投訴大幅度上升，甚至一度暫停新業務開戶，造成了重大的損失。因此，該移動公司在擴容彩鈴系統的時候，聘請了九鼎云州的咨詢人員，對系統進行性能評估，根據其業務發展的實際情況，對2年內系統各項指標進行估算，找出不達標的指標，要求供應商改進。在評估過程中，九鼎云州的咨詢人員發現了系統中存在的大量性能隱患，及時幫助供應商解決了性能問題，該系統上線后，完全達到了移動公司的設計要求，取得了良好的效果。    

系統運行階段的數據庫優化  

系統運行階段的數據庫優化是傳統意義上的數據庫優化范疇的工作。當系統正式上線后，系統的優化往往受到很多的限制，因此優化的手段也較前幾個階段少，優化的成本也大大增加。在系統運行階段，往往是由于缺乏嚴格的日常維護，因此很多系統性能隱患沒有及時發現，等到發現問題的時候，往往已經錯過了解決問題的最好時機，并且由于生產系統給問題解決的時間有限，往往造成解決問題的時間嚴重不足。

為了避免上述問題的出現，在系統運行階段，加強系統日常的監控和維護是十分必要的。在這個階段，大量的咨詢服務公司提供了豐富的服務項目，九鼎云州也在長期的數據庫維護工作中，和客戶一起，不斷完善服務的種類和內容，以滿足客戶日益增長的IT服務需求。以下是幾種特別貼近企業級用戶的服務。

現場和遠程在線護航服務：在系統繁忙的時段，咨詢人員在現場值守，協助解決問題。比如對于電信公司，在每個月月初的幾天，是出帳的繁忙期，在這幾天里，很容易出現一些突發性的性能問題，如果有專業DBA在現場支持，可以降低這幾天的業務風險。現場護航服務的價格較為昂貴，因此對于資金不是十分充裕的客戶來說，選擇遠程在線護航服務是一種變通的做法，其效果和現場護航服務類似，但是可以節約大量的費用。    

遠程離線護航服務：在線護航需要服務提供者能夠連到客戶的系統進行服務，由于種種原因（當然價格也是其中的因素之一），客戶無法使用在線服務，那么離線的遠程護航服務也是一種不錯的選擇。客戶可以把現場采集到的數據，通過電子郵件發給服務提供商，由服務提供商的技術人員對這些數據進行離線分析，對于系統存在的問題，提出合理的建議。離線分析數據一般包括Statspack報告、awr報告、addm報告、以及服務提供商提供的專用采集腳本采集的數據。數據分析的周期可以是每天、每周或者每月。

某大型電器制造企業售后服務再造系統是一個十分龐大的業務系統，平時在線使用的人數超過8000人，業務遍布全球。我們曾經為其提供了有效的離線護航服務，每天現場技術人員會生成上午和下午高峰期間的STATSPACK報告，通過電子郵件發送給咨詢顧問。咨詢顧問每天對這些報告進行分析，及時把建議反饋給現場技術人員。在此期間，州通過STATSPACK報告的分析，協助現場技術人員解決了大量的性能問題。有一次九鼎云州的技術人員從STATSPACK報告中的某些指標，發現系統中可能有索引損壞了，通知現場人員的進行時候，現場技術人員還沒有發現，只是發現今天某個業務模塊的投訴增加，經過確認，確實是一個索引損壞，導致了某個業務走全表掃描，業務產生了積壓。

數據庫監理服務：對數據庫建立一套日常監控、數據自動采集和故障報警體系。這種服務需要相關的軟件配合，僅僅依靠人工是較難實現的。通過適當的應用軟件，可以幫助客戶建立客戶化的監控平臺以及標準的監控體系，幫助客戶實現數據庫監控的簡單化、標準化和自動化。九鼎云州的數據庫綜合監控與優化服務套餐就是一種典型的數據庫監理服務。對于企業用戶來說，數據庫監理是一種規避風險的有效手段，通過對數據庫進行有效的監理，可以提高系統的無故障運行時間，確保系統性能的穩定。由于數據庫監理的復雜性，需要服務提供者具有較強的綜合服務能力，并且有較強的業務背景，因此能夠實施數據庫監理服務的服務提供商還十分少，這種服務在業界還少為人知。    

圖片

數據庫監理服務需要有一個強大的數據庫監控平臺作為支撐，作為數據庫監控平臺，應具有以下功能：

• 能夠集中管理分散的數據庫系統，做到集中、實時地監控并能夠在系統隱患發生前提供報警
• 具有獨特的高智能分析功能，可以使ORACLE數據庫發揮近乎極致的效率，并且是對于ORACLE數據庫的維護簡化為每天只需檢查生成的智能報告，查看是否有系統隱患產生。
• 如果有了系統隱患，可提供詳細的解決建議。
• 能夠完整保留歷史運行數據，以提供將來故障定位、歷史分析時所需的數據    

l在新業務上線時或系統優化時，可以作為優化、測試與調整的工具，幫助定位問題根源，提供容量使用情況，以作為決策的依據

通過數據庫監理的服務，可以向用戶提供一種預防性的監控管理方案：

• 通過集中管理、集中監控的手段實現分散數據庫的簡單、有效、自動化管理
• 通過自動化的評價報告確定系統現存問題和準確現狀
• 進而通過專業的分析，定位系統瓶頸，并采取針對解決措施
• 提供調優輔助，消除系統存在問題
• 確認調優措施的實施效果，繼而重新確定系統存在的新問題和狀態。

當問題被發現后，具有實施能力的服務提供商可以及時為客戶提供合理的解決方案，并協助客戶消除隱患，解決問題。通過以上過程的不斷反復循環，使系統的問題在萌芽狀態被發現并消除。使用戶每時每刻清晰的了解自己系統的運行狀況和存在的問題，并提示問題解決方案和系統運行管理建議。從而使用戶系統常年保持安全性和高效率的最佳平衡狀態。使用戶的設備投資獲得最大的經濟收益。

數據遷移和數據重組服務：無論是出于性能的考慮還是其他原因，對于生產系統進行數據遷移和重組都是十分困難的，特別是針對于海量數據庫的數據遷移和重組。目前這類服務主要由IBM/HP/SUN/EMC等設備供應商提供，而由于設備供應商不是專業的數據庫服務提供者，因此在數據遷移和重組過程中，沒有充分考慮到數據庫優化的需求，在進行數據遷移和重組的過程中喪失了一次極好的優化機會。如果數據庫咨詢服務提供商和設備供應商共同來完成數據遷移和重組工作，那么可以在數據遷移和重組過程中，針對系統存在的IO方面的問題進行一次優化，從而達到事半功倍的效果。    

某聯通公司的數據庫性能出現問題，IO出現嚴重瓶頸。在其進行存儲擴容的時候，我們和HP的工程師一起對擴容后的存儲進行了合理的規劃，并根據目前的性能瓶頸，制定了合理的二次條帶方案。數據遷移后，IO瓶頸得到了徹底解決，數據庫的性能提高了2倍以上。

結論