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