码迷,mamicode.com
首页 > 数据库 > 详细

记一次Oracle 10g数据恢复事件

时间:2015-01-16 16:54:03      阅读:191      评论:0      收藏:0      [点我收藏+]

标签:数据库   数据恢复   oracle   

事实证明,不作死就不会死,这次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)多多备份,不要偷懒!

没了。

记一次Oracle 10g数据恢复事件

标签:数据库   数据恢复   oracle   

原文地址:http://blog.csdn.net/ll328062201/article/details/42777143

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!