一次失误drop database

昨天重读《精通oracle系统管理》,对于命令行删除数据库很好奇,我就不顾一切的去验证了一下,好在自己的虚拟机,随便怎么搞都没啥关系,否则祸真是闯大了!

命令行删除数据库步骤:startup database restrict

                      Drop database

就是这两句简单的命令把我折腾了很久!

反思一下!

首先我做这个命令前没有经过大脑,否则我会先rmandatabase 进行一个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.ora中加入如下参数
_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
、建议成功后严格执行以上的711步,完成数据库的检查与分析
4
、全部完成后做一次数据库的全备份
5
、建议联机日志文件一定要实现镜相在不同的磁盘上,避免这种情况的发生,因为任何数据的丢失对于生产来说都是不容许的。

 

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/22821701/viewspace-666271/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/22821701/viewspace-666271/

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值