如果你正在营造微软 .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基础。