記一次Oracle 10g資料恢複事件，oracle10g

記一次Oracle 10g資料恢複事件，oracle10g

事實證明，不作死就不會死，這次Oracle崩潰，花費了我兩天的時間，只因為我裝了些莫名的安卓模擬器之後又卸載了。

卸載之後，發現oracle資料庫用不了了，心一涼，因為自己存了進兩年的資料全在裡面，近70個g。於是趕緊進Net Manager，進不去了，需要輸入設定檔的路徑！這絕對是ORAACLE_HOME沒了。。。於是在環境變數中添加一個ORACLE_HOME變數，地址指向E:\oracle\product\10.2.0\db_1。再進Net Manager，沒問題了，卻發現報錯ora-12514。。。

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

趕緊搜搜，網上一般兩種做法：1.修改監聽檔案listener.ora檔案，在裡面加一段SID_DESC...GLOBAL_NAME= orcl （自己的執行個體名），解釋是因為靜態監聽需要設定主動尋找該執行個體，否則它找不到這個執行個體。於是我如是修改，接著報另一個錯誤：ora-01034和ora-27101。

繼續上網尋找，說是由於不正常退出等一些操作而導致Oracle不知道指向哪個執行個體名，需要在cmd中用set ORACLE_SID=orcl設定，於是設定。接著需要重新啟動Oracle。這時問題又來了，我竟然忘記自己的sys使用者了！由於時間久遠，自己怎麼都想不起來自己的sys使用者了，也就是說，當我在cmd中進入sqlplus後，無法conn了。。。這下我突然慌神了，感覺問題挺大。

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

冷靜下來分析原因，竟探索服務中有兩個監聽服務：一個是標準的OracleOraDb10g_home1TNSListener，另一個則是OracleTNSListener，而後者啟動了，前者沒有啟動。上網搜下它們的區別，沒有資料，心裡很困惑。

於是打算再建個監聽看看。netca接著建，發現又多了一個監聽服務：OracleTNSListener1。我似乎明白了什麼。。。上網搜尋監聽服務的命名規則，發現是以Oracle開頭，TNS+監聽名結尾，中間加上ORACLE_HOME_NAME構成。瞬間明白了，原來ORACLE_HOME_NAME這個配置都沒了！這個ORACLE_HOME_NAME其實就是在你安裝資料庫時預設的一個選項，叫做名稱。

瞭解之後，決定環境變數中設定ORACLE_HOME_NAME。這個資訊包括上面的ORACLE_HOME其實都在oracle的一個設定檔中儲存的。當設定檔丟失時，oracle還會通過環境變數來找，所以在環境變數中配置好，oracle就可以使用了。配置ORACLE_HOME_NAME，值為OraDb10g_home1。

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

呵呵，還是太天真。依舊報ora-12514錯誤。

我又冷靜了大半天，通過串連其它機器的資料庫以及查看監聽狀態lsnrstl status來檢查監聽是否正常，發現監聽是沒問題的。既然監聽沒問題，也就是說，上面的努力全白費了，資料庫連不上的根本原因其實是執行個體的問題。

又查閱alert_orcl.log檔案（E:\oracle\product\10.2.0\admin\orcl\bdump\下），翻到最後部分，發現一些tns-12560錯誤。結合網上的一些說法，最後推定：Oracle資料庫壞了。。。

這真是巨大的悲劇。我沒有sys使用者，無法nomount、mount、open，不知道具體哪部分發生了什麼樣的錯誤。也許重新啟動一下就好了，但是我沒有sys使用者，就沒有操作的許可權。

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

那麼，我就要使用資料檔案來進行資料恢複了！

上網搜尋，很多教程，發現它們都是在講只有資料檔案的恢複，而我現在資料檔案、控制檔案、記錄檔都在，感覺應該會更加簡單。於是決定先在別的電腦上實驗一下。

我翻出自己的筆記本，網上的教程說只要建立個同名的執行個體，連接埠等一致即可，然後將上述檔案（主要是oradata這個檔案夾）copy進去覆蓋掉，再重啟服務就行了。那就這麼試試吧！

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

cmd進入到sys使用者（本的sys使用者存在），開始嘗試啟動：shutdown immediate、start nomount都沒問題（nomount是參數檔案找控制檔案，只要控制檔案路徑準確，就不會報錯），接著alter database mount（這階段是控制檔案找資料檔案，找不到就會報錯），報錯，因為資料檔案在控制檔案中儲存的地址是10g的E:\oracle\product\10.2.0\oradata，而不是11g的app\...於是將資料檔案拷貝到控制檔案指向的地址（都被逼到這份兒上了— —！），之後啟動mount，沒問題！

突然整個人躁起來了！這是要成功嗎？

然後alter database open了啊！螢幕上蹦蹦蹦往下彈些良好的資訊了啊！要成功了嗎？

呵呵，還是太天真。ora-00704和ora-39700。繼續搜尋，發現是資料字典表因為版本的問題而報錯啊！網上說執行sql指令碼更新資料字典。那就整吧！

catupgrd.sql、catalog.sql、catproc.sql、utlrp.sql四個指令碼，在cmd的sqlplus中@路徑來執行。這四個指令碼在我這裡只找到三個，第三個沒有，於是依次執行。

呵呵，一大波錯誤滾屏襲來啊！！！全是無法建立啊！！！感覺要跳樓了啊！！！

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

10g安裝完畢，將oradata覆蓋，繼續在cmd的sqlplus中執行。shutdown immediate、start nomount、alter database mount沒問題，alter database open。。。又報錯了。。。我去，竟然報dbf檔案是11g的而不是10g的！原來dbf被11g這麼一搞就被玷汙了啊！真是羞澀啊！

重新拷10g的oradata檔案夾，繼續open。。。

終於成功了！！！

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

總結一下：

（1）ora-12514隻有兩方面錯誤，監聽異常，或者執行個體未啟動，可以在這兩方面進行排查，而不去盲目地按照網上的方法改listener.ora和重建監聽，也許是執行個體不行了呢；

（2）若要進行資料恢複，則最好有oradata這個檔案夾下的所有檔案，這樣有恃無恐；

（3）我折騰兩天，也許在最開始重啟資料庫就會恢複正常，但是sys使用者丟了，使得這一切困難起來；

（4）要學會冷靜分析，結合自己遇到的情況採取相應的措施，而不能一味按照網上的解決辦法執行，那也許並不適合你；

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

沒了。