SQLServer2005與Oracle10g轉(zhuǎn)換方法總結(jié)

字號:

此次需要完成的目標(biāo)是將庫從SQLServer 2005完整的移植到Oracle10g中,包括表結(jié)構(gòu)、數(shù)據(jù)、視圖、函數(shù)以及存儲(chǔ)過程的移植,移植主要基于Oracle的OMWB(Oracle Migration Workbench)來完成,盡管OMWB能幫助完成大部分具備難度的工作,但還是有很多工作量的事情需要在OMWB完成后來手工進(jìn)行,所以整個(gè)移植過程工作量看起來會(huì)非常大,但是不是僅僅只有工作量的問題呢?我覺得不是,寫下這篇blog以便需要進(jìn)行此項(xiàng)操作的同學(xué)以及給自己做個(gè)備忘。
     由于目前OMWB僅支持SQLServer2000,根據(jù)官方網(wǎng)站的消息,OMWB的下一版會(huì)推出對SQLServer 2005的支持,所以在目前的情況下只能先把庫從SQLServer 2005移植到SQLServer 2000,這就是我們移植過程的第一步了。
    一、SQLServer 2005-->SQLServer 2000
     一直以來,版本要降級都是很困難的,因?yàn)樵谛掳姹局斜厝粫?huì)有些新的特性,而如果剛好湊巧你使用到了這些特性的話,在降級到低版本時(shí)就會(huì)碰到一些問題,在經(jīng)過幾次的嘗試后,總結(jié)而言,這個(gè)過程還是比較容易做的,畢竟是同樣的數(shù)據(jù)庫,再怎么樣也不會(huì)出太大的問題,不過也沒有像將庫從SQLServer 2000升級為SQLServer 2005那么簡單,整個(gè)移植過程這么進(jìn)行:
    1、基于SQLServer 2005的數(shù)據(jù)導(dǎo)出將表結(jié)構(gòu)和數(shù)據(jù)導(dǎo)入到SQLServer 2000;
     這步中需要注意的是默認(rèn)情況下SQLServer會(huì)將表和視圖一起導(dǎo)入,在這里不要選擇視圖,否則導(dǎo)入到SQLServer 2000后有些視圖會(huì)變成表,選擇需要導(dǎo)入的表后基本上這步不會(huì)出現(xiàn)什么問題,可以完成表結(jié)構(gòu)和數(shù)據(jù)的移植。
    2、基于SQLServer 2005的生成腳本將視圖/函數(shù)/存儲(chǔ)過程移植到SQLServer 2000;
     這步需要慢慢來,因?yàn)樵谝晥D/函數(shù)/存儲(chǔ)過程中你可能使用到了一些SQLServer 2005的新特性,如果碰到這樣的情況,只能是手工進(jìn)行修改,以使它完全符合SQLServer 2000的要求,盡管在生成腳本時(shí)你可以選擇生成的目標(biāo)版本為SQLServer 2000,但還是會(huì)有部分腳本執(zhí)行是會(huì)出錯(cuò)的。
    在完成了SQLServer 2005到SQLServer 2000的移植后,就可以基于OMWB來把庫從SQLServer 2000移植到Oracle了,這步盡管有工具,還是會(huì)比較的麻煩,總結(jié)如下:
    二、SQLServer 2000-->Oracle 10g
    關(guān)于如何基于OMWB將庫從SQLServer 2000移植到Oracle 10g的操作步驟可參見此篇文檔:
    http://www.oracle.com/technology/global/cn/obe/10gr2_db_vmware/develop/omwb/omwb.htm
    大家現(xiàn)在從oracle官方站下的話可能會(huì)找不到sqlserver 2000的插件包,如果找不到的話可以從這里下載:
     我在這里要總結(jié)的是基于OMWB將庫從SQLServer 2000移植到Oracle 10g后還需要手工做的一些事情,不要指望OMWB能無縫的幫你把庫從SQLServer移植到Oracle中,銀彈是不存在的,因此我們需要做些手工的工作完成庫的移植:
    1、移植表結(jié)構(gòu)和數(shù)據(jù)可能會(huì)出現(xiàn)的問題;
     表中字段的默認(rèn)值/主鍵/外鍵/索引移植不過去,這些需要手工的進(jìn)行補(bǔ)充;
    2、移植視圖可能會(huì)出現(xiàn)的問題;
     移植過去的視圖可能會(huì)出現(xiàn)各種語法錯(cuò)誤的問題,這需要手工的修正,一般來說都是較為簡單的錯(cuò)誤;
     另外一種問題就是有些視圖可能會(huì)無法移植過去,這些視圖就只能在對比OMWB的移植報(bào)告后找出來手工的進(jìn)行移植了。
    3、移植函數(shù)/存儲(chǔ)過程可能會(huì)出現(xiàn)的問題;
     移植過去的函數(shù)/存儲(chǔ)過程中可能仍然會(huì)有不少的語法問題,例如像SCOPE_IDENTITY()、REPLICATE、newid()這些OMWB不知道該怎么處理的函數(shù),還有像返回Table類型的這種函數(shù),這些都只能在移植后手工的來進(jìn)行糾正,關(guān)于函數(shù)不同造成的語法錯(cuò)誤的現(xiàn)象大家可以參看這篇文檔來做SQLServer和Oracle函數(shù)的對照:
    http://www.mikecat.net/blogview.asp?logID=1559
     移植過去的函數(shù)/存儲(chǔ)過程可能編譯是沒有問題,也就是Oracle認(rèn)為沒有語法問題,但執(zhí)行起來卻會(huì)報(bào)錯(cuò),像字符串相加,經(jīng)過OMWB移植后有些字符串相加會(huì)替換成||,但是有些會(huì)遺漏,這個(gè)時(shí)候也只能手工來糾正這些錯(cuò)誤了;
     移植過去的函數(shù)/存儲(chǔ)過程在執(zhí)行過程中可能會(huì)出現(xiàn)某些表的主鍵值不能為空的現(xiàn)象,造成這種現(xiàn)象的原因多數(shù)為在SQLServer中該字段的默認(rèn)值定義的為IDENTITY,但在Oracle中沒法賦予這樣的默認(rèn)值,只能在插入的sql語句中加上對于主鍵字段的賦值,可采用sequence的方式來生成順序號;
     移植過去的函數(shù)/存儲(chǔ)過程中如果其中的查詢語句是采用字符串的方式,然后動(dòng)態(tài)執(zhí)行的話,這個(gè)時(shí)候的查詢語句就得手工修改為符合oracle的語法了,因?yàn)镺MWB在移植時(shí)是不會(huì)對字符串形式的查詢語句來做處理的;
     部分函數(shù)/存儲(chǔ)過程會(huì)由于OMWB確實(shí)無法處理,造成移植不到oracle,這個(gè)時(shí)候也必須參照OMWB的移植報(bào)告找出這些函數(shù)/存儲(chǔ)過程來手工移植了。
     整個(gè)移植過程可能會(huì)碰到比上面所列出的更多的別的問題,可以看出整個(gè)移植過程確實(shí)需要耗費(fèi)不小的工作量,但總體而言,完成的難度并不高。
     其實(shí)真的是這樣嗎?當(dāng)然不是,就算你完成了上面的移植工作,那也只能說表面看上去移植是完成了,很有可能會(huì)出現(xiàn)這個(gè)存儲(chǔ)過程語法等等都沒有問題了,但執(zhí)行的效果和SQLServer就是不一樣,這是為什么呢?可能會(huì)是因?yàn)镺racle和SQLServer在并發(fā)控制、事務(wù)機(jī)制上是不同的,而這會(huì)影響到程序調(diào)用時(shí)的sql的編寫、存儲(chǔ)過程的編寫等等,也就是說,在上面的移植過程的工作完成后,還得仔細(xì)檢查現(xiàn)在的sql語句/函數(shù)/存儲(chǔ)過程是否根據(jù)Oracle的機(jī)制達(dá)到了原來在SQLServer中期望的效果,只有做到這步的效果是一樣的,才可以說移植過程完成了。
    最后順帶說的就是應(yīng)該根據(jù)Oracle的機(jī)制來采用符合oracle優(yōu)化原則的方法來優(yōu)化表/視圖/函數(shù)/存儲(chǔ)過程,如果不做這步的話,從sqlserver移植到oracle估計(jì)意義也不大了,當(dāng)然,這可以不列為移植過程的工作