數(shù)據(jù)庫中的熱點問題

---

熱點是數(shù)據(jù)庫應用中常見的問題之一。在系統(tǒng)并發(fā)量比較小的時候，通常感覺不到它的存在，而當并發(fā)請求急劇增加的時候，響應時間被大大地拉長，極端情況系統(tǒng)掛起。

熱點可能在記錄上，可能在數(shù)據(jù)或索引頁面上，也可能在其它數(shù)據(jù)庫對象上，比如緩沖池、程序包，甚至到數(shù)據(jù)庫之下的操作系統(tǒng)層。常見的是前兩種。

典型的記錄熱點場景有：應用維護流水號，或者余額控制，相關(guān)信息保存在用戶表的記錄中，每次交易都作UPDATE操作。UPDATE會在記錄上加獨占鎖，會堵塞其它應用對同一條記錄的UPDATE操作，這個獨占鎖要等整個事務提交或回滾后才會釋放。假設這個事務執(zhí)行時間是10毫秒，那么這個系統(tǒng)能支撐的最大交易吞吐量是100筆/秒，更多的交易請求進來將處于等待狀態(tài)。

如何能夠知道系統(tǒng)存在這種熱點問題？ 如果做數(shù)據(jù)庫監(jiān)測的話，可關(guān)注并發(fā)應用數(shù)、應用等鎖次數(shù)和平均鎖等待時間，

如果等鎖次數(shù)及等待時間隨應用并發(fā)增加而增加的話，很有可能存在這種問題。

也有可能你的系統(tǒng)負載一直不高，看不到上述變化，又怎么能知道系統(tǒng)有這種風險？

在DB2中可用命令db2pd –db -tcbstats獲取表相關(guān)的操作信息，在“TCB Table Stats:”段內(nèi)容中有表上發(fā)生UPDATE的次數(shù)，用次數(shù)除以表的記錄數(shù)，可計算出平均每行記錄被更新的次數(shù)，如果某表上這個指標較高，意味著可能有熱點記錄問題。當然這個辦法不一定很準確，比如表中有很多條記錄，其中一條或幾條被更新的次數(shù)遠高于其它，便不能用這種方法識別出來，更準確的方法是捕捉到每一條SQL語句，分析UPDATE操作指向的記錄。 預先知道隱含問題，就可以改進系統(tǒng)，避免出現(xiàn)類似“雙十一”或“秒殺”活動對系統(tǒng)帶來的沖擊。

改進方法就是去除熱點或分散熱點。比如可用數(shù)據(jù)庫的SEQUENCE幫助產(chǎn)生流水號，數(shù)據(jù)庫的SEQUENCE可在內(nèi)存一次產(chǎn)生多個流水號，個數(shù)由CACHE指定，并發(fā)高的系統(tǒng)可加大CACHE；分散熱點是將一條記錄拆成多條記錄，根據(jù)傳入?yún)?shù)更新對應記錄。

除記錄熱點外，還有可能出現(xiàn)數(shù)據(jù)頁面或索引頁面熱點。比如多條記錄保存在同一個數(shù)據(jù)頁面，雖然并發(fā)應用更新的是不同記錄，但數(shù)據(jù)庫內(nèi)部在更新數(shù)據(jù)頁面內(nèi)容時會加LATCH以避免內(nèi)容錯亂，用一般的數(shù)據(jù)庫監(jiān)控可能不能發(fā)現(xiàn)此類問題，使用db2pd -latch有可能看到?jīng)_突。解決辦法是減少同一個數(shù)據(jù)頁面內(nèi)保存的記錄數(shù)，比如(ALTERTABLE myTable PCTFREE 90; REORG TABLE myTable)，重組之后每個頁面只用10%的空間保存記錄。當然你也可能有其它方法達到此目的。

索引頁面的熱點主要發(fā)生在索引字段內(nèi)容一直增加或減少的情況，比如時間戳或流水號上的索引，每次INSERT進來的記錄，其相關(guān)索引內(nèi)容都落在最后的索引頁面中，這在單服務器的數(shù)據(jù)庫中可能沒太大問題，但在集群環(huán)境中，這個熱點問題會被放大。DB2中有一種RANDOM INDEX可規(guī)避這個問題，比如：CREATEINDEX myIdx ON myTable (seqno RANDOM)；RANDOMINDEX是基于變換后的內(nèi)容構(gòu)建索引，因此它失去了原來的順序，避免了索引頁面熱點，但只適合“=”條件查詢，BETWEEN及“>”之類查詢條件不能從這種索引中得到原來的好處。

如果能在設計開發(fā)階段就考慮到些熱點問題，避開它，就更好了。

如果您碰到其它一些熱點問題，也可以拿出來跟大家分享一下。

慧都控件網(wǎng)年終促銷第一波已開啟，全場6折起，豪禮搶不停>>>

截止時間：2016年10月30日

更多大數(shù)據(jù)與分析相關(guān)行業(yè)資訊、解決方案、案例、教程等請點擊查看>>>

詳情請咨詢在線客服！

客服熱線：023-66090381