在Oracle數據庫中要順利地解決一個問題很不容易 ，你可能會花大量精力去做相應的研究，並按照標准步驟一步一步執行，特別是閱讀了官方文檔，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上存在問題，但就是不說出來。
真的不用為這種情況辯論，但你能夠做什麼來緩和這個不良影響呢?使用這個方法你可以將一個無意識的數據變更事件變成一個服務變更事件，如果你偶然發現了某些遺漏的步驟或信息，請在論壇中要求分析員更正相關筆記。
