就像遭遇到友好的火灾不太可能一样，你遇到MetaLink上的“完全指南”毫无作用也并非罕见。你可能会认为，按照使用MetaLink的过程和步骤，你已经给予了应有的注意，特别是在读完官方文档以后，例如其自述文件，My Oracle Support(Metalink的新名称)说明，包括“完全”常见问题解答等，你成功的可能性将非常接近100%。导致少于100%的因素是可能偶尔发现一些费解的东西或者新的错误。如果你真的认为如此，那就是大错特错了，因为有些关于安装x功能或迁移产品Y的Oracle的信息几乎是残缺不全和完全不正确的。

        
                                                 图:  oracle "My Oracle Support"技术支持首页

　　就像一些比较老的工具如STATSPACK一样，你可能会认为到现在为止，所有典型的错误或问题应该都能在Oracle发布的“完全FAQ”中看到了。正如版本升级进行的众多的测试那样，你可能也认为“完全”手工迁移指南在迁移操作步骤中应该是毫无问题的。

　　对于STATSPACK，另一个相对简单的操作(通过安装脚本)和 (以前) MetaLink提到的方法一样。如下所示的二个例子说明了为了避免出现技术问题，不管如何审慎都是不够的。不管怎么幻想，这里都没有模糊不清的或者一次性的操作。第三个例子可能很多人知之甚少，但也没有真正超出其他人曾经做过的领域。

　　安装STATSPACK的问题

　　在更旧版本的DBMS软件(Oracle 10g之前的版本))时，运行spcreate.sql脚本可能会导致数以千计的对象无效，不仅仅只有业务的对象，也包括Oracle自身的对象。起初你会认为没有问题，到时候只要运行utlrp.sql重新编译一切就OK。事实上，当你坐在那里并且等待修复脚本运行时，你将一无所获。为什么是这样?因为有一个对象是DBMS的UTILITY 包，在安装STATSPACK的时候该包已经无效了。它并没有作为Oracle拥有的第一个对象被重新编译。你可能可以手动地编译一些其它的东西，但是这个包你将处于无效状态。

　　你是否相信，如果由Oracle提供的这个内置包无效，而你能仅仅通过重新运行脚本，并且在第一次安装的环境中成功，没有其他问题并且不影响系统?如果你有这样的想法，现在趁早打消。 在STATSPACK安装情况，什么造成一切是混乱的原因?原因是运行spcreate.sql时调用其它的脚本。一个便是spcusr.sql脚本。 这个脚本调用“@@dbmsjob”包，通过名字猜猜它是做什么的?没错-它就是来安装(或至少尝试) DBMS_JOB的，如果在你的系统中你已经存在DBMS_JOB怎么办，如果DBMS_JOB正在被使用又怎么办?

　　这种情况是如何造成的呢?STATSPACK工具由来已久。说明文档、发布说明、关系型数据库管理系统中类似README的文件(spdoc.txt)，甚至是STATSPACK完全参考说明都没有直接(或近来是)提到dbmsjob造成的任何问题。一个更新了的说明(149113.1，“安装和配置StatsPack [sic]包")中提到一个建议，在spcusr.sql脚本中调用dbmsjob包。该说明也提及了一个2002年就已经记载的一个错误，这个记载的错误在过了六年之久来才加入到文档中。

　　Oracle 10g版本中的spcusr， 对dbmsjob的调用删除了，因为现在(或当时)的情况看来，使用DBMS_JOB非常广泛。总而言之，Oracle没有以清楚明白的说明提供 dbmsjob和DBMS_UTILITY的问题是一个重大的过失。

　从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的看到的任何说明都是可利用的。以这种方法，你能阻止一个意外的数据改变事件转变成一个雇佣改变事件。如果你发现一些遗漏的步骤或信息，请要求相关负责人修改正确，使该社区的其他人也能获得帮助。

　　原文：http://www.databasejournal.com/features/oracle/article.php/3798191/Oracle-Support-Notes--Complete-Guides-Usually-Arent.htm