SQLServer2005与Oracle10g转换方法总结

这次要完成的目标是将库从SQLServer 2005完全迁移到Oracle10g，包括表结构、数据、视图、函数、存储过程的迁移。迁移主要基于Oracle的OMWB(Oracle Migration Workbench)，尽管OMWB可以帮助完成最困难的任务。但是，在OMWB完成之后，仍然有大量的工作量需要手动完成，因此整个迁移过程看起来会非常繁重，但不仅仅是工作量吗？我不这么认为。为需要这样做的学生写这篇博客，为自己做个备忘录。

目前，OMWB只支持SQLServer2000。根据官方网站，OMWB的下一个版本将支持SQLServer 2005。所以在目前的情况下，我们只能先把库从SQLServer 2005移植到SQLServer 2000，这是我们移植过程的第一步。

一. SQL Server 2005-> SQL Server 2000

一直以来，降级版本都是非常困难的，因为新版本中会有一些新的特性，而如果你只是碰巧使用了这些特性，那么降级到较低版本时就会遇到一些问题。经过几次尝试，总之，这个过程还是比较好做的。毕竟是同一个数据库，无论如何都不会有大的问题，但不像是把库从SQLServer 2000升级到SQLServer 2005。

1.基于SQLServer 2005的数据导出，将表结构和数据导入SQLServer 2000；
在这一步需要注意的是，默认情况下，SQLServer会一起导入表和视图。不要在这里选择视图，否则有些视图在导入到SQLServer 2000后会变成表。基本上选择好要导入的表后，这一步就不会有问题了，表结构和数据都可以移植。
2。将视图/函数/存储过程移植到SQLServer 2000上；基于SQLServer 2005的生成脚本；
这一步需要慢慢来，因为你可能在视图/函数/存储的过程中使用了SQLServer 2005的一些新特性。如果遇到这样的情况，只能手动修改，使其完全符合SQLServer 2000的要求。尽管您可以选择生成的脚本的目标版本为SQLServer 2000，但有些脚本在执行时会出错。
SQL server 2005到SQLServer 2000的迁移完成后，可以将库从SQLServer 2000迁移到基于OMWB的Oracle。这一步，尽管有工具，也会很麻烦。可以总结如下:

二、SQL SQLServer 2000 - >Oracle 10g

看这个文档:
http://www.oracle.com/technology/global/cn/obe/10gr2 _ db _ VMware/develop/OMWB/omwb . htm
如果你现在下了oracle官方网站，可能就找不到sqlserver 2000的插件包了。如果找不到，可以从这里下载:

在这里，我想总结一下基于OMWB的库从SQLServer 2000迁移到Oracle 10g后需要手动完成的一些事情。不要指望OMWB会帮你把库从SQLServer无缝迁移到Oracle。银弹不存在，我们需要做一些手工来完成库的迁移:
1。迁移表的结构和数据可能出现的问题；
表中字段的默认值/主键/外键/索引不能移植，这些需要手工补充；
2。迁移视图时可能出现的问题；
移植过来的视图可能存在各种语法错误，需要手动修改。一般来说，都是比较简单的错误；
还有一个问题是，有些观点可能移植不过去。这些观点只有在比较了OMWB的移植报告后才能找到并人工移植。
3。移植函数/存储过程中可能出现的问题；
移植过去的函数/存储过程可能还是有相当多的语法问题。比如OMWB不知道怎么处理的SCOPE_IDENTITY()、REPLICATE、newid()之类的函数，以及返回表类型之类的函数，移植后只能手动纠正。关于不同函数导致的语法错误，可以参考这个文档，做一个SQLServer和Oracle函数的比较:
http://www.mikecat.net/blogview.asp? logID = 1559

移植过去的函数/存储过程可能编译没有问题，就是Oracle认为没有语法问题，但是执行的时候会报错，像字符串加法。OMWB移植后，有些字符串的添加会被替换为||，但有些会被省略。此时，只能手动纠正这些错误。
在移植的函数/存储过程执行过程中，可能会出现某些表的主键值不能空的现象。造成这种现象的原因大多是该字段的默认值在sqlServer中定义为IDENTITY，而在Oracle中是不可能给出这样的默认值的。只有主键字段可以分配给插入的SQL语句，序列号可以按顺序生成。
如果移植过去的函数/存储过程中的查询语句都是以字符串的形式执行，然后动态执行，此时的查询语句就不得不手动修改，以符合oracle的语法，因为OMWB在移植时不会以字符串的形式处理查询语句；

有些函数/存储过程不能移植到oracle，因为OMWB不能处理它们。此时，必须通过参考OMWB的移植报告来找出这些函数/存储过程，以便进行手动移植。

整个迁移过程可能会遇到比上面列出的更多的问题。可以看出，整个迁移过程确实需要大量的工作，但总体来说，完成的难度并不高。

真的是这样吗？不会，当然，即使你完成了上面的迁移，也只能说表面上完成了迁移，很可能存储过程语法等不会有问题。，但是执行效果和SQLServer只是不同而已。为什么？可能是因为Oracle和sqlServer在并发控制和事务机制上的不同，会影响程序调用时sql和存储过程的编译等。也就是说，在上述迁移过程完成后，需要根据Oracle的机制，仔细检查当前的SQL语句/函数/存储过程在SQLServer中是否达到了最初想要的效果。只有当这一步的效果相同时，我们才能说迁移过程完成了。
最后顺便说一句，表/视图/函数/存储过程要按照oracle的机制进行优化。如果不走这一步，估计从sqlserver迁移到Oracle意义不大。当然，这不能列为迁移过程。