要順利地解決乙個問題很不容易 ，當看了metalink上不完整的「完全指南」後，問題就不大了，你可能會花大量精力去做相應的研究，並按照標準步驟一步一步執行，特別是閱讀了官方文件，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的**。在2023年的乙個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上存在問題，但就是不說出來。
真的不用為這種情況辯論，但你能夠做什麼來緩和這個不良影響呢?使用這個方法你可以將乙個無意識的資料變更事件變成乙個服務變更事件，如果你偶然發現了某些遺漏的步驟或資訊，請在論壇中要求分析員更正相關筆記。
Oracle資料庫完全解除安裝
1 停止oracle所有的服務 開始 執行 輸入services.msc 2 刪除登錄檔上的oracle的有關鍵值 開始 執行 輸入regedit 將hkey loacal machine software下的主鍵oracle全部刪除。3.下面刪除oracle服務 進入hkey loacal mac...
完全刪除oracle資料庫
軟體環境 1 windows 2000 oracle 8.1.7 2 oracle安裝路徑為 c oracle 實現方法 1 開始 設定 控制面板 管理工具 服務 停止所有oracle服務。2 開始 程式 oracle orahome81 oracle installation products u...
完全解除安裝oracle資料庫
1.關閉oracle所有的服務。可以在windows的服務管理器中關閉 2.開啟登錄檔 regedit 開啟路徑 hkey local machine system currentcontrolset services 刪除該路徑下的所有以oracle開始的服務名稱，這個鍵是標識oracle在win...