嗨，我是 Kirk我是與 GSE 團隊合作的資深首席工程師這段影片的目的是要瞭解Microsoft SQL 伺服器 TSQL 資料庫工具 DBCC CHECKDB我們將討論應運行 DBCC CHECKDB 的原因和時間，以及確定所涉及的資料庫檢查級別和運行時的命令選項。
因此，在開始示範前，我們會先討論一些重點DBCC CHECKDB 是一種 TSQL 工具，可查看給定 SQL 伺服器資料庫中所有物件的邏輯和物理完整性。我們也提供一些修復選項 還有「TABLOCK」的選項 與使用或不使用資料庫的快照有關我們要看看「ESTIMATEONLY」選項 以及為什麼要使用此選項 這與在 CHECKDB 程序中使用「TEMPDB」有關
另外，我們也會查看「PHYSICAL_ONLY」 我們為什麼要使用此選項以及何時使用該選項我們也會看看 如何控制 CHECKDB 程序中 涉及的處理器數量 稱為「MAXDOP」所以現在我們會看到一些執行 DBCC CHECKDB 的範例因此，第一個命令本身實際上將檢查 DBCC CHECKDB 在給定資料庫中可能查看的所有內容。
這些是輸出的結果當我們運行 this 時，我們最感興趣的返回行是在資料庫中發現的“分配錯誤”和“一致性錯誤”的數量。所以，我有一個健康的“AdventureWorks2019”資料庫，所以一切都沒有錯誤。因為這是小型資料庫，因此執行速度相當快如果我們有一個更大的資料庫，例如一個資料庫的大小是這個資料庫的 100 倍，運行它需要更長的時間。
而且，很多人想知道我們應該多久嘗試一次DBCC CHECKDB，通常SQL大師會告訴你，你想儘快嘗試運行它。如果資料庫中有任何不一致或任何類型的軟體損壞，您希望儘快發現並處理它。所以我們要看的下一個選項 是「WITH PHYSICAL_ONLY」的選項
這是相同的命令，除了在本例中它實際上只檢查物理實體或資料庫本身的結構。它通常比完全檢查運行得更快，這就是為什麼我們希望在維護時間有限的生產環境中運行它。我們還有另一個選項，稱為“WITH TABLOCK”，因此我們需要瞭解DBCC CHECKDB的一件事，它做的第一件事就是創建一個快照檔，該檔包含在“TEMPDB”資料庫中，有時我們可能無法將“TEMPDB”用於類似CHECKDB進程的操作。
所以，無論我們指定什麼“WITH TABLOCK”，我們告訴DBCC CHECKDB不要創建快照檔，因此它不會佔用“TEMPDB”中的空間，因此它通常會運行得更快。我們可以作為選項運行的另一件事是“WITH ESTIMATEONLY”。此特定命令將告訴我們在運行 CHECKDB 時，我們期望在「TEMPDB」資料庫中使用多少空間。
這是輸出的範例，以千位元組為單位，大約是 230 兆位元組另一個選項是「WITH MAXDOP」現在，無論運行什麼 DBCC CHECKDB，它都會嘗試使用並行運行所需的盡可能多的處理器。它希望運行多個線程，以便嘗試儘快執行。因此，我們希望允許在此過程中運行的處理器數量可能存在限制，因此我們可以使用“WITH MAXDOP”語句來限制它。
在這種情況下，我告訴 SQL 只使用一個處理器來運行我們的 CHECKDB。而且，當我們這樣做時，專用於此的處理器較少，但是，運行DBCC CHECKDB通常需要更長的時間。現在，我們繼續看看修復選項我們有不同的修復選項其中效果最激烈的是「REPAIR_ALLOW_DATA_LOSS」每當我們使用此選項嘗試修復返回並出現錯誤的資料庫時，您實際上可能會丟失數據。我們也可以使用「REPAIR_REBUILD」
REPAIR_REBUILD 被視為軟修復選項，我們的意思是它保證在運行此選項時我們不會丟失資料庫中的可用數據。因此，按照此命令的配置方式，我們將使用“Master”資料庫的上下文。每當我們執行類似操作時，我們都必須將資料庫置於「SINGLE_USER」模式以允許修復操作。這樣我們才能執行命令
現在我們可以選擇「ESTIMATEONLY」 再一次，「ESTIMATEONLY」會告訴我們 在「TEMPDB」中 我們要放棄多少空間根據我們在此處的返回，我們的快照檔將佔用大約 230 兆位元組。在進行修復後 我們會將它放回「MULTI_USER」模式使用「ESTIMATEONLY」時 我們並沒有實際執行修復 我們只是做了預估所以，我們來看看如何使用「REPAIR_REBUILD」執行命令
我們再次前往「Execute」 然後將其放回「MULTI_USER」因此，在“主”資料庫的上下文中，我們將再次將其置於“SINGLE_USER”模式。這次，我們要執行修復操作這是較為溫和的修復操作您將會看到很多 我們在一般資料庫檢查中看到的內容 當然，我們再次想要檢查回報的錯誤範例中的情況依然是沒有錯誤
我的資料庫狀況相當好此操作的最後一部分是將其放回「MULTI_USER」模式所以「REPAIR_ALLOW_DATA_LOSS」修復命令與「REPAIR_REBUILD」完全相同，只是我們使用的是「REPAIR_ALLOW_DATA_LOSS」通常我們會在嘗試執行「REPAIR_REBUILD」時執行這個命令 而「REPAIR_REBUILD」傳回並告訴我們無法完成資料庫修復
所以，如果沒有良好的備份，我們最後的手段 是的，我們應該在被迫進行“REPAIR_ALLOW_DATA_LOSS”之前使用良好的備份如果不存在備份，這是我們使資料庫重新連線並可用的唯一選項。以上就是我們討論 DBCC CHECKDB 的演示，考慮何時使用 CHECKDB 以及一些最常見的可用命令選項。我希望這段影片能協助您瞭解在嘗試維護一致、穩定的 SQL Server 資料庫安裝時，使用 DBCC CHECKDB 的價值。
謝謝收看
