要順利地解決一個問題很不容易 ，當(dāng)看了Metalink上不完整的“完全指南”后，問題就不大了，你可能會花大量精力去做相應(yīng)的研究，并按照標(biāo)準(zhǔn)步驟一步一步執(zhí)行，特別是閱讀了官方文檔，README文本文件后。在我的Oracle支持筆記中(Metalink)，包括了“完整的”FAQ，看了這些后，你成功的可能性幾乎會達到100%，如果低于100%，那可能是你不經(jīng)意發(fā)現(xiàn)了Oracle的一個bug，因為Oracle提供的某些官方信息，如安裝某個特性X或遷移產(chǎn)品Y的文檔也會有錯誤，有的可能還不完整或未完成。

正如STATSPACK很古老一樣，你可能會認(rèn)為時至今日所有常見的錯誤或問題都已經(jīng)收錄進Oracle發(fā)布的完全FAQ中了;正如版本升級一樣會經(jīng)過大量的測試，你可能會認(rèn)為“完整的”手動遷移指南中的步驟也是經(jīng)過多次測試的，把它當(dāng)作圣經(jīng)一樣對待。另一個是相對簡單的操作(通過安裝腳本)總會與Metalink上(之前的)的筆記匹配。下面以兩個例子進行說明無論你付出多大努力，總是避免不了問題的出現(xiàn)。第三是有些東西很少有人知道，但這并不意味著就沒有人遇到過了。

安裝STATSPACK

在老的Oracle版本中(10g前)，運行spcreate.sql腳本可能會引起上百個對象無效，不僅僅是你自己的對象，還包括Oracle的對象，你可能會認(rèn)為這個問題好解決，只需要運行utlrp.sql重新編譯所有對象就可以了。如果你坐在那里等待修復(fù)腳本運行，你會發(fā)現(xiàn)什么事情都沒有發(fā)生，為什么會這樣?因為安裝STATSPACK間接讓一個對象無效，這個對象就是DBMS_UTILITY包主體。因為首先重新編譯的是Oracle的對象，但它不是，你能做的只有手動編譯其它對象，但這個包主體的狀態(tài)仍然是無效的。

你是否認(rèn)為Oracle提供的內(nèi)置腳本肯定不會有問題，即使變?yōu)闊o效狀態(tài)，也可以重新運行它，并不會產(chǎn)生什么不良后果，對系統(tǒng)也不會有什么大的影響?如果你就是這種想法，那趕緊糾正這種想法，安裝STATSPACK時，是什么引起這些亂七八糟的事情的?運行spcreate.sql時會調(diào)用其它腳本，其中一個就是spcusr.sql腳本，這個腳本又調(diào)用“@@dbmsjob”，從名字上猜測出它是干什么的了嗎?對了，它就是安裝(至少會嘗試)內(nèi)置的DBMS_JOB，如果此時你的系統(tǒng)上恰好有一個DBMS_JOB，那真正發(fā)生DBMS_JOB時究竟該使用哪一個呢?

如何來解決這個問題呢?STATSPACK已經(jīng)安裝成功了，在rdbms目錄下的文檔、發(fā)行注記、類REAME文件(spdoc.txt)中也沒有任何關(guān)于dbmsjob引起問題的描述，至少最近還沒有，即使是翻遍STATSPACK完全參考也找不到丁點這方面的信息。現(xiàn)在有一個筆記更新了(149113.1，“安裝和配置STATSPACK[sic]包”)，它里面推薦注釋掉spcusr.sql腳本中調(diào)用dbmsjob的代碼。在2002年的一個bug中也有提到，但在這個文檔中卻沒有包括，直到六年后才包括進來了。

在幾年前發(fā)布的Oracle 10g中的spcusr，調(diào)用dbmsjob的代碼被移除了，更多的是使用DBMS_JOB了?？偟恼f來，這是Oracle歷史上一個非常大的敗筆，它從來就沒有清晰地對比過dbmsjob和DBMS_UTILITY。

手動從Oracle 9i遷移到10g

有一個問題在許多論壇中問得比較頻繁，那就是如何在Oracle不同版本之間遷移，升級或遷移指南(依賴于版本)列出了許多遷移方法，其中一個就是人工方式。伴隨10g的發(fā)布，Oracle也提交了一篇筆記(316889.1)，標(biāo)題是“手動升級到10gR2完整檢查清單”，總的來說，這篇筆記幫助非常大，它詳細(xì)地說明了升級要做的一切事項，甚至是一步一步的步驟都列得非常指清楚。不幸的是，這篇筆記還是遺漏了兩個東西，其中一個是顯示停機地址，這一步對于Oracle來說當(dāng)然很清楚，因為這是一個未公開的bug，它會刪除與XML DB相關(guān)的占位符表，在未運行升級腳本前，如果沒有刪除，它是一個記錄表，因此，很可能會導(dǎo)致一個不可恢復(fù)的錯誤，或者需要從備份恢復(fù)。這個筆記的早期版本提到過運行了升級腳本后會刪除一個表，如果你等待這個錯誤發(fā)生，你就厄運臨頭了。未公開的bug為什么就不能列在這個指南中呢，最少也應(yīng)該在指南中將其標(biāo)志為“已知問題”。

“完全”指南的另一個問題是存在一些關(guān)于時區(qū)數(shù)據(jù)的錯誤信息，筆記中說道這個問題僅在10gR1中存在，但在10gR2中卻仍然存在，今天再來看這篇筆記，你會發(fā)現(xiàn)已經(jīng)做了許多修正，甚至多了一個已知問題，但在第5步中仍然寫到“請注意，這一步僅在10gR1中才需要”，而且，語句在末尾仍然遺漏了一個句號。

改變單詞大小

當(dāng)你從32位遷移/升級到64位系統(tǒng)時(反之亦然)，你應(yīng)該格外小心，具體要取決于你是如何升級/遷移的。如果你所有要做的事情是從32位版本遷移到64位(反之亦然)，需要手動改變單詞，此時需要運行一個腳本(utlirp.sql)，取決于你文檔的源(包括Metalink上的筆記)，當(dāng)腳本編譯完所有對象時，可能會給你一個提示，但那不是真的。

單詞大小的改變使數(shù)據(jù)庫中的所有PL/SQL無效，直到你重新編譯所有對象，你可以閱讀這個腳本，你會發(fā)現(xiàn)它的主要步驟是更新一個屬于SYS用戶的表，將status列的值設(shè)為6，在哪里調(diào)用utlrp.sql呢?

傳達改變

你可能是第一個遇到新bug的幸運兒，你如何提取你的經(jīng)驗，將其吸收進“完全”指南和勘誤表中呢?不要指望分析你的例子會一翻風(fēng)順，在Oracle的所有權(quán)上有一個巨大的缺點，這里的所有權(quán)指的是有一個顧問取得了顧客問題的所有權(quán)，并解決了這個問題，使用Oracle支持，你最大的收獲是“通過你的注釋分析是誰寫的這個筆記，我現(xiàn)在可以關(guān)閉這個SR嗎?”

在面向最佳客戶服務(wù)的公司里，缺乏正確地響應(yīng)客戶問題的姿態(tài)和策略，這樣的公司都不會有大發(fā)展，可為什么在Oracle這樣的大公司里仍然存在這個問題呢?認(rèn)真地說，我知道Oracle公司的人肯定會讀到這些文章的，當(dāng)人家已經(jīng)給你指出其中的錯誤，為什么你卻仍然不修復(fù)它呢?我不止一次在技術(shù)活動日上聽取某些組織或公布了聯(lián)系信息的高級支持經(jīng)理的演講，要等到異常事件在公司內(nèi)被處理過后才修復(fù)筆記嗎?

總結(jié)

當(dāng)你執(zhí)行某些準(zhǔn)備工作(研究和測試)時，你會感覺非常沮喪，因為你執(zhí)行步驟不正確踩到了Oracle地雷，它使我想起了電影“死亡區(qū)域”，當(dāng)Christopher Walken抓住了deputy(他就是殺手)媽媽的機械臂時，通過對視，他察覺到他的媽媽已經(jīng)知道她兒子犯罪了，Walken義憤填膺地吼道：“你知道了，是不是，你一定知道了”，這和“完整”FAQ中的事情是一樣的，有人明明知道Metalink上存在問題，但就是不說出來。

真的不用為這種情況辯論，但你能夠做什么來緩和這個不良影響呢?使用這個方法你可以將一個無意識的數(shù)據(jù)變更事件變成一個服務(wù)變更事件，如果你偶然發(fā)現(xiàn)了某些遺漏的步驟或信息，請在論壇中要求分析員更正相關(guān)筆記。

本文使用海納銳利編輯并轉(zhuǎn)載, 版權(quán)歸原作者所有。