共用方式為

SQL 問答集：嚴重損壞修復和資料庫鏡像

  • 發行項

備份、嚴重損壞修復和資料庫鏡像都有無數的變形，全都適合無數的案例。

Paul S. Randal

臨時解決方案

**問：**我讀過大量的相互矛盾的意見，關於應為 tempdb 以減少 PAGELATCH 爭用配置我的伺服器上有多少資料檔案。 可你揭示任何對此嗎？

**答：**你正確 — — 有很多有關于 tempdb 配置差意見。 PAGELATCH 在 tempdb 中的爭用，來自哪裡多併發連接創建和刪除小表的工作負載。 這些操作需要分配和需要在 tempdb 中的資料檔案頁。 而這又需要獨佔訪問記憶體中分配點陣圖資料檔案頁 （使請注意哪些資料檔案的頁中使用或不特殊頁）。

如果有多個併發連接試圖同時分配和取消分配，只有一個連接可同時擁有對分配點陣圖的訪問。 這將導致爭用和性能有所降低。

一種減輕此爭用的一點是要啟用跟蹤標誌 1118年 （您可以瞭解更多有關這我的 SQLskills.com 博客)。 一個更有效的方法是創建多個 tempdb 資料檔案。 通過創建多個資料檔案，SQL Server 將執行分配 （和取消分配） 迴圈賽結束的資料檔案。 這種方式，分配點陣圖的數量增加 （一個或多個每個資料檔案） 和整體系統爭用將會減少。

問題是：您應創建多少個資料檔案？ 長一段時間，人們可以給的最好的建議是創建一個 tempdb 資料的微軟官方立場檔為每個邏輯處理器核心 （例如，兩個具有四核心 Cpu 和超執行緒啟用等於 8 個邏輯內核） 是不正確的。 這種方法具有多於 8 個核心的伺服器上可能導致記憶體洩漏的道路。 另一種普遍持有的信念是入手四分之一到一半處理器核心的數量是一個好的開始。

然後在 SQL 傳遞國家首腦會議在 2011 年底，鮑勃 · 沃德從 Microsoft 產品支援提交了更優雅公式確定您要創建的檔的數目。 如果您的伺服器有少於 8 個邏輯內核，使用邏輯核心的數量，作為 tempdb 資料檔案的數目。 如果您的伺服器有超過八個邏輯內核，開始與八 tempdb 資料檔案，然後添加四更多一次，如果爭用繼續。

保持銘記這是廣義的意見。 有至少三次具有 64 核心伺服器需要 128 tempdb 資料檔案的地方 — — 核心的兩倍多 — — 以紓緩的爭用。 你實際里程肯定會有所不同。

一個完美的計畫

**問：**我最近檢討我們的災害復原計畫，發現我們不做我們的系統資料庫的定期備份。 你建議這樣做嗎？ 什麼是最壞的可能發生，如果我們不這樣做呢？

**答：**它是一個好主意，定期審查您的災害復原計畫。 它是更好實施這些計畫。 你會發現是否你跑得通過實踐裸機還原的事情之一是您的 SQL Server 環境就不會有回來的完整功能，因為您將缺少的系統資料庫。

許多 Dba 時不考慮系統資料庫 （大師、 模型、 msdb 和任何複製散發資料庫） 規劃或測試災害復原過程。 這是一個巨大的錯誤。 這些資料庫是您的 SQL Server 實例的關鍵。 您需要保護這些，只是為你做你的使用者資料庫檢查其完整性。

沒有點中有您的資料可用，如果您無法連接到 SQL Server 實例。

也是如此，如果主是缺少的因為你沒有的所有必要的登錄資訊時，你不能在進入工作狀態帶該實例。 沒有備份的主人，你在看之前應用程式可以連線，重新創建所有資料庫的所有登錄資訊。

備份 msdb 資料庫，因為它包含所有 SQL 代理作業 （如備份和一致性檢查），至關重要的是 SQL 代理警報 （如高嚴重錯誤和 早期警告你 I/O 子系統走錯了），您的 SSIS 包和您的備份歷史記錄表。 如果您有任何種類的自動化系統，將生成一組語句，方便易行的還原資料庫災害復原，它可能使用的備份歷史記錄表 msdb 中這樣做。 Msdb （如果這場災難拿出你整個的 I/O 子系統） 的副本，不需要將拼湊 RESTORE 語句用手，其中是單調乏味的工作，將添加到的停機時間。

Model 資料庫是關鍵的如果您已經有一個您想要複製到的所有新資料庫的配置。 例如，如果您有一個每個託管用戶端有其自己的資料庫環境，您將需要模型。 如果沒有它，您必須重新設置這些配置選項。

關鍵的重塑複製資料流程，無需執行耗時 re-initializations 訂閱資料庫的複製散發資料庫。 總體而言，你沒有災害復原策略，除非您備份的您的系統資料庫，以及您的使用者資料庫。

若要獲取您開始，簽出這些 SQL Server 連線叢書的系統資料庫備份和恢復：

增長、 增長、 增長

**問：**我們在理解問題的麻煩在事務日誌不斷增長，即使我們手動縮小後。 我們犯了在我們的內部事務和執行記錄備份中的工作，所以為什麼不會在日誌保持增長嗎？

**答：**這裡的問題似乎是您的開發人員都沒有意識到他們不表現他們看起來在代碼中，使用嵌套的事務。 說明了你在做什麼的示例代碼流程如下：

BEGIN TRAN; Do some work … BEGIN TRAN; Do some more work … COMMIT TRAN Continue with more work …

儲存引擎而言，啟動一個嵌套的事務，第二個開始陳德，不會真正開始 sub-transaction。 它不是增量 @ @ TRANCOUNT 1。 沒有寫進指示已開始一個新的事務的事務日誌。 嵌套事務所做的所有工作都是實際上的初始事務的一部分。

這意味著當提交陳德發出的嵌套事務，什麼也沒發生遞減 @ @ TRANCOUNT，除了因為真的沒有嵌套的事務。 直到初始事務，沒有什麼是致力使 @ @ TRANCOUNT 回到零的提交。 這就是為什麼越來越多的事務日誌。 您仍然有一個單一的、 長時間運行的事務。

此外，您不應該執行常規事務日誌收縮操作。 每當成長事務日誌，日誌的新部分，初始化為零。 它是覆蓋在先前的 NTFS 卷的那部分零。 所以任何隨後的經濟崩潰恢復操作不會失敗，發生這種情況 （請參閱我的 SQLskills.com 博客解釋）。

雖然事務日誌的新部分正在初始化為零，將暫停該資料庫的所有日誌記錄活動。 您的工作負荷會暫時停止。 這一暫停可能很長，如果您已設置事務日誌自動增長量很大。

它總是更好地避免自動增長如果可能所需的事務日誌。 如果事務日誌增長再次每次您縮小，獨自一人離開。 很明顯它需要大於到您正在萎縮的大小。

鏡像鏡像

**問：**我們只被實現了資料庫鏡像和發現我們將不再執行一些我們的表的索引重建。 規模龐大的事務日誌生成的重載我們的網路和資料庫鏡像會減慢。 為什麼會這樣呢，我們如何工作圍繞著它嗎？

**答：**這一問題會遇到很多人執行資料庫鏡像。 它源自這一事實，性能和可靠性測試完成活資料庫鏡像不包含常規資料庫維護。

執行索引重建操作時，很多人使用大容量日誌記錄復原模式。 因此，事務日誌不會成長在操作期間，這限制，生成的事務日誌的量。 資料庫鏡像只允許完整復原模式，其中索引重建操作完全記錄。 然後他們可以生成盡可能多事務日誌卷，作為正在重建索引的大小。

當執行索引重新生成完整恢復模型中的其他事務日誌記錄的數量可能是真正的大和飽和的主體和鏡像資料庫伺服器之間的網路連結。 如果發生這種情況，發送佇列可能建立在主體資料庫上。 這可能會導致交易處理延誤的任何並行應用程式工作負載。

這意味著對許多人來說，索引重建操作不可能使用資料庫鏡像時。 即使使用資料庫鏡像日誌流壓縮包含 SQL Server 2008 和更高版本中是如此。

替代索引維護策略是使用更改索引...重組而不是更改索引...重建。 重新組織索引僅解決現有索引碎片。 您可以中斷它，而不會丟失已經完成的工作。 另一方面，重新生成索引，始終生成新的索引碎片的程度無關。 如果您中斷它，你什麼也沒得到。 一切都將回滾。

對於較大的索引，並不是實際要重建，請執行以下步驟：

  • **第一天：**開始運行更改索引...在維護視窗期間重新組織。 讓它運行為一小時左右。 殺死該命令。 它不會回滾任何東西，你就會取得了一些進展，在從索引中刪除碎片。
  • **第二天：**開始再次重新組織。 它不記得第一天，但應快速遍歷的第一天，開始從索引的下一部分中刪除碎片所做的工作。 一個小時左右後再次殺死它。
  • **天后兩個：**重複，直到您已經確立，無論閾值以下的碎片級別滴或只是無限期地繼續由天過程。

這允許您限制的事務日誌量生成 （和因此傳輸中使用資料庫鏡像） 由您的常規索引維護。 如果想要獲得更多先進的而不是經過一定的時間，殺害重組進程可以監視生成多少事務日誌並殺死它一旦達到某一閾值 （請參閱我的 SQLskills.com 博客更多詳細資訊）。

Paul S. Randal

Paul S. Randal 為 SQLskills.com、 微軟區域主任和 SQL 伺服器 MVP 的董事總經理。 他工作在 SQL Server 儲存引擎團隊在微軟從 1999 年到 2007 年。 他寫的 SQL Server 2005 的 DBCC CHECKDB/修復並負責核心儲存引擎在 SQL Server 2008 開發過程中。 Randal 是災害復原、 高可用性和資料庫維護方面的專家，也是經常在世界各地的會議簡報者。 在他博客 SQLskills.com/blogs/paul，你可以找到他在 Twitter 上和 twitter.com/PaulRandal。

相關內容