要顺利地解决一个问题很不容易 ，当看了Metalink上不完整的“完全指南”后，问题就不大了，你可能会花大量精力去做相应的研究，并按照标准步骤一步一步执行，特别是阅读了官方文档，README文本文件后。在我的Oracle支持笔记中（Metalink），包括了“完整的”FAQ，看了这些后，你成功的可能性几乎会达到100%，如果低于100%，那可能是你不经意发现了Oracle的一个bug，因为Oracle提供的某些官方信息，如安装某个特性X或迁移产品Y的文档也会有错误，有的可能还不完整或未完成。

　　正如STATSPACK很古老一样，你可能会认为时至今日所有常见的错误或问题都已经收录进Oracle发布的完全FAQ中了；正如版本升级一样会经过大量的测试，你可能会认为“完整的”手动迁移指南中的步骤也是经过多次测试的，把它当作圣经一样对待。另一个是相对简单的操作（通过安装脚本）总会与Metalink上（之前的）的笔记匹配。下面以两个例子进行说明无论你付出多大努力，总是避免不了问题的出现。第三是有些东西很少有人知道，但这并不意味着就没有人遇到过了。

　　安装STATSPACK

　　在老的Oracle版本中（10g前），运行spcreate.sql脚本可能会引起上百个对象无效，不仅仅是你自己的对象，还包括Oracle的对象，你可能会认为这个问题好解决，只需要运行utlrp.sql重新编译所有对象就可以了。如果你坐在那里等待修复脚本运行，你会发现什么事情都没有发生，为什么会这样？因为安装STATSPACK间接让一个对象无效，这个对象就是DBMS_UTILITY包主体。因为首先重新编译的是Oracle的对象，但它不是，你能做的只有手动编译其它对象，但这个包主体的状态仍然是无效的。

　　你是否认为Oracle提供的内置脚本肯定不会有问题，即使变为无效状态，也可以重新运行它，并不会产生什么不良后果，对系统也不会有什么大的影响？如果你就是这种想法，那赶紧纠正这种想法，安装STATSPACK时，是什么引起这些乱七八糟的事情的？运行spcreate.sql时会调用其它脚本，其中一个就是spcusr.sql脚本，这个脚本又调用"@@dbmsjob"，从名字上猜测出它是干什么的了吗？对了，它就是安装（至少会尝试）内置的DBMS_JOB，如果此时你的系统上恰好有一个DBMS_JOB，那真正发生DBMS_JOB时究竟该使用哪一个呢？

　　如何来解决这个问题呢？STATSPACK已经安装成功了，在rdbms目录下的文档、发行注记、类REAME文件（spdoc.txt）中也没有任何关于dbmsjob引起问题的描述，至少最近还没有，即使是翻遍STATSPACK完全参考也找不到丁点这方面的信息。现在有一个笔记更新了（149113.1，“安装和配置STATSPACK[sic]包”），它里面推荐注释掉spcusr.sql脚本中调用dbmsjob的代码。在2002年的一个bug中也有提到，但在这个文档中却没有包括，直到六年后才包括进来了。

　　在几年前发布的Oracle 10g中的spcusr，调用dbmsjob的代码被移除了，更多的是使用DBMS_JOB了。总的说来，这是Oracle历史上一个非常大的败笔，它从来就没有清晰地对比过dbmsjob和DBMS_UTILITY。

　　手动从Oracle 9i迁移到10g

　　有一个问题在许多论坛中问得比较频繁，那就是如何在Oracle不同版本之间迁移，升级或迁移指南（依赖于版本）列出了许多迁移方法，其中一个就是人工方式。伴随10g的发布，Oracle也提交了一篇笔记（316889.1），标题是“手动升级到10gR2完整检查清单”，总的来说，这篇笔记帮助非常大，它详细地说明了升级要做的一切事项，甚至是一步一步的步骤都列得非常指清楚。不幸的是，这篇笔记还是遗漏了两个东西，其中一个是显示停机地址，这一步对于Oracle来说当然很清楚，因为这是一个未公开的bug，它会删除与XML DB相关的占位符表，在未运行升级脚本前，如果没有删除，它是一个记录表，因此，很可能会导致一个不可恢复的错误，或者需要从备份恢复。这个笔记的早期版本提到过运行了升级脚本后会删除一个表，如果你等待这个错误发生，你就厄运临头了。未公开的bug为什么就不能列在这个指南中呢，最少也应该在指南中将其标志为“已知问题”。

　　“完全”指南的另一个问题是存在一些关于时区数据的错误信息，笔记中说道这个问题仅在10gR1中存在，但在10gR2中却仍然存在，今天再来看这篇笔记，你会发现已经做了许多修正，甚至多了一个已知问题，但在第5步中仍然写到“请注意，这一步仅在10gR1中才需要”，而且，语句在末尾仍然遗漏了一个句号。