数据库移植不是简单的导出导入

　　Oracle 11g最早的版本是运行在Linux系统下的，也提供安装了相关的关系数据库管理系统软件，你所运行的新实例包含了很多意想不到的新特性。不过，这一切都得在你成功的把源数据库(或模式)移植新的目标数据库之后再说。你可能正计划在周五的半夜占用八小时的停工和维护时间来执行移植操作。那么在移植之前，你可以做些什么来尽可能保证整个移植过程顺利“无痛”的进行呢?只要你对以下四个重要方面做好规划，就可以使你的移植过程与众不同：统筹管理、导出阶段、导入阶段和交接阶段。

　　统筹管理/项目规划

　　如果你是数据库移植计划的负责人，你肯定希望整个移植过程能够像你所计划的那样步步顺利。

　　为了使所有的移植步骤能够顺利进行，你需要制定一个详细的计划流程图。如果没办法做到上述要求，那么最低限度，你可以制定一条低技术路线，拿出一份计划时间表来。即使你只是在心血来潮的时候把想法和问题记录下来，对于让所有人在移植过程中达到步调一致也能起到一定的作用。最好能把以下的方面都认真考虑，加以计划：

• 　　 图解移植计划流程，召开协调会议
• 　　 落实每一个团队成员责任，确定他们在移植过程中的角色和应负的责任
• 　　 制定一份联系名录，包括如何联系其他关键人员(包括主管、系统管理员、测试人员、开发人员、第三方软件供应商、客户、帐户主管等等)，把这份名录分发给相关成员
• 　　 确定对某些特殊客户的移植操作时间
• 　　 在工作结束后告知相关负责人员，约定时间和地点。
• 　　 通知办公楼保安人员(以及清洁工作人员)关于你们要在办公室里加班的事情，以免引起不必要的误会。
• 　　 为文件系统建立一个传输点，保证有足够的磁盘空间用来导出数据
• 　　 要深入认识模式的变化，包括修改关键表的时间和机理、数据转换过程等)
• 　　 安排好计划进度表，搞清楚是不是整个移植过程中每个数据库管理员都需要留下来全程“陪护”，还是可以把每个人的时间错开

　　预导出和导出阶段

　　如果你(或导出操作的负责人)时间充裕的话，你完全可以事先对导出操作进行多次演练，确保移植计划的这个环节再没有什么小问题出来骚扰你。导出过程必须是一步式操作吗?不是的，可以根据功能群来分阶段实施导出过程，可以考虑把导出过程分解成以下几个功能群：支持表、主表、已修改表、历史/静态表。

　　通过以这种方式把表分成不同的功能群，你可以交替进行导出和导入操作操作。一旦某类群的导出操作完成了，你就可以着手进行相应的导入操作。在分开执行的情况下，导出过程可能需要两个小时，而导入过程可能得花四个小时;但并不意味着需要连续运行六个小时才能完成整个过程。为什么导出和导入花费的时间不一样呢?要知道导出和导入并不是一对一的镜像关系。不要忘记索引是不需要导出的，而是在数据都加载到目标数据库之后才重新构建，所以导出过程要比导入过程运行得快一点，如果稍微优化一下，两者都可以以更快的速度运行。你要怎么驱动导出过程：是用交互模式(interactive mode)还是使用shell 脚本和参数文件的非交互模式?Linux下的Shell脚本具有四个主要的特点：

• 　　 它是一个访问读取过程
• 　　 能够追踪反馈信息，分析总结系统登录档案
• 　　 检测管理系统的功能(包括参数文件、根据制定路径存储dump和日志文件的功能，数据库连接等)
• 　　 关键步骤或操作之后会询问是否需要继续执行的退出机制

　　只要一个脚本就能够驱动整个导出进程，而且退出点可以作为指示信号使用(和echo语句一起广泛使用，可以指示运行到了进程的哪一个步骤)。演练和完善脚本过程中一个主要的度量标准就是执行完整个导出操作所花费的时间。

　　如果正在进行的是一个模式移植(schema migration，相对于全库移植)，那么模式之间的依赖性是什么?找找诸如build_manager、process_logger等名称或项目。Build_manager可能包含一般或公共函数、过程和包。Process_logger则可能包含所有模式的进程日志(在一个源文本文件中常常能看到“pragma autonomous_transaction”，这是在执行事务失败过程发现错误的一种方法)。除非新模式整合了这些外部的和相关的模式，否则必须在目标数据库中为这些“被遗留下来”的部分模式进行说明解释。

　　如果正在执行导出操作，那些非导出的模式可能会导致一些问题的出现。所以当执行导出操作的时候，你可能需要禁用连接、修改密码、屏蔽其他进程，暂停cron服务。网络程序的连接往往像杂草一样难以遏制，而防止其连接的有效方法之一就是修改密码。假设你的导出计划获得了圆满成功，最后要决定的就是如何处理源数据库。