事實證明，不作死就不會死，這次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）多多備份，不要偷懶！
沒了。
