我正在開發一個非常大的資料庫（250 多個演出），包含超過 2.25 億筆記錄。該資料庫因其龐大的規模而難以使用。該資料庫將僅用作唯讀。
我們正在尋求更快的硬件，但無論哪種方式，我都試圖找到使用資料庫的最有效方法。該資料庫必須每晚從主資料庫更新，且停機時間必須保持在最低限度。主資料庫由第三方維護。
我正在嘗試找到每晚有效更新資料庫的最佳方法，但我運氣不佳。我研究了差異備份和交易日誌備份，但為了應用其中任何一個，必須先還原完整資料庫備份。就我而言，這完全違背了差異備份的目的，因為它不會為我節省任何[停機]時間。我不妨每晚對主資料庫進行一次完整備份，然後簡單地恢復完整備份，這樣會更快。
我希望找到一種解決方案，可以完成一次完整備份（或可能每月一次），然後從那時起只需應用某種相互構建的增量備份（基於原始完整備份） 。這將使停機時間降至最低，因為一旦完成第一次完整備份，我只會每晚套用增量備份。為了速度，我會在每次「增量」備份後重建索引。我還沒有成功地找到任何像這樣真正可行的解決方案。
我嘗試過在測試資料庫上使用 STANDBY 進行完全恢復，這樣我就可以查詢數據，然後仍然應用交易日誌，並且僅應用交易日誌。這在某種程度上是有限的成功，因為我無法執行添加索引之類的操作，因為這在技術上是寫入資料庫。然而，這非常接近我正在尋找的內容，因為數據本身是唯讀的。有沒有任何解決方案可以這樣運作？我寧願避免使用 STANDBY 選項來執行此操作，因為它不應該以這種方式使用。
我現在剛剛深入研究資料庫備份和效能並進行了大量研究，不斷閱讀 MSDN - 但似乎這個解決方案不是一個選擇。我想我會問作為最後的手段 - 當然這裡有一些管理大型資料庫，每晚進行恢復是不切實際的。
有什麼建議麼？我也願意接受有關性能的建議/鏈接，因為我從未使用過如此大小的資料庫。
恐怕複製可能是唯一的答案。
答案1
日誌傳送滿足了我們保持主（300 GB）資料庫可用的需求，並將日誌傳送到另一台伺服器上的備用副本。交易日誌每 15 分鐘應用一次。我們的報告使用備用副本。