跨多個 SQL Server 版本的事務日誌傳送
我相信 TLS 僅適用於/支持相同版本的 SQL Server。
我要做的是在 SQL Server 2012 伺服器（以及其他客戶端 2008 R2 的情況下）上維護生產事務 SQL Server 2005 數據庫（180 Gb）的報告（只讀）版本。我可以隨時進行簡單的備份和恢復，但為了改善數據庫刷新之間的延遲，我想看看我是否可以執行諸如事務日誌傳送之類的操作。
如果在這種情況下 TLS 不可用，專家組建議的替代策略是什麼。
我相信 TLS 僅適用於/支持相同版本的 SQL Server。
讓我告訴你，事務日誌傳送只不過是將日誌記錄從一台伺服器傳輸到另一台伺服器，它很輕，你可以通過創建備份、複製和恢復作業來創建自己的“日誌傳送”。您正在嘗試做的一種方法可能是使用 TSQL。您將 SQL Server(SS) 2005 設為主要，將 SS2012/2008R2 設為次要，這可以實現，但請考慮以下場景：2005 數據庫伺服器由於任何原因而失敗，並且您將 SS2012/2008R2 聯機現在一切都很好，但是您會能夠使用來自 SS2012/2008R2 的更新數據使 SS 2005 聯機，您不能，因為無法在較低版本的數據庫上恢復較高版本的備份。所以這會導致我猜你不想要的數據失去。所以我建議你不要去這種情況。
我想說將您的 SQL Server 2005 升級到 2008 R2 或 SQL Server 2012，這是最好的做法。在所有情況下，高可用性版本不匹配都會給您帶來問題。話雖如此，如果這無法立即實現，請按照 RTO、RPO 安排適當的 SQL Server 2005 數據庫備份。當然，以 2005 為輔助配置 logshipping 也很好。
編輯：使用者在下面詢問後
我想避免大型備份和恢復週期，如果我無法做到這一點，這些週期將留給周末和通宵。
那麼在這種情況下，您可以使用差異備份來降低 RTO。這肯定會減少您在災難後恢復所有備份所需的總時間。還原順序將是完整備份，然後是 LATEST 差異備份，然後是按順序在最新差異備份之後進行的所有日誌備份。假設您在每天凌晨 12 點進行一次完整備份，每 4 小時進行一次差異備份，並且每 1 小時進行一次日誌備份。假設數據庫在下午 3:50 失敗。你會恢復
- 12點全備份。
2.12點差分備份
- 12 PM差異備份之後進行的日誌備份（1PM、2PM和3PM日誌備份）我認為這沒什麼大不了的。
這是您必須做的最低要求 Logshipping 不是這裡的解決方案。您可以創建自己的腳本來自動化恢復過程。
有文件系統備份也可以完成這項工作，它們對 mdf anf ldf 文件進行文件系統備份，災難發生後您只需要附加這些 mdf 和 ldf 文件，但文件系統備份無法及時恢復
是的，可以通過 sql server 數據庫複製來實現您的要求。目標伺服器必須與源伺服器版本相同或更高。
如果您需要“最新”更新，可以定期或連續執行複制。