事实证明，不作死就不会死，这次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）多多备份，不要偷懒！
没了。
原文地址：http://blog.csdn.net/ll328062201/article/details/42777143
