SQL問題與解答：備份和設置
XXXL 事務日志
問：我們的產品使用 SQL Server 來存儲數據。我們會不時發布新的產品版本，其中包含針對數據庫運行的升級腳本。由于我們在典型的測試數據庫中測試我們***的升級腳本，事務日志文件的大小增長到了 40GB 以上。我們希望阻止日志文件增長到如此之大。我們可以選擇哪種方案？出于災難恢復的目的，我們需要繼續使用完整恢復模式。
答：首先，我很高興得知您正在使用典型的客戶數據進行測試。我多次發現分層應用程序供應商會使用小型數據集來測試這種腳本，然后即投入發行并提供給客戶使用，而客戶在生產過程中則會遇到各種各樣的問題。如果您是用戶，我會解答您的問題。然后您可以根據客戶的具體情況來應用我的答案。
您說您需要繼續使用完整恢復模式。這意味著您已進行事務日志備份，且您沒有遇到事務日志增長失控等常見問題。這很好，因為進行事務日志備份是在提交事務之后唯一能夠清除事務日志的操作。（有關這個問題的背景，請參見 technet.microsoft.com/magazine/2009.02.logging，以了解事務日志的工作原理以及不同的恢復模式如何影響其行為。）
因此，執行事務日志備份的頻率在一方面決定了清除事務日志以阻止其增長的速率。例如，如果您的定期備份作業每 30 分鐘執行一次事務日志備份，事務日志文件必須足以保存在 30 分鐘內生成的***的事務日志數據量。否則，數據量將增長。
如果您的升級腳本運行 60 分鐘且每 30 分鐘生成 20 GB 的事務日志，則事務日志文件大小應為 20GB。可能這樣文件仍然太大，因此您需要在運行升級腳本時提高事務日志備份的頻率。這樣可以更頻繁地清除事務日志，從而阻止其過度增長。我們在客戶辦事處曾遇到過相似的問題，結果他們需要在大型數據庫中運行相似的腳本的數小時內每分鐘執行一次事務日志備份。
我們需要記住一件事，即這些“額外的”事務日志備份構成了日志備份鏈的一部分，并且是災難恢復所必須的。確保它們的名字都有意義且未被刪除。
另外，還應考慮以下事項：作為您所設計的升級過程的一部分，發生的***的單項事務是什么？僅當日志記錄來自已提交的事務時，可清除事務日志（這樣說可能過于簡單，有關詳細信息，請參見前面所提到的文章）。這意味著長期運行的事務不允許清除日志，即便事務日志備份不備份所生成的事務日志。
如果您的升級腳本包含一個需要 15GB 日志空間的事務，則事務日志文件將需要至少 15GB 來在提交事務前保存整個事務。在這種情況下，無論您執行事務日志備份的頻率如何，該事務日志都不會被清除。這種情況下唯一的解決辦法是，如果可能，將大型事務拆分成較小的事務。
請記住，運行升級腳本所需的事務日志大小取決于事務日志備份的頻率以及您所創建的***的單個事務的大小。
配置難題
問：我們正在為我們的一個數據庫服務器配置一些新的直接連接存儲，我們希望確保我們理解了所有的選擇方案并正確配置。您能不能解釋一下對于 SQL Server，我們應了解哪些不同的配置設置？
答：配置存儲時需要有策略的設置和配置選項，因此，我傾向于由專門的存儲管理員來負責。SQL Server 管理員肯定需要關注一些選項，以確保正確設置。
首先是底層 RAID 級別。涉及到性能與冗余性問題時，各種 RAID 級別的權衡互不相同。例如，仍能提供一定冗余性的***的 RAID 配置為 RAID-5，但此配置只能用于處理單驅動器故障（除非采用 RAID-6 或配置了熱備用驅動器），并且根據陣列中驅動器的數量，它有時會削弱大量寫入工作負荷的性能。
RAID-10 提供了***的冗余性，但更為昂貴。陣列的總容量***為構成驅動器總容量的一半。有關各種 RAID 級別的深入探討，請參見 TechNet 白皮書物理數據庫存儲設計附錄 A。
需要考慮的其他主要因素為 RAID 條帶大小、NTFS 分配單元大小（簇大小）以及磁盤分區對齊方式。如果設置有誤，所有上述因素都會導致性能明顯下降。其中最重要的一個因素為使用 Windows Server 2003 創建的磁盤卷的磁盤分區對齊方式。默認的對齊方式為 31.5KB，但這與 64KB 的常用 RAID 條帶大小（或者其中的多個條帶大小）不匹配。因此，每個 I/O 事實上需要讀或寫兩個 RAID 條帶來滿足 IO。很明顯，這會導致性能急劇降低。
默認情況下，Windows Server 2008 采用 1MB 的對齊方式。在 Windows Server 2003 上創建并升級到由 Windows Server 2008 托管的任何卷的對齊方式都不會變化，因此它們仍有可能會受到影響。要想解決這一問題就必須重新格式化卷，由于這樣能夠提高性能，所以還是值得的。
對于這些問題的詳細探討很明顯已超出了此專欄的主題范圍，但是您可以閱讀我的博客帖子您的磁盤分區偏移量、RAID 條帶大小和 NTFS 分配單元設置是否正確？，以了解詳細信息（包括更多相關帖子的鏈接）。
配置任何新的存儲時，***在開始應用生產負載之前進行壓力測試和性能測試。壓力測試使您能夠排除可導致停機或數據丟失的任何配置問題。性能測試可幫助您驗證新的存儲能否提供您的工作負載所需的 I/O 能力。Microsoft 提供可幫助實現這些操作的免費工具，請參見白皮書預部署 I/O ***實踐以了解詳細信息。
鏡像，鏡像
問：我對于設置數據庫鏡像時見證服務器的性質有些不解。見證服務器需要有多強大？它是否依賴于它執行故障轉移的數據庫的數量？將見證服務器放置在哪個數據中心有沒有影響？我希望確保鏡像數據庫能夠獲得***的可用性。
答：見證服務器的角色是任何數據庫鏡像系統中最容易被誤解的一個方面。同步數據庫鏡像配置中見證服務器存在的唯一目的是，當主體服務器變得不可用時幫助促進自動故障轉移。
主體服務器會持續向鏡像服務器而不是見證服務器發送事務日志記錄。作為自動故障檢測機制的一部分，主體服務器、鏡像服務器和見證服務器每秒都會相互 ping。如果出于任何原因鏡像服務器判定它無法與主體服務器通信，除非見證服務器同意它也無法與主體服務器通信，否則鏡像服務器無法啟動自動故障轉移。如果兩臺服務器達成一致，便形成仲裁，并由鏡像服務器啟動自動故障轉移。如果見證服務器不存在，則無法形成仲裁且無法啟動自動故障轉移。
因此，見證服務器存在的唯一目的就是幫助形成仲裁。它不會啟動故障轉移或在托管鏡像數據庫中扮演任何角色。通常，這種仲裁存在于主體服務器與鏡像服務器之間。
由于見證服務器不會做任何上述處理，它不需要非常強大。它可以托管任意版本的 SQL Server，包括免費的 SQL Server Express Edition。對于可作為見證服務器的 SQL Server 的特定實例，數據庫鏡像會話數也沒有限制。
見證服務器***放置在與主體服務器或鏡像服務器不同的數據中心。但是，大多數公司并不具備三個數據中心，因此問題是應將見證服務器與鏡像服務器還是與主體服務器放置在一起。
如果僅有兩個數據中心可用，應始終將見證服務器與主體服務器放置在一起。這與形成仲裁有關系。如果將見證服務器與鏡像服務器放置在一起，當主體服務器失去網絡鏈接時，見證服務器和鏡像服務器會形成仲裁并由鏡像服務器啟動故障轉移。
這種情況下主體服務器可能沒有任何問題，當未形成仲裁時，它會使主體數據庫脫機。它假定在這種情況下鏡像會執行故障轉移。為防止出現這種問題，應將主體服務器與見證服務器放置在一起，這樣可以在發生網絡故障時使主體服務器維持與見證服務器的仲裁。從而使主體數據庫保持可用。
見證服務器完全可選，但如果不存在見證服務器則不可能發生自動故障轉移，因此無法保證鏡像的數據庫的***可用性。對于其他方式，數據庫鏡像操作均相同。如果配置了見證服務器但由于某些原因它不可用，除了執行自動故障轉移的功能以外，鏡像功能不受影響。
每個數據庫鏡像會話也可以配置兩個見證服務器。為見證服務器角色增加更高冗余性的唯一方法是，在故障轉移群集中托管見證 SQL Server 實例。有關數據庫鏡像配置的詳細信息，請參見 TechNet 白皮書 SQL Server 2005 中的數據庫鏡像。
【編輯推薦】
