从9i到10g的手动迁移中的问题

　　在各大论坛上频频出现的问题就是如何处理Oracle各版本之间的迁移。升级或迁移指南(根据版本)列出几个方法，其中之一的是一种手动方法。 10g版本是非常重要的，并且Oracle发布了(316889.1)题为“10gR2升级指南完全清单”的说明。总之，这是一个“手把手”的帮助文件，详细说明如何操作，对用户来说是一个很大的帮助。不幸地，该说明文档中有两个(至少)遗漏的步骤。遗漏的步骤(其实 Oracle已经知道而未文档记录的Bug)是撤销与XML DB相关的表，这个表本质上一些占位符之类的。它是一张记录表，如果在升级脚本运行之前没有撤销将可能引起一个不可恢复的错误并且将需要恢复备份(在开始之前你真的真的需要将之撤销，要相信我)。一个早期版本的说明提到在升级脚本运行之后再撤销该表。如果等到那时，你将是注定要失败的。为什么没有在指南列出这些可能性的错误呢？至少它可以放在指南的“已知问题”的部分。

　　关于数据库内时区数据，是“完全”指南存在的另一个问题，其中有一些错误信息。说该问题只适用于10gR1，但是它真正地也适用于R2(并且一直都适用)。你现在看看说明，许多的版本说明还是这样陈述的，甚至是一些其它已知的问题，上面仍然说(在说中文档中的第5步) “注意，该步骤仅仅对10gR1是必须的”。

　　字长度的变化问题

　　当从32位迁移到64位软件(或反之亦然)时，相关的操作步骤已经有了，具体步骤就取决于怎样迁移或升级。如果你从纯粹需要从Oracle的32位版本迁移到一个64位版本(反之亦然)，则字长变化过程要手动地完成。要求你运行脚本(utlirp.sql)，并且根据你所需要的文档来操作(包括关于MetaLink的说明)，当你操作完成后被告诉脚本编译了所有无效对象。文档上的说法实际上是不对的。

　　字长的变化使数据库内所有PL / SQL无效。那么你要重新编译一切，只有在正确的或在新版本的Oracle软件下编译代码才能保证字长变化有效，除此之外别无其它的办法。你可以通过阅读脚本，看更新系统表和将状态栏设置为6的主要步骤。生成utlrp.sql脚本的命令在哪里？

　　交流反馈通道不畅问题

　　很幸运，你可能是第一个遇到新Bug的的幸运者。你如何让你的经验和反馈意见纳入“完全”指南和勘误表？别抱有希望Oracle分析师会处理你的问题。在甲骨文的一些部门缺乏认真负责的态度，我指的人真负责的态度是有员工掌握客户的问题，并确保客户的问题得到解决。至于Oracle技术支持，你获得最好的结果便是 “我将你的评论递交给写该注解的分析师。那个分析员已经记下了问题。”

　　在更好的面向顾客服务的公司中，那态度、政策或者缺乏承担顾客的问题责任的公司不会长久。那这些为什么在鼎鼎大名的Oracle公司内存在？诚然，我知道Oracle的员工偶尔会读这些批评性文章。 既然这些不正确的注解已经反馈给你们，你们为什么不修改这些错误说明呢？我参加过一个叫做技术日的活动，听了一些组织和星级技术支持经理的报告。获知修改说明必须达到公司处理异常的标准。

　　总结

　　在实施阶段，当你想完成某方面的任务(如研究和测试)，或者由于进入Oracle某个陷阱而不得不停止工作的时候，你将感到沮丧。这让我想到了电影“Dead Zone”，当Christopher Walken抓住Deputy的母亲(她儿子是杀手)的胳膊，刹那间意识到这位母亲隐瞒了她儿子的罪行。沃肯惊充满愤怒。大声说道， “你知道。不是吗？ 你知道。” 同样的事出现在 “完全”常见问题解答和MetaLink的指南上，当某人明明知道那里有问题却并没有把问题加到上面去。

　　虽然没有真正的方法来防御这种情况，但是你能通过做一些功课来减轻对自己的工作的影响，如用心的去读相关文献、发布说明、脚本评论(我现在回忆不起来具体要怎么做)，这包括README文件(以及那些不是命名为“readme “的文件)，并且在My Oracle Support的看到的任何说明都是可利用的。以这种方法，你能阻止一个意外的数据改变事件转变成一个雇佣改变事件。如果你发现一些遗漏的步骤或信息，请要求相关负责人修改正确，使该社区的其他人也能获得帮助。