cbod數(shù)據(jù)庫導(dǎo)致交易超時(shí)現(xiàn)象的分析

1、CBOD數(shù)據(jù)庫備份導(dǎo)致交易超時(shí)現(xiàn)象分析IBM目錄 TOC o 1-3 h z u HYPERLINK l _Toc410739575 一、問題描述： PAGEREF _Toc410739575 h 3 HYPERLINK l _Toc410739576 一、分析過程 PAGEREF _Toc410739576 h 4 HYPERLINK l _Toc410739577 三、問題總結(jié)： PAGEREF _Toc410739577 h 5 HYPERLINK l _Toc410739578 四、改進(jìn)路徑 PAGEREF _Toc410739578 h 5 HYPERLINK l _Toc41073

2、9579 附錄1：山東農(nóng)信IBM軟件服務(wù)工作報(bào)告_DB2_20140403 PAGEREF _Toc410739579 h 7 HYPERLINK l _Toc410739580 附錄2：問題重現(xiàn)與驗(yàn)證 PAGEREF _Toc410739580 h 7一、問題描述：在2013年起，CBOD核心數(shù)據(jù)庫進(jìn)行批前備份時(shí)，有用戶反應(yīng)出現(xiàn)交易超時(shí)情況。批量處理前備份的開始時(shí)間是18：30，根據(jù)統(tǒng)計(jì)，交易超時(shí)的情況，一般發(fā)生在備份啟動后的3-5分鐘內(nèi)。交易超時(shí)的控制機(jī)制是在Tuexdo中間件層設(shè)置的，將指定時(shí)間內(nèi)沒有返回結(jié)果的服務(wù)kill掉。但在此時(shí)間端內(nèi)，已排除其他原因?qū)е碌慕灰壮瑫r(shí)的可能性。因此，可

3、以判斷交易超時(shí)與數(shù)據(jù)庫備份動作有關(guān)。以2014年3月25日為例，在18:30啟動在線全備份，備份語句為db2 backup db ngcbsdb online to /ngcbsdbbak/backup parallelism 400 compress include logs通過應(yīng)用程序監(jiān)控，發(fā)現(xiàn)，從18:30分開始，3分鐘之內(nèi)有近20K筆交易，其中約513筆的交易會因超時(shí)而失敗.TIMESTAMPTCCBTLATTOTAL18.30854312818.312478733418.32262551合計(jì) 513筆從nmon監(jiān)控結(jié)果觀察，發(fā)現(xiàn)備份開始之后出現(xiàn)一個(gè)I/O的一個(gè)跳躍分析過程遠(yuǎn)程技術(shù)支持

4、于2014年4月期間，通過IBM 800服務(wù)，進(jìn)行咨詢(PMR07746)?，F(xiàn)場巡檢DB2售后人員現(xiàn)場進(jìn)行了現(xiàn)象重現(xiàn)和問題跟蹤，形成了分析報(bào)告，參見山東農(nóng)信IBM軟件服務(wù)工作報(bào)告_DB2_20140403問題模擬與重現(xiàn)IBM SWG專家和GTS系統(tǒng)遷移團(tuán)隊(duì)一起，在2014年10月30日和11月13日，利用新的核心數(shù)據(jù)庫服務(wù)器P780和新的存儲設(shè)備8870，進(jìn)行了2次問題重現(xiàn)測試。通過壓力測試工具，執(zhí)行大量的事務(wù)處理，最高事務(wù)處理峰值到達(dá)2700TPS，并在期間，進(jìn)行數(shù)據(jù)庫聯(lián)機(jī)備份，試圖模擬類似生產(chǎn)環(huán)境的超時(shí)現(xiàn)象。經(jīng)過2次測試，備份期間的超時(shí)筆數(shù)均極少，2-3筆，與生產(chǎn)環(huán)境出現(xiàn)的現(xiàn)象不一致。因此

5、，我們推論，在新的生產(chǎn)環(huán)境下，無法模擬出類似的現(xiàn)象。三、問題總結(jié)：DB2備份時(shí)交易超時(shí)的現(xiàn)象與DB2備份機(jī)制有關(guān)。在DB2軟件角度分析，在執(zhí)行online backup前，需要一個(gè)保證數(shù)據(jù)一致性的機(jī)制-將bufferpool中的dirty page flush到disk上。這個(gè)機(jī)制將保證數(shù)據(jù)庫的一致性和完整性。在dirty page flush期間，可能會導(dǎo)致部分交易的延遲或等待。注：其他數(shù)據(jù)庫產(chǎn)品，均有類似機(jī)制，例如Oracle。參考 HYPERLINK /developerworks/data/library/techarticle/dm-0407tham/ IBM DB2 UDB ver

6、sus Oracle backup and recovery。從硬件處理能力角度分析，當(dāng)交易量日益增大，需要刷新的dirty page量不斷增長，而IO處理能力沒有提升，因此，導(dǎo)致刷新時(shí)間變長，交易超時(shí)筆數(shù)增多。換句話說，當(dāng)IO性能得到提升后，該現(xiàn)象應(yīng)該得到大大緩解。在新硬件環(huán)境上未能復(fù)現(xiàn)問題即有此有關(guān)。四、改進(jìn)路徑由于該問題是DB2保證數(shù)據(jù)一致性和完整性的機(jī)制之一，因此，無法根本避免。但結(jié)合IBM眾多客戶的經(jīng)驗(yàn)，可以有以下幾種方法進(jìn)行改進(jìn)：備份時(shí)間窗口調(diào)整。避免在業(yè)務(wù)高峰期進(jìn)行數(shù)據(jù)庫備份操作，將有效減輕該現(xiàn)象的影響程度。根據(jù)DB2 L2/L3的經(jīng)驗(yàn)，若干銀行客戶曾經(jīng)在交易或者批量高峰時(shí)，遇到

7、過類似問題，絕大部分客戶通過調(diào)整作業(yè)時(shí)間窗口的方式，有效緩解了該問題。可通過調(diào)整softmax參數(shù)，提升flush的頻率，降低online backup之前bufferpool中的dirty page數(shù)量，從減少受影響的交易，減少超時(shí)交易數(shù)。但調(diào)整softmax會導(dǎo)致更加頻繁的flush，帶來更大的I/O開銷，及影響I/O的穩(wěn)定；因此對softmax參數(shù)值的調(diào)整，必需在接近生產(chǎn)系統(tǒng)壓力的測試環(huán)境上測試調(diào)試。IBM在DB2新版本，會持續(xù)優(yōu)化該操作。在DB2新版本上，提供了新的命令，也有一定的幫助。DB2 V10.5中，提供了獨(dú)立的刷新 bufferpool命令。附錄1：山東農(nóng)信IBM軟件服務(wù)工作

8、報(bào)告_DB2_20140403附錄2：問題重現(xiàn)與驗(yàn)證驗(yàn)證目的：審慎的驗(yàn)證上述原因的準(zhǔn)確性，在問題重現(xiàn)后，驗(yàn)證IBM技術(shù)支持團(tuán)隊(duì)給出的調(diào)整softmax的建議的效果。驗(yàn)證過程：IBM SWG專家和GTS系統(tǒng)遷移團(tuán)隊(duì)一起，在10月30日和11月13日，利用新的核心數(shù)據(jù)庫服務(wù)器P780和新的存儲設(shè)備8870，進(jìn)行了2次問題重現(xiàn)測試。通過壓力測試工具，執(zhí)行大量的事務(wù)處理，最高事務(wù)處理峰值到達(dá)2700TPS，并在期間，進(jìn)行數(shù)據(jù)庫聯(lián)機(jī)備份，試圖模擬類似生產(chǎn)環(huán)境的超時(shí)現(xiàn)象。驗(yàn)證結(jié)果：經(jīng)過2次測試，備份期間的超時(shí)筆數(shù)均極少，2-3筆，與生產(chǎn)環(huán)境出現(xiàn)的現(xiàn)象不一致。因此，我們推論，在新的生產(chǎn)環(huán)境下，無法模擬出類似的現(xiàn)象。而不能模擬類似現(xiàn)象的原因，與新的存儲設(shè)備IO性能大幅提升有一定關(guān)系。由于無法重現(xiàn)問題，因此