事实证明，不作死就不会死，这次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）多多备份，不要偷懒！
没了。