SQLServer2005移植到Oracle10g经验总结

Posted 2023-04-04

参考技术A

　　此次需要完成的目标是将库从SQLServer 完整的移植到Oracle g中 包括表结构 数据 视图 函数以及存储过程的移植 移植主要基于Oracle的OMWB（Oracle Migration Workbench）来完成 尽管OMWB能帮助完成大部分具备难度的工作 但还是有很多工作量的事情需要在OMWB完成后来手工进行 所以整个移植过程工作量看起来会非常大 但是不是仅仅只有工作量的问题呢？我觉得不是 写下这篇blog以便需要进行此项操作的同学以及给自己做个备忘

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

　　一 SQLServer >SQLServer

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

　　 基于SQLServer 的数据导出将表结构和数据导入到SQLServer

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

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

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

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

　　二 SQLServer >Oracle g

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

　　op/omwb/

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

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

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

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

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

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

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

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

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

　　?logID=

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

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

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

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

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

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

　　最后顺带说的就是应该根据Oracle的机制来采用符合oracle优化原则的方法来优化表/视图/函数/存储过程 如果不做这步的话 从sqlserver移植到oracle估计意义也不大了 当然 这可以不列为移植过程的工作

lishixinzhi/Article/program/Oracle/201311/16982

NO4 系统移植-项目技术资料共享解决方案

系统移植项目-技术资料共享解决方案

前言

本文只做解决方案分析，不做具体技术点的说明

一：为什么需要技术资料的共享

系统移植项目的移植点可以分：（1）操作系统移植，例如：由window移植到linux上，由Aix移植到window上等，（2）程序语言的移植，例如vb6升级到vb.net，由PHP移植到Java上等，（3）后台数据库移植，例如：DB2移植到sql server，由sql server移植到Oracle上等。

一般的项目都是包含多个移植点，很少能有一个移植点的项目。

在项目过程中，操作系统的差异，语言的差异，数据库的差异等，因个人掌握知识和工作经验的不同，在对应这些差异时使用的方法不同，在单个点上都是正确的，但是将两者对比就可能出现处理结果不一致，导致后续操作出现了bug。还有就是，系统移植时，程序跨操作系统，跨语言的，不是每个人的知识都能覆盖到所有的知识，所有就需要技术担当将已知的技术知识技术个项目组内组员及时共享。

这样才能在同一类问题有统一的对应方法，让每个组员快速准确的了解掌握对应的技术知识。

二：过往的共享方法。

（1）       文档方法：在项目过程中，将产生的问题记录到文档【问题一览】，移植技术点记录到【技术一览】文档中，这样在项目过程中就产生了很多文档。

局限性：（A）在项目进行过程中，前期阶段组员还是很积极的做文档记录和查看文档，担是到项目中后期就很少或者就不在看这些文档。如果有新的问题点或技术点是或有原来的对应方法有了更好的对应案是，如果只更新了文档，没有通知到每个组员，这样新的知识就没有了解，更不用说掌握了。

局限性：（B）缺乏规范的统一管理，因每个人的认知不同，同一个问题可能会归到不同类别区，例如：一个技术知识点，有的人记录到【问题一览】文档，有的人记录到【技术点一览】文档，就有可能造成一个问题会被记录到多个文档中，首先会造成不知道那个文件中记录的是最准确的疑惑。其次是增加了文档管理的成本。

局限性：（C）如果公司没有陪伴项目结束后项目文档归档整理，项目技术信息记录的专门人员，项目结束后所有的技术资料就只是文档了，其他类似项目需要时，从海量的文档中找到想要的资料也是很困难的。还有就是在开发人员书写文档是，如果记述比较简单，后来人员就比较难以看懂，这也是废物一堆。

该方法适用于公司规模不大且项目周期较长的公司.

（2）       通用系统平台方法：试用开源的Java的一个平台，里面包含了C#，Java，C，VB等很海量的资料，该平台是对公司共享的，每一个开发人员都能登录问题或技术资料等信息，这样所有的信息混杂在一起，区分想要的资料比较困难，所有试用一段时间后就不了了之。该平台本人并没有试用过，只是听以前员工说过。

三：项目技术库平台方法。

（1）       平结构简述：

     首先是公司内部一个BS的系统。是一个以项目为单位和技术类型为单位相互交叉的信息记录、展示的平台。平台结果如下图所示。

                                             

平台模块说明：

（a）       系统管理：用于该平台的管理，如用户管理，项目管理，项目结束或项目内技术点确定后将该项划分到对应的技术类型中。

（b）       项目：从技术类型中获取和该项目类似的技术信息，管理项目内技术知识的（知识点追加，知识点答复，知识点确认、定案）

（c）       技术类型：主要是查看功能，将已经确定的技术资料按照类别一览化的呈现出来。

（d）       后台数据存储：主要是提供系统服务和平台数据信息存储。

（2）       核心模块【项目】的主要功能说明：

首先该平台是做项目的技术信息共享的，如何能让信息共享是他主要的功能和作用。要有简单明了的界面展示，其次是要有历史记录的信息查看和新技术问题的及时更新。

界面展示：（a）一览的展示，以项目技术信息为例。画面布局：左右结构，左侧是项目结构树，建议不要超过2层，划分要准确明了，右侧是技术记录一览，要求一览有关键字和准确文字说明，做到一目了然。如下图所示

                                        

界面展示：（b）技术资料，按照用户上下结构（可以参照论坛的方式），上面用户提出问题，后续用户回答问题或发布自己言论。如下图所示

                                         

这只是简单的页面布局展示，下面将该模块功能结合页面布局做详细功能描述

（a）       每个组员登录后，首先展示的当前所在项目的【项目】模块信息一览。

（b）       组员有登录和修改记录项的权限，登录，修改（主要技术点修改）后该记录会自动顶置，其后其他组员登录后会在最顶端看到，表示有内容需要查看。

（c）       历史积累信息获取，首先好获取该项目的所有技术点【参照上一篇文章：NO3系统升级-资产棚卸 】，获取所有技术点，根据这些技术点从技术类型总选择出历史的技术信息。

（d）       历史信息只能查看，如果出现和历史信息不一致的方案，应该追加新的解决方案。

（e）       当一个问题或一个技术资料最终定案，可以锁定该条记录，并整理成可以供其他项目使用的资料后，在登录到技术类型中。便于其他项目使用。

（四）：平台展望：

该平台是已项目为单位，根据以往的项目经验，单项的问题点只有几项到几十项之间，并不是太多，所有登录后几乎是一目了然，如果新问题或旧问题有新的解决方案，也能在最新标示出来，不需要使用人员通知方式通知到每一个组员，简单明了。

使用系统平台配合平台管理员能是公司的项目经验有很好的积累。技术知识的获取在项目开始前就能做准确的获取，减少重复的技术调查等，提高了效率。

以上是项目中的技术资料的共享方案，因时间仓促和个人能力有限，先只能写到这里，共享平台的基本实现和主要思想能基本上表达出来了，有看到的请自行完善。有什么需求可以发我邮箱或在文章后留言说明。