在 SQL Server 2014 到 SQL Server 2005 之間複製數據 - 臨時解決方案
我將安裝一個新的 SQL Server 2014 數據庫系統，它基於我們目前的 SQL Server 2005 數據庫系統。當我們上線時，新系統將在一個全新的基礎架構上，如果我們遇到任何問題，目前的基礎架構可以用於回滾。
業務要求至少有 2 週的回滾選項可用。因此，如果發生災難情況，我們將需要切換回 SQL Server 2005 數據庫系統。所以我面臨的挑戰是在 SQL Server 2014 數據庫系統上線時複製數據。
我正在尋找一種將數據（不一定是架構）從 SQL Server 2014 系統複製到 SQL Server 2005 系統的方法。
我不是 SQL Server 複製的真正粉絲，我的偏好是不使用它。我的理解是，這對我們來說無論如何都不是一個選擇，因為版本相距太遠，因此不受支持。
我想與社區聯繫，了解是否有任何工具可用於實現此類複製。如果這有助於找到正確的解決方案，我們可能會實施模式更改凍結。
如果有的話，您能告訴我們有哪些選擇嗎？還是我們應該尋求在內部開發一個定制系統？
您是否知道任何 Microsoft 合作夥伴可以通過已經開發的解決方案為我們實現這一目標？
提前感謝您的任何建議。
喬
閱讀您的問題並更多地考慮可能的解決方案使我推薦事務複製。
確保您確實對您的架構實施了更改凍結。
來自BOL：
對於事務複製，**事務發布的訂閱者可以是發布者版本的兩個版本中的任何版本。**例如，SQL Server 2000 發布者可以有 SQL Server 2008 訂閱者，而 SQL Server 2008 發布者可以有 SQL Server 2000 訂閱者。
基於以上事實，
- 備份您目前的 sql server 2005 數據庫，並確保您在所有伺服器上啟用了即時文件初始化。
- 凍結所有數據和架構更改**<-這是您的停機時間。**
- 將您的數據庫從 sql server 2005 遷移到 2014 並執行所有恢復後步驟。
- 將您的應用程序重新指向新的伺服器實例。
- 設置從 sql server 2014 到 sql server 2008R2 的 T-Rep（這將是一個中間伺服器或實例，如果你願意，可以在同一個新伺服器上）。你關心這一步，因為你想在受支持的版本上。確保使用 tsql手動初始化複製。
- 現在有另一層從 sql server 2008 R2（中間）複製到您的 sql server 2005 伺服器。確保使用 tsql 手動初始化複製。
**注意：**如果伺服器在同一個數據中心，那麼你甚至可以做一個非常快的快照。
上述練習是值得的，因為您需要一個受支持的回滾計劃。由於您的企業希望將事情保留 2 週，因此一旦您進行了上述測試，您應該會很好。
**注意：**我沒有嘗試過（因為我沒有遇到過必須將數據從 sql server 2014 複製到 2005 的情況），但理論上它應該可以工作（儘管不支持）。試一試小型數據庫，您將能夠輕鬆衡量所需的工作量。
您選擇什麼將取決於您可以停機多長時間以及您可以忍受多少數據失去。
如果您沒有很多 INSERT 數據進入（更新很好），您可以查看有多少數據失去是可以接受的，並編寫出兩者之間的差異。您可以使用SQL Data Compare之類的程序來比較兩者的備份，並讓它編寫出您必須在舊版本上執行的所有更改並讓它“部署”它們。我沒有針對不同版本的備份對此進行測試，但我不明白為什麼它不起作用，我們必須先徹底測試它。
即使您有大量的 INSERT 數據並且它增長很快，如果 SQL 數據比較在具有適當資源的穩定機器上也可以很好地工作。您甚至可以每天或每小時在“準備好熱備”系統上進行數據比較同步，從而減少數據負載。如果您可以接受的數據失去是 20 分鐘，那麼每 15 分鐘同步一次，假設您的實時數據庫可以處理它。
繞過鎖定： 您始終可以將生產副本記錄到其他地方並同步到該位置，這樣您就不會在讀取數據時阻止 prod 讀/寫，因為這將是一個問題。您可以快照並比較快照，這樣您就不會阻止寫入，但是在產品上如此頻繁地拍攝快照並不是它的設計方式。
便宜的選擇
假設您可接受的數據失去時間為 20 分鐘。您每 15 分鐘進行一次事務日誌備份（當然還要對其進行測試），並且每晚進行一次經過測試的完全備份（如果沒有經過測試，我們如何確保只有 20 分鐘的數據失去）。假設您發生了崩潰並且它崩潰了。
然後，您將：
- 恢復 2014 年數據的完整備份。
-恢復2014年的交易記錄。
測試您的舊 SQL 2005 備份後，打開 RedGate SQL 比較。
將 2014 年數據與 2005 年數據進行比較。
將 2014 年的數據更改推送到 2005 年。
如果您需要比這更快的恢復，請查看 SQL 數據比較命令行工具，它們非常簡單且易於自動化，只需注意在上面列出的產品系統上進行臨時大讀取的風險。您最好從鏡像對的快照或負載之間的事務日誌傳送對中執行此操作。否則，您實際上可能會導致人們無法訪問數據的問題！
昂貴的選擇：
其他選項是創建將數據寫入兩個不同端點的數據庫應用程序代理或防火牆。戴爾有一個 ETL 工具，它是 Oracle 獨有的，它為此提供 SQL Server，一家新興公司 ScaleArc 也是如此。這些需要相當多的投資、調整和維護。它們不是為“1 off”解決方案而創建的。