改变单词大小

　　当你从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上存在问题，但就是不说出来。

　　真的不用为这种情况辩论，但你能够做什么来缓和这个不良影响呢？使用这个方法你可以将一个无意识的数据变更事件变成一个服务变更事件，如果你偶然发现了某些遗漏的步骤或信息，请在论坛中要求分析员更正相关笔记。