如何由Sybase向SQL Server移植數(shù)據(jù)庫
2024-08-31 00:52:06
供稿：網(wǎng)友
最近參與了將一個Sybase數(shù)據(jù)庫移植到Microsoft SQL Server 2000上的項目，我在這一項目上獲得的經(jīng)驗，將對Sybase數(shù)據(jù)庫治理員把Sybase數(shù)據(jù)庫移植到SQL Server 2000平臺上有一定的幫助。
盡管二者之間的一些差別是相當(dāng)大的，例如Sybase數(shù)據(jù)庫治理系統(tǒng)中的存儲過程在SQL Server就不能被編譯，而其它差別則不太大。在完成這一轉(zhuǎn)換前，對腳本文件和存儲過程中編程邏輯的行為和結(jié)果進(jìn)行測試是很有必要的。
在下面的部分中，我們將討論這二種數(shù)據(jù)庫系統(tǒng)之間的一些主要的不同點(diǎn)，在移植的規(guī)劃階段，我們必須仔細(xì)研究這些區(qū)別。
數(shù)據(jù)兼容模式
對SQL Server 2000和Sybase之間的一些兼容性差別的一個臨時性解決方案是改變SQL Server中的數(shù)據(jù)庫兼容性級別，使之與Sybase相符。為此，我們可以使用sp_dbcmptlevel存儲過程。
下面表中的語句和結(jié)果顯示出不同版本數(shù)據(jù)庫之間的差別：
（Untitled-1）
注重：
1、當(dāng)兼容性模式被設(shè)置為70時，下面的詞匯不能被用作對象名和標(biāo)識符：BACKUP、DENY、PRECENT、RESTORE和TOP。
2、當(dāng)兼容性模式被設(shè)置為65時，下面的詞匯不能被用作對象名和標(biāo)識符：AUTHORIZATION、CASCASE、CROSS、DISTRIBUTED、ESCAPE、FULL、INNER、JOIN、LEFT、OUTER、PRIVILEGES、RESTRICT、RIGHT、SCHEMA和WORK。
下面是sp_dbcmptlevel的語法：
sp_dbcmptlevel [[@dbname=] name][,[@new_cmptlevel=]version]
@dbname是用于檢查和改變兼容性水平的數(shù)據(jù)庫名字。
@new_cmptlevel決定數(shù)據(jù)庫被設(shè)置的兼容性水平（將它設(shè)置為70、65、60，缺省值為NULL）。
例如：
sp_dbcmptlevel pubs
這一行代碼返回下面的結(jié)果：
The current compatibility level is 70.（當(dāng)前的兼容性級別為70。）
現(xiàn)在我們來看一下另外一個例子：
sp_dbcmptlevel pubs, 65
它返回如下的結(jié)果：
DBCC execution completed. （DBCC執(zhí)行結(jié)束。）
果DBCC打印出錯誤信息，則需要與系統(tǒng)治理員聯(lián)系。我們可以使用rerunsp_dbcmptlevel驗證pubs數(shù)據(jù)庫是否修改得正確：
sp_dbcmptlevel pubs
它返回下面的結(jié)果：
The current compatibility level is 65（當(dāng)前的兼容性級別為65。）
除了上面的例子外，兼容性級別的差別還擴(kuò)展到了保留字。Sybase和SQL Server都有許多不能被用作數(shù)據(jù)庫中對象名字的的保留字，二種產(chǎn)品的保留字相似，但并不完全相同。
由于能夠在Sybase中使用的對象可能不能在SQL Server中使用，這一問題使得由Sybase向SQL Server的移植憑添了許多困難。下面是在SQL Server中是保留字，而在Sybase中不是保留字的詞匯清單。
注重：名字為下列清單中詞匯的Sybase數(shù)據(jù)庫中的對象在移植到SQL Server數(shù)據(jù)庫時必須換為其它名字。
BACKUP COLUMN COMMITTED CONTAINS CONTAINSTABLE
CROSS CURRENT_DATE CURRENT_TIME CURRENT_TIMESTAMP CURRENT_USER
DENY DISTRIBUTED FILE FLOPPY FREETEXT
FREETEXTTABLE FULL IDENTITYCOL INNER JOIN
事務(wù)治理模式
Sybase SQL Server
Set chained [ on : off ] Set implicit_transactions [on : off ]
在Sybase中使用下面的代碼判定事務(wù)模式：
SELECT @@tranchained
GO
下面是可能返回的結(jié)果：
0 表明使用的是非鏈鎖式事務(wù)模式
1 表明連接運(yùn)行在鏈鎖模式下
在SQL Server中使用下面的代碼判定事務(wù)模式：
IF (@@options & 2) > 0
PRINT on
ELSE
PRINT off
下面是可能的返回結(jié)果：
0 off
>0 on
隔離水平
在一個關(guān)系數(shù)據(jù)庫這樣的多線程應(yīng)用軟件中，數(shù)據(jù)庫引擎對運(yùn)行的進(jìn)程間的數(shù)據(jù)是如何被隔離的治理是非常重要的，在表示隔離水平時，Sybase和SQL Server的語法是不同的。下面的表格表明了Sybase和SQL Server在表示隔離水平時的差別。
Sybase SQL Server
0 READ UNCOMMITTED
1 READ COMMITTED
2 REPEATABLE READ
3 SERIALIZABLE
游標(biāo)語法
二種產(chǎn)品中存儲過程的創(chuàng)建和執(zhí)行基本相似，但在移植時，游標(biāo)語句中的一些例外是我們應(yīng)當(dāng)注重的。下面是一個例子：
CREATE PROCEDURE sql_cursor AS
DECLARE @lname char(20), @fname char(20)
DECLARE mycursor CURSOR FOR
SELECT au_lname, au_fname FROM authors
OPEN mycursor
FETCH FROM mycursor INTO @lname, @fname
WHILE @@ FETCH_STATUS = 0
/* Sybase數(shù)據(jù)庫使用@SQLSTATUS而不是@@ FETCH_STATUS */
BEGIN
FETCH FROM mycursor INTO @lname, @fname
/*
** 這里應(yīng)當(dāng)是一些業(yè)務(wù)邏輯
*/
END
CLOSE mycursor
DEALLOCATE /* Sybase數(shù)據(jù)庫在這里需要CURSOR這個詞 * / mycursor
Sybase SQL Server
Fetch命令執(zhí)行成功 0 0
Fetch命令執(zhí)行失敗 1 -2
沒有可存取的記錄了 2 -1
退回觸發(fā)器
SQL Server中不存在這個命令，因此在向SQL Server移植時，使用了ROLLBACK TRIGGER命令的Sybase存儲過程必須被進(jìn)行修改。在修改帶有觸發(fā)器的數(shù)據(jù)庫表中的數(shù)據(jù)時，使用ROLLBACK TRIGGER命令輕易引起誤解，一個ROLLBACK TRIGGER命令只退回觸發(fā)器以及觸發(fā)觸發(fā)器的數(shù)據(jù)修改，假如已經(jīng)被提交了，則事務(wù)的其它部分會繼續(xù)，被寫到數(shù)據(jù)庫中。因此，事務(wù)中的所有語句可能沒有被成功地完成，但數(shù)據(jù)已經(jīng)被提交了。
下面是Sybase數(shù)據(jù)庫中一個使用ROLLBACK TRIGGER的樣例觸發(fā)器：
CREATE TABLE table1 (a int, b int)
GO
CREATE TRIGGER trigger1 on table1 FOR INSERT
AS
IF EXISTS (SELECT 1 FROM inserted WHERE a = 100)
BEGIN
ROLLBACK TRIGGER with RAISERROR 50000 Invalid value for column a
END
INSERT INTO table2
SELECT a, GETDATE() from inserted
RETURN
GO
在上面的代碼中，除非a = 100，則所有插入table1的數(shù)據(jù)也被作為審計行插入table2中，假如a = 100，ROLLBACK TRIGGER命令被觸發(fā)，而INSERT命令沒有被觸發(fā)，批命令的其它部分繼續(xù)執(zhí)行，這時會出現(xiàn)錯誤信息，表明在一個INSERT命令中出現(xiàn)了錯誤。下面是所有的INSERT命令：
BEGIN TRAN
INSERT INTO table1 valueS (1, 1)
INSERT INTO table1 valueS (100,2)
INSERT INTO table1 valueS (3, 3)
GO
SELECT * FROM table1
在執(zhí)行這些命令后，table1和table2二個數(shù)據(jù)庫表將各有2個記錄，Table1表中的值為1，1以及3，3，由于ROLLBACK TRIGGER命令，第二個INSERT命令沒有執(zhí)行；Table2表中的值為1，（當(dāng)前日期）以及3，（當(dāng)前日期），由于當(dāng)a = 100時ROLLBACK TRIGGER被觸發(fā)，觸發(fā)器中的所有處理被中止，100沒有被插入到Table2表中。
在SQL Server中模擬這一操作需要更多的代碼，外部的事務(wù)必須與保存點(diǎn)同時使用，如下所示：
CREATE trigger1 on table1 FOR INSERT
AS
SAVE TRAN trigger1
IF EXISTS (SELECT * FROM inserted WHERE a = 100)
BEGIN
ROLLBACK TRAN trigger1
RAISERROR 50000 ROLLBACK
END
INSERT INTO table2
SELECT a, GETDATE() FROM inserted
GO
這一觸發(fā)器以一個存儲點(diǎn)開始，ROLLBACK TRANSACTION只退回觸發(fā)邏輯，而不是整個事務(wù)（規(guī)模要小于Sybases數(shù)據(jù)庫中的ROLLBACK TRIGGER語句。對批命令的修改如下：
BEGIN TRAN
SAVE TRAN save1
INSERT INTO table1 valueS (1, 1)
IF @@error = 50000
ROLLBACK TRAN save1
SAVE TRAN save2
INSERT INTO table1 valueS (100, 1)
IF @@error = 50000
ROLLBACK TRAN save2
SAVE TRAN save3
INSERT INTO table1 valueS (3, 3)
IF @@error = 50000
ROLLBACK TRAN save3
COMMIT TRAN
我們可以發(fā)現(xiàn)，改變不可謂不大。由于ROLLBACK TRIGGER命令能夠使任何批命令不能成功執(zhí)行，因此在移植的SQL Server存儲過程代碼中必須包括另外的邏輯，根據(jù)ROLLBACK TRIGGER的使用，這可能是一個艱巨而必要的任務(wù)，沒有什么捷徑可走。假如在移植后所有的ROLLBACK TRIGGER命令被改變?yōu)镽OLLBACK TRANSACTION，觸發(fā)器的執(zhí)行也會發(fā)生變化，因此我們應(yīng)當(dāng)十分小心。
命令優(yōu)化
SQL Server能夠?qū)ELECT、INSERT、UPDATE和DELETE命令進(jìn)行優(yōu)化，Sybase數(shù)據(jù)庫則只支持對SELECT命令進(jìn)行優(yōu)化。下面是SQL Server和Sybase在GUI方面的對比：
Sybase SQL Server
使用被稱作SHOWPLAN的基于文本的查詢分析工具 使用Query Analyzer。
在ISQL中啟動SHOWPLAN的命令按鈕 多Query Analyzer中啟動SHOWPLAN_ALL或 SHOWPLAN_TEXT的命令
SET SHOWPLAN ON SET SHOWPLAN_ALL
GO GO
臨時數(shù)據(jù)庫表的名字
表名字的類型 最大長度
SQL Server表名字 128
SQL Server臨時表名字 116
Sybase表名字 30
Sybase臨時表名字 13
數(shù)據(jù)類型
數(shù)據(jù)類型 Sybase SQL Server
char(n) 255 8000
varchar(n) 255 8000
nchar(n) 255 4000
nvarchar(n) 255 4000
binary 255 8000
varbinary 255 8000
注重：
1）SQL Server中的bit類型數(shù)據(jù)的值可以被設(shè)置為0、1或NULL。
2) Sybase中的bit類型數(shù)據(jù)的值不可以被設(shè)置為NULL。
同一性列
Sybase SQL Server
Numeric(x,0) Tinyint,smallint,int,decimal(x,0) or numeric(x,0)
打印語法
在進(jìn)行移植時，所有使用替換語法的打印語句必須被改變?yōu)镽AISERROR語句。
結(jié)論
將Sybase數(shù)據(jù)庫轉(zhuǎn)換為SQL Server數(shù)據(jù)庫并非是不可能的，但二種產(chǎn)品之間存在許多差異，在轉(zhuǎn)換時需要加以解決。根據(jù)應(yīng)用程序的規(guī)模，這種轉(zhuǎn)換可能需要大量的時間。盡管無需重新編寫所有的應(yīng)用程序，但需要完成的工作并不少。
我目前還沒有發(fā)現(xiàn)這二種數(shù)據(jù)庫間轉(zhuǎn)換的更簡單的方法。由于二種產(chǎn)品在許多方面都非常相似，我們非常輕易成功地將Sybase數(shù)據(jù)庫轉(zhuǎn)換為SQL Server數(shù)據(jù)。
