SQLServer2005如何移植到Oracle10g

共计 2500 个字符，预计需要花费 7 分钟才能阅读完成。

这篇文章主要介绍“SQLServer2005 如何移植到 Oracle10g”，在日常操作中，相信很多人在 SQLServer2005 如何移植到 Oracle10g 问题上存在疑惑，丸趣 TV 小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”SQLServer2005 如何移植到 Oracle10g”的疑惑有所帮助！接下来，请跟着丸趣 TV 小编一起来学习吧！

由于目前 OMWB 仅支持 SQLServer2000，根据官方网站的消息，OMWB 的下一版会推出对 SQLServer 2005 的支持，所以在目前的情况下只能先把库从 SQLServer 2005 移植到 SQLServer 2000，这就是我们移植过程的第一步了。

SQLServer2005 怎样移植到 Oracle10g

一、SQLServer 2005– SQLServer 2000

一直以来，版本要降级都是很困难的，因为在新版本中必然会有些新的特性，而如果刚好凑巧你使用到了这些特性的话，在降级到低版本时就会碰到一些问题，在经过几次的尝试后，总结而言，这个过程还是比较容易做的，毕竟是同样的数据库，再怎么样也不会出太大的问题，不过也没有像将库从 SQLServer 2000 升级为 SQLServer 2005 那么简单，整个移植过程这么进行：

1、基于 SQLServer 2005 的数据导出将表结构和数据导入到 SQLServer 2000;

这步中需要注意的是默认情况下 SQLServer 会将表和视图一起导入，在这里不要选择视图，否则导入到 SQLServer 2000 后有些视图会变成表，选择需要导入的表后基本上这步不会出现什么问题，可以完成表结构和数据的移植。

2、基于 SQLServer 2005 的生成脚本将视图 / 函数 / 存储过程移植到 SQLServer 2000;

这步需要慢慢来，因为在视图 / 函数 / 存储过程中你可能使用到了一些 SQLServer 2005 的新特性，如果碰到这样的情况，只能是手工进行修改，以使它完全符合 SQLServer 2000 的要求，尽管在生成脚本时你可以选择生成的目标版本为 SQLServer 2000，但还是会有部分脚本执行是会出错的。

在完成了 SQLServer 2005 到 SQLServer 2000 的移植后，就可以基于 OMWB 来把库从 SQLServer 2000 移植到 Oracle 了，这步尽管有工具，还是会比较的麻烦，总结如下：

二、SQLServer 2000– Oracle 10g

关于如何基于 OMWB 将库从 SQLServer 2000 移植到 Oracle 10g 的操作步骤可参见此篇文档：

大家现在从 oracle 官方站下的话可能会找不到 sqlserver 2000 的插件包，如果找不到的话可以从这里下载：

我在这里要总结的是基于 OMWB 将库从 SQLServer 2000 移植到 Oracle 10g 后还需要手工做的一些事情，不要指望 OMWB 能无缝的帮你把库从 SQLServer 移植到 Oracle 中，银弹是不存在的，因此我们需要做些手工的工作完成库的移植：

SQLServer2005 怎样移植到 Oracle10g

1、移植表结构和数据可能会出现的问题;

表中字段的默认值 / 主键 / 外键 / 索引移植不过去，这些需要手工的进行补充;

2、移植视图可能会出现的问题;

移植过去的视图可能会出现各种语法错误的问题，这需要手工的修正，一般来说都是较为简单的错误;

另外一种问题就是有些视图可能会无法移植过去，这些视图就只能在对比 OMWB 的移植报告后找出来手工的进行移植了。

3、移植函数 / 存储过程可能会出现的问题;

移植过去的函数 / 存储过程中可能仍然会有不少的语法问题，例如像 SCOPE_IDENTITY()、REPLICATE、newid() 这些 OMWB 不知道该怎么处理的函数，还有像返回 Table 类型的这种函数，这些都只能在移植后手工的来进行纠正，关于函数不同造成的语法错误的现象大家可以参看这篇文档来做 SQLServer 和 Oracle 函数的对照：

移植过去的函数 / 存储过程可能编译是没有问题，也就是 Oracle 认为没有语法问题，但执行起来却会报错，像字符串相加，经过 OMWB 移植后有些字符串相加会替换成 ||，但是有些会遗漏，这个时候也只能手工来纠正这些错误了;

移植过去的函数 / 存储过程在执行过程中可能会出现某些表的主键值不能为空的现象，造成这种现象的原因多数为在 SQLServer 中该字段的默认值定义的为 IDENTITY，但在 Oracle 中没法赋予这样的默认值，只能在插入的 sql 语句中加上对于主键字段的赋值，可采用 sequence 的方式来生成顺序号;

移植过去的函数 / 存储过程中如果其中的查询语句是采用字符串的方式，然后动态执行的话，这个时候的查询语句就得手工修改为符合 oracle 的语法了，因为 OMWB 在移植时是不会对字符串形式的查询语句来做处理的;

部分函数 / 存储过程会由于 OMWB 确实无法处理，造成移植不到 oracle，这个时候也必须参照 OMWB 的移植报告找出这些函数 / 存储过程来手工移植了。

整个移植过程可能会碰到比上面所列出的更多的别的问题，可以看出整个移植过程确实需要耗费不小的工作量，但总体而言，完成的难度并不高。

其实真的是这样吗? 当然不是，就算你完成了上面的移植工作，那也只能说表面看上去移植是完成了，很有可能会出现这个存储过程语法等等都没有问题了，但执行的效果和 SQLServer 就是不一样，这是为什么呢? 可能会是因为 Oracle 和 SQLServer 在并发控制、事务机制上是不同的，而这会影响到程序调用时的 sql 的编写、存储过程的编写等等，也就是说，在上面的移植过程的工作完成后，还得仔细检查现在的 sql 语句 / 函数 / 存储过程是否根据 Oracle 的机制达到了原来在 SQLServer 中期望的效果，只有做到这步的效果是一样的，才可以说移植过程完成了。

到此，关于“SQLServer2005 如何移植到 Oracle10g”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注丸趣 TV 网站，丸趣 TV 小编会继续努力为大家带来更多实用的文章！