ORACLE文件误删除的回复

今日一个同事找到我说他的数据库无法使用了,希望我帮忙研究一下。

其实本人对数据库也没什么深入研究,只是没事的时候喜欢度看看网上高手的资料,遇到事情的时候习惯结合高手资料进行不断尝试以便总结经验。

言归正传一起来研究一下。

同事说他之前想备份数据库表空间文件tnits_BAK_2.ORA,备份了之后习惯性的删除了原有文件,然后想维护一下服务器,就重启数据库服务器了。结果服务器起来之后再启动数据库才想起来有数据库文件刚才被删除掉了,数据库就起不来了,这就是操作过程。

先让他启动了监听lsnrctl start,发现监听能启动起来

使用sqlplus /nolog进入数据库,然后执行startup,系统提示如下:

cannot start already-running ORACLE - shut it down first

这说明在启动的时候有问题了。此时想到可以对数据库启动过程进行分步执行用于判断哪一步出现的问题。

启动数据库分为三个步骤,分别为nomount、mount、open,一般我们在直接使用startup的时候是自动执行这3步的。

当然我们也可以手工单独执行这3个步骤:

startup nomount

alter database mount

alter database open

将这三句在sql窗口中执行,结果如下:

SQL> startup nomount

SP2-0714: invalid combination of STARTUP options

SQL> alter database mount;

alter database mount

*

ERROR at line 1:

ORA-01100: database already mounted

SQL> alter database open;

alter database open

*

ERROR at line 1:

ORA-01113: file 9 needs media recovery

ORA-01110: data file 9: ‘/DataExt/tnits_BAK_2.ORA‘

这里第三个语句中的报错引起了我的重视,他提示“需要回复介质文件”,这说明我同事删除之后还原回去的tnits_BAK_2.ORA这个文件没能让数据库软件检测到。

看了一下同事提供出来的原来文件的截图和还原之后的文件截图发现文件大小并没有区别,只是文件的修改时间上有区别。

修改前

修改后

既然数据库系统没有识别出来文件并提示需要回复介质文件那么我就手工回复一下,执行recover datafile 9,提示如下:

SQL> recover datafile 9

SP2-0640: Not connected

Media recovery complete.

然后再次打开数据库发现依然无法正常打开,还是提示找不到tnits_BAK_2.ORA这个数据文件。

SQL> alter database open ;

alter database open

*

ERROR at line 1:

ORA-01113: file 9 needs media recovery

ORA-01110: data file 9: ‘/DataExt/tnits_BAK_2.ORA‘

突然想到oracle在启动的时候会验证检查点SNC,如果检查点验证不通过,那么是不是有可能不识别还原的文件,从而导致上面提示的找不到某个文件呢

为了验证一下我决定tnits_BAK_2.ORA置为offline状态然后再启动试试。

SQL> alter database datafile ‘/DataExt/tnits_BAK_2.ORA‘  offline;

alter database datafile ‘DataExt/tnits_BAK_2.ORA‘  offline

*

ERROR at line 1:

ORA-01516: nonexistent log file, datafile, or tempfile

"DataExt/tnits_BAK_2.ORA"

结果看来还是不成功,不使用文件名直接使用文件编号再次尝试更改文件状态:

SQL> alter database datafile 9 offline;

alter database datafile 9 offline

*

ERROR at line 1:

ORA-01145:

offline immediate disallowed unless media recovery enabled

这次看来有点效果,但是依然不对,记得在网上看到过一个文章似乎数据库归档和非归档是有区别的,马上上网找了一个文档看了一下,果然是有区别的,归档数据库可以直接使用offline,非归档要使用offline drop才行。

使用如下命令进行操作:

SQL> alter database datafile  ‘/DataExt/tnits_BAK_2.ORA‘ offline drop;

Database altered.

成功完成。

alter database datafile  ‘/DataExt/tnits_BAK_2.ORA‘ offline;

Database altered.

也完成了。

再次执行打开数据库命令,发现可以成功打开了。

SQL> alter database open;

Database altered.

进入数据库进行了验证,发现各项数据还都在,应用程序也可以正常运行,至此修复完毕。

总结如下:

1、数据文件切记不要轻易删除,就算要删除也不要再操作系统层面进行删除,数据库本身可以进行文件的删除,有指定的命令。

2、在数据库启动和online的时候,Oracle一定会去online一个“一致”的表空间。此时,它会发现表空间内部SCN的不一致。根据提示,我们需要手工进行文件恢复。或者使用offline drop和offline让数据库在启动时跳过一致性监测。关于此点可以参考http://www.linuxidc.com/Linux/2014-05/101881p2.htm,以及http://blog.csdn.net/folio/article/details/8156805

3、回复的时候要确认数据库是否为归档模式,确认方式为使用dba权限登录sql窗口,然后执行ARCHIVE LOG LIST,结果提示Database log mode No Archive Mode则为非归档。或执行select name,log_mode from v$database;如果结果为QUERY NOARCHIVELOG则为非归档。

时间: 2024-11-05 13:48:51

ORACLE文件误删除的回复的相关文章

Oracle 数据文件误删除的不完全恢复

应用环境: 我的一个表被人不小心误删除了,这时候,我不可以把整个库都恢复回去,那样太麻烦了. 所以现在我就从新到一个新库,只将这一个数据文件拷贝过来恢复. 那我们Oracle在恢复文件的时候是不可以只恢复一部分数据文件的,因为oracle  要保证数据文件块头信息一致,所以如果我们要恢复部分文件的话,就得采取以下这种方法: 可以另起一个库,再把要恢复的数据文件拷贝过来,恢复.(当然不单单是该数据文件,还要包括system表空间,undo表空间) 1)另起一个库很简单,可以搞出参数文件,在参数文件

完全卸载oracle文件

1.首先停掉所有oracle服务:计算机--管理--服务和应用程序---点击服务,对应所有oracle开头的名称全部停掉: 2.在环境变量中,path变量名中对应的value中oracle对应的路径删掉 3.打开注册表(REGEDIT命令),删除    HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE  4.打开注册表中的 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services 删除以ORACLE开头的所有服务 5.删除HKE

sentos文件误删除恢复

Centos 文件误删除 当意识到误删除文件后,切忌千万不要再频繁写入了,否则 你的数据恢复的数量将会很少. 而我们要做的是,第一时间把服务器上的服务全部停掉,直接killall 进程名 或者 kill -9 pid . 然后把误删除文件所在分区,重新挂载成ro,只读的 (mount  -o ro  /dev/sdb2  /data/). 然后我们需要去下载和安装一个工具叫做   extundelete 1.安装依赖包# yum install e2fsprogs* -y 2.下载并安装extu

Linux文件误删除恢复操作

Linux文件误删除恢复操作 作为一个多用户.多任务的操作系统,Linux下的文件一旦被删除,是难以恢复的.尽管删除命令只是在文件节点中作删除标记,并不真正清除文件内容,但是其他用户和一些有写盘动作的进程会很快覆盖这些数据.不过,对于家庭单机使用的Linux,或者误删文件后及时补救,还是可以恢复的 一.用运SecureCRT远程对操作系统上,查看一下当前系统版本号,及文件系统格式 二.为方便本次实验,我们新创建一文件. 三.执行删除操作 rm -rf  web_1.txt 四.运用,系统自还工具

oracle 控制文件误删除手动恢复小测试

测试系统 OLinux 5.9 oracle版本 11.2.0.4 备份控制文件 1.备份到trace文件 SQL> alter database backup controlfile to trace; Database altered. 查看告警日志,确定备份控制文件trace的位置信息 alter database backup controlfile to trace Backup controlfile written to trace file /u01/app/oracle/dia

北亚案例:oracle数据库误删除数据的恢复方法

学习数据库时,我们只是以学习的态度,考虑如何使用数据库命令语句,并未想过工作中,如果误操作一下,都可能导致无可挽回的损失.当我在工作中真正遇到这些问题时,我开始寻找答案. 今天主要以oracle数据库为例,介绍关于表中数据删除的解决办法.(不考虑全库备份和利用归档日志) 删除表中数据有三种方法: ·delete(删除一条记录) ·drop或truncate删除表格中数据 1.delete误删除的解决方法 原理:利用oracle提供的闪回方法,如果在删除数据后还没做大量的操作(只要保证被删除数据的

恢复oracle中误删除drop掉的表

查看回收站中表 select object_name,original_name,partition_name,type,ts_name,createtime,droptime from recyclebin; 恢复表 SQL>flashback table test_drop to before drop;或SQL>flashback table "BIN$b+XkkO1RS5K10uKo9BfmuA==$0" to before drop; 注:必须9i或10g以上版本

恢复oracle数据库误删除数据的方法汇总

学习数据库时,我们只是以学习的态度,考虑如何使用数据库命令语句,并未想过工作中,如果误操作一下,都可能导致无可挽回的损失.当我在工作中真正遇到这些问题时,我开始寻找答案.今天主要以oracle数据库为例,介绍关于表中数据删除的解决办法.(不考虑全库备份和利用归档日志) 删除表中数据有三种方法:·delete(删除一条记录)·drop或truncate删除表格中数据 1.delete误删除的解决方法    原理:利用oracle提供的闪回方法,如果在删除数据后还没做大量的操作(只要保证被删除数据的

恢复oracle中误删除的表

查看回收站中表 select object_name,original_name,partition_name,type,ts_name,createtime,droptime from recyclebin; 恢复表 SQL>flashback table ZCM002;或SQL>flashback table "BIN$A8uJNocaGVzgUwwrCgpDBg==$0" to before drop; 注:必须9i或10g以上版本支持,flashback无法恢复全文