Oracle 11g数据库移植

核心提示： 如果正在进行的是一个模式移植(schema migration，相对于全库移植)，Oracle 11g数据库移植(6)，那么模式之间的依赖性是什么?找找诸如build_manager、process_logger等名称或项目，Build_manager可能包含一般或公共函数、过程和包，如果

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

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

导入阶段

演练模式的构建和诸如表空间和数据文件等相关物理/逻辑对象的构建。这样做的最终目的是不管怎样都不要在这个阶段出现错误提示，并保证所有创建脚本都是可重复运行的。关于导入的参数文件，需要确保源用户和目标用户能够相互匹配。利用indexfile的种种好处，在目标数据库中预先创建表。

对于正在接受修改的表，我们必须清楚这些过程发生在什么地方、发生的时间和机制。这些变化是发生在用户的模式里吗?还是随着新表式的插入发生在某个临时或移植的模式里。

必须全面了解主表是如何改变的。你可能会想当然地认为定义非空约束(NOT NULL constraints)无关紧要，不过应用程序的变化完全依赖于它们。换句话说，如果由于移植过程中出现一些阻滞，你试图重建某个表的时候，仅仅关注主键约束(PK)、外键约束(FK)和唯一约束(FK)是不够的。