本週剛好遇到近2個月來的週休，今天下午剛好跟同學約在咖啡廳討論一些論文的東西，結束之後我就一個人留下來複習週五上課的內容，上午的課程都在講一些比較觀念性的東西，其實有幾個點老師講的不錯，下午就在介紹效能分析的工具跟實作，我就來寫寫我週五的心得好了。
影響DB效能的主要因素為何(依影響程序排列):
1,AP程式
2.DB規劃
3.效能調整
4.T-sql
5.硬體問題
其實原因很簡單，就是用什麼樣的程式與方式去存取資料庫，而資料庫的規劃是否符合使用需求並搭配正確的索引以方便程式進行查詢與使用。所以AP程式與DB規劃一般來說是影響資料庫效能的最大原因。
DB的問題:
一般來說DB的問題通常都會在資料成長後才會浮現，如果是剛上線的系統就產生問題，通常是一開始就低估了系統負載或是有錯誤的程式與不正確的資料庫規劃所產生。
這部分我覺得老師說的很好，他還提出了應用程式開發流程的觀念讓我們了解，並把效能調較分出三個階段:
1. 應用程式初期開發階段:
2. 應用程式布署期間
3. 應用程式布署後發生效能問題時
其中階段一就是在開發初期，程式與DB的規劃都在這一期要完成，同時也仍有較大的空間可以去進行調查與修改；階段二最重要的就是壓力測試了，給予AP與DB足夠的壓力進行測試才可驗證整套系統的可靠性，同時也可確定相關硬體也能夠負荷；階段三通常都已經無解了，只能透過T-SQL的語法來進行微調。
效能問題的界定:
1. 基準線
2. 調整成本
3. 最佳化
所謂的基準線就是在DB運作最穩定時的情況，利用各種工具去監控並記錄產生基準線；調整成本就是用最低成本將DB效能調整至接近基準線，最佳化則是完成調整後再進行監控並重新建立基準線，一部DB主機可能會一直在這這樣的循環不斷進行。
結合以上的觀念就是我們週五上課的核心吧，透過這樣的觀念，後面老師就開始介紹如何建立基準線，並模擬CPU、MEMORY與DISK等異常的情況，為什麼會去介紹這幾個看起來是硬體異常的情況呢?因為在AP程式或DB規劃有問題時通常都會發生這幾個東西的異常狀況。舉個例來說好了，如果像在部內的地方發展基金這樣常需要跑大量報表的系統(OLTP)，如果它的SQL開啟平行執行序這樣的功能(同時用多顆CPU去處理單一工作)，當這個報表很大，CPU沒辦法很快的處理完成，那麼CPU QUEUE LENGTH值就會越來越高，其他的USER的工作就沒辦法處理，很容易就會產生TIME OUT的現象，那麼就會發生很多抱怨與怒氣到我們身上了，解決方式呢? 關閉平行處理，用單顆或是半數的CPU去處理這樣工作，那麼要看處理時間END USER是否可以接受；用獨立的主機去處理這樣的工作，那麼就需要花費較多的硬體成本，不過在用以上兩個方式時都必須再去檢視這樣工作相關的TSQL語法與問題，有時有可能是BLOCK或DEADLOCK造成的問題。
又寫了一堆，其實還有不少工具的使用與介紹，不過這部分就不好寫了，也許有一天我有機會在實際環境用上這樣的工具我再來寫吧，但是一天的課程真的不夠講解整個資料庫的東西，很多東西還得再去學習，這又是件不容易的事了，以後再看看有沒有機會去學的更深入點了。
留言列表
