切勿破壞這個(gè)結(jié)構(gòu)鏈

問：我已經(jīng)為數(shù)據(jù)庫定義了備份策略。 我的計(jì)劃涉及事務(wù)日志備份，這樣我們執(zhí)行災(zāi)難恢復(fù)時(shí)幾乎不會(huì)丟失數(shù)據(jù)。 我研究了可能會(huì)遇到的一些問題，并幾次讀到需要注意不能破壞日志備份鏈。 您能解釋一下這是什么意思以及在何種情況下會(huì)破壞它嗎？

答：問得好，許多人都忽略了這個(gè)問題。 日志備份鏈（有時(shí)簡稱為日志鏈）指的是一系列不間斷的事務(wù)日志備份，覆蓋的時(shí)間段從最近的數(shù)據(jù)備份（完整備份或差異備份）到要還原該備份時(shí)。 還原序列的示例如下：

• 最近的完整數(shù)據(jù)庫備份
• 然后是最近的差異數(shù)據(jù)庫備份
• ***是所有事務(wù)日志備份

大多數(shù)人會(huì)保留更多事務(wù)日志備份，一旦某個(gè)備份被破壞，您必須還原最近的數(shù)據(jù)備份。 在我去年撰寫的兩篇《TechNet 雜志》文章“了解 SQL Server 備份”和“利用備份進(jìn)行災(zāi)難恢復(fù)”中，可獲得有關(guān)備份和還原的更多信息。

如果任何必要的日志備份被損壞或不能按照所選序列還原，則日志備份鏈會(huì)被破壞并且無法還原被破壞的時(shí)間之前的備份。 如果只損壞了其中一個(gè)日志備份，您可能會(huì)使用 WITH CONTINUE_AFTER_ERROR 選項(xiàng)強(qiáng)制其進(jìn)行還原。 這會(huì)強(qiáng)制還原已損壞的事務(wù)日志記錄，從而導(dǎo)致數(shù)據(jù)庫損壞。 我對(duì)是否強(qiáng)制進(jìn)行此類還原也拿不定主意。

可能會(huì)導(dǎo)致必要的日志備份不可用的一項(xiàng)操作是“帶外”日志備份，該操作不能確保會(huì)保留日志備份。 例如，您可能通過這種方式向開發(fā)人員提供副本。 該日志備份是日志備份鏈的一部分，因?yàn)樗俏ㄒ话谇耙粋€(gè)日志備份后生成的日志記錄的日志備份。

也就是說，除非您使用 WITH COPY_ONLY 選項(xiàng)執(zhí)行日志備份，并允許下一個(gè) 日志備份有效地備份同一組日志記錄才行。 請(qǐng)參見我的博客文章“BACKUP WITH COPY_ONLY”，了解有關(guān)如何避免損壞備份鏈的詳細(xì)信息。

損壞日志備份鏈的操作的一個(gè)更常見示例是阻止您在日常操作期間執(zhí)行事務(wù)日志備份。 這些類型的操作包括：

• 切換到 SIMPLE 恢復(fù)模式，然后返回 FULL 或 BULK_LOGGED
• 使用 BACKUP LOG … WITH NO_LOG 或 TRUNCATE_ONLY 選項(xiàng)將日志轉(zhuǎn)儲(chǔ)到 SQL Server 2005 和早期版本中
• 從數(shù)據(jù)庫快照還原數(shù)據(jù)庫

您需要在上述任何操作后執(zhí)行數(shù)據(jù)備份（完整備份或差異備份）以允許日志備份繼續(xù)。 這稱為“重新啟動(dòng)日志備份鏈”。

***一件事：與一般認(rèn)識(shí)相反，執(zhí)行完整備份或差異備份不會(huì) 損壞日志備份鏈，事實(shí)上，不會(huì)對(duì)日志備份產(chǎn)生任何影響。

群集這些索引

問：SQL Server 2008 數(shù)據(jù)庫中的許多表不包含群集索引。 我聽說使用導(dǎo)致額外 IO 的前推記錄時(shí)，可能遇到性能問題。 您是否能告訴我如何檢查此問題以及應(yīng)該采取什么措施？

答：堆是一個(gè)不包含群集索引的表。 它在本質(zhì)上是無序的。 不了解堆中的前推記錄及其用法的讀者，請(qǐng)參見我的博客文章“轉(zhuǎn)發(fā)和前推記錄以及后向指針大小”了解詳細(xì)信息。 在查詢處理期間，堆中的前推記錄可能會(huì)導(dǎo)致額外的隨機(jī) IO 操作，而這會(huì)導(dǎo)致性能下降。

檢查您的查詢是否正在處理前推記錄的最簡便方法是查看訪問方法性能對(duì)象中的每秒前推記錄性能計(jì)數(shù)器。 然后，對(duì)數(shù)據(jù)庫中的一些表使用帶有 DETAILED 模式的 sys.dm_db_index_physical_stats 動(dòng)態(tài)管理函數(shù)，該函數(shù)將在輸出的 forwarded_record_count 列中返回每個(gè)表的前推記錄數(shù)。 有關(guān)詳細(xì)信息，請(qǐng)參閱聯(lián)機(jī)叢書中的此主題。

刪除前推記錄的最糟糕的方法是創(chuàng)建群集索引，然后再刪除該索引。 這會(huì)導(dǎo)致表中的所有非群集索引自動(dòng)重新生成兩次，浪費(fèi)大量資源。 有關(guān)詳細(xì)信息，請(qǐng)參閱我的博客文章：“表結(jié)構(gòu)更改時(shí)，非群集索引會(huì)怎樣？”

***刪除和阻止堆中的前推記錄的最簡便方法是創(chuàng)建群集索引。 在此，我不希望討論為什么在大多數(shù)情況下應(yīng)當(dāng)使用群集索引而不是堆，從而陷入“群集索引與堆”的爭論 。 有關(guān)此問題的詳細(xì)信息，請(qǐng)參閱我妻子 Kimberly Tripp 的“群集鍵”博客文章系列。 我鼓勵(lì)您使用群集索引進(jìn)行評(píng)估。

表記錄大小增加時(shí)，如果空間不足，會(huì)引起前推記錄。 因此，阻止前推記錄的另一個(gè)方法是防止更改記錄大小。 例如，這意味著使用可變長度列的默認(rèn)值。

在 SQL Server 2008 中，有一個(gè)新的 ALTER TABLE … REBUILD 語句允許您重新生成堆。 此語句的工作原理與允許您重新生成索引的 ALTER INDEX … REBUILD 語句的工作原理相同。 Microsoft 添加此語句是為了支持?jǐn)?shù)據(jù)壓縮功能，但這里我們將其用于其他目的。 有關(guān)詳細(xì)信息，請(qǐng)參閱聯(lián)機(jī)叢書中的此主題。

索引維護(hù)

問：我已將索引維護(hù)例程更改為使用聯(lián)機(jī)索引重新生成，但有時(shí)在維護(hù)例程運(yùn)行時(shí)仍會(huì)出現(xiàn)阻塞問題。 為什么會(huì)這樣？ 我認(rèn)為聯(lián)機(jī)索引操作不使用鎖定，所以不應(yīng)該出現(xiàn)任何阻塞才對(duì)。 這是正常現(xiàn)象，還是我的操作有問題？

答：您看到的是正常現(xiàn)象。 在操作開始時(shí)有一個(gè)必需的共享表鎖定，同時(shí)操作初始化（這個(gè)過程非常快）。 此過程轉(zhuǎn)瞬即逝。 此鎖定的排隊(duì)方式必須與任何其他鎖定類似，并且它將阻止任何新查詢對(duì)該表進(jìn)行修改，直到您再次同意并釋放此鎖定。

在您完成所有當(dāng)前正在運(yùn)行的修改查詢后，才可以獲取此鎖定。 這可能需要相當(dāng)長一段時(shí)間，具體取決于您的工作負(fù)荷。 這意味著在聯(lián)機(jī)索引操作開始時(shí)可能會(huì)出現(xiàn)阻塞。

在操作結(jié)束時(shí)，必須對(duì)鎖定進(jìn)行架構(gòu)修改，將該鎖定視為獨(dú)占鎖定以完成修改。 此過程同樣相當(dāng)快。 然后立即解除獨(dú)占該鎖定。 此鎖定將阻止對(duì)表進(jìn)行任何類型的新查詢（讀取或?qū)懭耄钡侥獠⑨尫糯随i定。

再次重申，在 SQL 完成所有當(dāng)前正在運(yùn)行的讀取或?qū)懭氩樵兒螅趴梢垣@取此鎖定。 這同樣意味著可能出現(xiàn)阻塞。

總而言之，盡管此功能名為聯(lián)機(jī)索引操作，但它的確還需要兩個(gè)可能導(dǎo)致阻塞問題的短期鎖定。 與傳統(tǒng)的脫機(jī)索引操作相比，這種方法的優(yōu)點(diǎn)在于絕大多數(shù)索引操作沒有使用鎖定，因此整體并發(fā)程度有所提高。 “SQL Server 2005 中的聯(lián)機(jī)索引操作”白皮書對(duì)這些操作的工作原理進(jìn)行了更為詳細(xì)的介紹。

縮短索引維護(hù)時(shí)間

問：我繼承了一些系統(tǒng)，在這些系統(tǒng)中，常規(guī)索引維護(hù)操作的運(yùn)行時(shí)間很長并生成大量 IO，但因?yàn)樗饕荒苁橇闼榈模晕覜]有重新生成任何索引。 我希望減少工作負(fù)荷，因?yàn)樾阅軟]有得到任何改進(jìn)。 您能為我建議一個(gè)有幫助的策略嗎？

答： 這個(gè)問題普遍存在。 原因在于維護(hù)索引操作決定要重新生成或重新組織哪些索引的方式。

大多數(shù)人針對(duì)數(shù)據(jù)庫中的所有索引運(yùn)行 sys.dm_db_index_physical_stats 動(dòng)態(tài)管理函數(shù)（以前提到過），然后選擇是重新生成、重新組織還是不執(zhí)行任何操作。 他們使用輸出中的 WHERE 子句根據(jù) avg_fragmentation_in_percent、page_count 和 avg_page_space_used_in_percent 值做出決定。

問題是索引碎片不像其他統(tǒng)計(jì)信息一樣存儲(chǔ)在內(nèi)存中。 此函數(shù)必須讀取并處理各個(gè)索引才能確定其零碎程度。 如果數(shù)據(jù)庫中的大多數(shù)索引一成不變或緩慢變化（就碎片來說），將不會(huì)重新生成或重新組織這些索引。 每次執(zhí)行維護(hù)索引操作時(shí)檢查它們的碎片根本就是在浪費(fèi)時(shí)間。

大多數(shù)動(dòng)態(tài)管理視圖支持“謂詞推送”，即只處理與 WHERE 子句中的謂詞匹配的數(shù)據(jù)。 但是，sys.dm_db_index_physical_stats 是一個(gè)函數(shù)而不是視圖，因此它無法做到這一點(diǎn)。 這就意味著您必須手動(dòng)篩選函數(shù)，并要求函數(shù)只處理您知道可能成為碎片且可能需要重新生成或重新組織的那些索引。

我建議監(jiān)視幾周內(nèi)出現(xiàn)的碎片。 這樣您就可以了解哪些索引需要檢查碎片，而不用檢查所有索引。 有了這些索引的列表后，創(chuàng)建一個(gè)包含表名稱、索引名稱和碎片閾值的表以便采取措施。 您可能會(huì)發(fā)現(xiàn)，一些索引包含較多的碎片才會(huì)影響性能，而另一些則不然。 這將是您稍后用來推動(dòng)索引維護(hù)操作的“驅(qū)動(dòng)力表”。 系統(tǒng)將循環(huán)處理該表中介紹的所有索引，并只對(duì)它們運(yùn)行 sys.dm_db_index_physical_stats 函數(shù)。

我已對(duì)多個(gè)客戶應(yīng)用了此方法。 在某些情況下，索引維護(hù)操作的運(yùn)行時(shí)間會(huì)從幾小時(shí)縮短到 15 分鐘或更短。 這完全是因?yàn)闆]有對(duì)靜態(tài)索引運(yùn)行此函數(shù)。 您還可以進(jìn)一步跟蹤索引重新生成以及可能自動(dòng)更改索引的 FILLFACTOR 設(shè)置的頻率，希望這可以進(jìn)一步減少索引維護(hù)操作所執(zhí)行的工作。

有關(guān)執(zhí)行索引維護(hù)的各種方法的詳細(xì)信息，請(qǐng)參閱我的博客文章“索引維護(hù)的重要性”，有關(guān)函數(shù)實(shí)際操作的詳細(xì)說明，另請(qǐng)參閱我的博客文章“深入了解 sys.dm_db_index_physical_stats”。

原文地址

本文來源：微軟TechNet中文站