編者按
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的看到的任何說明都是可利用的以這種方法你能阻止一個意外的數據改變事件轉變成一個雇傭改變事件如果你發現一些遺漏的步驟或信息請要求相關負責人修改正確使該社區的其他人也能獲得幫助
原文
From:http://tw.wingwit.com/Article/program/Oracle/201311/17739.html
