从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的员工偶尔会读这些批评性文章。 既然这些不正确的注解已经反馈给你们，你们为什么不修改这些错误说明呢?我参加过一个叫做技术日的活动，听了一些组织和星级技术支持经理的报告。获知修改说明必须达到公司处理异常的标准。