Oracle Database 11g数据库移植的技巧


　　数据库版本频繁更新，不同版本数据库之间的移植是经常让数据库管理员头疼的问题。数据库移植不仅仅是导出导入的过程，由于新旧运行平台、操作系统、应用设备等的不同，其中涉及的问题方方面面，cuug将为大家介绍Oracle Database 11g数据库移植的技巧。

　　在数据库声明周期中最常发生的一件事就是不断地把数据库从老版本移植到新版本。不同版本之间的数据库移植有时候可能就像把数据从老版本里导出再导入到新版本中一样简单，不过其中涉及到的问题往往比你想象中复杂得多。而且移植过程还会涉及到其他一些显著的改变，例如操作系统改变、模式修改、以及相关应用软件的变化等等。每一项变化都存在着固有的风险性，不过人们常常认为还是应该把这些变化全部结合起来一起清除，来个一劳永逸，而且这样在移植过程中从头到尾都不去进行检测。这种情况出现了如此频繁，实在让人非常惊讶。

　　从一个软件工程师的观点来看，把这么多重要的改变通通放在一个步骤里实现是不是很好的解决办法并且足够安全呢?此外，不仅仅是实施移植而已，还要在实际移植之前检测这些变化是否适用于目标环境。

　　还有其他一些值得注意的地方：在依赖关系链打断移植过程之前，先把它给打断了，否则受打击的将是你。假设在从Oracle10g移植到11g的情况下，要把基层操作系统从Linux改为Solaris，在一个模式里修改主表，并且运行更新的或修改了版本的相关应用软件，那么应该在哪些步骤打断依赖关系链呢?换句话说，哪些步骤更加更安全、更熟悉、并且被其他很多人应用过了?而哪些步骤其他人都没有尝试过，而只适用于你的情况呢?

　　分清楚哪些是已经被实践过的而哪些又是未知的

　　如果你是Oracle新版本的边缘用户或者是最近才开始使用新版本的用户，那么在你(和你的公司)准备从老版本的关系数据库管理系统软件移植到新版本之前，已经有很多前辈为你做过“预演”了。同样的，那些前辈们已经跨越了采用Linux作为基本操作系统所带来的阴暗面。

　　考虑到关系数据库管理系统和操作系统的综合转换已经被大家所熟知，你的数据库产品所依赖的版本和操作系统是打破依赖关系链的理想之所在。如果把所有的操作都结合在一起一步到位的实施，那么移植过程是一个要么成功要么失败的过程，没有中间地带，而失败意味着时间可能都会浪费在这个过程的最简单部分，也就是说数据的移出和移入要花费大把的时间，如果失败，这些过程的执行等于做了无用功。如果你把整体移植过程至少分成两个不同的阶段，你将会把依赖关系链分割成若干小的关系链。这个必须熟习的指导性原则就是通过安全渐进的步骤完成移植过程。

　　对于数据库模式和应用软件的处理则要由你自己来决定。除非你已经对模式和应用软件的转换进行了彻底测试并使其正常运作了，否则整体移植过程的这一部分是否成功仍是个未知之数。如果让新应用软件和数据库上线，然后才发现新软件和数据库代码会导致连锁触发(cascading triggers)反应(将会导致实例瘫痪)，这样的情况会让你沮丧不已。实际产品环境中常包含成千上万条记录，而开发人员和测试人员在测试环境下的测试规模只有一百条记录，很难进行一次彻底的测试。