淺析SQL Server複製的向後相容性

雖然說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介面。

到目前為止，SQL Server資料庫支援Oracle與IBMDB2兩個產品的訂閱服務期。如果要支持者兩個資料庫伺服器的話，SQL Server現在已經提供了比較完備的OLE DB訪問介面。為此資料庫管理員也不用再擔心介面不相容的問題。不過採用這個非微軟的訂閱伺服器，有比較多的限制條件。作為資料庫管理員要了解這些限制條件，並且在實際工作中一絲不苟的遵守它。類似的限制條件主要有以下幾個方面。

如果訂閱伺服器即有SQL Server定於伺服器，也有Oracle訂閱伺服器或者其他非微軟的訂閱伺服器，那麼必須先為Oracle等非微軟的訂閱服務期啟用釋出，然後再建立SQLServer訂閱伺服器。資料庫管理員只要用四個字就可以記住這個規則，即客人優先。另外，如果在這種混合型的訂閱伺服器，則必須要使用OLE DB訪問介面，而不能夠採用ODBC訪問介面。而且執行分發代理時所使用的帳戶必須對OLE DB訪問介面的安裝目錄具有讀取的許可權。這也是為什麼筆者強烈推薦使用OLE DB訪問介面的原因。因為採用了這個介面之後，則以後如果要相容其它訂閱伺服器，就是一個水到渠成的事情。不需要經過額外的調整與配置，就可以在對現有架構影響不大的情況下部署非SQL Server的訂閱伺服器。

另外需要注意的是，不同的資料庫處理NULL值的方式不同。為此採用不同牌子的訂閱伺服器，可能會影響到空值、空字串和NULL值的顯示方式，而且這個顯示方式又會影響在定義了唯一約束的列中插入值的行為。如在Oracle資料庫中，如果在某一列中設定為了唯一行約束，那麼這個列仍然可以具有多個NULL值。但是在SQL Servre資料庫中則不同。只要這個列設定了唯一行約束，那麼這個列就職能夠有一個Null值。所以，在混合型的訂閱伺服器中，有時候還需要通過應用程式或者其他手段來消除這種差異。或者在資料庫設計時，要有意識的避免這種情況，如禁用NULL值等等。或者可以跟Oracle或者IBM DB2的資料庫管理員聯絡。往往這些大牌的資料庫為了相互之間實現相容，都會在資料庫中預先實現了一些措施，來防止各個作業系統處理機制不同所導致的相容問題。

三、 合併複製過程中同時更新多列。

在合併複製到過程中，可能需要對目標列同時進行更新。合併複製是支援這個功能的。在合併複製執行更新時，資料庫會更新一個Update語句中指定的所有列，並將沒有更改的列重置為原先的值。不過合併複製更新往往涉及到比較多的記錄，為此其執行速度會比較慢。為了提高這個執行的速度，在2008以前的資料庫系統彙總，為此專門設定了一個fase_multicol_updateproc。如需要合併複製時，會建議資料庫管理員將這個選項設定為false，以提高合併複製更新的執行效率。

不過在SQL Server 2008中，通過優化器資料庫系統會自動對相關的合併複製更新語句進行優化。而且這個優化的效果比這個選賢設定為False還要明顯。雖然在2008資料庫中，為了向前相容還存在這個引數，不過其存在的實際意義已經不大。為此資料庫管理員在需要各並複製更新時，不用為了提高其操作效能而再單獨的去設定這個引數。在以後的版本中，即使資料庫管理員設定了這個引數，資料庫系統也會忽略掉。

可見無論是在對資料庫進行升級又或者部署最新版本的資料庫時，管理員不僅需要考慮到向前相容的問題(原有的設計要能夠在新版資料庫中實現)，同時也要考慮到資料庫系統的向後相容(儘量避免使用過時的功能或者即將不用的引數)。畢竟企業使用資料庫是一個長久的過程，如往往一用就是幾十年。在這麼大的事件跨度內，不知道會出現多少個資料庫的版本。所以，資料庫的向後相容與資料庫向前相容一樣的重要。不過相對來說，向後相容可能實現起來相對容易一點。只要資料庫管理員瞭解哪些引數或者功能可能在後續版本中被淘汰，就可以做好這個向後相容性的工作。