Oracle數(shù)據(jù)庫(kù)支持筆記
在Oracle數(shù)據(jù)庫(kù)中要順利地解決一個(gè)問(wèn)題很不容易 ，你可能會(huì)花大量精力去做相應(yīng)的研究，并按照標(biāo)準(zhǔn)步驟一步一步執(zhí)行，特別是閱讀了官方文檔，README文本文件后。在我的Oracle支持筆記中(Metalink)，包括了“完整的”FAQ，看了這些后，你成功的可能性幾乎會(huì)達(dá)到100%，如果低于100%，那可能是你不經(jīng)意發(fā)現(xiàn)了Oracle的一個(gè)bug，因?yàn)镺racle提供的某些官方信息，如安裝某個(gè)特性X或遷移產(chǎn)品Y的文檔也會(huì)有錯(cuò)誤，有的可能還不完整或未完成。
正如STATSPACK很古老一樣，你可能會(huì)認(rèn)為時(shí)至今日所有常見(jiàn)的錯(cuò)誤或問(wèn)題都已經(jīng)收錄進(jìn)Oracle發(fā)布的完全FAQ中了;正如版本升級(jí)一樣會(huì)經(jīng)過(guò)大量的測(cè)試，你可能會(huì)認(rèn)為“完整的”手動(dòng)遷移指南中的步驟也是經(jīng)過(guò)多次測(cè)試的，把它當(dāng)作圣經(jīng)一樣對(duì)待。另一個(gè)是相對(duì)簡(jiǎn)單的操作(通過(guò)安裝腳本)總會(huì)與Metalink上(之前的)的筆記匹配。下面以?xún)蓚€(gè)例子進(jìn)行說(shuō)明無(wú)論你付出多大努力，總是避免不了問(wèn)題的出現(xiàn)。第三是有些東西很少有人知道，但這并不意味著就沒(méi)有人遇到過(guò)了。
安裝STATSPACK
在老的Oracle數(shù)據(jù)庫(kù)版本中(10g前)，運(yùn)行spcreate.sql腳本可能會(huì)引起上百個(gè)對(duì)象無(wú)效，不僅僅是你自己的對(duì)象，還包括Oracle的對(duì)象，你可能會(huì)認(rèn)為這個(gè)問(wèn)題好解決，只需要運(yùn)行utlrp.sql重新編譯所有對(duì)象就可以了。如果你坐在那里等待修復(fù)腳本運(yùn)行，你會(huì)發(fā)現(xiàn)什么事情都沒(méi)有發(fā)生，為什么會(huì)這樣?因?yàn)榘惭bSTATSPACK間接讓一個(gè)對(duì)象無(wú)效，這個(gè)對(duì)象就是DBMS_UTILITY包主體。因?yàn)槭紫戎匦戮幾g的是Oracle的對(duì)象，但它不是，你能做的只有手動(dòng)編譯其它對(duì)象，但這個(gè)包主體的狀態(tài)仍然是無(wú)效的。
你是否認(rèn)為Oracle提供的內(nèi)置腳本肯定不會(huì)有問(wèn)題，即使變?yōu)闊o(wú)效狀態(tài)，也可以重新運(yùn)行它，并不會(huì)產(chǎn)生什么不良后果，對(duì)系統(tǒng)也不會(huì)有什么大的影響?如果你就是這種想法，那趕緊糾正這種想法，安裝STATSPACK時(shí)，是什么引起這些亂七八糟的事情的?運(yùn)行spcreate.sql時(shí)會(huì)調(diào)用其它腳本，其中一個(gè)就是spcusr.sql腳本，這個(gè)腳本又調(diào)用“@@dbmsjob”，從名字上猜測(cè)出它是干什么的了嗎?對(duì)了，它就是安裝(至少會(huì)嘗試)內(nèi)置的DBMS_JOB，如果此時(shí)你的系統(tǒng)上恰好有一個(gè)DBMS_JOB，那真正發(fā)生DBMS_JOB時(shí)究竟該使用哪一個(gè)呢?
如何來(lái)解決這個(gè)問(wèn)題呢?STATSPACK已經(jīng)安裝成功了，在rdbms目錄下的文檔、發(fā)行注記、類(lèi)REAME文件(spdoc.txt)中也沒(méi)有任何關(guān)于dbmsjob引起問(wèn)題的描述，至少最近還沒(méi)有，即使是翻遍STATSPACK完全參考也找不到丁點(diǎn)這方面的信息?，F(xiàn)在有一個(gè)筆記更新了(149113.1，“安裝和配置STATSPACK[sic]包”)，它里面推薦注釋掉spcusr.sql腳本中調(diào)用dbmsjob的代碼。在2002年的一個(gè)bug中也有提到，但在這個(gè)文檔中卻沒(méi)有包括，直到六年后才包括進(jìn)來(lái)了。
在幾年前發(fā)布的Oracle 10g中的spcusr，調(diào)用dbmsjob的代碼被移除了，更多的是使用DBMS_JOB了。總的說(shuō)來(lái)，這是Oracle歷史上一個(gè)非常大的敗筆，它從來(lái)就沒(méi)有清晰地對(duì)比過(guò)dbmsjob和DBMS_UTILITY。手動(dòng)從Oracle 9i遷移到10g
有一個(gè)問(wèn)題在許多論壇中問(wèn)得比較頻繁，那就是如何在Oracle不同版本之間遷移，升級(jí)或遷移指南(依賴(lài)于版本)列出了許多遷移方法，其中一個(gè)就是人工方式。伴隨10g的發(fā)布，Oracle也提交了一篇筆記(316889.1)，標(biāo)題是“手動(dòng)升級(jí)到10gR2完整檢查清單”，總的來(lái)說(shuō)，這篇筆記幫助非常大，它詳細(xì)地說(shuō)明了升級(jí)要做的一切事項(xiàng)，甚至是一步一步的步驟都列得非常指清楚。不幸的是，這篇筆記還是遺漏了兩個(gè)東西，其中一個(gè)是顯示停機(jī)地址，這一步對(duì)于Oracle來(lái)說(shuō)當(dāng)然很清楚，因?yàn)檫@是一個(gè)未公開(kāi)的bug，它會(huì)刪除與XML DB相關(guān)的占位符表，在未運(yùn)行升級(jí)腳本前，如果沒(méi)有刪除，它是一個(gè)記錄表，因此，很可能會(huì)導(dǎo)致一個(gè)不可恢復(fù)的錯(cuò)誤，或者需要從備份恢復(fù)。這個(gè)筆記的早期版本提到過(guò)運(yùn)行了升級(jí)腳本后會(huì)刪除一個(gè)表，如果你等待這個(gè)錯(cuò)誤發(fā)生，你就厄運(yùn)臨頭了。未公開(kāi)的bug為什么就不能列在這個(gè)指南中呢，最少也應(yīng)該在指南中將其標(biāo)志為“已知問(wèn)題”。
“完全”指南的另一個(gè)問(wèn)題是存在一些關(guān)于時(shí)區(qū)數(shù)據(jù)的錯(cuò)誤信息，筆記中說(shuō)道這個(gè)問(wèn)題僅在10gR1中存在，但在10gR2中卻仍然存在，今天再來(lái)看這篇筆記，你會(huì)發(fā)現(xiàn)已經(jīng)做了許多修正，甚至多了一個(gè)已知問(wèn)題，但在第5步中仍然寫(xiě)到“請(qǐng)注意，這一步僅在10gR1中才需要”，而且，語(yǔ)句在末尾仍然遺漏了一個(gè)句號(hào)。
改變單詞大小
當(dāng)你從32位遷移/升級(jí)到64位系統(tǒng)時(shí)(反之亦然)，你應(yīng)該格外小心，具體要取決于你是如何升級(jí)/遷移的。如果你所有要做的事情是從32位版本遷移到64位(反之亦然)，需要手動(dòng)改變單詞，此時(shí)需要運(yùn)行一個(gè)腳本(utlirp.sql)，取決于你文檔的源(包括Metalink上的筆記)，當(dāng)腳本編譯完所有對(duì)象時(shí)，可能會(huì)給你一個(gè)提示，但那不是真的。
單詞大小的改變使數(shù)據(jù)庫(kù)中的所有PL/SQL無(wú)效，直到你重新編譯所有對(duì)象，你可以閱讀這個(gè)腳本，你會(huì)發(fā)現(xiàn)它的主要步驟是更新一個(gè)屬于SYS用戶(hù)的表，將status列的值設(shè)為6，在哪里調(diào)用utlrp.sql呢?
傳達(dá)改變
你可能是第一個(gè)遇到新bug的幸運(yùn)兒，你如何提取你的經(jīng)驗(yàn)，將其吸收進(jìn)“完全”指南和勘誤表中呢?不要指望分析你的例子會(huì)一翻風(fēng)順，在Oracle的所有權(quán)上有一個(gè)巨大的缺點(diǎn)，這里的所有權(quán)指的是有一個(gè)顧問(wèn)取得了顧客問(wèn)題的所有權(quán)，并解決了這個(gè)問(wèn)題，使用Oracle支持，你最大的收獲是“通過(guò)你的注釋分析是誰(shuí)寫(xiě)的這個(gè)筆記，我現(xiàn)在可以關(guān)閉這個(gè)SR嗎?”
在面向最佳客戶(hù)服務(wù)的公司里，缺乏正確地響應(yīng)客戶(hù)問(wèn)題的姿態(tài)和策略，這樣的公司都不會(huì)有大發(fā)展，可為什么在Oracle這樣的大公司里仍然存在這個(gè)問(wèn)題呢?認(rèn)真地說(shuō)，我知道Oracle公司的人肯定會(huì)讀到這些文章的，當(dāng)人家已經(jīng)給你指出其中的錯(cuò)誤，為什么你卻仍然不修復(fù)它呢?我不止一次在技術(shù)活動(dòng)日上聽(tīng)取某些組織或公布了聯(lián)系信息的高級(jí)支持經(jīng)理的演講，要等到異常事件在公司內(nèi)被處理過(guò)后才修復(fù)筆記嗎?
總結(jié)
當(dāng)你執(zhí)行某些準(zhǔn)備工作(研究和測(cè)試)時(shí)，你會(huì)感覺(jué)非常沮喪，因?yàn)槟銏?zhí)行步驟不正確踩到了Oracle地雷，它使我想起了電影“死亡區(qū)域”，當(dāng)Christopher Walken抓住了deputy(他就是殺手)媽媽的機(jī)械臂時(shí)，通過(guò)對(duì)視，他察覺(jué)到他的媽媽已經(jīng)知道她兒子犯罪了，Walken義憤填膺地吼道：“你知道了，是不是，你一定知道了”，這和“完整”FAQ中的事情是一樣的，有人明明知道Metalink上存在問(wèn)題，但就是不說(shuō)出來(lái)。
真的不用為這種情況辯論，但你能夠做什么來(lái)緩和這個(gè)不良影響呢?使用這個(gè)方法你可以將一個(gè)無(wú)意識(shí)的數(shù)據(jù)變更事件變成一個(gè)服務(wù)變更事件，如果你偶然發(fā)現(xiàn)了某些遺漏的步驟或信息，請(qǐng)?jiān)谡搲幸蠓治鰡T更正相關(guān)筆記。
【編輯推薦】
