误删除数据文件,数据库还没有关闭

简介:

系统环境

RHEL5u4,Oracle11GR2

故障现象

数据文件被误删除

具体情况

接到反馈说,数据文件data20120512.dbf被误删除,需要恢复

数据库提示

ERROR at line 1:
ORA-01116: error in opening database file 16
ORA-01110: data file 16:
‘/u01/app/oracle/product/11.2.0/oradata/ebridge/data20120512.dbf
ORA-27041: unable to open file
Linux Error: 2: No such file or directory
Additional information: 3

数据库还没有被关闭

解决过程

恢复的原理是,在Linux操作系统中,如果文件从操作系统级别被rm掉,之前打开该文件的进程仍然持有相应的文件句柄,所指向的文件仍然可以读写,并且该文件的文件描述符可以从/proc目录中获得。但是要注意的是,此时如果关闭数据库,则此句柄会消失.

检查dbwr的进程PID
[root@jingyong ~]# ps -ef|grep dbw0|grep -v grep
oracle 2236 1 0 06:40 ? 00:00:01 ora_dbw0_jingyong

dbwr会打开所有数据文件的句柄。在proc目录中可以查到,目录名是进程PID,fd表示文件描述符
[root@jingyong ~]# cd /proc/2236/fd

[root@jingyong fd]# ls -l
total 0
lr-x—— 1 oracle oinstall 64 May 31 08:15 0 -> /dev/null
l-wx—— 1 oracle oinstall 64 May 31 08:15 1 -> /dev/null
l-wx—— 1 oracle oinstall 64 May 31 08:15 10 -> /u01/app/oracle/diag/rdbms/jingyong/jingyong/trace/jingyong_ora_2213.trc
l-wx—— 1 oracle oinstall 64 May 31 08:15 11 -> /u01/app/oracle/diag/rdbms/jingyong/jingyong/trace/jingyong_ora_2213.trm
lr-x—— 1 oracle oinstall 64 May 31 08:15 12 -> /u01/app/oracle/product/11.2.0/db/rdbms/mesg/oraus.msb
lr-x—— 1 oracle oinstall 64 May 31 08:15 13 -> /dev/zero
lr-x—— 1 oracle oinstall 64 May 31 08:15 14 -> /proc/2236/fd
lr-x—— 1 oracle oinstall 64 May 31 08:15 15 -> /dev/zero
lrwx—— 1 oracle oinstall 64 May 31 08:15 16 -> /u01/app/oracle/product/11.2.0/db/dbs/hc_jingyong.dat
lrwx—— 1 oracle oinstall 64 May 31 08:15 17 -> /u01/app/oracle/product/11.2.0/db/dbs/lkJINGYONG
lrwx—— 1 oracle oinstall 64 May 31 08:15 18 -> /u01/app/oracle/product/11.2.0/oradata/jingyong/control01.ctl
lrwx—— 1 oracle oinstall 64 May 31 08:15 19 -> /u01/app/oracle/product/11.2.0/oradata/jingyong/control02.ctl
l-wx—— 1 oracle oinstall 64 May 31 08:15 2 -> /dev/null
lrwx—— 1 oracle oinstall 64 May 31 08:15 20 -> /u01/app/oracle/product/11.2.0/oradata/jingyong/system01.dbf
lrwx—— 1 oracle oinstall 64 May 31 08:15 21 -> /u01/app/oracle/product/11.2.0/oradata/jingyong/sysaux01.dbf
lrwx—— 1 oracle oinstall 64 May 31 08:15 22 -> /u01/app/oracle/product/11.2.0/oradata/jingyong/undotbs01.dbf
lrwx—— 1 oracle oinstall 64 May 31 08:15 23 -> /u01/app/oracle/product/11.2.0/oradata/jingyong/users01.dbf (deleted)
lrwx—— 1 oracle oinstall 64 May 31 08:15 24 -> /u01/app/oracle/product/11.2.0/oradata/jingyong/example01.dbf
lrwx—— 1 oracle oinstall 64 May 31 08:15 25 -> /u01/app/oracle/product/11.2.0/oradata/jingyong/jy01.dbf
lrwx—— 1 oracle oinstall 64 May 31 08:15 26 -> /u01/app/oracle/product/11.2.0/oradata/jingyong/temp01.dbf
lr-x—— 1 oracle oinstall 64 May 31 08:15 27 -> /u01/app/oracle/product/11.2.0/db/rdbms/mesg/oraus.msb
l-wx—— 1 oracle oinstall 64 May 31 08:15 3 -> /u01/app/oracle/product/11.2.0/db/rdbms/log/jingyong_ora_2213.trc
lr-x—— 1 oracle oinstall 64 May 31 08:15 4 -> /dev/null
lr-x—— 1 oracle oinstall 64 May 31 08:15 5 -> /dev/null
lr-x—— 1 oracle oinstall 64 May 31 08:15 6 -> /dev/null
lrwx—— 1 oracle oinstall 64 May 31 08:15 7 -> /u01/app/oracle/product/11.2.0/db/dbs/hc_jingyong.dat

注意其中”/u01/app/oracle/product/11.2.0/oradata/jingyong/users01.dbf (deleted)”字样,表示该文件已经被删除,
直接cp该句柄文件名回原位置
[root@jingyong fd]# cp 23 /u01/app/oracle/product/11.2.0/oradata/jingyong/users01.dbf

数据文件users01.dbf恢复回来了,因为了用的是root用户操作的要修改一下权限
[root@jingyong jingyong]# ls -lrt
total 2564428
-rw-r—– 1 root root 723525632 May 16 13:33 system_01.dbf
-rw-r—– 1 root root 104865792 May 22 15:46 example01_bak.dbf
-rw-r—– 1 oracle oinstall 52429312 May 31 06:40 redo02.log
-rw-r—– 1 oracle oinstall 52429312 May 31 06:40 redo01.log
-rw-r—– 1 oracle oinstall 1056768 May 31 06:40 jy01.dbf
-rw-r—– 1 oracle oinstall 104865792 May 31 06:40 example01.dbf
-rw-r—– 1 root root 24911872 May 31 08:16 users01.dbf.bak
-rw-r—– 1 oracle oinstall 31465472 May 31 08:20 temp01.dbf
-rw-r—– 1 oracle oinstall 608182272 May 31 08:21 sysaux01.dbf
-rw-r—– 1 oracle oinstall 104865792 May 31 08:22 undotbs01.dbf
-rw-r—– 1 oracle oinstall 723525632 May 31 08:22 system01.dbf
-rw-r—– 1 oracle oinstall 52429312 May 31 08:22 redo03.log
-rw-r—– 1 root root 24911872 May 31 08:23 users01.dbf
-rw-r—– 1 oracle oinstall 10076160 May 31 08:23 control02.ctl
-rw-r—– 1 oracle oinstall 10076160 May 31 08:23 control01.ctl

[root@jingyong jingyong]# chown oracle:oinstall users01.dbf
[root@jingyong jingyong]# chmod 777 users01.dbf
[root@jingyong jingyong]# ls -lrt
total 2564428
-rw-r—– 1 root root 723525632 May 16 13:33 system_01.dbf
-rw-r—– 1 root root 104865792 May 22 15:46 example01_bak.dbf
-rw-r—– 1 oracle oinstall 52429312 May 31 06:40 redo02.log
-rw-r—– 1 oracle oinstall 52429312 May 31 06:40 redo01.log
-rw-r—– 1 oracle oinstall 1056768 May 31 06:40 jy01.dbf
-rw-r—– 1 oracle oinstall 104865792 May 31 06:40 example01.dbf
-rw-r—– 1 root root 24911872 May 31 08:16 users01.dbf.bak
-rw-r—– 1 oracle oinstall 31465472 May 31 08:20 temp01.dbf
-rw-r—– 1 oracle oinstall 723525632 May 31 08:22 system01.dbf
-rwxrwxrwx 1 oracle oinstall 24911872 May 31 08:23 users01.dbf
-rw-r—– 1 oracle oinstall 104865792 May 31 08:23 undotbs01.dbf
-rw-r—– 1 oracle oinstall 608182272 May 31 08:23 sysaux01.dbf
-rw-r—– 1 oracle oinstall 52429312 May 31 08:23 redo03.log
-rw-r—– 1 oracle oinstall 10076160 May 31 08:23 control02.ctl
-rw-r—– 1 oracle oinstall 10076160 May 31 08:23 control01.ctl

进行数据文件恢复
[oracle@jingyong ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.1.0 Production on Fri May 31 08:24:35 2013

Copyright (c) 1982, 2009, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 – Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> alter database datafile 4 offline;

Database altered.

SQL> recover datafile 4;
Media recovery complete.
SQL> alter database datafile 4 online;

Database altered.


本文转自 张冲andy 博客园博客,原文链接:http://www.cnblogs.com/andy6/p/5716077.html   ,如需转载请自行联系原作者


相关文章
|
2月前
|
Kubernetes 关系型数据库 MySQL
ChaosBlade常见问题之数据库进行故障注入报错ibdata1文件异常如何解决
ChaosBlade 是一个开源的混沌工程实验工具,旨在通过模拟各种常见的硬件、软件、网络、应用等故障,帮助开发者在测试环境中验证系统的容错和自动恢复能力。以下是关于ChaosBlade的一些常见问题合集:
27 1
|
2月前
|
监控 关系型数据库 数据库
OceanBase数据库常见问题之文件存在但是数据库提示文件不存在如何解决
OceanBase 是一款由阿里巴巴集团研发的企业级分布式关系型数据库,它具有高可用、高性能、可水平扩展等特点。以下是OceanBase 数据库使用过程中可能遇到的一些常见问题及其解答的汇总,以帮助用户更好地理解和使用这款数据库产品。
|
2月前
|
XML 关系型数据库 MySQL
【Mysql】有关数据库中一对多/一对一,多对一xml中文件映射问题
【Mysql】有关数据库中一对多/一对一,多对一xml中文件映射问题
19 0
|
1月前
|
JSON 关系型数据库 数据库
【python】Python将100个PDF文件对应的json文件存储到MySql数据库(源码)【独一无二】
【python】Python将100个PDF文件对应的json文件存储到MySql数据库(源码)【独一无二】
【python】Python将100个PDF文件对应的json文件存储到MySql数据库(源码)【独一无二】
|
1月前
|
JSON 关系型数据库 数据库
【python】Python将100个PDF文件对应的json文件存储到MySql数据库(源码)【独一无二】
【python】Python将100个PDF文件对应的json文件存储到MySql数据库(源码)【独一无二】
|
2月前
|
SQL Java 数据库连接
从来没想到我们会扒拉nohup文件去找我们想要的数据,然后往数据库中添加。。。...
从来没想到我们会扒拉nohup文件去找我们想要的数据,然后往数据库中添加。。。...
20 0
|
5月前
|
存储 JSON 关系型数据库
Pandas载入txt、csv、Excel、JSON、数据库文件讲解及实战(超详细 附源码)
Pandas载入txt、csv、Excel、JSON、数据库文件讲解及实战(超详细 附源码)
67 0
|
3天前
|
SQL 存储 小程序
数据库数据恢复—Sql Server数据库文件丢失的数据恢复案例
数据库数据恢复环境: 5块硬盘组建一组RAID5阵列,划分LUN供windows系统服务器使用。windows系统服务器内运行了Sql Server数据库,存储空间在操作系统层面划分了三个逻辑分区。 数据库故障: 数据库文件丢失,主要涉及3个数据库,数千张表。数据库文件丢失原因未知,不能确定丢失的数据库文件的存放位置。数据库文件丢失后,服务器仍处于开机状态,所幸未写入大量数据。
数据库数据恢复—Sql Server数据库文件丢失的数据恢复案例
|
18天前
|
NoSQL MongoDB 数据库
MongoDB数据恢复—MongoDB数据库文件被破坏的数据恢复案例
服务器数据恢复环境: 一台Windows Server操作系统服务器,服务器上部署MongoDB数据库。 MongoDB数据库故障&检测: 工作人员在未关闭MongoDB数据库服务的情况下,将数据库文件拷贝到其他分区。拷贝完成后将原MongoDB数据库所在分区进行了格式化操作,然后将数据库文件拷回原分区,重新启动MongoDB服务,服务无法启动。
|
23天前
|
存储 关系型数据库 MySQL
如何处理爬取到的数据,例如存储到数据库或文件中?
处理爬取的数据,可存储为txt、csv(适合表格数据)或json(适合结构化数据)文件。若需存储大量数据并执行复杂查询,可选择关系型(如MySQL)或非关系型(如MongoDB)数据库。以MySQL为例,需安装数据库和Python的pymysql库,创建数据库和表,然后编写Python代码进行数据操作。选择存储方式应考虑数据类型、数量及后续处理需求。
25 1