Oracle提供一些基本的大綱管理，但你必須首先確定SQL的最佳"重寫"計劃。有經驗的SQL調優人員能夠為你做這些工作。你愿意使這個過程自動化嗎？市場上有一些工具能幫助你轉換SQL，并且提供易用的大綱管理能力。
在所有的例子中，應該理解你有權改善套裝應用軟件基本代碼的性能。你只需確保你選擇的方式沒有危及你的應用及供應商的立場。
客戶化
客戶化是供應商提供全套功能的最佳嘗試。你的公司購買的套裝應用軟件可能沒有足夠的業務專業知識，但能自動化地進行業務處理。靈活地適合你業務的特有需求是很重要的。
前面已經討論了一些客戶化的分支：供應商不提供產品支持，客戶化需要形成文檔，也需要維護這些改變和在改變過程中的投資，使得通過升級保持改變能順利進行。對于一些公司，根據Gartner，通�？蛻艋膬r格是實施套裝應用軟件的20％以上。
你著手進行客戶化過程時是怎樣影響你改善應用性能的能力？選擇有很多，可以是你自己內部進行這些一般改變的團隊，或者是供應商提供的工具，或者雇傭專門的咨詢人員。
供應商通常是一個"服務"公司，就像應用軟件開發商那樣。如果這些定制的源代碼是供應商自己的雇員做的，那么你的擔心就會少點。
然而，當咨詢人員走了，并且過了一段時間之后它們的工作并沒達到想象中的那樣，那么你可能還是跟以前一樣，好像處理原始的源代碼。
簡單地理解客戶化中哪些部分是你優化的，哪些不是，這項任務可能是一個挑戰。我們無法注重那些是重要的或者同你的供應商一起工作以了解這些分界線解。
讓我們假設你處理的是你自己的代碼。無論是內部人員或者外面的咨詢人員編寫代碼，這都無關緊要。你制定客戶化的需求規范，支付相關的開發費用，，所以你的責任就是確保它能按照你的標準工作。
這個過程應該是任何一個開發項目都有的。時間、工具和資源應該都是工程計劃中的預算。從設計到交付，都必須考慮到性能影響。
代碼整合
套裝應用軟件很少單獨運行。通常地，它必須與其它商業套裝應用軟件或者已有的應用系統通信。這就意味著它們將是一些集成的形式，與應用數據庫交互。這能通過各種各樣的方法實現，并且所選的方法將影響到系統的性能。
你將怎樣把這些不同的應用連接在一起呢？你能夠選擇企業應用集成（EAI）和面向服務架構（Service Oriented Architecture）。最后的選擇當然是自己完全創建一個了。
對于EAI解決方案，你要做的大部分是不同的客戶化代碼。盡管EAI供應商花費了巨大的努力，對于它們真的沒有辦法預測應用間交互的復雜性。對于外部整合，唯一真正可能的是應用安裝了不同的解決方法，而完全沒有客戶化。這種情況很少，但我們應該假設將花費相當多時間和成本用于把這些應用綁定在一起。
正如客戶化的例子，實施路徑能夠從內部團隊或咨詢人員來進行。所有關心的和涉及的調優問題都在這里。而特別有意思的挑戰是你可能處理兩個或更多的不同供應商。它應該及時注意到，這些供應商經�；ハ喔偁�，并且通常不會融洽地相處。如果事情還不夠有意思，考慮你還要把EAI供應商的咨詢顧問包括進來。在所有的情況中，團隊管理者和供應商的關系是關鍵。對于大部分情況來說，我們必須繼續強調性能管理仍然是個人的挑戰。應用整合的影響最能支持這種論點。
如果它方的團隊不太好管理，那么轉向你自己的團隊。比較常見的情況是需要整喝套裝應用軟件和內部已有應用程序。當你的SAP和PeopleSoft應用有很完善的文擋，內部開發應用的文擋卻殘缺不全。在這個混合中，你可能有一個比較好的機會，跟內部的人一起工作。
既然你要負責性能影響，嚴格的和受過訓練的實施團隊很關鍵。建立性能基準指標，并且確保你的團隊理解它們的重要性。這個建議對于內部和外部的整合團隊都適用。
對于性能，理解調優目標很關鍵。最關鍵的問題是確定交互的種類。編碼和用于日常事務數據上傳的性能優化目標明顯是批處理工作的類型。獲得整個結果集和移動它是關鍵。另一邊，如果你需要實時更新不同的系統，你可能打算在每個事務發生時繼續工作。兩階段提交是否有順序？通常老的系統沒有新系統的底層硬件能力強大。在這些情況中，你應該清楚地知道哪種性能問題跟哪種平臺相關。對于早期信息系統的應用，給數據集編寫查詢可能不合適，這些數據集可能是在內存中發現的，而早期應用系統是在存儲速度緩慢的設備中發現的。
調優性能是你的權力，所以堅持正確的方法交付系統給相關團體。
報表
從性能的角度出發，商業智能（BI）和報表解決方案是你應用架構具有挑戰的一部分。
這些工具的特點是它們體現了一些非常強大的方式，用于捕獲有意義的關系和信息。不幸的是，捕獲這些有意義的關系的過程對于你的應用性能可能是致命的。
通常地，人們將使用從BI供應商獲得的工具連接目標數據庫，并且搜索所需的信息。我們需要理解的是報表產生過程大部分由手工完成，獨立于所需的數據庫種類。換句話說，不可能有那么多的優化用于各種數據庫。
另一個挑戰是捕獲表的過程，這個表是報表工具用戶需要查詢的。因為一些套裝應用軟件有大量的復雜表，在查詢過程中用戶需要等待非常長時間。
現在，如果每個人只是簡單地運行數據倉庫或數據中心，那么沒什么難的，這些數據倉庫或數據中心間接地跟你的主要應用綁定在一起。不幸的是，通常不是這種情況，繁忙的執行請求訪問大部分最新的數據。而且，我們看到組織作為應用性能挑戰知道它本身。盡管你負責維護應用性能，如果執行請求實時訪問這些數據，這時你必須響應它的請求。很有可能，這些隨機點擊只能引起很短的業務中斷，而會獲得重要的返回結果。
這種特別的報表情況幾乎不可能調優，但它們能夠控制。有工具能夠捕獲和最小化這些影響，但這可能終止查詢或延遲查詢。對它的性能改善微乎其微。
有可能通過計劃任務和命令行重復運行報表。要這么做，我們將訪問報表里的代碼。一些供應商會允許你查看它們的報表，并且自己可以手工修改。在這些實例中，你或你的團隊可能需要一定的技巧、工具和時間來做這項工作。
你不能直接改變那些查詢嗎？如果在Oracle運行，想想那些與大綱一起工作的工具的使用。前面已經討論了大綱的工作情況和優勢。
當使用報表和BI解決方案，考慮它們存儲報表和可修改查詢的能力。如果不是這樣的話，看看Oracle數據庫的大綱。
版本升級
除了主要套裝應用軟件的初始化，幾乎沒什么事主要組件的升級如此有影響。你的組織越依賴應用，對業務影響的改變越重要。而升級不總是在你的控制范圍之內。
作為一個很好的藉口，供應商可能需要你作一定的升級用于保護里面的數據。也可能因為供應商希望節省技術支持和維護成本。不管什么情況，你公司之外的人決定你將需要做的一些重要的改變。
這意味著你需要做很多事。其中的一些可能是好的，它非�？赡芤馕吨罅客顿Y于你的IT小組。它體現在時間花費、高昂的咨詢成本和它可能意味著業務過程的中斷，而這些業務過程是你一直在努力進行改善的。
這篇文章之前討論的每個地方可能是緊密的。最大的挑戰是業務的發展變化和應用的客戶化，對升級中的下一步沒有多少負面影響。強烈推薦你推行一個正確的策略，涉及過程，培訓和合適的工具投資。
除了評估需要用于預先調優改變和可能使它們前進，你可能再一次重復整個過程。理想的情況是，你所有的調優問題將通過新的升級解決，但這是不可能的。在實施之前，你應該試圖復制軟件新版本的環境。正確的數據負載和模擬使用，你應該能很好地工作。在這一點上，你可以優先初始化調優活動，也可以在升級后再做。
還必須討論的一個地方是升級過程的實際性能。當供應商在升級腳本和程序中執行中，它們沒有與客戶反饋和QA相關的類似環境。所以，你也不必驚奇，改善升級腳本的性能還大有余地。
這些腳本必須從系統的一個版本轉移你的表和數據到新的版本中。那取決于數據量和應用的復雜性，它們可能運行非常長的時間。如果你是幸運的，那么這個"長時間"可能意味著一個周末。如果你倒霉，意味著你的業務可能在一個星期中有一些地方不可用。使得員工無事可做，并且業務一個星期都不能運行顯然非常糟糕。
我們將假設你已經訪問這些腳本，也有可用于正確調優它們的技巧或工具。我們建議你在測試之前和之后考慮，確認你的結果仍然跟調優前和調優后保持一致。另外，我們將再一次強調，它仍然是關鍵：和你的供應商一起確認主題。按照我們的經驗，我們知道有些人認為這個想法很好而有些人卻不以為然。
結論和建議
我們希望你看完這篇文章后，你能主動地優化你的套裝應用軟件。如果主動地并不斷地在應用的整個生命周期中進行調優，那任何一個IT組織都將獲益。
實施商業套裝應用軟件也有不同的開發生命周期。首先，你必須設計適合已存在業務計算環境的產品。接下來，你將可能創建一些客戶化應用，它們必須經過測試和實施。你也將同時開始與現有應用的整合。以相似的方式繼續維護內部應用。當問題或機會出現時，你只需把它們拆下來就行。
升級套裝應用軟件是特別好的機會，去掉不好的，創建更完善的。很明顯，這個不同于內部應用。仍然，還有一些潛在的因素會對性能調優成功有影響。
正如通常情況，你需要理解調優的目標。知道達到性能目標的正確方式。使你的組織確信調優是必須的，用于調優的預算也是適當的，計劃相應的時間、調優專家和工具來保證目標的達成。
通常應同你的供應商一起工作，理解限制和機會。它們是你實施成功的應用和調優的主要合作伙伴。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
