SQL 問題與解答：備份和設定

本文轉載之：http://technet.microsoft.com/zh-cn/magazine/gg293114.aspx

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 的特定例項，資料庫映象會話數也沒有限制。

見證伺服器最好放置在與主體伺服器或映象伺服器不同的資料中心。但是，大多數公司並不具備三個資料中心，因此問題是應將見證伺服器與映象伺服器還是與主體伺服器放置在一起。

如果僅有兩個資料中心可用，應始終將見證伺服器與主體伺服器放置在一起。這與形成仲裁有關係。如果將見證伺服器與映象伺服器放置在一起，當主體伺服器失去網路連結時，見證伺服器和映象伺服器會形成仲裁併由映象伺服器啟動故障轉移。

這種情況下主體伺服器可能沒有任何問題，當未形成仲裁時，它會使主體資料庫離線。它假定在這種情況下映象會執行故障轉移。為防止出現這種問題，應將主體伺服器與見證伺服器放置在一起，這樣可以在發生網路故障時使主體伺服器維持與見證伺服器的仲裁。從而使主體資料庫保持可用。

見證伺服器完全可選，但如果不存在見證伺服器則不可能發生自動故障轉移，因此無法保證映象的資料庫的最高可用性。對於其他方式，資料庫映象操作均相同。如果配置了見證伺服器但由於某些原因它不可用，除了執行自動故障轉移的功能以外，映象功能不受影響。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/8183550/viewspace-682622/，如需轉載，請註明出處，否則將追究法律責任。