Oracle 11g数据库移植

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

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

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

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

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

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

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

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

　　手动操作和设置导出和导入过程

　　关于导出和导入的实用工具，你不一定要接受其默认参数。事实上，你应该采用大部分的自定义设置，这样能够使移植过程更容易进行，而且在产品环境实际进行操作时能够节省大量时间。

　　我们首先来看看索引文件的参数设置，在导入过程中，最好使用indexfile=filename的设置，原因至少有四条。

　　第一，这样可以把表和索引等对象信息(全部或部分，取决于导出dump文件中包含了什么内容)存储在指定的输出文件中。想知道创建模式的源代码在哪里吗?如果你没有源代码，那这个参数(连同一个返回所有其他信息的简单查询)对于这些信息的提供会有很大帮助。查询部分会将全部的或user_source数据字典的内容输出到文件中。包、包体、存储过程、函数和触发器等代码信息都包括在输出的结果文件里。再稍微加工一下，例如执行CREATE OR REPLACE命令，清除SQL*Plus工具存储区域里无用的结果(如标题行、换页等)，剩下的就是一个模式最重要那部分的当前代码