淺析SQL Server復(fù)制的向后兼容性
一、 在SQL Server 2008中不推薦使用事務(wù)復(fù)制的訂閱過期。
其實這個訂閱保持期就好像是一個“有效期”或者叫做“質(zhì)保期”。如果數(shù)據(jù)庫系統(tǒng)未能夠在有效的“質(zhì)保期”內(nèi)完成同步訂閱工作,則這訂約作業(yè)就會停用或者過期。如假設(shè)最大的分發(fā)保持期為72小時(這是SQLServer數(shù)據(jù)庫的默認(rèn)設(shè)置,管理員可以根據(jù)實際情況來調(diào)整),如果訂閱未能夠在72小時內(nèi)同步的話,而且分發(fā)數(shù)據(jù)庫中還存在尚未傳遞到訂閱服務(wù)器的更改,則訂閱作業(yè)將會被分發(fā)服務(wù)器上運行的“清除分發(fā)”作業(yè)標(biāo)記為停用。此時數(shù)據(jù)庫管理員如果要重新啟用這個訂閱功能的話,那么就必須重新初始化訂閱。
而在數(shù)據(jù)庫中,主要是這個sp_addpublication過程來控制這個訂閱周期。在這個存儲過程中,有一個@retention 屬性。這個屬性主要用來設(shè)置訂閱活動的保持期。默認(rèn)情況下這個屬性的值為336小時。如果訂閱活動在保持期內(nèi)不活動的話,則過期后系統(tǒng)就會將其自動刪除。一般來說,這個值可以大于發(fā)布服務(wù)期使用的分發(fā)數(shù)據(jù)庫的最大保持期。也就是說,他們具有一定的獨立性。如果數(shù)據(jù)庫管理員想讓訂閱永遠(yuǎn)不過期的話,則只需要將這個參數(shù)設(shè)置為0即可。不過根據(jù)微軟的官方資料可以知道,這個參數(shù)的話在以后的版本中可能會被逐漸的淘汰。因為這個屬性如果設(shè)置不當(dāng)?shù)脑?,會給合并復(fù)制造成一系列的不利影響,影響合并復(fù)制作業(yè)的穩(wěn)定性。為此數(shù)據(jù)庫管理員在部署復(fù)制作業(yè)時,最好不要使用這個參數(shù),以免跟后續(xù)的數(shù)據(jù)庫版本不兼容。
如果一定要使用這個參數(shù)的話,那么最好能夠遵循下面的一些建議。
一是如果采用合并復(fù)制,那么合并發(fā)布的保持期最好給一個寬限期。因為可能數(shù)據(jù)庫部署在不同的時區(qū),如果沒有寬限期的話,那么這些分布在不同時區(qū)中的訂閱服務(wù)器,運行起來就可能會出現(xiàn)問題。為此筆者建議,通常情況下需要給其一個24小時的寬限期。即使現(xiàn)在企業(yè)用不到,但是隨著后續(xù)規(guī)模的擴大,很有可能要在不同的國家設(shè)置數(shù)據(jù)庫服務(wù)器。如美國的企業(yè),可能會在國內(nèi)的辦事處設(shè)置一臺訂閱服務(wù)器,以提高辦公的效率。此時就應(yīng)該為其設(shè)置24小時的寬限期。
二是盡量不要將這個參數(shù)設(shè)置為0。如果把這個參數(shù)設(shè)置為0,就表示沒有保持期的限制。雖然這從某個程度來講,可以簡化數(shù)據(jù)庫管理員的維護工作。但是將這個參數(shù)的值設(shè)置為0,可能會產(chǎn)生一系列的負(fù)面效應(yīng)。如此時數(shù)據(jù)庫系統(tǒng)將無法刪除元數(shù)據(jù)等等。
為此,筆者的建議時,在實現(xiàn)復(fù)制服務(wù)時,最好不要采用這個參數(shù)。如果一定要用的話,那么要給其設(shè)置一個合理的寬限期;并且最好不要將這個參數(shù)設(shè)置為0。雖然這不是強制性的規(guī)定,但是為了復(fù)制服務(wù)能夠穩(wěn)定運行,各位數(shù)據(jù)庫管理員最好還是好好考慮筆者的這個建議。
二、 非SQL Server訂閱服務(wù)器的處理。
SQL Server數(shù)據(jù)庫在橫向的兼容性上表現(xiàn)還是不錯的。其不但可以支持SQL Server訂閱服務(wù)器,還能夠支持非SQLServer的訂閱服務(wù)器。如果企業(yè)需要采用非SQLServer的訂閱服務(wù)器,那么有兩個實現(xiàn)的渠道,分別為ODBC與OLE DB。不過由于ODBC其在性能、安全上都不如OLE DB接口,為此在后續(xù)的版本中,微軟數(shù)據(jù)庫可能不會再支持ODBC接口。所以在2008版本中實現(xiàn)訂閱服務(wù)器的話,那么最好不要再使用這個ODBC接口,而改用OLE DB接口。
到目前為止,SQL Server數(shù)據(jù)庫支持Oracle與IBMDB2兩個產(chǎn)品的訂閱服務(wù)期。如果要支持者兩個數(shù)據(jù)庫服務(wù)器的話,SQL Server現(xiàn)在已經(jīng)提供了比較完備的OLE DB訪問接口。為此數(shù)據(jù)庫管理員也不用再擔(dān)心接口不兼容的問題。不過采用這個非微軟的訂閱服務(wù)器,有比較多的限制條件。作為數(shù)據(jù)庫管理員要了解這些限制條件,并且在實際工作中一絲不茍的遵守它。類似的限制條件主要有以下幾個方面。
如果訂閱服務(wù)器即有SQL Server定于服務(wù)器,也有Oracle訂閱服務(wù)器或者其他非微軟的訂閱服務(wù)器,那么必須先為Oracle等非微軟的訂閱服務(wù)期啟用發(fā)布,然后再創(chuàng)建SQLServer訂閱服務(wù)器。數(shù)據(jù)庫管理員只要用四個字就可以記住這個規(guī)則,即客人優(yōu)先。另外,如果在這種混合型的訂閱服務(wù)器,則必須要使用OLE DB訪問接口,而不能夠采用ODBC訪問接口。而且運行分發(fā)代理時所使用的帳戶必須對OLE DB訪問接口的安裝目錄具有讀取的權(quán)限。這也是為什么筆者強烈推薦使用OLE DB訪問接口的原因。因為采用了這個接口之后,則以后如果要兼容其它訂閱服務(wù)器,就是一個水到渠成的事情。不需要經(jīng)過額外的調(diào)整與配置,就可以在對現(xiàn)有架構(gòu)影響不大的情況下部署非SQL Server的訂閱服務(wù)器。
另外需要注意的是,不同的數(shù)據(jù)庫處理NULL值的方式不同。為此采用不同牌子的訂閱服務(wù)器,可能會影響到空值、空字符串和NULL值的顯示方式,而且這個顯示方式又會影響在定義了唯一約束的列中插入值的行為。如在Oracle數(shù)據(jù)庫中,如果在某一列中設(shè)置為了唯一行約束,那么這個列仍然可以具有多個NULL值。但是在SQL Servre數(shù)據(jù)庫中則不同。只要這個列設(shè)置了唯一行約束,那么這個列就職能夠有一個Null值。所以,在混合型的訂閱服務(wù)器中,有時候還需要通過應(yīng)用程序或者其他手段來消除這種差異?;蛘咴跀?shù)據(jù)庫設(shè)計時,要有意識的避免這種情況,如禁用NULL值等等?;蛘呖梢愿鶲racle或者IBM DB2的數(shù)據(jù)庫管理員聯(lián)系。往往這些大牌的數(shù)據(jù)庫為了相互之間實現(xiàn)兼容,都會在數(shù)據(jù)庫中預(yù)先實現(xiàn)了一些措施,來防止各個操作系統(tǒng)處理機制不同所導(dǎo)致的兼容問題。
三、 合并復(fù)制過程中同時更新多列。
在合并復(fù)制到過程中,可能需要對目標(biāo)列同時進行更新。合并復(fù)制是支持這個功能的。在合并復(fù)制執(zhí)行更新時,數(shù)據(jù)庫會更新一個Update語句中指定的所有列,并將沒有更改的列重置為原先的值。不過合并復(fù)制更新往往涉及到比較多的記錄,為此其執(zhí)行速度會比較慢。為了提高這個執(zhí)行的速度,在2008以前的數(shù)據(jù)庫系統(tǒng)匯總,為此專門設(shè)置了一個fase_multicol_updateproc。如需要合并復(fù)制時,會建議數(shù)據(jù)庫管理員將這個選項設(shè)置為false,以提高合并復(fù)制更新的執(zhí)行效率。 [!--empirenews.page--]
不過在SQL Server 2008中,通過優(yōu)化器數(shù)據(jù)庫系統(tǒng)會自動對相關(guān)的合并復(fù)制更新語句進行優(yōu)化。而且這個優(yōu)化的效果比這個選賢設(shè)置為False還要明顯。雖然在2008數(shù)據(jù)庫中,為了向前兼容還存在這個參數(shù),不過其存在的實際意義已經(jīng)不大。為此數(shù)據(jù)庫管理員在需要各并復(fù)制更新時,不用為了提高其操作性能而再單獨的去設(shè)置這個參數(shù)。在以后的版本中,即使數(shù)據(jù)庫管理員設(shè)置了這個參數(shù),數(shù)據(jù)庫系統(tǒng)也會忽略掉。
可見無論是在對數(shù)據(jù)庫進行升級又或者部署最新版本的數(shù)據(jù)庫時,管理員不僅需要考慮到向前兼容的問題(原有的設(shè)計要能夠在新版數(shù)據(jù)庫中實現(xiàn)),同時也要考慮到數(shù)據(jù)庫系統(tǒng)的向后兼容(盡量避免使用過時的功能或者即將不用的參數(shù))。畢竟企業(yè)使用數(shù)據(jù)庫是一個長久的過程,如往往一用就是幾十年。在這么大的事件跨度內(nèi),不知道會出現(xiàn)多少個數(shù)據(jù)庫的版本。所以,數(shù)據(jù)庫的向后兼容與數(shù)據(jù)庫向前兼容一樣的重要。不過相對來說,向后兼容可能實現(xiàn)起來相對容易一點。只要數(shù)據(jù)庫管理員了解哪些參數(shù)或者功能可能在后續(xù)版本中被淘汰,就可以做好這個向后兼容性的工作。