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 中的資料庫鏡像。

原文地址

查看更多相關文章

編輯精選】