要顺利地解决一个问题很不容易 ，当看了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中才需要”，而且，语句在末尾仍然遗漏了一个句号。
改变单词大小
当你从32位迁移/升级到64位系统时(反之亦然)，你应该格外小心，具体要取决于你是如何升级/迁移的。如果你所有要做的事情是从32位版本迁移到64位(反之亦然)，需要手动改变单词，此时需要运行一个脚本(utlirp.sql)，取决于你文档的源(包括Metalink上的笔记)，当脚本编译完所有对象时，可能会给你一个提示，但那不是真的。
单词大小的改变使数据库中的所有PL/SQL无效，直到你重新编译所有对象，你可以阅读这个脚本，你会发现它的主要步骤是更新一个属于SYS用户的表，将status列的值设为6，在哪里调用utlrp.sql呢?
传达改变
你可能是第一个遇到新bug的幸运儿，你如何提取你的经验，将其吸收进“完全”指南和勘误表中呢?不要指望分析你的例子会一翻风顺，在Oracle的所有权上有一个巨大的缺点，这里的所有权指的是有一个顾问取得了顾客问题的所有权，并解决了这个问题，使用Oracle支持，你最大的收获是“通过你的注释分析是谁写的这个笔记，我现在可以关闭这个SR吗?”
在面向最佳客户服务的公司里，缺乏正确地响应客户问题的姿态和策略，这样的公司都不会有大发展，可为什么在Oracle这样的大公司里仍然存在这个问题呢?认真地说，我知道Oracle公司的人肯定会读到这些文章的，当人家已经给你指出其中的错误，为什么你却仍然不修复它呢?我不止一次在技术活动日上听取某些组织或公布了联系信息的高级支持经理的演讲，要等到异常事件在公司内被处理过后才修复笔记吗?
总结
当你执行某些准备工作(研究和测试)时，你会感觉非常沮丧，因为你执行步骤不正确踩到了Oracle地雷，它使我想起了电影“死亡区域”，当Christopher Walken抓住了deputy(他就是杀手)妈妈的机械臂时，通过对视，他察觉到他的妈妈已经知道她儿子犯罪了，Walken义愤填膺地吼道：“你知道了，是不是，你一定知道了”，这和“完整”FAQ中的事情是一样的，有人明明知道Metalink上存在问题，但就是不说出来。
真的不用为这种情况辩论，但你能够做什么来缓和这个不良影响呢?使用这个方法你可以将一个无意识的数据变更事件变成一个服务变更事件，如果你偶然发现了某些遗漏的步骤或信息，请在论坛中要求分析员更正相关笔记。
正如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中才需要”，而且，语句在末尾仍然遗漏了一个句号。
改变单词大小
当你从32位迁移/升级到64位系统时(反之亦然)，你应该格外小心，具体要取决于你是如何升级/迁移的。如果你所有要做的事情是从32位版本迁移到64位(反之亦然)，需要手动改变单词，此时需要运行一个脚本(utlirp.sql)，取决于你文档的源(包括Metalink上的笔记)，当脚本编译完所有对象时，可能会给你一个提示，但那不是真的。
单词大小的改变使数据库中的所有PL/SQL无效，直到你重新编译所有对象，你可以阅读这个脚本，你会发现它的主要步骤是更新一个属于SYS用户的表，将status列的值设为6，在哪里调用utlrp.sql呢?
传达改变
你可能是第一个遇到新bug的幸运儿，你如何提取你的经验，将其吸收进“完全”指南和勘误表中呢?不要指望分析你的例子会一翻风顺，在Oracle的所有权上有一个巨大的缺点，这里的所有权指的是有一个顾问取得了顾客问题的所有权，并解决了这个问题，使用Oracle支持，你最大的收获是“通过你的注释分析是谁写的这个笔记，我现在可以关闭这个SR吗?”
在面向最佳客户服务的公司里，缺乏正确地响应客户问题的姿态和策略，这样的公司都不会有大发展，可为什么在Oracle这样的大公司里仍然存在这个问题呢?认真地说，我知道Oracle公司的人肯定会读到这些文章的，当人家已经给你指出其中的错误，为什么你却仍然不修复它呢?我不止一次在技术活动日上听取某些组织或公布了联系信息的高级支持经理的演讲，要等到异常事件在公司内被处理过后才修复笔记吗?
总结
当你执行某些准备工作(研究和测试)时，你会感觉非常沮丧，因为你执行步骤不正确踩到了Oracle地雷，它使我想起了电影“死亡区域”，当Christopher Walken抓住了deputy(他就是杀手)妈妈的机械臂时，通过对视，他察觉到他的妈妈已经知道她儿子犯罪了，Walken义愤填膺地吼道：“你知道了，是不是，你一定知道了”，这和“完整”FAQ中的事情是一样的，有人明明知道Metalink上存在问题，但就是不说出来。
真的不用为这种情况辩论，但你能够做什么来缓和这个不良影响呢?使用这个方法你可以将一个无意识的数据变更事件变成一个服务变更事件，如果你偶然发现了某些遗漏的步骤或信息，请在论坛中要求分析员更正相关笔记。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
