日归档:2014 年 1 月 5 日

艰难的修复数据库过程,却发现Oracle 11.2果然强大

具体参见: http://t.askmaclean.com/thread-3790-1-1.html http://www.itpub.net/thread-1839128-1-1.html 纯属自娱自乐,没有实际意义的,顺便说下我的发现和测试中的发现(虽然到现在为止数据库还没有open,我还会继续鼓捣他,毕竟还有些方法还没用上,O(∩_∩)O哈哈~。。。); 首先就是11.2太强大了,很多时候以往的错误都可以fixed,数据库可以open后,做很多跟损坏先关的check 1, 从11.2开始,控制文件自动备份完成的信息由m000完成,且他还完成很多其余工作,当然,只在别的进程触发的时候,他才会去工作 2,DBA_TABLESPACE和V$TABLESPACE的来源不同,一个来源于控制文件,一个来源于基表ts$ 3,ts$和file$不能跳号 4,DBMS_HM很强大(Health Manager),他会定期检查数据库的很多东西,然后让m000进程写trace 。。。 主要的测试步骤已经不太都记得了,但是主要模拟步骤如下: 我的环境: db 11.2.0.3 OEL 5.8 1,创建2个表空间(其实1个也可以,几个都行,为了看得更加清晰),然后切换日志,然后在OS上讲包括UNDOTBS在内的这些数据文件(普通的数据文件和undo的数据文件就可以) 2,启动数据库的时候,你会发现,报错说文件丢失或者损坏,这时你offline drop掉这个报错的文件,数据库应该就可以打开,当然后台有m000生成的trace,HealthManager会不断的触发m000把所有其余随坏的信息都写入trace 3,想办法清理undo$中的问题回滚段 4,创建新的普通数据的表空间,例如“UNDTBS333”,但是设置UNDO_TABLESPACE=这个普通的表空间(scope=spfile),然后启动数据库————–这时我当时的第一个误操作 5,数据库报错,具体忘记了,怎么解决的也忘记了,印象中无非就是undo的隐含参数等等,然后创建正确的undo表空间(create undo tablespace …)给数据库使用 6,解决后,数据库可以正常open,delete from fs$ where name=‘你曾经误操作的那个普通数据表空间 UNDTBS333’,这么做是因为当时我没有仔细考虑风险,因此,手工清理了 其实如果全部都是手工做的话,也可以的,后面发现了需要手工清理什么,但是当时确实么有想太多,误操作了。。。 7,其实这样数据库也还是可以open的,没有太大问题,我用DBMS_HM.RUN_CHECK(‘Dictionary Integrity Check’, ‘lunar-ck-Dict’)检查,其实这时数据库只有undo$, ts$ 和file$数据不一致,没有影响其他数据对象(因为测试过程没有添加用户测试数据) … 继续阅读

发表在 backup&recovery, Internal, Oracle 11.1 & Oracle11.2 | 标签为 , | 留下评论