一次失误drop database
昨天重读《精通oracle系统管理》，对于命令行删除数据库很好奇，我就不顾一切的去验证了一下，好在自己的虚拟机，随便怎么搞都没啥关系，否则祸真是闯大了！
命令行删除数据库步骤：startup database restrict
Drop database
就是这两句简单的命令把我折腾了很久！
反思一下！
首先我做这个命令前没有经过大脑，否则我会先rman对database 进行一个full backup!
具体命令：shutdown database
Rman target / nocatalog
Startup mount
Backup database
List backup of database
Restore database untile scn 1234455
Recover database until scn1234455
总结一下！
首先：
查看预警日志发现报错：
Sun Jun 20 06:23:46 2010
drop database
Sun Jun 20 06:23:46 2010
Deleted file /u01/oradata/oracle/system01.dbf
Deleted file /u01/oradata/oracle/sysaux01.dbf
Deleted file /u01/oradata/oracle/users01.dbf
Deleted file /u01/oracle/dbs/d:data.ora
Deleted file /u01/UNDOTBS03.dbf
Deleted file /u01/undo.dbf
Deleted file /u01/bfspace.dbf
Deleted file /u01/temp04.dbf
Deleted file /u01/oradata/oracle/redo01.log
Deleted file /u01/oradata/oracle/redo02.log
Deleted file /u01/oradata/oracle/redo03.log
Deleted file /u01/oradata/oracle/temp01.dbf
Deleted file /u01/temp01.dbf
Deleted file /u01/temp02.dbf
Deleted file /u01/temp03.dbf
Instance terminated by USER, pid = 24744
Deleted file /u01/oradata/oracle/control01.ctl
Deleted file /u01/oradata/oracle/control02.ctl
Deleted file /u01/oradata/oracle/control03.ctl
Completed: drop database
（郁闷的是发现日志的时间也就是操作系统的时间设置有误。现在已经设置好了:select sysdate from dual;
#date –s yyyy-mm-dd
#date –s hh:mm:ss)
可以从日志清晰的看出我drop database。
当我启动数据库的时候，报错：
Sun Jun 20 12:15:36 2010
ORA-00202: control file: '/u01/oradata/oracle/control01.ctl'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3
当时我并不知道drop datbase造成的 后果，还以为及时阻止了呢，
经过一些弯路，最终的解决方法是：
我根据报错就像rman恢复控制文件。
Shutdown abort
Rman target / nocatalog
Restore control file from “/u01/oradata/oracle/control01.ctl”
恢复了控制文件以后，数据库就可以开启到mount状态了！
然后rman target / nocatalog
Startup mount
List backup of database
Restore database untile scn 1234455
Recover database until scn12344555
Recover database until scn 1234455
Startup mount
Alter database open resetlogs
当然中间走了很多弯路，现在把所走的弯路总结一下，以免走回头路！
怎么恢复redo file
因为中间未进行recover的时候有报错：
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1: '/u01/oradata/oracle/system01.dbf'
就想解决这个问题，
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS
---------- ---------- ---------- ---------- ---------- --- ----------------
FIRST_CHANGE# FIRST_TIME
------------- ----------
1 1 71 52428800 1 NO CURRENT
2093748 2010-04-11
3 1 70 52428800 1 YES INACTIVE
2061024 2010-04-10
2 1 69 52428800 1 YES INACTIVE
2036997 2010-04-09
可以看出是非归档模式，并且正在使用。
在上网找到一篇写的非常好，损坏非当前联机日志
大家都清楚，联机日志分为当前联机日志和非当前联机日志，非当前联机日志的损坏是比较简单的，一般通过clear命令就可以解决问题。
1、启动数据库，遇到ORA-00312 or ORA-00313错误，如
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: 'D:\ORACLE\ORADATA\TEST\REDO01.LOG'
从这里我们知道日志组1的数据文件损坏了
从报警文件可以看到更详细的信息
2、查看V$log视图
SQL> select group#,sequence#,archived,status from v$log;
GROUP# SEQUENCE# ARCHIVED STATUS
---------- ---------- -------- ----------------
1 1 YES
INACTIVE
2 2 YES
INACTIVE
3 3 NO CURRENT
可以知道，该组是非当前状态，而且已经归档。
3、用CLEAR命令重建该日志文件
SQL>alter database clear logfile group 1;
如果是该日志组还没有归档，则需要用
SQL>alter database clear unarchived logfile group 1;
4、打开数据库，重新备份数据库
SQL>alter database open;
说明：
1、如果损坏的是非当前的联机日志文件，一般只需要clear就可以重建该日志文件，但是如果该数据库处于归档状态但该日志还没有归档，就需要强行clear。
2、建议clear，特别是强行clear后作一次数据库的全备份。
3、此方法适用于归档与非归档数据库
损坏当前联机日志
归档模式下当前日志的损坏有两种情况，
一、是数据库是正常关闭，日志文件中没有未决的事务需要实例恢复，当前日志组的损坏就可以直接用alter database clear unarchived logfile group n来重建。
二、是日志组中有活动的事务，数据库需要媒体恢复，日志组需要用来同步，有两种补救办法
A. 最好的办法就是通过不完全恢复，可以保证数据库的一致性，但是这种办法要求在归档方式下，并且有可用的备份
B. 通过强制性恢复，但是可能导致数据库不一致。
下面分别用来说明这两种恢复方法
5.1.2.1 通过备份来恢复
1、打开数据库，会遇到一个类似的错误
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: 'D:\ORACLE\ORADATA\TEST\REDO01.LOG'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2) 系统找不到指定的文件
2、查看V$log，发现是当前日志
SQL> select group#,sequence#,archived,status from v$log;
GROUP# SEQUENCE# ARCHIVED STATUS
---------- ---------- -------- ----------------
1 1 NO CURRENT
2 2 YES
INACTIVE
3 3 YES
INACTIVE
3、发现clear不成功
SQL> alter database clear unarchived logfile group 1;
alter database clear unarchived logfile group 1
*
ERROR at line 1:
ORA-01624: log 1 needed for crash recovery of thread 1
ORA-00312: online log 1 thread 1: 'D:\ORACLE\ORADATA\TEST\REDO01.LOG'
4、拷贝有效的数据库的全备份，并不完全恢复数据库
可以采用获取最近的SCN的办法用until scn恢复或用until cnacel恢复
recover database until cancel
先选择auto，尽量恢复可以利用的归档日志，然后重新
recover database until cancel
这次输入cancel，完成不完全恢复，也就是说恢复两次。
如：
SQL> recover database until cancel;
Auto
……
SQL> recover database until cancel;
Cancel;
5、利用alter database open resetlogs打开数据库
说明：
1、这种办法恢复的数据库是一致的不完全恢复，会丢失当前联机日志中的事务数据
2、这种方法适合于归档数据库并且有可用的数据库全备份。
3、恢复成功之后，记得再做一次数据库的全备份。
4、建议联机日志文件一定要实现镜相在不同的磁盘上，避免这种情况的发生，因为任何数据的丢失对于生产来说都是不容许的。
如果没有备份，进行强制性恢复
1、打开数据库，会遇到一个类似的错误
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: 'D:\ORACLE\ORADATA\TEST\REDO01.LOG'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2) 系统找不到指定的文件
2、查看V$log，发现是当前日志
SQL> select group#,sequence#,archived,status from v$log;
GROUP# SEQUENCE# ARCHIVED STATUS
---------- ---------- -------- ----------------
1 1 NO CURRENT
2 2 YES
INACTIVE
3 3 YES
INACTIVE
3、发现clear不成功
SQL> alter database clear unarchived logfile group 1;
alter database clear unarchived logfile group 1
*
ERROR at line 1:
ORA-01624: log 1 needed for crash recovery of thread 1
ORA-00312: online log 1 thread 1: 'D:\ORACLE\ORADATA\TEST\REDO01.LOG'
4、把数据库down掉
SQL>shutdown immediate
5、在init
_allow_resetlogs_corruption=TRUE
6、重新启动数据库,利用until cancel恢复
SQL>recover database until cancel;
Cancel
如果出错，不再理会，发出
SQL>alter database open resetlogs;
7、数据库被打开后，马上执行一个full export
8、shutdown数据库,去掉_all_resetlogs_corrupt参数
9、重建库
10、import并完成恢复
11、建议执行一下ANALYZE TABLE ...VALIDATE STRUCTURE CASCADE;
说明：
1、该恢复方法是没有办法之后的恢复方法，一般情况下建议不要采用，因为该方法可能导致数据库的不一致
2、该方法也丢失数据，但是丢失的数据没有上一种方法的数据多，主要是未写入数据文件的已提交或未提交数据。
3、建议成功后严格执行以上的7到11步，完成数据库的检查与分析
4、全部完成后做一次数据库的全备份
5、建议联机日志文件一定要实现镜相在不同的磁盘上，避免这种情况的发生，因为任何数据的丢失对于生产来说都是不容许的。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/22821701/viewspace-666271/ ，如需转载，请注明出处，否则将追究法律责任。
