日归档：2014 年 1 月 5 日

具体参见: 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$数据不一致，没有影响其他数据对象（因为测试过程没有添加用户测试数据） … 继续阅读 →