如果你計劃將數據庫從SQL Server 2000 升級到 SQL Server 2005。你在升級之前一定會測試每樣東西，並且證明應用程序是穩定的。即使這樣，如果升級之後發生任何問題的話，你仍然會想要確保你仍然可以回退到原來的環境中去，並且保證不丟失任何的數據修改。
這篇文章列出了保持原有數據(SQL Server 2000)中數據最新，直到新的環境被證明是最棒的方法。
保持原有SQL Server環境最新的方法：
在SQL Server中，有一些方法可以用來復制數據修改到另外一個數據庫中去：
1、日志傳送
2、拷貝數據庫任務
3、復制(事務，快照)
4、SQL 追蹤
5、編程(觸發器、DTS，BCP等)
6、第三方工具
下面我們來討論其中的三種方法：
日志傳送
我們可以在SQL Server 2005數據庫(主數據庫)和SQL Server 2000數據庫(從數據庫)之間傳送日志嗎?
我努力在因特網上尋找這個問題的積極答案，但是很不走運。然後我試圖自己創造性地尋找一種解決方法，使用產品自帶的標准工具。也沒有門，天啊……我只能在第二個數據庫中使用WITH NORECOVERY將日志從SQL Server 2000 傳送到SQL Server 2005，沒有其他辦法。所以，答案是“沒有”，使用日志傳送是不現實的。
拷貝數據庫
不幸的是，當開啟拷貝數據庫向導的時候，當源和目標版本不同的時候，你就會收到錯誤信息，不能繼續下去。
復制
事務復制
事務復制是在兩個版本之間工作的。這個解決方案有兩個問題：
有一些SQL Server的版本不能作為PRIMARY 或者DISTRIBUTOR參加復制模型，《SQL Server 2005 Features Comparison》一書中對此有詳細描述。
沒有定義Unique鍵的表不能參加這個模型。
快照復制
這個解決方案有效，但是也有幾項例外。例如，如果表中有用戶自定義數據類型，並且必須在表被創建之前創建，那麼由於在SQL Server2000沒有CREATE TYPE這個命令，就會失敗。
SQL 追蹤
用SQL Server Profiler 或者SQL Trace可以捕捉到工作量，並且導出到 SQL 腳本中。腳本可以在從數據庫中再次運行。
這個解決方案存在的問題包括：
1、執行的命令是有一定順序的。如果一個事務在一個單獨的執行中被打開或者關閉了，而這個操作不是這一系列命令中的一個，那麼腳本就無法使其發生關系，因為“會話”無法被Traces識別了。
2、如果在兩個版本之間，命令語法有區別，那麼在從數據庫中的執行一定會失敗。
編程
如果你有一小批數據庫要移植，那麼你可能會考慮編寫一個數據庫組件來傳輸數據的修改。
示例：
· 使用觸發器——這可能會影響性能，因為觸發器是事務的一部分。
· 使用DTS或者BCP來傳輸數據——這種方法在很大程度上依賴數據量的大小。
第三方工具
你可以使用第三方工具，例如Log Readers來從事務日志、腳本中讀取SQL 命令，然後在從數據庫中執行它們。還有，雖然我無法自己找到這樣的一個工具，但是在SQL Server 2005中肯定會有一個工具能夠備份事務日志，並且在SQL Server2000中順利地重新存儲它們。
其它
你還可以創新……
例如，在某些情況下，你可以將日志傳送到從SQL Server 2005數據庫中，把它的兼容級別改為80，然後備份並重新存儲到第三個數據庫中去。
結論
對於關鍵的數據庫，保留要升級的數據庫的舊的版本，以及最新的數據修改，以便在需要回滾的時候用到，確實是個好主意。
但是……任何事物都沒有“最好的解決方法”。你必須分析你的數據庫特點和結構，然後決定針對你的需求的最佳解決方法。就我個人來說，我傾向於認為復制是最快最可靠的解決方法。
