SQL Server數(shù)據(jù)庫鏡像下有效的索引維護(hù)

SQL Server數(shù)據(jù)庫鏡像下有效的索引維護(hù)

我們?cè)谧鏊饕亟ǖ臅r(shí)候，由于索引重建產(chǎn)生太多日志，習(xí)慣切換到大容量日志恢復(fù)模式。而在生產(chǎn)環(huán)境，我們配置了數(shù)據(jù)庫鏡像作為高可用，鏡像只能運(yùn)行于完整恢復(fù)模式，難道我們就不做索引維護(hù)了么？

當(dāng)生產(chǎn)環(huán)境使用鏡像的時(shí)候，這是一個(gè)很常見的問題。當(dāng)使用鏡像前，盡管很多人會(huì)做負(fù)載性能測(cè)試，以我的經(jīng)驗(yàn)，在他們的測(cè)試中不會(huì)包含維護(hù)操作。常規(guī)的維護(hù)操作是業(yè)務(wù)環(huán)節(jié)的一部分，因此，我們應(yīng)該將其包含在所有的測(cè)試場(chǎng)景中。

我們先來了解下原理，使用大容量日志恢復(fù)模式允許索引重建（使用ALTER INDEX ... REBUILD）操作產(chǎn)生更少的事務(wù)日志，也就是說，事務(wù)日志不會(huì)像在完整恢復(fù)模式下執(zhí)行的操作那么大。而數(shù)據(jù)庫鏡像只允許使用完整恢復(fù)模式，因此索引重建會(huì)記錄完整日志。產(chǎn)生的大量的額外的日志很容易導(dǎo)致主和鏡像之間的網(wǎng)絡(luò)問題，在主上會(huì)會(huì)導(dǎo)致非常大的SEND隊(duì)列。如果SEND隊(duì)列變得非常大，當(dāng)主宕機(jī)時(shí)，會(huì)有潛在的數(shù)據(jù)丟失的隱患，甚至超出可以容忍的數(shù)據(jù)丟失服務(wù)級(jí)別協(xié)議。

那么我們?cè)撛趺醋瞿兀?/p>

我們可以錯(cuò)開時(shí)間使用ALTER INDEX ... REORGANIZE做索引維護(hù)。重新組織索引只是處理存在的碎片，它是可以中斷的，而不會(huì)丟失已經(jīng)完成的工作。重建索引，不論碎片有多少，總是會(huì)建立一個(gè)新索引，如果你中斷了，整個(gè)重建過程將回滾。

對(duì)于很大的索引，去重建是不實(shí)際的，應(yīng)該執(zhí)行以下步驟：   

• 第1天：在維護(hù)窗口，開始ALTER INDEX ... REORGANIZE。讓它運(yùn)行1個(gè)小時(shí)，然后KILL掉。它不會(huì)回滾索引維護(hù)的操作，剛才的索引重新組織將會(huì)移除一些碎片。    

• 第2天：再次開始重新組織索引。它不會(huì)記住第1天工作到哪了，它會(huì)快速穿過第1天的工作，開始移除索引的下一個(gè)部分的碎片。在1小時(shí)后KILL掉。    

• 重復(fù)以上動(dòng)作直到碎片級(jí)別降到合適的閾值，或者只是繼續(xù)無限期的每天處理。

該方法允許你限制通過常規(guī)的索引維護(hù)產(chǎn)生的事務(wù)日志的數(shù)量。如果你想更深入的優(yōu)化，不用再一定時(shí)間后殺掉重新組織的進(jìn)程，你可以監(jiān)控事務(wù)日志產(chǎn)生的數(shù)量，然后到達(dá)一定閾值后再殺掉。具體，可以參考：Script: open transactions with text and plans（http://www.sqlskills.com/blogs/paul/script-open-transactions-with-text-and-plans/）