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