對DB2數(shù)據(jù)庫性能上的錯誤理解有哪些？

作者：佚名 2010-09-06 08:52:25

在實際操作中DB2數(shù)據(jù)庫設(shè)計中其物理設(shè)計應(yīng)該與邏輯結(jié)構(gòu)竟可能的相近，主要是為DB2數(shù)據(jù)庫性能做出的物理設(shè)計改變不能被忽略，因為它們并不來自于邏輯設(shè)計。

以下的文章主要向大家描述的是DB2數(shù)據(jù)庫設(shè)計中其物理設(shè)計應(yīng)該與邏輯結(jié)構(gòu)的原因，其中主要原因包括DB2缺省就是好的，不要在SQL WHERE謂詞里使用否定，以及依靠EXPLAIN來決定是否訪問路徑是好的內(nèi)容描述。

DB2缺省就是好的

實際：缺省的一般不是***的，他們因版本不同而改變。比如考慮綁定參數(shù)CURRENTDATA。

不要在SQL WHERE謂詞里使用否定

實際：另外一個這種規(guī)則并沒有被解釋清楚。只有謂詞是一個否定時，SQL訪問路徑可能使用一個不必要的表空間掃描。但是在其它的多數(shù)情況下，多余的過濾應(yīng)該在DB2引擎里完成，這會較好。

我可以只依靠EXPLAIN來決定是否訪問路徑是好的

實際：EXPLAIN不顯示執(zhí)行的查詢塊的順序，不會告訴你1或者2階段的謂詞，不會告訴你一個塊會多長時間執(zhí)行一次。基本的，EXPLAIN只是導(dǎo)出一些數(shù)據(jù)到一個表里，然后結(jié)合其他一些信息來進行更多的一些解釋。有一些工具來幫助處理此過程(如Visual Explain)，但是如果所有的事實都沒有被考慮的話，這樣的方式只會帶來壞處。

不要做EDM池太大以避免其分頁

實際：EDM池通常通過分頁來提升DB2性能(這里分頁是指擴展存儲，而不是磁盤)而不是變得更小并且因為頁面置換和其他因素持續(xù)重建內(nèi)部結(jié)構(gòu)。

擴展不會關(guān)系其他任何東西

實際：什么時候開始的?未來如果世界上充滿了SAN或者ESS，那差不多。擴展的影響已經(jīng)因為新的磁盤緩存控制器而變得很小了，但是仍然有一些額外的檢查和處理需要來管理它們。

關(guān)系的劃分不會在DB2中使用

實際：關(guān)系的劃分已經(jīng)在過去的許多系統(tǒng)中被使用了，可以有效的通過數(shù)據(jù)庫設(shè)計者和程序開發(fā)者來實現(xiàn)。在目前的商業(yè)智能(BI)和市場系統(tǒng)中，它可以被數(shù)次用在每個單個程序中。

將所有的包綁定到兩個計劃中：一個批處理和一個在線的

實際：在介紹DB2包的時候，這是一個不好的陳述。有許多理由可以說這個理解是錯誤的。

未授權(quán)的讀是不好的

實際：未授權(quán)的讀并不是一個四字單詞但是是一個非常好的DB2數(shù)據(jù)庫性能增強，可以被用在比經(jīng)常理解的更多的地方。

在沒有超時和死鎖的情況下不會有鎖問題

實際：事實上沒有一個問題發(fā)生并不意味著沒有需要關(guān)注的的性能問題。經(jīng)常鎖定不被認(rèn)為是一個問題，因為注意力主要放在反應(yīng)的調(diào)節(jié)測量(統(tǒng)計死鎖或者超時的數(shù)量)，而不是后發(fā)式的調(diào)節(jié)(監(jiān)控鎖等待時間)。

ESA數(shù)據(jù)壓縮總是好的

實際：當(dāng)壓縮能被在很多地方起作用時，有一些情況它能帶來問題。每種情況都要在壓縮使用前決定是否使用它。這不是可選的，而是必須要在高層決定是否使用還是不使用。