建站
咨詢
售后
建站咨詢
新聞中心
此文章主要向大家闡述的是DB2應用系統(tǒng)性能的優(yōu)化的實際操作方案的分享，大家都知道DB2數(shù)據(jù)庫是一種高性能的大型關(guān)系DB2管理系統(tǒng)，其廣泛的應用在客戶/服務器體系結(jié)構(gòu)中。評價系統(tǒng)性能優(yōu)化的標準有：
創(chuàng)新互聯(lián)是網(wǎng)站建設專家,致力于互聯(lián)網(wǎng)品牌建設與網(wǎng)絡營銷，專業(yè)領域包括成都網(wǎng)站設計、成都網(wǎng)站建設、電商網(wǎng)站制作開發(fā)、小程序開發(fā)、微信營銷、系統(tǒng)平臺開發(fā)，與其他網(wǎng)站設計及系統(tǒng)開發(fā)公司不同，我們的整合解決方案結(jié)合了恒基網(wǎng)絡品牌建設經(jīng)驗和互聯(lián)網(wǎng)整合營銷的理念，并將策略和執(zhí)行緊密結(jié)合，且不斷評估并優(yōu)化我們的方案，為客戶提供全方位的互聯(lián)網(wǎng)品牌整合方案！
吞吐量、響應時間、并行能力等。本文從數(shù)據(jù)庫的設計、查詢的優(yōu)化、并發(fā)控制以及客戶/服務器模式這四個角度來討論優(yōu)化系統(tǒng)性能。
設計數(shù)據(jù)庫
1.熟悉業(yè)務系統(tǒng)
對業(yè)務系統(tǒng)的熟悉程度對整個 DB2應用系統(tǒng)的性能有很大影響，一個對業(yè)務不熟悉的設計人員，盡管有豐富的數(shù)據(jù)庫知識，也很難設計出性能***的數(shù)據(jù)庫應用系統(tǒng)。
2.規(guī)范化與非規(guī)范化
數(shù)據(jù)庫被規(guī)范化后，減少了數(shù)據(jù)冗余，數(shù)據(jù)量變小，數(shù)據(jù)行變窄。這樣DB2的每一頁可以包括更多行，那么每一區(qū)里的數(shù)據(jù)量更多，從而加速表的掃描，改進了單個表的查詢性能。但是，當查詢涉及多個表的時候，需要用很多連接操作把信息從各個表中組合在一起，導致更高的CPU和I/O花銷。
那么，有很多時候需要在規(guī)范化和非規(guī)范化之間保持平衡，用適當?shù)娜哂嘈畔頊p少系統(tǒng)開銷，用空間代價來換取時間代價。有訂單信息表OrderDetail，它里面記錄了投遞員信息，收款員信息，物品信息，價格策略，客戶信息…..這些信息分別在投遞員信息表、收款員信息表、物品信息表、價格策略表、客戶信息表中存放。
如果按照規(guī)范化的要求，OrderDetail查詢時就必須要與這么多個表進行連接或者嵌套查詢。如果OrderDetail表中的數(shù)據(jù)量是在***的，那么一次查詢所需要的時間可能會達到好幾個小時。事實上，只要在設計時保證數(shù)據(jù)的邏輯有效性，很多信息都可以直接冗余在OrderDetail表中，這些冗余的數(shù)據(jù)能夠極大的提高查詢的效率，從而減少CPU和I/O操作。
3.數(shù)據(jù)條帶化
如果一個表的記錄條數(shù)超過一定的規(guī)模，那么最基本的查詢操作也會受到影響，需要將該表根據(jù)日期水平劃分,把最近、最經(jīng)常用的數(shù)據(jù)和歷史的、不經(jīng)常用的數(shù)據(jù)劃分開來，或是根據(jù)地理位置、部門等等進行劃分。還有一種劃分方式――垂直劃分，即把一個屬性列很多的表分割成好幾個小表，比如把經(jīng)常用到的屬性放在一個表里，不經(jīng)常用到的屬性放在另一個表里，這樣可以加快表的掃描，提高效率。
4.選擇數(shù)據(jù)類型
對每一屬性選擇什么樣的數(shù)據(jù)類型很大程度上依據(jù)表的要求，但是在不違背表要求的前提下，選擇適當?shù)臄?shù)據(jù)類型可以提高系統(tǒng)性能。比如有text列存放一本書的信息，用BLOB而不是character(1024)，BLOB存放的是指針或者文件參照變量，真正的文本信息可以放在數(shù)據(jù)庫之外，從而減少數(shù)據(jù)庫存儲空間，使得程序運行的速度提高。DB2提供了UDT（User Defined Datatypes）功能，用戶可以根據(jù)自己的需要定義自己的數(shù)據(jù)類型。
5. 選擇索引
索引是數(shù)據(jù)庫中重要的數(shù)據(jù)結(jié)構(gòu)，它的根本目的就是為了提高查詢效率?，F(xiàn)在大多數(shù)的數(shù)據(jù)庫產(chǎn)品都采用IBM***提出的ISAM索引結(jié)構(gòu)。使用索引可以快速、直接、有序的存取數(shù)據(jù)。索引的建立雖然加快了查詢，另一方面卻將低了數(shù)據(jù)更新的速度，因為新數(shù)據(jù)不僅要增加到表中，也要增加到索引中。另外，索引還需要額外的磁盤空間和維護開銷。因此，要合理使用索引：
在經(jīng)常進行連接，但是沒有指定為外鍵的屬性列上建立索引。
在頻繁進行排序或分組（即進行g(shù)roup by或order by操作）的列上建立索引。按索引來排序或分組，可以提高效率。
在條件表達式中經(jīng)常用到的不同值較多的列上建立檢索，在不同值少的列上不要建立索引。
如果待排序的列有多個，可以在這些列上建立復合索引（compound index），即索引由多個字段復合而成。
查詢優(yōu)化
現(xiàn)在的數(shù)據(jù)庫產(chǎn)品在 DB2應用系統(tǒng)查詢優(yōu)化方面已經(jīng)做得越來越好，但由于用戶提交的SQL語句是系統(tǒng)優(yōu)化的基礎，很難設想一個原本糟糕的查詢計劃經(jīng)過系統(tǒng)的優(yōu)化之后會變得高效，因此用戶所寫語句的優(yōu)劣至關(guān)重要。下面重點說明改善用戶查詢計劃的解決方案。
1.排序 LaG\u0014ERCx\u001F
在很多時候，應當簡化或避免對大型表進行重復的排序。當能夠利用索引自動以適當?shù)拇涡虍a(chǎn)生輸出時，可以避免排序的步驟，當以下的情況發(fā)生時，排序就不能省略：
索引中不包括一個或幾個待排序的列；
group by或order by子句中列的次序與索引的次序不一樣；
排序的列來自不同的表。
為了避免不必要的排序，就要正確地增建索引，合理地合并數(shù)據(jù)庫表，盡管有時可能影響表的規(guī)范化，但相對于效率的提高是值得的。如果排序不可避免，那么應當試圖簡化它，如縮小排序列的范圍等。
2.主鍵
主鍵用整型會極大的提高查詢效率，而字符型的比較開銷要比整型的比較開銷大很多，用字符型數(shù)據(jù)作主鍵會使數(shù)據(jù)插入、更新與查詢的效率降低。數(shù)據(jù)量小的時候這點降低可能不會被注意，可是當數(shù)據(jù)量大的時候，小的改進也能夠提高 DB2應用系統(tǒng)的響應速度。
3.嵌套查詢
在SQL語言中，一個查詢塊可以作為另一個查詢塊中謂詞的一個操作數(shù)。因此，SQL查詢可以層層嵌套。例如在一個大型分布式數(shù)據(jù)庫系統(tǒng)中，有訂單表Order、訂單信息表OrderDetail，如果需要兩表關(guān)聯(lián)查詢：
- SELECT
- FROM Order
- WHERE OrderNo
- ( SELECT OrderNo
- FROM OrderDetail
- WHERE Price=0.5)
在這個查詢中，找出報紙單價為0.5元的收訂員名單。下層查詢返回一組值給上層查詢，然后由上層查詢塊再根據(jù)下層塊提供的值繼續(xù)查詢。在這種嵌套查詢中，對上層查詢的每一個值OrderNo，下層查詢都要對表OrderDetail進行全部掃描，執(zhí)行效率顯然不會高。
在該查詢中，有2層嵌套，如果每層都查詢1000行，那么這個查詢就要查詢100萬行數(shù)據(jù)。在 DB2應用系統(tǒng)開銷中，對表Order的掃描占82％，對表OrderDetail的搜索占 16％。如果我們用連接來代替，即：
- SELECT CreateUser
- FROM Order,OrderDetail
- WHERE Order.OrderNo=OrderDetail.OrderNo AND Praice=0.5
那么對表Order的掃描占74％，對表OrderDetail的搜索占14％。
而且，一個列的標簽同時在主查詢和where子句中的查詢中出現(xiàn)，那么很可能當主查詢中的列值改變之后，子查詢必須重新查詢一次。查詢嵌套層次越多，效率越低，因此應當盡量避免子查詢。如果子查詢不可避免，那么要在子查詢中過濾掉盡可能多的行。
4.通配符
在SQL語句中，LIKE關(guān)鍵字支持通配符匹配，但這種匹配特別耗費時間。例如：SELECT * FROM Order WHERE CreateUser LIKE ‘M_ _ _’ 。即使在CreateUser字段上建立了索引，在這種情況下也還是采用順序掃描的方式，Order表中有1000條記錄，就需要比較1000次。如果把語句改為SELECT * FROM Order WHERE CreateUser >’M’ AND CreateUser <’N’，在執(zhí)行查詢時就會利用索引來查詢，顯然會大大提高速度。
5.distinct
使用distinct是為了保證在結(jié)果集中不出現(xiàn)重復值，但是distinct會產(chǎn)生一張工作表，并進行排序來刪除重復記錄，這會大大增加查詢和I/O的操作次數(shù)。因此應當避免使用distinct關(guān)鍵字。
6.負邏輯
負邏輯如!=、<>、not in等，都會導致DB2用表掃描來完成查詢。當表較大時，會嚴重影響系統(tǒng)性能，可以用別的操作來代替。
7.臨時表
使用臨時表時數(shù)據(jù)庫會在磁盤中建立相應的數(shù)據(jù)結(jié)構(gòu)，因為內(nèi)存的訪問速度遠遠大于外部存儲器的訪問速度，在復雜查詢中使用臨時表時，中間結(jié)果會被導入到臨時表中，這種磁盤操作會大大降低查詢效率。另外，在分布式系統(tǒng)中，臨時表的使用還會帶來多個查詢進程之間的同步問題。所以，在進行復雜查詢時***不要使用臨時表。
8.存儲過程
DB2中的Stored Procedure Builder可以產(chǎn)生存儲過程，運行并測試存儲過程。存儲過程可以包含巨大而復雜的查詢或SQL操作，經(jīng)過編譯后存儲在DB2數(shù)據(jù)庫中。用戶在多次使用同樣的SQL操作時，可以先把這些SQL操作做成存儲過程，在需要用到的地方直接引用其名字進行調(diào)用。
存儲過程在***次執(zhí)行時建立優(yōu)化的查詢方案，DB2 將查詢方案保存在高速緩存里，以后調(diào)用運行時可以直接從高速緩存執(zhí)行，省去了優(yōu)化和編譯的階段，節(jié)省了執(zhí)行時間，從而提高效率和系統(tǒng)利用率。
***的查詢方案按照某些標準選擇往往不可行，要根據(jù)實際的要求和具體情況，通過比較進行選擇。DB2提供的Query Patroller可以對不同的查詢方案的查詢代價進行比較，通過追蹤查詢語句，返回查詢不同階段的 DB2應用系統(tǒng)開銷，從而作出***選擇。DB2提供的 Performance Monitor也對整個數(shù)據(jù)庫系統(tǒng)的性能進行監(jiān)控，包括I/O時間、查詢次數(shù)、排序時間、同步讀寫時間等等。
數(shù)據(jù)庫系統(tǒng)的并發(fā)控制也能影響系統(tǒng)性能。多個用戶的同時操作可能導致數(shù)據(jù)的不一致性，DB2為了防止同時修改造成數(shù)據(jù)丟失和訪問未被提交的數(shù)據(jù)，以及數(shù)據(jù)的保護讀，采用Lock機制來實現(xiàn)控制。
DB2中可以對表空間、表、表列和索引加鎖。鎖的粒度越大，鎖越簡單，開銷小，并發(fā)度低；粒度小，鎖機制復雜，開銷大，并發(fā)度高。大型系統(tǒng)在并發(fā)處理中如果遇到所要分配的資源處于鎖定狀態(tài)， DB2應用系統(tǒng)會把進程掛起等待。
如果一個很耗時的查詢操作工作于一個經(jīng)常使用的表上，此時使用表一級鎖，意味著整個系統(tǒng)都要等待你的查詢結(jié)束以后才能夠繼續(xù)運行。所以在復雜查詢中，盡量避免使用表一級鎖。如果有這一類的需要該怎么辦呢？可以利用視圖來解決這一類問題。視圖避免了對表的直接操作，同時有能夠保證數(shù)據(jù)庫的高效運轉(zhuǎn)。
網(wǎng)站名稱：優(yōu)化DB2應用系統(tǒng)性能的方案有哪些？
網(wǎng)頁鏈接：http://www.dlmjj.cn/article/djhgocd.html
