SQL 問題與解答：備份和設置
SQL Server 是一個強大的平臺，但需要在考慮事務日誌設置和其他配置問題時注意技巧。
Paul S.Randal
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 中的数据库镜像。
.jpg)
**Paul S.**Randal是 SQLskills.com 常務董事、Microsoft 區域總監兼 SQL Server MVP。從 1999 年到 2007 年，他一直在 Microsoft 的 SQL Server 存儲引擎團隊工作。他曾編寫過 DBCC CHECKDB/repair for SQL Server 2005，並在 SQL Server 2008 的開發過程中負責核心存儲引擎部分的工作。Randal 是災難恢復、高可用性和資料庫維護方面的專家，經常在全球出席一些會議。您可以訪問他的博客 SQLskills.com/blogs/paul，也可以通過 Twitter (Twitter.com/PaulRandal) 與他聯繫。