.NET框架下Oracle到SQL Server遷移

如果你正在營造微軟 .NET 網路而後端執行著 Oracle 資料庫，那麼你應該把後端遷移到 SQL Server。這一問題的核心不在於比較資料庫的效能而是尋求最適合你的工具。在 .NET 體系結構下要回答這兩個問題，答案只有一個，那就是 .NET Server。在這篇文章裡，我們首先探究下為什麼你的網路中存在 Oracle 伺服器，然後討論如何將其遷移到 SQL Server，最後闡述由這一舉措所能獲得的利弊。

系統中的Oracle

如果在你的網路中存在 Oracle 伺服器，你需要搞清楚為什麼需要它的理由——誰在使用它，什麼應用程式要用到它，在它上面正執行著什麼應用程式等等。

誰在使用它？

首先你應該搞清楚誰在使用Oracle伺服器。否則還沒有得出答案就匆匆搬走伺服器很可能會促成大錯。當然，真要這麼做倒也是一種很快就能找出資料庫使用者的方法。但我們還是勸你萬萬不可。

網路管理員可能有監視或記錄Oracle使用情況的執行過程。開發人員可能要採用當前的伺服器開發應用程式。經理們可能要根據資料庫儲存的資料得出分析報告或利用 Oracle 後端做出企業決策。而且資料庫的使用者完全可能遍及世界各地。在確定因從 Oracle 到 SQL Server這一遷移過程而受到影響的使用者之時，你必須考慮到以上所有這些可能性。

什麼應用程式要用到它？

現在假設你一個挨一個地問遍了所有的使用者以瞭解誰在使用 Oracle ？而他們的回答恰恰都是否定的，那麼你接下來就應該檢視記錄檔案瞭解哪些工作站正在訪問資料庫。在你檢查這些記錄檔案的時候，你可能會發現：不僅僅只有工作站才訪問資料庫，其他伺服器也要訪問資料庫。

好，拿起筆來記下正在訪問資料庫的伺服器，然後找出這些伺服器訪問資料庫的特定應用程式。通過比較資料表內儲存的資料和伺服器上執行的應用程式即可確定出這類應用程式。

Oracle伺服器上在執行什麼應用程式？

既然你已經知道了訪問資料庫的使用者和外部應用程式，現在你就需要找出資料庫伺服器自身正在執行的應用程式了。這些應用程式可能是資料庫的儲存過程（以及相應的觸發器、定製資料型別以及安全性設定等）也可能是不在 Oracle 以內執行的獨立應用程式。你尤其得注意新增到伺服器之上的 Oracle 開發工具。

遷移到 SQL Server

你永遠都不要衝動地立即撥去Oracle 伺服器的電源裝上在 SQL Server。關鍵伺服器在遷移的時候一定要三思而後行。為什麼這個過程要專門起個遷移（migration）這名字？還不是因為遷移總不是突然發生的。如果你採取一些簡單的合理步驟，遷移過程就能在沒有任何障礙的情況下實現。

本機應用程式和外部應用程式

遷移應用程式請採取以下步驟：

1. 在網路中安裝新的 SQL Server。

2. 建立應用程式使用的“裝置”和資料表。

3. 禁止應用程式訪問資料庫而實現應用程式的離線。

4. 從 Oracle 拷貝當前資料到 SQL Server。

5. 把所有的應用程式都指向新資料庫。

6. 允許應用程式訪問資料表和裝置中的新資料。

考慮SQL

在 SQL Server和 Oracle 之間遷移存在一個要命的問題：它們分別說著 SQL-PL/SQL （Oracle）和Transact-SQL （微軟）這兩種不同的SQL方言。

在大多數情況下，如果你能使用其中一種SQL語言就多半能使用其它的SQL語言。考慮到SQL的函式、操作符、語句等等因素我特意搞了一份SQL程式設計師參考，這份資料表明瞭各種DBMS所支援的特性。當然，如果 SQL 產品的這些美國供應商們都老老實實遵守美國標準SQL（ANSI-SQL）哪裡還會產生這樣大的問題！

此外你你還可能會遭遇以下的問題：

Oracle 的dual表——在 SQL Server上你可能會遇到select ‘x’;這樣的語句。而在 Oracle上這條語句就必須被轉換成select ‘x’ from dual; 。dual是一種由Oracle生成的系統表。除了這個 SQL 語法問題之外，你還不能把這個表拷貝到你的 SQL Server上，因為它是一個 Oracle 系統表。

Truncation -- 兩種DBMS 都支援FLOOR和ROUND函式，但是 Oracle 還多了個 TRUNC 函式。如果你的 Oracle 系統用到了TRUNC 函式，那麼牽扯之處就需要你重新編輯了——可能得想法換成FLOOE或ROUND函式。

Concatenation-SQL Server 7 不支援 ANSI || 連線方法，但是 SQL Server 2000卻可以支援了。現在兩種資料庫都都採用加號（+）表示連線，但最好還是把這個符號用在算術運算上吧！

就看你到底用的是兩種伺服器的具體版本了，有關 SQL 語言的遷移問題幾乎總是會突然在沒有預料到的情況下冒出來。

放棄Oracle 的業務案例

這種資料庫的遷移並不是簡單的感情遊戲，選擇微軟產品而非 Oracle 是受到業務案例支援的。Oracle 在法庭和宣傳戰中為了打敗微軟投入了相當多的資源。然而，從經濟性的角度來看，Oracle並不具更高的價效比。此外，Oracle 只有一種核心產品，相比微軟還是底氣不足。複雜的銷售過程之外，你最好得找個更牛氣點的公司提供支援。這個公司應該健康向上，產品受到普遍歡迎，在遭遇更強大的對手之前得保證這家公司至少在數年之內非常強大。

遷移到 SQL Server又能獲得什麼呢？

首先，你獲得的系統同你的網路體系結構保持了高度的一致性。你無需專人負責 UNIX 系統的管理。為 DBMS 量身打造的管理工具能以最佳狀態同那些網路作業系統工具協同工作。

其次，系統實現了對 .NET 應用程式的內在支援。.NET體系結構並不要求你一定要使用 SQL Server，但這種伺服器是預設的資料庫。用於Oracle 的 ODBC 驅動程式當然也不錯，但它們總是一個可能的故障點。

第三，在.NET網路下采用Oracle的成本比採用SQL Server更高。當你購買更多的Win2K 伺服器許可證以及VS.NET和Office許可證時，你可能會得到折扣。

最後，就算你單獨購買了 SQL Server系統也可能比Oracle來得便宜。最近購買Oracle 許可證在討價還價的時候還難得像拔牙似的。我記得曾問過一個銷售代表價格，他竟然說：“你買得起嗎？”

小結

如果你正在營造.NET網路，採用SQL Server作為你的DBMS是理智的，原因在於它正是微軟 .NET Server應用套件的核心組成部分。從平臺之間的遷移是一個必須仔細考慮、周密部署的重要過程。在轉換平臺之前你更應該擁有一個統一、有效、易於管理和可靠的.NET基礎。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/12639172/viewspace-630022/，如需轉載，請註明出處，否則將追究法律責任。