記一次Oracle 10g數據恢復事件

事實證明，不作死就不會死，這次Oracle崩潰，花費了我兩天的時間，只由于我裝了些莫名的安卓摹擬器以后又卸載了。

卸載以后，發現oracle數據庫用不了了，心1涼，由于自己存了進兩年的數據全在里面，近70個g。因而趕快進Net Manager，進不去了，需要輸入配置文件的路徑！這絕對是ORAACLE_HOME沒了。。。因而在環境變量中添加1個ORACLE_HOME變量，地址指向E:oracleproduct10.2.0db_1。再進Net Manager，沒問題了，卻發現報錯ora⑴2514。。。

這是個最最多見的報錯，意味著很容易解決或很難解決。

趕快搜搜，網上1般兩種做法：1.修改監聽文件listener.ora文件，在里面加1段SID_DESC...GLOBAL_NAME= orcl （自己的實例名），解釋是由于靜態監聽需要設置主動尋覓該實例，否則它找不到這個實例。因而我如是修改，接著報另外一個毛病：ora-01034和ora⑵7101。

繼續上網尋覓，說是由于不正常退出等1些操作而致使Oracle不知道指向哪一個實例名，需要在cmd中用set ORACLE_SID=orcl設置，因而設置。接著需要重新啟動Oracle。這時候問題又來了，我居然忘記自己的sys用戶了！由于時間久遠，自己怎樣都想不起來自己的sys用戶了，也就是說，當我在cmd中進入sqlplus后，沒法conn了。。。這下我突然慌神了，感覺問題挺大。

上1條路走不通，我決定換個思路，就是這么活躍。網上還有1種辦法就是說重建監聽。那就重建唄。cmd中netca邊建邊視察。基本無異常。建立成功。然后在OS的服務中找到監聽服務，啟動之（這里也能夠在cmd中lsnrctl start）。但是啟動后還是報ora⑴2514，就是說所有努力都白費啦！！！

冷靜下來分析緣由，竟發現服務中有兩個監聽服務：1個是標準的OracleOraDb10g_home1TNSListener，另外一個則是OracleTNSListener，而后者啟動了，前者沒有啟動。上網搜下它們的區分，沒有資料，心里很困惑。

因而打算再建個監聽看看。netca接著建，發現又多了1個監聽服務：OracleTNSListener1。我似乎明白了甚么。。。上網搜索監聽服務的命名規則，發現是以Oracle開頭，TNS+監聽名結尾，中間加上ORACLE_HOME_NAME構成。瞬間明白了，原來ORACLE_HOME_NAME這個配置都沒了！這個ORACLE_HOME_NAME其實就是在你安裝數據庫時默許的1個選項，叫做名稱。

了解以后，決定環境變量中設置ORACLE_HOME_NAME。這個信息包括上面的ORACLE_HOME其實都在oracle的1個配置文件中保存的。當配置文件丟失時，oracle還會通過環境變量來找，所以在環境變量中配置好，oracle就能夠使用了。配置ORACLE_HOME_NAME，值為OraDb10g_home1。

配置完成，刪除1切監聽，重建。以后發現，標準的OracleOraDb10g_home1TNSListener的出現了，而且啟動了！下面的OracleServiceORCL是1直都啟動的，這兩個服務都啟動了，就意味著。。。弄好了！

呵呵，還是太天真。照舊報ora⑴2514毛病。

我又冷靜了大半天，通過連接其它機器的數據庫和查看監聽狀態lsnrstl status來檢查監聽是不是正常，發現監聽是沒問題的。既然監聽沒問題，也就是說，上面的努力全白費了，數據庫連不上的根本緣由實際上是實例的問題。

又查閱alert_orcl.log文件（E:oracleproduct10.2.0adminorcldump下），翻到最后部份，發現1些tns⑴2560毛病。結合網上的1些說法，最后推定：Oracle數據庫壞了。。。

這真是巨大的悲劇。我沒有sys用戶，沒法nomount、mount、open，不知道具體哪部份產生了甚么樣的毛病。或許重新啟動1下就行了，但是我沒有sys用戶，就沒有操作的權限。

只能改變思路，決心重新安裝數據庫了！

那末，我就要使用數據文件來進行數據恢復了！

上網搜索，很多教程，發現它們都是在講只有數據文件的恢復，而我現在數據文件、控制文件、日志文件都在，感覺應當會更加簡單。因而決定先在別的電腦上實驗1下。

我翻出自己的筆記本，網上的教程說只要建立個同名的實例，端口等1致便可，然后將上述文件（主要是oradata這個文件夾）copy進去覆蓋掉，再重啟服務就好了。那就這么試試吧！

但這里我發現個問題，筆記本是11g的Oracle，真是坑爹。無奈只好硬著頭皮將上述文件拷到對應文件夾下。

cmd進入到sys用戶（本的sys用戶存在），開始嘗試啟動：shutdown immediate、start nomount都沒問題（nomount是參數文件找控制文件，只要控制文件路徑準確，就不會報錯），接著alter database mount（這階段是控制文件找數據文件，找不到就會報錯），報錯，由于數據文件在控制文件中存儲的地址是10g的E:oracleproduct10.2.0oradata，而不是11g的app...因而將數據文件拷貝到控制文件指向的地址（都被逼到這份兒上了― ―！），以后啟動mount，沒問題！

突然全部人躁起來了！這是要成功嗎？

然后alter database open了啊！屏幕上蹦蹦蹦往下彈些良好的信息了啊！要成功了嗎？

呵呵，還是太天真。ora-00704和ora⑶9700。繼續搜索，發現是數據字典表由于版本的問題而報錯啊！網上說履行sql腳本更新數據字典。那就整吧！

catupgrd.sql、catalog.sql、catproc.sql、utlrp.sql4個腳本，在cmd的sqlplus中@路徑來履行。這4個腳本在我這里只找到3個，第3個沒有，因而順次履行。

呵呵，1大波毛病滾屏襲來啊！！！全是沒法創建啊！！！感覺要跳樓了啊！！！

冷靜片刻，覺得10g和11g是不可逾越的鴻溝，因而決定，卸載11g，改成10g繼續上面的操作。

10g安裝終了，將oradata覆蓋，繼續在cmd的sqlplus中履行。shutdown immediate、start nomount、alter database mount沒問題，alter database open。。。又報錯了。。。我去，居然報dbf文件是11g的而不是10g的！原來dbf被11g這么1弄就被玷污了啊！真是羞澀啊！

重新拷10g的oradata文件夾，繼續open。。。

終究成功了！！！

弄了我兩天啊！！！成功了！！！

總結1下：

（1）ora⑴2514只有兩方面毛病，監聽異常，或實例未啟動，可以在這兩方面進行排查，而不去盲目地依照網上的方法改listener.ora和重建監聽，或許是實例不行了呢；

（2）若要進行數據恢復，則最好有oradata這個文件夾下的所有文件，這樣有恃無恐；

（3）我折騰兩天，或許在最開始重啟數據庫就會恢復正常，但是sys用戶丟了，使得這1切困難起來；

（4）要學會冷靜分析，結合自己遇到的情況采取相應的措施，而不能1味依照網上的解決辦法履行，那或許其實不合適你；

（5）多多備份，不要偷懶！

沒了。

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈