介紹
這篇文章討論了一些優化商業套裝軟件的機會。負責可接受應用性能的應用管理團隊成員可能是這篇文章討論受益最多的。這篇文章中主要集中在數據庫調優,所以數據庫管理員(DBA)和開發者可能發現這篇文章很有價值。我們將討論與這些產品和所考慮策略相關的基本調優問題,還有可能幫助你進行成功調優的技術建議。
首先,我們將指出套裝應用軟件在企業中發揮越來越重要的作用,和因此對信息技術組織意味著什么。我們這時將分析特有的調優挑戰,這些挑戰是由這些產品體現出來的,在后面我們將簡單地看看供應商提供的解決方案。下一部分回顧常見的性能提高策略,依次跟著最佳調優這些產品的建議。
套裝應用軟件的增長
多年以來,商業上已經開始使用套裝應用軟件自動化他們的業務流程。早期介紹的套裝應用軟件通常是從財務和金融應用開始,然后到庫存管理和制造業。到了90年代中期,一些供應商像SAP和Baan快速發展。對于這些軟件供應商,真正的轉折點是千年蟲問題的到來。許多公司,擔心他們內部開發的應用失敗,選擇購買有保證的解決方案,而不是試圖重寫已有的應用系統。緊接著,ERP市場爆炸性地出現了不可計數的服務和附加產品。
結果,定制業務應用系統的開發急劇萎縮。加上經濟的低迷,應用開發人員的作用減少了,在一些情況下,重點轉移到外包和離岸解決方案。在這些外力的作用下,2003年美國程序員出現最高的失業率就一點也不奇怪了,因此人們不再創建新的應用,而更傾向于像傳統那樣維護現有的應用。
近幾年的經濟低迷不僅打擊了程序員勞動力,對供應商也有一定的打擊,使其不能呈強勁的增長趨勢。但是像SAP這樣的供應商還是有一定的增幅,而且Microsoft Great Plains和Navision的購買給中小企業創造了效益。比起90年代和2000年初期,市場還是比較低迷的。然而,可以預見,盡管市場低迷,我們將看到ERP市場仍有大體上6%的增長。特別地這個激發因素是渴望滿足靈活的調整需求,并且購買這些有適應能力的產品變成了流行的作法。盡管有一定的增長,客戶應該仍然謹慎。根據調查,50%損失慘重的IT失敗是跟商業的ERP失敗有關的。
外包和避免定制開發的相結合慢慢形成一個新的有趣現象。在這種情況下,業務應用的外包像CRM或者由應用供應商套裝應用軟件集已經慢慢地增長。
商業應用的常見問題
對于IT部門,實施重要的商業應用這個行為是一個非常關鍵的事情。
通常,實施企業ERP或者CRM應用是昂貴的。它的花銷不僅區限于套裝應用軟件license,還包括購買附帶硬件,進行系統升級和人力成本等。
在這種情況下,人力成本指的是給咨詢人員的錢,你必須依靠這些咨詢人員才能成功部署應用。根據AMR的研究,75%的ERP市場開銷或利潤是跟編程和咨詢服務有關的。由于實現應用所需要的知識,這些錢通常投資給部門外的咨詢人員。
你所購買軟件的公司可能有一個咨詢隊伍,他們很樂意幫助你實施具體業務的改變,風險是他們的產品是寫給通常的商業團體,而且你的業務需求可能有改變。這對于技術分類來說可能是相當有問題的觀點。
通常,你有兩個選擇。你或者試圖改變應用適合業務的需要,或者繼續使用已購買的應用而不管業務是否滿足。后者聽起來不是很順耳,但對于供應商來說這個肯定是它們喜歡的選項,并且不斷被很多公司采納。對于一些領域,公司的運作已經非常規范(例如財務系統),一些必要的變化可能是很小。如果你的公司由于運作方式具有獨特的優勢,那將面臨更多挑戰。
你決定迎接這些挑戰嗎?你必須回到一些定制的應用上來。不總是不一樣,Gartner集團的研究發現大部分的ERP實施的20%是定制功能的。定制伴隨著一些挑戰和風險。你必須首先確定特定的供應商對客戶化的態度。供應商將為應用的一些領域提供比較少的支持,因為一旦代碼修改了他們就不能控制代碼了。在一些情況中,這可能明確地禁止。
這篇文章的重點是調優應用的性能,你應該注意到,轉移到套裝應用軟件并沒有減小你對應用的控制。首先,你不能 "擁有"供應商創建的代碼。第二,你可能不能訪問用于定制的源代碼。第三,通常不贊成改變系統,即使是為了調優。然而,基于前面三點的假設,這篇文章的后面將幫助你找到克服這些挑戰的方式。
供應商工具
在管理應用的時候必須有輔助工具。大部分供應商給你提供了可能用來管理應用環境的各種各樣工具。
通常地,這些工具主要集中于基本的管理。對于所有的應用,用戶管理,參數設置和類似的功能都是一樣的。越成熟的產品能使你更好地理解增強應用能力的組件,但很少強調性能調優(你可能需要第三方供應商)。
這個行業歷史最老的供應商SAP提供了一個最昂貴的工具集。SAP提供了數據庫管理,SQL Studio,DB Loader等其它工具。
Oracle有一系列基本的企業管理功能(OEM)工具,并且很樂意以Management Pack(也有其它的管理包)的這種形式賣這些工具給你。
PeopleSoft有一套完整的以Peopletools為形式的定制和管理工具,用于幫助你開發,部署,維護和升級系統。
Siebel有一個最簡單并且數量最少的管理工具。像其它提到的大部分工具一樣,使用Server Manager管理應用。
典型的性能策略
一般人們認為對于改善套裝應用軟件的性能幾乎無事可作,這觀點是錯誤的。通常地,這種假設導致了部門不能從問題的根源出發解決問題。
客戶首先趨向于尋找硬件升級的方式提高應用的性能。通常對于客戶來說,在供應商或相關的咨詢人員的強烈建議下,配置更大的和/或更快的硬件。最強大的計算平臺經常是基于快速增長或使用假設購買的。網絡硬件升級到最新的路由器和網橋,購買更新更快的存儲設備。當應用第一次投入生產時,它運行良好。在早期這段時間中,應用響應可能處于最佳狀態,數據裝載是輕量級的,并且應用的所有表現都沒問題。由于處理能力,通信能力和訪問速度不可思議的強大,任何真正的問題可能是看不出來的。
只要系統運行良好,可能就沒必要強調性能了。然而,隨著時間的流逝,系統開始發現變化,這時你將可能會想到調優。最后,你可能看是否還能升級硬件。在這種情況下,你可能手工調整操作系統或與應用組件相關網絡層的配置。大部分的供應商在他們的文檔里面都提供了建議性的設置,但它們不是必須的,并且不被看作技術支持或維護協議的一部分。
如果情況沒有改善,下一階段將調優應用組件本身。然而,這并不意味著實際的應用代碼,而是調整用于Web服務器,單獨緩沖機制,應用服務器,數據庫服務器或者存儲系統的相關參數。這種多層的結合非常復雜,確定它的問題來源不太容易。
當我們關注數據庫時,你的數據庫中有太多的方面可以調整。只在Oracle中,你就有好幾百個參數可以利用,并且有很多數據用于檢查確定究竟是什么引起了性能問題。就像其它組件一樣,這種參數的調整也是一個復雜且綜合的問題。
調優數據庫實例的值幾乎在你的控制中,雖然你的應用供應商可能提一些建議,并且在這些地方可能有一些要求。除了有權利用這些變量,另一個優點是它們沒有相關的明確成本。對于特定挑戰條件,當這個是真的時候,你可能需要求助于咨詢專家,你只能尋求他們的建議了。在這個層面上,確實有一些真正獨特的應用?赡艿脑,你的部門有一些預算給你或專家調優。你可能缺少深度的知識用于這些不同的層,或者沒有足夠的預算用于尋求外部的幫助,市場上肯定有一些工具和知識幫助你優化特定實例。
數據存儲跟數據庫是緊緊綁定在一起的。在這個層次上,你會留下數據庫參數的安全限制,并且致力于物理層的低層次處理。在這一點上,你需要一個安全和被檢驗了的方法優化你的存儲系統而不中斷應用流程。存儲是遠離數據庫直接控制的一個步驟。通常不容易發現數據庫和在這些存儲設備上數據段之間的關系,并且你可能再次需要一些特定的工具。
你可能遇到的最大問題來自異構組件。例如,你的Oracle數據庫服務器可能是Solaris box,而Apache Web服務器在Linux上。在它們之間,可能是運行在AIX上的WebSphere應用服務器。把它們所有的參數捆綁在一起(并且可能還有它們所有單獨工具)是一種挑戰。
打包應用實現的分析
在某種程度上,我們已經談了一些關于標準套裝應用軟件。我們也討論了這些應用的客戶化,但是理解應用比理解基本應用和客戶化更重要。其它的應用組件也影響數據庫性能。
首先是供應商的基本代碼。我們或多或少已經談了一些。稍后的文章中我們將討論,在不改變代碼的情況下,如何改變數據庫實例中的性能。
在討論的第二部分中我們將繼續探討定制。定制指的是為了打包應用能夠滿足組織特有的需求,而采取的一些調整,這當中有一些特別的挑戰。
討論的第三部分將集成已存在的業務系統。在應用性能調優的上下文中,我們看到一些特有的和有意思的挑戰。
在一些自動化的業務應用中,還有各種各樣的輔助工具一起工作,保證業務的成功執行。最常見的輔助功能是企業報表解決方案。它們提供很大的價值,但也能給數據庫性能帶來了至關重要的挑戰。
關注的最后一個區域是應用升級和升級對于業務意味著什么。典型的需求經常和可用性,意義相關聯,"我們得把系統停多長時間進行升級?"我們將討論用于調優的機會最小化停機時間
在這些所有區域中,首先所有這些討論的改變和其中的任何一部分在測試環境中都應該是穩定的。知道調優決不是一個單獨的事件是很重要的。當壓力和用例模式改變時,你調優的值也將改變。為了看到這些值是如何改變,對壓力模擬進行試驗將是明智的。
基本的應用
正如前面提到的,當改善基本"開箱即用"的套裝應用軟件性能時,既有挑戰也有機會。我們討論了硬件升級的方法和常見的底層系統層的調優,像硬件/OS和網絡本身。在這段里,我們將提出由DBA進行調優工作。
沿著系統層相同的方式,通過數據庫實例的調優可能影響性能?隙ǖ氖,數據庫大師級人物將能夠檢查數據庫的日志,并且查明性能問題。一個有經驗的DBA能夠指定通常與改變參數和設置有關的解決方案?赡艿脑,你的底層數據庫將允許你這么干,不用停止系統。我們打算確保解決方案比問題本身好。
如果你的員工沒有這種調優專家的能力,你可以選擇咨詢顧問或者有優勢的工具,幫助你提高性能。這些工具能夠產生智能報表。
如果你從事這種參數類型調優,表明你按規則實踐了。正如前面討論的,在線交易處理性能的改善和提高可能不如批處理那么明顯。另外,你的性能處理概圖將在每星期,每月,每季度和每年都改變?紤]這些時間很重要。在各種壓力概圖期間回顧你的性能調優將使你能夠及時選擇最合適你的解決方案。你應該有專業工具,你的參數調優可以是動態的,藉以你能修改任意你原來的設置計劃。
一旦你已經做了基本組件能做的所有調優,你不可避免地會對特有的應用代碼進行調優,這意味著底層表的形式邏輯設計和相關索引(和每個查詢本身)都已優化。
例如表和索引,它們有一些選項你可以做別的調整;蛟S您的整體應用概況是這樣, 附加的索引也許改進數據存取性能。你能迅速創造新索引來支持一次特殊查詢,但理解它們帶來的危險是很重要的。索引的創建和維護是需要成本的。在一個有大量變動數據(一些插入和刪除)的表中,維護那些索引的代價往往會大于某些個別SQL語句的性能改善。
強烈推薦你在確定優化索引策略時,考慮范圍更寬的SQL語句。當然,這說起來容易,實施起來是復雜的。對于一個大型的應用,可能真的很難理解源代碼和已存在結構的所有查詢。這時你應該如何做呢?
對于這樣的過程,SQL調優工具可能是你最佳的選擇。如果你能夠使用工具把你所關注的SQL集盡可能關聯起來,那么你就能很快地找到正確的解決方案了。
你應該選擇那些SQL用來評估呢?肯定是從你的應用源程序中選擇。你怎么確定評估哪個SQL語句呢,那是一個挑戰?我們建議你按以下步驟進行:捕獲在預定采樣時間中運行的SQL語句。典型的一天采樣時間應該體現出使用最通常和最頻繁的應用程序的用戶的使用情況。如果你的應用是利用綁定變量(在Oracle中)寫的,那么工具所捕獲到最經常使用的值對你很有幫助。在典型的一天采樣時間或一個星期采樣時間中,你很可能涉及到一些重要的批處理。務必確定捕獲這些活動,并且理解這些操作和可能與這些批處理運行相關限制的時間周期。
搜集完SQL后,你可能發現需要關注的語句很多。這時,考慮每一種語句的單獨目標很重要。對于OLTP環境,你可能打算考慮查詢的頻繁程度,因為有很多的用戶可能使用它。對于批處理環境,要考慮的是任務完成的時間長短或資源消耗的多少。
這時,刪除索引存在一些問題。你可能發現你的應用不太需要特定的索引。這可能是一個要解決的難題,如同這可能會代表對產品的原始計劃表的變動。正如前面提到的,首先要確定你的供應商。這里存在一些原因,某些索引可能不再需要,你也不必管理它們。但是可能還有一些索引是用來支持一些模塊的查詢,而你并沒有購買這些模塊。即使你以后計劃購買這些模塊,你也肯定能在實施之前創建這些索引。
這里有一些情況,在套裝應用軟件代碼中寫的查詢本身需要改善。對于一些數據庫,基本上需要重寫代碼。如果你的數據庫是Oracle,還有點希望。"Outline"特征使你能夠改變一些SQL的執行計劃,而不必要重寫SQL本身。。通常,一個查詢將送達數據庫,并且如果相關的執行計劃沒有在緩存中,這時優化器將會創建一個執行計劃。對于套裝應用軟件,我們對改善不能變更的源代碼比計劃穩定性更感興趣 。你能夠創建執行計劃的大綱,這個計劃比原始地編寫查詢語句優先級高。
文章來源于領測軟件測試網 http://www.kjueaiud.com/