导入阶段

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

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

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

　　那定时任务工具cron和数据库作业呢?你要如何移植/导出所有的这些东西呢?通常与cron作业密切相关的是电子邮件。要注意新服务器是否配置好电子邮件通知系统，是否需要创建数据库连接。

　　在导入过程进行的时候，是否需要开启日志记录呢?有没有必要把所有导入的事件都记录到日志里呢?记录触发器是不是有必要，特别是对于行级触发器(即每行都执行)?在导入过程中需要插入数量达百万以上的行，对于行级触发器，每插入一行就需要执行一次甚至更多的触发器操作。如果依赖源数据库的某个表的触发器已经执行某些操作，那么在导入过程中有必要再次执行相同的操作吗?以上这些问题都是需要认真考虑的。

　　你可能很聪明地禁用了不少自动功能，以便加快导入过程。不过千万别聪明过头而忘记把你禁用的功能重新启用。由于移植过程很可能都是在午夜进行，睡意朦胧的你很可能会导致大量人为错误的产生。如果你实在不是熬夜的料，最好让其他人帮你检查这些工作和操作步骤，特别是当运行的对象对于数据库或模式来说至关重要重要的时候。

　　导入后需要关注的事项

　　所有的移植工作都顺利完成了?你以为可以松一口气了，不过任务还没有真正结束。你还需要创建基础备份，所以你必须搞清楚以下问题：是不是应该在移植完成新数据库构建完毕后立即着手进行备份?你是不是已经能够成功地从导出备份、冷备份和热备份转变到RMAN备份?你之前有没有练习过RMAN备份和恢复操作?

　　首选方案当然是在移植顺利完成后立即开始进行备份。不过，前提是移植过程非常顺利，你的计划和目标非常明确。假设由于某些不定因素导致移植完成后应用软件无法正常运行，又该怎么办呢?移植完成后产品环境下的完全测试可以减少这种情况的发生，但是如果没有进行大规模测试呢?要怎样才能回复到源数据库状态?你是不是还有足够的时间重新再来一遍?只要你对导出过程会发生的问题有充分的认识，就不会有二次尝试的必要了。

　　不要以为每个人都对发生的事情了如指掌。客户支持人员是不是知道如何把桌面工具软件指向新的数据库?还是会在抱怨对数据库的修改无效后几个星期才知道代开trouble tickets系统查看。对于作为数据库管理员的你来说闭上眼也能显而易见的东西对于那些不懂数据库语言的人而言可能相当晦涩。

　　总结

　　本文所涵盖的数据库移植技巧、步骤和问题都来源于真实的案例。就像上面说的，有些客户服务代表会抱怨数据库没有显示数据的变化，很可能是不清楚该如何把桌面客户关系管理工具指向新数据库而导致的。这应该是数据库管理员的责任还是客户代表主管的责任呢?插入变换格式后的数据和工作区到主表中也常常会出现问题，这就很可能和非空约束有关了。

　　关于数据库移植有一个最起码的常识：如果你连事先进行测试并处理好导致失败的问题的时间都没有，你更不可能有时间来做第二次尝试?关于移植过程中起到作用的一些外部因素，本文所提到的一些技巧和注意事项进行了深入的解析，希望大家看过之后在数据库移植过程中能少走弯路，顺利完成升级。

　　IT专家网原创文章，未经许可，严禁转载！