雖然說SQL Server 2008到目前為止已經算是新版本的數據庫系統了。但是其以後還會不斷的更新換代。為此在部署SQL Server 2008的時候，數據庫管理員仍然需要考慮到向後兼容性的問題。為了減少以後升級的麻煩，數據庫管理員有必要了解這個話題。具體來說，就是要了解SQLServer2008的數據庫版本中，哪些功能可能在以後的數據庫版本中會被拋棄。然後數據庫管理員在部署這些功能時，要慎重。能夠不用就不用，或者用其他功能來代替。免得在以後數據庫升級過程中，再來進行調整。筆者現在就以數據復制功能為例，談談如何做好這個向後的兼容性。
一、 在SQL Server 2008中不推薦使用事務復制的訂閱過期。
其實這個訂閱保持期就好像是一個“有效期”或者叫做“質保期”。如果數據庫系統未能夠在有效的“質保期”內完成同步訂閱工作，則這訂約作業就會停用或者過期。如假設最大的分發保持期為72小時(這是SQLServer數據庫的默認設置，管理員可以根據實際情況來調整)，如果訂閱未能夠在72小時內同步的話，而且分發數據庫中還存在尚未傳遞到訂閱服務器的更改，則訂閱作業將會被分發服務器上運行的“清除分發”作業標記為停用。此時數據庫管理員如果要重新啟用這個訂閱功能的話，那麼就必須重新初始化訂閱。
而在數據庫中，主要是這個sp_addpublication過程來控制這個訂閱周期。在這個存儲過程中，有一個@retention 屬性。這個屬性主要用來設置訂閱活動的保持期。默認情況下這個屬性的值為336小時。如果訂閱活動在保持期內不活動的話，則過期後系統就會將其自動刪除。一般來說，這個值可以大於發布服務期使用的分發數據庫的最大保持期。也就是說，他們具有一定的獨立性。如果數據庫管理員想讓訂閱永遠不過期的話，則只需要將這個參數設置為0即可。不過根據微軟的官方資料可以知道，這個參數的話在以後的版本中可能會被逐漸的淘汰。因為這個屬性如果設置不當的話，會給合並復制造成一系列的不利影響，影響合並復制作業的穩定性。為此數據庫管理員在部署復制作業時，最好不要使用這個參數，以免跟後續的數據庫版本不兼容。
如果一定要使用這個參數的話，那麼最好能夠遵循下面的一些建議。
一是如果采用合並復制，那麼合並發布的保持期最好給一個寬限期。因為可能數據庫部署在不同的時區，如果沒有寬限期的話，那麼這些分布在不同時區中的訂閱服務器，運行起來就可能會出現問題。為此筆者建議，通常情況下需要給其一個24小時的寬限期。即使現在企業用不到，但是隨著後續規模的擴大，很有可能要在不同的國家設置數據庫服務器。如美國的企業，可能會在國內的辦事處設置一台訂閱服務器，以提高辦公的效率。此時就應該為其設置24小時的寬限期。
二是盡量不要將這個參數設置為0。如果把這個參數設置為0，就表示沒有保持期的限制。雖然這從某個程度來講，可以簡化數據庫管理員的維護工作。但是將這個參數的值設置為0，可能會產生一系列的負面效應。如此時數據庫系統將無法刪除元數據等等。
為此，筆者的建議時，在實現復制服務時，最好不要采用這個參數。如果一定要用的話，那麼要給其設置一個合理的寬限期;並且最好不要將這個參數設置為0。雖然這不是強制性的規定，但是為了復制服務能夠穩定運行，各位數據庫管理員最好還是好好考慮筆者的這個建議。
二、 非SQL Server訂閱服務器的處理。
SQL Server數據庫在橫向的兼容性上表現還是不錯的。其不但可以支持SQL Server訂閱服務器，還能夠支持非SQLServer的訂閱服務器。如果企業需要采用非SQLServer的訂閱服務器，那麼有兩個實現的渠道，分別為ODBC與OLE DB。不過由於ODBC其在性能、安全上都不如OLE DB接口，為此在後續的版本中，微軟數據庫可能不會再支持ODBC接口。所以在2008版本中實現訂閱服務器的話，那麼最好不要再使用這個ODBC接口，而改用OLE DB接口。
