Linux 平台下 误删 oracle 数据文件的恢复方法

1 问题描述
数据库在正常运行，误操作，直接rm 掉了数据文件。https://www.cndba.cn/hbhe0316/article/4901

https://www.cndba.cn/hbhe0316/article/4901

https://www.cndba.cn/hbhe0316/article/4901

[root@db01 ~]# cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 7.7 (Maipo)
[oracle@db01 ~]$ sqlplus / as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Mon Jul 12 21:04:17 2021
Version 19.11.0.0.0

Copyright (c) 1982, 2020, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> startup
ORACLE instance started.

Total System Global Area 1660940976 bytes
Fixed Size                  9138864 bytes
Variable Size            1241513984 bytes
Database Buffers          402653184 bytes
Redo Buffers                7634944 bytes
Database mounted.
Database opened.

这个问题也要分2种情况，一种是归档模式，一种是非归档模式，归档模式处理就容易很多了。但现在很多由开发人员管理的库是非归档，并且也缺乏专业的运维技能，误操作的概率也会增加很多。https://www.cndba.cn/hbhe0316/article/4901https://www.cndba.cn/hbhe0316/article/4901

2 创建测试数据

[oracle@db01 ~]$ sqlplus / as sysdba
SQL> alter session set container=hbhe;
SQL> alter pluggable database open;
SQL> create tablespace tbs02 datafile '/u01/tbs02.dbf' size 100m;
SQL> create user testuser identified by wwwwww default tablespace tbs02;
SQL> grant connect,resource,dba to testuser;
SQL> conn testuser/wwwwww as sysdba

SQL> conn testuser/wwwwww as sysdba
SQL> create table test1 as select * from all_users;
SQL> create table test2 as select * from all_users;
SQL> create table test3 as select * from all_users;
SQL> select count(1) from test1;
  COUNT(1)
----------
        37

3 归档模式处理
3.1 模拟故障

SQL> archive log list;
Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            /u01/app/oracle/product/19.3.0/dbhome_1/dbs/arch
Oldest online log sequence     16
Next log sequence to archive   18
Current log sequence           18
[root@db01 u01]# rm -rf tbs02.dbf

3.2 恢复
如果在这个时候，重启了数据库或者操作系统，那么句柄就会消失，也就只能通过扫描磁盘进行文件恢复。

[oracle@db01 u01]#  ps -ef|grep dbw0|grep -v grep
oracle    1844     1  0 21:04 ?        00:00:00 ora_dbw0_orcl
[oracle@db01 u01]# cd /proc/1844/fd
[oracle@db01 fd]$ ll
total 0
lr-x------ 1 oracle oinstall 64 Jul 12 21:42 0 -> /dev/null
l-wx------ 1 oracle oinstall 64 Jul 12 21:42 1 -> /dev/null
l-wx------ 1 oracle oinstall 64 Jul 12 21:42 2 -> /dev/null
lrwx------ 1 oracle oinstall 64 Jul 12 21:42 256 -> /u01/app/oracle/oradata/ORCL/control01.ctl
lrwx------ 1 oracle oinstall 64 Jul 12 21:42 257 -> /u01/app/oracle/oradata/ORCL/control02.ctl
lrwx------ 1 oracle oinstall 64 Jul 12 21:42 258 -> /u01/app/oracle/oradata/ORCL/system01.dbf
lrwx------ 1 oracle oinstall 64 Jul 12 21:42 259 -> /u01/app/oracle/oradata/ORCL/sysaux01.dbf
lrwx------ 1 oracle oinstall 64 Jul 12 21:42 260 -> /u01/app/oracle/oradata/ORCL/undotbs01.dbf
lrwx------ 1 oracle oinstall 64 Jul 12 21:42 261 -> /u01/app/oracle/oradata/ORCL/users01.dbf
lrwx------ 1 oracle oinstall 64 Jul 12 21:42 262 -> /oradata/tbs01.dbf
lrwx------ 1 oracle oinstall 64 Jul 12 21:42 263 -> /u01/app/oracle/oradata/ORCL/temp01.dbf
lrwx------ 1 oracle oinstall 64 Jul 12 21:42 264 -> /u01/app/oracle/oradata/ORCL/pdbseed/undotbs01.dbf
lrwx------ 1 oracle oinstall 64 Jul 12 21:42 265 -> /u01/app/oracle/oradata/ORCL/pdbseed/sysaux01.dbf
lrwx------ 1 oracle oinstall 64 Jul 12 21:42 266 -> /u01/app/oracle/oradata/ORCL/pdbseed/system01.dbf
lrwx------ 1 oracle oinstall 64 Jul 12 21:42 267 -> /u01/app/oracle/oradata/ORCL/pdbseed/temp012021-06-27_08-52-02-744-AM.dbf
lrwx------ 1 oracle oinstall 64 Jul 12 21:42 268 -> /u01/tbs02.dbf (deleted)
lrwx------ 1 oracle oinstall 64 Jul 12 21:42 269 -> /u01/app/oracle/oradata/ORCL/hbhe/users01.dbf
lrwx------ 1 oracle oinstall 64 Jul 12 21:42 270 -> /u01/app/oracle/oradata/ORCL/hbhe/undotbs01.dbf
lrwx------ 1 oracle oinstall 64 Jul 12 21:42 271 -> /u01/app/oracle/oradata/ORCL/hbhe/sysaux01.dbf
lrwx------ 1 oracle oinstall 64 Jul 12 21:42 272 -> /u01/app/oracle/oradata/ORCL/hbhe/system01.dbf
lrwx------ 1 oracle oinstall 64 Jul 12 21:42 273 -> /u01/app/oracle/oradata/ORCL/hbhe/temp01.dbf
lr-x------ 1 oracle oinstall 64 Jul 12 21:42 3 -> /dev/null
lr-x------ 1 oracle oinstall 64 Jul 12 21:42 4 -> /u01/app/oracle/product/19.3.0/dbhome_1/rdbms/mesg/oraus.msb
lr-x------ 1 oracle oinstall 64 Jul 12 21:42 5 -> /proc/1844/fd
lrwx------ 1 oracle oinstall 64 Jul 12 21:42 6 -> /u01/app/oracle/product/19.3.0/dbhome_1/dbs/hc_orcl.dat
lrwx------ 1 oracle oinstall 64 Jul 12 21:42 7 -> /u01/app/oracle/product/19.3.0/dbhome_1/dbs/lkORCL
lr-x------ 1 oracle oinstall 64 Jul 12 21:42 8 -> /u01/app/oracle/product/19.3.0/dbhome_1/rdbms/mesg/oraus.msb
lrwx------ 1 oracle oinstall 64 Jul 12 21:42 9 -> socket:[10160]

[oracle@db01 fd]$ cp 268 /u01/tbs02.dbf

因为数据库一直是open的，那么SCN也会不断的变化，我们cp出来的数据文件和数据库当前的信息不一致，所以我们需要进行recover：
SQL>   alter session set container=hbhe;
SQL> alter database datafile '/u01/tbs02.dbf' offline;.
SQL> recover datafile '/u01/tbs02.dbf';
Media recovery complete.
SQL> alter database datafile '/u01/tbs02.dbf' online;

[oracle@db01 u01]$     ls -l /u01/tbs02.dbf 
-rw-r----- 1 oracle oinstall 104865792 Jul 12 21:49 /u01/tbs02.dbf

也正常。 这里有2个注意的问题：数据库是归档模式，数据库或者操作系统没有重启。这2点非常关键。 也正式如此，才让操作比较简单。
如果是非归档模式，那就要复杂很多了。
在非归档模式下，如果删除了数据文件，并且又触发了CKPT，那么CKPT 会直接把整个实例中断掉，也就是说，如果是比较繁忙的数据库，如果误删除数据文件，实例可能会中断，一旦实例中断，那么用之前讲的通过句柄恢复就没有可能性了。
当然也有另一种可能性，就是删除数据文件之后，可以先通过句柄恢复，然后用expdp导出数据，尽可能的挽救部分数据。 这个动作就是与时间赛跑的过程了。
总之生产环境，操作一定要小心，还有要开归档，除非数据允许丢失。https://www.cndba.cn/hbhe0316/article/4901https://www.cndba.cn/hbhe0316/article/4901

https://www.cndba.cn/hbhe0316/article/4901

之前有一篇文章将DB2误删了活动日志，其实误删了DB2的数据文件也可用通过这种方法挽救回来，前提是没有重启DB2和操作系统。https://www.cndba.cn/hbhe0316/article/4901https://www.cndba.cn/hbhe0316/article/4901

版权声明：本文为博主原创文章，未经博主允许不得转载。

Linux,oracle