系統架構時考慮效能要素

*******伺服器硬體上的考慮

新增新的CPU,擴充套件系統記憶體或者新增更多的磁碟會得到有效的效能增強,但只能在短時間內起到作用,當應用資料量持續上漲,工作量負荷不斷升高時,又會面臨同樣的效能問題。不好的資料庫設計，不恰當的SQL都會讓硬體投入顯的無力。

*******系統可擴充套件性設計

可擴充套件性是指系統能夠處理更多有效工作載荷的能力。一般包括如下幾個方面：

1:儲存系統未以最佳I/O配置策略進行生產實施，造成了低效率。

2:記憶體管理中由於使用者大量申請記憶體導致整體伺服器過度的記憶體交換。

3:糟糕的事務設計造成了鎖等待和序列化事務問題。

4:不良的資料庫設計造成執行代價昂貴的SQL;

5:不良的SQL和不恰當的索引設計導致應用系統I/O總量上的巨大開銷。

6:不良的SQL和不恰當的索引設計導致資料庫內部維護的巨大開銷。

7:應用在生產環境中SQL實際執行計劃與預計SQL執行計劃嚴重偏離。

對系統可擴充套件性具有影響的諸要素：

1:SQL應用程式碼問題(中介軟體效率問題，資料庫效率問題)

2:I/O裝置衝突(儲存子系統效率)

3:記憶體分配問題(頁面交換問題)

4:資源衝突問題(資源等待問題)

5:網路瓶頸(網路衝突,網路穩定性)

***********系統結構設計中的最佳化要素

大多數應用可以拆分成三個組成部分:

1:使用者介面(UI):使用者介面表現，用於使用者資料輸入，業務邏輯呼叫等操作。該部分包括：(1)定義簡潔有效的工作介面。(2)定義簡單明快的介面操作流程

2:中介軟體業務邏輯：實現業務流程和業務目標的過程化計算，進行資料庫訪問，生成使用者介面等。

3:資料庫業務邏輯：實現業務流程和業務目標的資料庫計算部分，如把資料儲存到Oracle表中，根據條件修改資料等。

結構方案設計需要不斷跌代重複考慮如下問題：

問題一：系統目前和未來將支援的使用者數。

這裡不考慮少量使用者數訪問的情況。如果是大量使用者的訪問模式，例如internet 訪問情況下的資料庫訪問，由於任何人無法預計使用者數，必須依賴某種緩衝機制來防止伺服器資源的耗盡。例如可以用負載均衡的方式來降低伺服器壓力(構建RAC，構建Stream或DataGuard同步複製系統)，使用中介軟體方式將使用者訪問分層(構建WebLogic叢集)。

問題二：使用者訪問的資料量和動態資料量分佈

使用者資料訪問量的大小以及資料的動態程度將直接影響到資料庫的邏輯設計方式(cdm)和物理實施方法(pdm)。表的設計，索引的設定將是直接受影響的元素。通常在資料庫實體設計時，採用表的垂直分割技術和表的資料分割槽技術來進行針對資料量要素的遮蔽。

[@more@]