.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基礎。