编者按：Oracle用户服务手册MetaLink往往成为Oracle技术支持服务人员和Oracle用户的最后的“救命稻草”，然而，MetaLink上的所谓的“Oracle完全指南”往往并不可信。

　　就像遭遇到友好的火灾不太可能一样，你遇到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的问题是一个重大的过失。