決定複製策略
我們的 SQL Server 2008R2（標準版）伺服器上有幾十個中小型 (<1Gb) 數據庫，每個月都會創建一個或兩個以上。伺服器本身是一個相當規範的任務盒；大量的處理器、記憶體、磁碟空間和吞吐量。不幸的是，我們沒有類似規格的 DBA 來諮詢內部 :(
所有數據庫目前都處於
SIMPLE恢復模式，部分原因是為了方便，主要是由於不了解FULL模式的工作原理。每天晚上都會備份數據庫（使用 BackupExec）。我們現在正在尋找在我們的 SQL 基礎架構中引入某種簡單冗餘的最佳方式；我們有一個與主伺服器類似規格的配套伺服器，如果主伺服器出現故障，可以快速投入使用。我們的要求是相當基本的：我們只需要一些機制，將數據庫的副本定期復製到另一台伺服器。我們不需要自動故障轉移，也不一定需要實時複製數據：每 5-15 分鐘一次就可以了，只要它也不影響主伺服器的性能沉重。
理想情況下，複製的數據庫將可用於報告等的只讀查詢。我已經查看並嘗試了以下選項：
- 複製。我在這方面度過了一段糟糕的時光：我們已經在伺服器之間複製了一個數據庫超過一年，儘管它在大多數情況下執行良好，但顯然沒有原因，複製每隔幾個月就會中斷一次。我已經花了幾個小時（幾天？）試圖找出原因，但是日誌是難以理解的，所有的建議似乎都指向了我每次必須做的最終事情——吹走複製和/或重新初始化。這對一個數據庫來說並不有趣；必須為可能的數十個數據庫半定期地執行此操作是不可能的。
- 鏡像。我玩過這個，它似乎執行良好，但鏡像副本數據庫仍處於恢復模式，因此不可用於查詢。
- 日誌文件傳送。我還沒有深入研究這個問題，但校長似乎很容易。似乎如果我將還原操作設置為“待機”，我可以讓輔助數據庫可用於只讀查詢。但是，我看到一些註釋表明，在這種模式下，恢復可能會很耗時，並且在恢復期間可能需要關閉連接，如果我們開始依賴可用的只讀副本，這可能會影響我們.
對上述任何一項都沒有太多經驗——我們之前只真正使用過複製，而且如上所述，我們的經驗並不好——我希望有人能就最佳使用策略向我提供建議。我是否應該考慮其他任何方法，或者任何可能有幫助的第三方軟體？我是不是太天真了，根本不可能滿足我們所有的（希望是適度的）要求？
我們不需要自動故障轉移，也不一定需要實時複製數據：每 5-15 分鐘一次就可以了。
您需要做的第一件事是將數據庫恢復模式更改為 FULL，因為簡單模式不支持日誌傳送。
在您的情況下，日誌傳送將是恕我直言的最佳選擇，無需升級到企業版（這取決於您的預算和其他要求）。
Logshipping 為您提供了將日誌備份恢復到至少 1 分鐘的靈活性，以滿足您的要求。
只要確保沒有人進行臨時日誌備份，因為它會破壞日誌鏈，導致日誌傳送失敗。
或者，您可以將輔助伺服器用於報告目的，將恢復日誌備份的選項設置為待機模式。
閱讀線上書籍的日誌運輸。