昨天在学习的过程中，做了一次大胆的尝试。
切忌无备份的修改，即使是对测试库。。。。。
我的在线重做日志是这样分布的：
共3组，每组有两个并且这两个分布在不同的磁盘上。
昨天，我在毫无备份的情况，把第一组（分为redo01_a.rdo和redo01_b.rdo）的a删除了。
我原以为在startup到open的过程中，oracle虽然会报错但会自动创建丢失的redo01_a.rdo文件，因为我想
第一组的redo01_b.rdo文件并没有丢失，而且他们是相同的。
熟不知，我错了
oracle虽然报了错，但是并没有启动到我理想的open状态，更可怕的是oracle并没有自动创建丢失的redo01_a.rdo文件。
我突然感到这事儿棘手了，后悔当时没有copy一份redo01_a.rdo文件。接着我打开联机文档，试着在mount的状态下删除第一组的redo01_a.rdo文件，因为此时并没有任何数据发生故障。
我将redo01_b.rdo文件拷贝为redo01_a.rdo,并置于正确的位置，可还是不行的，说文件头信息不对。。。
我执行：
alter database open resetlogs;
失败，说要不完全恢复时采用这个。
尝试了：
ALTER DATABASE DROP LOGFILE MEMBER ‘/u01/oradata/denver/redo01_a.rdo’;
居然报错说 该文件找不到，我知道更棘手
我也没有去网上搜答案 因为我知道我能行。
但是 接下来的事情 应证我又错了/
我试着删除第一组日志 失败了
我shutdown immediate后 去看了看参数文件 我的pfile和spfile都有。
可发现里面并没有记录在线重做日志的任何信息。
此时我想到了控制文件 因为控制文件里面肯定就是记录的在线重做日志信息，但是是data类型的，我怎么看呢？更何况我还想修改？
此时想到了《循序渐进oracle》上面说，可以用gettrcname.sql脚本重建控制文件。
对，连忙将数据库置于mount状态下，执行了：
alter database backup controlfile trace;
和：
@/u01/oracle/rdbms/admin/gettrcname.sql
得到了结果：
TRACE_FILE_NAME
-------------------------------------------
/u01/admin/denver/udump/denver_ora_4449.trc
连忙打开
more /u01/admin/denver/udump/denver_ora_4449.trc
从STARTUP NOMOUNT到
CHARACTER SET AL32UTF8
;
全部拷贝出来，到新的脚本中。
并且修改了里面有关在线日志组的信息，将第一组的a去掉了。
满以为这下ok了，可接下来我没想到 我还是错了 而且错得离谱。
我shutdown immediate后 再startup nomunt；
然后执行刚刚自己建立的脚本。可是数据库报错了
控制文件没有创建成功。
我试着将数据库mount起来
这下不好了
mount不上了
此时，虽然控制文件创建失败，但是当前的控制文件已经被修改了（后悔刚刚又没有备份那控制文件。。。）
这下连mount都失败了
我这troubleshooting的能力真是糟糕到顶了
后面我慢慢看了看刚刚gettrcname得到那个trc文件
发现 里面有NORESETLOGS和RESETLOGS之分，哎呀
这才发现我应该用RESETLOGS的那段，后悔自己当时没有仔细看清楚，（DBA确实要沉着和细心呐）
ok，这下有点儿希望了。。。。。。。。。。
用RESETLOGS的那段，重建了控制文件。（里面的日志组我并没有修改）
然后就可以启动到mount状态
心想，这不是又回到我刚刚的状态了吗？
怎么恢复redo01_a.rdo这个文件呢？
哦，原来我才知道RESETLOGS的那段就是用来做 alter database open resetlogs;的
我执行:
alter database open resetlogs;
OK,现在数据库丢失的那个日志oracle已经重建了。。。。
数据库恢复正常////
如果是全部的在线重做日志丢失，也是同过重建控制文件的方法恢复。！！！！
---the end----
阅读(1249) | 评论(0) | 转发(0) |
