编者按
Oracle 用户服务手册MetaLink往往成为Oracle技术支持服务人员和Oracle用户的最后的
救命稻草
然而
MetaLink上的所谓的
Oracle完全指南
往往并不可信
就像遭遇到友好的火灾不太可能一样你遇到MetaLink上的完全指南毫无作用也并非罕见你可能会认为按照使用MetaLink的过程和步骤你已经给予了应有的注意特别是在读完官方文档以后例如其自述文件My Oracle Support(Metalink的新名称)说明包括完全常见问题解答等你成功的可能性将非常接近%导致少于%的因素是可能偶尔发现一些费解的东西或者新的错误如果你真的认为如此那就是大错特错了因为有些关于安装x功能或迁移产品Y的Oracle的信息几乎是残缺不全和完全不正确的
图: oracle My Oracle Support技术支持首页
就像一些比较老的工具如STATSPACK一样你可能会认为到现在为止所有典型的错误或问题应该都能在Oracle发布的完全FAQ中看到了正如版本升级进行的众多的测试那样你可能也认为完全手工迁移指南在迁移操作步骤中应该是毫无问题的
对于STATSPACK另一个相对简单的操作(通过安装脚本)和 (以前) MetaLink提到的方法一样如下所示的二个例子说明了为了避免出现技术问题不管如何审慎都是不够的不管怎么幻想这里都没有模糊不清的或者一次性的操作第三个例子可能很多人知之甚少但也没有真正超出其他人曾经做过的领域
安装STATSPACK的问题
在更旧版本的DBMS软件(Oracle g之前的版本))时运行spcreatesql脚本可能会导致数以千计的对象无效不仅仅只有业务的对象也包括Oracle自身的对象起初你会认为没有问题到时候只要运行utlrpsql重新编译一切就OK事实上当你坐在那里并且等待修复脚本运行时你将一无所获为什么是这样?因为有一个对象是DBMS的UTILITY 包在安装STATSPACK的时候该包已经无效了它并没有作为Oracle拥有的第一个对象被重新编译你可能可以手动地编译一些其它的东西但是这个包你将处于无效状态
你是否相信如果由Oracle提供的这个内置包无效而你能仅仅通过重新运行脚本并且在第一次安装的环境中成功没有其他问题并且不影响系统?如果你有这样的想法现在趁早打消 在STATSPACK安装情况什么造成一切是混乱的原因?原因是运行spcreatesql时调用其它的脚本一个便是spcusrsql脚本 这个脚本调用@@dbmsjob包通过名字猜猜它是做什么的?没错它就是来安装(或至少尝试) DBMS_JOB的如果在你的系统中你已经存在DBMS_JOB怎么办如果DBMS_JOB正在被使用又怎么办?
这种情况是如何造成的呢?STATSPACK工具由来已久说明文档发布说明关系型数据库管理系统中类似README的文件(spdoctxt)甚至是STATSPACK完全参考说明都没有直接(或近来是)提到dbmsjob造成的任何问题一个更新了的说明(安装和配置StatsPack [sic]包)中提到一个建议在spcusrsql脚本中调用dbmsjob包该说明也提及了一个年就已经记载的一个错误这个记载的错误在过了六年之久来才加入到文档中
Oracle g版本中的spcusr 对dbmsjob的调用删除了因为现在(或当时)的情况看来使用DBMS_JOB非常广泛总而言之Oracle没有以清楚明白的说明提供 dbmsjob和DBMS_UTILITY的问题是一个重大的过失
从i到g的手动迁移中的问题
在各大论坛上频频出现的问题就是如何处理Oracle各版本之间的迁移升级或迁移指南(根据版本)列出几个方法其中之一的是一种手动方法 g版本是非常重要的并且Oracle发布了()题为gR升级指南完全清单的说明 总之这是一个手把手的帮助文件详细说明如何操作对用户来说是一个很大的帮助不幸地该说明文档中有两个(至少)遗漏的步骤遗漏的步骤(其实Oracle已经知道而未文档记录的Bug)是撤销与XML DB相关的表这个表本质上一些占位符之类的它是一张记录表如果在升级脚本运行之前没有撤销将可能引起一个不可恢复的错误并且将需要恢复备份(在开始之前你真的真的需要将之撤销要相信我)一个早期版本的说明提到在升级脚本运行之后再撤销该表如果等到那时你将是注定要失败的为什么没有在指南列出这些可能性的错误呢?至少它可以放在指南的已知问题的部分
关于数据库内时区数据是完全指南存在的另一个问题其中有一些错误信息说该问题只适用于gR但是它真正地也适用于R (并且一直都适用)你现在看看说明许多的版本说明还是这样陈述的甚至是一些其它已知的问题上面仍然说(在说中文档中的第步) 注意该步骤仅仅对gR是必须的
字长度的变化问题
当从位迁移到位软件(或反之亦然)时相关的操作步骤已经有了具体步骤就取决于怎样迁移或升级 如果你从纯粹需要从Oracle的位版本迁移到一个位版本(反之亦然)则字长变化过程要手动地完成要求你运行脚本(utlirpsql)并且根据你所需要的文档来操作(包括关于MetaLink的说明)当你操作完成后被告诉脚本编译了所有无效对象文档上的说法实际上是不对的
字长的变化使数据库内所有PL / SQL无效那么你要重新编译一切只有在正确的或在新版本的Oracle软件下编译代码才能保证字长变化有效除此之外别无其它的办法你可以通过阅读脚本看更新系统表和将状态栏设置为的主要步骤生成utlrpsql脚本的命令在哪里?
交流反馈通道不畅问题
很幸运你可能是第一个遇到新Bug的的幸运者你如何让你的经验和反馈意见纳入完全指南和勘误表?别抱有希望Oracle分析师会处理你的问题在甲骨文的一些部门缺乏认真负责的态度我指的人真负责的态度是有员工掌握客户的问题并确保客户的问题得到解决至于Oracle技术支持你获得最好的结果便是 我将你的评论递交给写该注解的分析师那个分析员已经记下了问题
在更好的面向顾客服务的公司中那态度政策或者缺乏承担顾客的问题责任的公司不会长久那这些为什么在鼎鼎大名的Oracle公司内存在?诚然我知道Oracle的员工偶尔会读这些批评性文章 既然这些不正确的注解已经反馈给你们你们为什么不修改这些错误说明呢?我参加过一个叫做技术日的活动听了一些组织和星级技术支持经理的报告获知修改说明必须达到公司处理异常的标准
总结
在实施阶段当你想完成某方面的任务(如研究和测试)或者由于进入Oracle某个陷阱而不得不停止工作的时候你将感到沮丧这让我想到了电影Dead Zone当Christopher Walken抓住Deputy的母亲(她儿子是杀手)的胳膊剎那间意识到这位母亲隐瞒了她儿子的罪行沃肯惊充满愤怒大声说道 你知道 不是吗? 你知道 同样的事出现在 完全常见问题解答和MetaLink的指南上当某人明明知道那里有问题却并没有把问题加到上面去
虽然没有真正的方法来防御这种情况但是你能通过做一些功课来减轻对自己的工作的影响如用心的去读相关文献发布说明脚本评论(我现在回忆不起来具体要怎么做)这包括README文件(以及那些不是命名为readme 的文件)并且在My Oracle Support的看到的任何说明都是可利用的以这种方法你能阻止一个意外的数据改变事件转变成一个雇佣改变事件如果你发现一些遗漏的步骤或信息请要求相关负责人修改正确使该社区的其他人也能获得帮助
原文
