性能問題應該從系統設計時期開始考慮，并延續到系統的生命期終止之時。
具有可伸縮性的系統是指當系統的負載增加一倍，系統需要的資源也同樣增加一倍。說起來簡單，但在現實環境中確難以做到。由于管理并發用戶的開銷的增長、鎖事務的增長、一致性讀負載的增加、操作系統負載的增加、低效的SQL或索引設計導致的過高的I/O等等因素，會導致系統資源的消耗的增長遠大于一倍。
破壞可伸縮性的因素：
1.低效的應用程序設計、實施和配置
2.硬件部分的規模不合適
3.軟件部分的限制
4.硬件部分的限制
系統的結構可分為硬件和軟件兩部分：
硬件部分包括：CPU、內存、I/O子系統和網絡模塊。
軟件部分包括：管理用戶接口、實現商業邏輯、管理用戶請求和資源分配、管理數據和事務。
在設計系統時，應該考慮以下幾個問題：
系統將支持多少用戶？
用戶的交互方式是什么？
用戶所處的位置？
網絡的速度怎樣？
用戶將訪問多少數據？有多少數據是只讀訪問？
用戶對響應時間的要求？
用戶是否需要24小時服務？
是否所有的修改需要實時完成？
應用程序設計原則：
設計簡單性原則：
1.如果表的設計復雜到沒有人能夠完全的理解，那么表的設計可能是比較差的。
2.如果SQL語句過長以致于優化程序無法優化該語句，那么SQL語句的設計、事務和表的設計一定存在問題。
3.如果表的相同列上被重復索引，那么索引的設計可能是有問題的。
4.如果提交的查詢沒有限定，以致無法迅速的將結果返回給在線用戶，那么用戶接口或事務的設計是有問題的。
5.如果數據庫的調用被許多層軟件從應用邏輯中抽象出來，那么，軟件開發的方法可能存在問題。
數據建模：應當注意，不要在非核心數據單元上花費過多的時間。
表和索引的設計：選擇合適的列進行索引、選擇索引類型、注意索引的代價、關注索引中列的順序。
一個表上如果有3個索引，那么當進行INSERT/UPDATE/DELETE操作時，會比不帶索引的表慢大約10倍。
組合索引中，選擇性高的列在前查詢時需要的I/O更少。選擇性低的列在前，有助于代排序操作的查詢。
SQL執行效率：
數據庫連接管理：應避免沒有必要的過多連接。
數據庫游標管理：使用cursor和綁定變量，盡量避免硬分析，較少軟分析。
硬分析：sql語句第一次提交，并在共享池中無法找到。
軟分析：sql語句第一次提交，但是可以在共享池中找到相同的語句。
實施新的應用程序：
切換方式包括兩種：Big Bang Approach（所有用戶一次性轉移到新的系統上）和Trickle Approach（用戶分多次轉移到新的系統上）。
性能清單列表：
1.設置MAXINSTANCES, MAXDATAFILES，MAXLOGFILES，MAXLOGMEMBERS和 MAXLOGHISTORY的值高于預期值。避免系統的增長導致必須重建控制文件。
2.設置BLOCK SIZE和優化模式與開發環境中相同。如果測試環境中的所有SQL語句的執行計劃都是正確的，可以測試環境中的統計信息導入到正式庫中。
3.盡量少修改初始化參數。除了SGA的組成部分和歸檔目錄的設置，其他初始化參數盡量保持默認值，可以為以后性能優化留下一定的余地。
4.通過設置數據庫對象的存儲參數來管理BLOCK的爭用。
5.所有的sql語句應該被優化。
6.驗證中間層軟件和程序采用高效的方式連接數據庫。
7.驗證sql語句有效的利用游標。
8.確認所有方案的對象從開發環境移植到了產品數據庫中。
9.一旦完成系統的切換，建立數據庫和操作系統統計信息的基線。
10.發現最先出現的瓶頸。
|
