己亥清爽恢复系列之数据文件3篇：非核心数据文件物理损坏或丢失（无备份恢复）

己亥清爽系列说明：清爽系列是作为恢复系列的基础篇，基于FS（File System）文件系统的手工还原恢复，也叫基于用户管理的还原恢复，来自于博客园AskScuti。

实验说明：物理删除非关键系统数据文件，模拟介质损坏或丢失，且在无备份的情况下，如何进行手工完全还原恢复操作。注：控制文件、在线日志和归档日志都完整的情况下。

基于版本：Oracle 11gR2 11.2.0.4 AskScuti

概念说明：请严格区分什么叫还原（Restore），什么叫恢复（Recover）。

还原（Restore）：如果是基于用户管理（手工）的还原恢复，需要用户主动在系统层面进行拷贝粘贴，这个操作过程称之为还原；如果是基于恢复管理器（RMAN）的恢复，则通过Restore命令进行还原（自动进行），后者不在基础篇讨论。

恢复（Recover）：在完成还原动作之后，数据回到了还原点，但从这个还原点到宕机时间点之间的数据，就要利用归档日志和在线日志进行前滚，直至应用到宕机前最后一次commit提交的状态（完全恢复），或应用到指定的某个时间点（不完全恢复）。

目录

1. 备份（略）

2. 实验

　　2.1 查询确认当前数据

　　2.2 物理删除数据文件

　　2.3 继续插入数据并提交

　　2.4 切换日志或重启

　　2.5 先启库再修复

　　　　2.5.1 将错误文件脱机并启动数据库

　　　　2.5.2 重建数据文件

　　　　2.5.3 恢复数据文件

　　　　2.5.4 将数据文件联机

　　　　2.5.5 验证数据

　　2.6 先修复再启库

　　　　2.6.1 重建数据文件

　　　　2.6.2 恢复数据文件

　　　　2.6.3 打开数据库

　　　　2.6.4 验证数据

1. 备份（略）

不是说好了无备份恢复吗？是的，只是怕你搞叉劈了，所以你还是备一下吧。点此处查看如何进行简单的手工冷备。这个实验和之前的第2篇实验对比着看，总结有什么不同？

2. 实验

2.1 查询确认当前数据

实验数据接第2篇实验。

SQL> delete from henry;

58 rows deleted.

SQL> commit;

Commit complete.

SQL> select count(*) from henry;

  COUNT(*)
----------
     0

SQL> insert into henry values(1);

1 row created.

SQL> insert into henry values(2);

1 row created.

SQL> insert into henry values(3);

1 row created.

SQL> commit;

Commit complete.

SQL> select count(*) from henry;

  COUNT(*)
----------
     3

2.2 物理删除数据文件

SQL> !rm -rf /u01/app/oracle/oradata/PROD1/henry01.dbf

SQL> !ls /u01/app/oracle/oradata/PROD1/
control01.ctl  example01.dbf  redo01.log  redo02.log  redo03.log  sysaux01.dbf    system01.dbf  temp01.dbf  undotbs01.dbf  users01.dbf

2.3 继续插入数据并提交

SQL> insert into henry values(4);

1 row created.

SQL> insert into henry values(5);

1 row created.

SQL> insert into henry values(6);

1 row created.

SQL> commit;

Commit complete.

SQL> insert into henry values(7);

1 row created.

2.4 切换日志或重启

SQL> alter system switch logfile;

System altered.

SQL> /

System altered.

SQL> /
alter system switch logfile
*
ERROR at line 1:
ORA-03113: end-of-file on communication channel
Process ID: 3157
Session ID: 1 Serial number: 5

这里可以选择触发完全检查点报错，也可以多次切换日志报错，也可以重启数据库报错。这里涉及到一个在线日志的理论，你可能会问，为什么切换日志会报错？这里先记着，后面博文单独介绍，完成后链接更新在此处。

2.5 先启库再修复

2.5.1 将错误文件脱机并启动数据库

SQL> startup
ORACLE instance started.

Total System Global Area  417546240 bytes
Fixed Size            2228944 bytes
Variable Size          293604656 bytes
Database Buffers      117440512 bytes
Redo Buffers            4272128 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 6 - see DBWR trace file
ORA-01110: data file 6: ‘/u01/app/oracle/oradata/PROD1/henry01.dbf‘

SQL> alter database datafile 6 offline;

Database altered.

SQL> alter database open;

Database altered.

2.5.2 重建数据文件

因为该数据文件没有备份，但是控制文件和日志文件、归档文件完整，通过控制文件重建数据文件，通过归档日志和在线日志，将数据前滚出来。

SQL> alter database create datafile 6;

Database altered.

SQL> !ls /u01/app/oracle/oradata/PROD1/
control01.ctl  example01.dbf  henry01.dbf  redo01.log  redo02.log  redo03.log  sysaux01.dbf  system01.dbf  temp01.dbf  undotbs01.dbf  users01.dbf

2.5.3 恢复数据文件

SQL> recover datafile 6;
ORA-00279: change 1288523 generated at 05/17/2019 17:31:53 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/fast_recovery_area/PROD1/archivelog/2019_05_17/o1_mf_1_15_gfx0kl
q8_.arc
ORA-00280: change 1288523 for thread 1 is in sequence #15

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
auto
ORA-00279: change 1309022 generated at 05/17/2019 17:43:14 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/fast_recovery_area/PROD1/archivelog/2019_05_17/o1_mf_1_16_gfx1mx
m6_.arc
ORA-00280: change 1309022 for thread 1 is in sequence #16

ORA-00279: change 1329816 generated at 05/17/2019 18:01:33 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/fast_recovery_area/PROD1/archivelog/2019_05_17/o1_mf_1_17_gfxflk
6g_.arc
ORA-00280: change 1329816 for thread 1 is in sequence #17

ORA-00279: change 1353859 generated at 05/17/2019 21:25:35 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/fast_recovery_area/PROD1/archivelog/2019_05_17/o1_mf_1_18_gfxg44
dn_.arc
ORA-00280: change 1353859 for thread 1 is in sequence #18

ORA-00279: change 1354479 generated at 05/17/2019 21:34:59 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/fast_recovery_area/PROD1/archivelog/2019_05_17/o1_mf_1_19_gfxg46
1o_.arc
ORA-00280: change 1354479 for thread 1 is in sequence #19

ORA-00279: change 1354482 generated at 05/17/2019 21:35:01 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/fast_recovery_area/PROD1/archivelog/2019_05_17/o1_mf_1_20_gfxg48
21_.arc
ORA-00280: change 1354482 for thread 1 is in sequence #20

ORA-00279: change 1354485 generated at 05/17/2019 21:35:03 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/fast_recovery_area/PROD1/archivelog/2019_05_17/o1_mf_1_21_gfxg49
94_.arc
ORA-00280: change 1354485 for thread 1 is in sequence #21

ORA-00279: change 1354488 generated at 05/17/2019 21:35:05 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/fast_recovery_area/PROD1/archivelog/2019_05_17/o1_mf_1_22_gfxg4t
g3_.arc
ORA-00280: change 1354488 for thread 1 is in sequence #22

ORA-00279: change 1374493 generated at 05/17/2019 21:35:22 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/fast_recovery_area/PROD1/archivelog/2019_05_17/o1_mf_1_23_gfxg8r
m0_.arc
ORA-00280: change 1374493 for thread 1 is in sequence #23

ORA-00279: change 1374793 generated at 05/17/2019 21:37:28 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/fast_recovery_area/PROD1/archivelog/2019_05_17/o1_mf_1_24_gfxg8s
pl_.arc
ORA-00280: change 1374793 for thread 1 is in sequence #24

ORA-00279: change 1374796 generated at 05/17/2019 21:37:29 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/fast_recovery_area/PROD1/archivelog/2019_05_17/o1_mf_1_25_gfxgf9
s2_.arc
ORA-00280: change 1374796 for thread 1 is in sequence #25

ORA-00279: change 1394799 generated at 05/17/2019 21:39:53 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/fast_recovery_area/PROD1/archivelog/2019_05_17/o1_mf_1_26_gfxj43
y1_.arc
ORA-00280: change 1394799 for thread 1 is in sequence #26

Log applied.
Media recovery complete.

The recovery process

因为我们归档完整，所以直接 AUTO 即可，也可以手工指定具体的归档文件，如果恢复到最后一个归档，提示没有，那么说明数据库要的这个文件应该属于在线日志，因为在线日志里面有需要恢复的数据。

2.5.4 将数据文件联机

SQL> select file#,name,status from v$datafile;

     FILE# NAME                            　　　　　　　　　　　　　　STATUS
---------- ------------------------------------------------------- ----------
     1 　　/u01/app/oracle/oradata/PROD1/system01.dbf           　　SYSTEM
     2 　　/u01/app/oracle/oradata/PROD1/sysaux01.dbf           　　ONLINE
     3 　　/u01/app/oracle/oradata/PROD1/undotbs01.dbf           　 ONLINE
     4 　　/u01/app/oracle/oradata/PROD1/users01.dbf           　　 ONLINE
     5 　　/u01/app/oracle/oradata/PROD1/example01.dbf           　 ONLINE
     6 　　/u01/app/oracle/oradata/PROD1/henry01.dbf          　　  OFFLINE

6 rows selected.

SQL> alter database datafile 6 online;

Database altered.

SQL> select file#,name,status from v$datafile;

     FILE# NAME                            　　　　　　　　　　　　　　STATUS
---------- ------------------------------------------------------- ----------
     1 　　/u01/app/oracle/oradata/PROD1/system01.dbf           　　SYSTEM
     2 　　/u01/app/oracle/oradata/PROD1/sysaux01.dbf           　　ONLINE
     3 　　/u01/app/oracle/oradata/PROD1/undotbs01.dbf              ONLINE
     4　　 /u01/app/oracle/oradata/PROD1/users01.dbf                ONLINE
     5 　　/u01/app/oracle/oradata/PROD1/example01.dbf              ONLINE
     6 　　/u01/app/oracle/oradata/PROD1/henry01.dbf                ONLINE

6 rows selected.

2.5.5 验证数据

SQL> select count(*) from henry;

  COUNT(*)
----------
     6

因为2.3小节在插入数据的时候，7 没有被提交，所以回滚掉，只有6行数据。

2.6 先修复再启库

2.6.1 重建数据文件

SQL> !rm -rf /u01/app/oracle/oradata/PROD1/henry01.dbf

SQL> !ls /u01/app/oracle/oradata/PROD1/
control01.ctl  example01.dbf  redo01.log  redo02.log  redo03.log  sysaux01.dbf    system01.dbf  temp01.dbf  undotbs01.dbf  users01.dbf

SQL> startup force
ORACLE instance started.

Total System Global Area  417546240 bytes
Fixed Size            2228944 bytes
Variable Size          293604656 bytes
Database Buffers      117440512 bytes
Redo Buffers            4272128 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 6 - see DBWR trace file
ORA-01110: data file 6: ‘/u01/app/oracle/oradata/PROD1/henry01.dbf‘

SQL> alter database create datafile 6;

Database altered.

2.6.2 恢复数据文件

2.5章节的恢复，使用的是 AUTO，本小节使用手工指定文件，观察有何差异？

SQL> recover datafile 6;
ORA-00279: change 1288523 generated at 05/17/2019 17:31:53 needed for thread 1
ORA-00289: suggestion : /u01/app/oracle/fast_recovery_area/PROD1/archivelog/2019_05_17/o1_mf_1_15_gfx0klq8_.arc
ORA-00280: change 1288523 for thread 1 is in sequence #15

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/u01/app/oracle/fast_recovery_area/PROD1/archivelog/2019_05_17/o1_mf_1_15_gfx0klq8_.arc
ORA-00279: change 1309022 generated at 05/17/2019 17:43:14 needed for thread 1
ORA-00289: suggestion : /u01/app/oracle/fast_recovery_area/PROD1/archivelog/2019_05_17/o1_mf_1_16_gfx1mxm6_.arc
ORA-00280: change 1309022 for thread 1 is in sequence #16

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/u01/app/oracle/fast_recovery_area/PROD1/archivelog/2019_05_17/o1_mf_1_16_gfx1mxm6_.arc
ORA-00279: change 1329816 generated at 05/17/2019 18:01:33 needed for thread 1
ORA-00289: suggestion : /u01/app/oracle/fast_recovery_area/PROD1/archivelog/2019_05_17/o1_mf_1_17_gfxflk6g_.arc
ORA-00280: change 1329816 for thread 1 is in sequence #17

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/u01/app/oracle/fast_recovery_area/PROD1/archivelog/2019_05_17/o1_mf_1_17_gfxflk6g_.arc
ORA-00279: change 1353859 generated at 05/17/2019 21:25:35 needed for thread 1
ORA-00289: suggestion : /u01/app/oracle/fast_recovery_area/PROD1/archivelog/2019_05_17/o1_mf_1_18_gfxg44dn_.arc
ORA-00280: change 1353859 for thread 1 is in sequence #18

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/u01/app/oracle/fast_recovery_area/PROD1/archivelog/2019_05_17/o1_mf_1_18_gfxg44dn_.arc
ORA-00279: change 1354479 generated at 05/17/2019 21:34:59 needed for thread 1
ORA-00289: suggestion : /u01/app/oracle/fast_recovery_area/PROD1/archivelog/2019_05_17/o1_mf_1_19_gfxg461o_.arc
ORA-00280: change 1354479 for thread 1 is in sequence #19

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/u01/app/oracle/fast_recovery_area/PROD1/archivelog/2019_05_17/o1_mf_1_19_gfxg461o_.arc
ORA-00279: change 1354482 generated at 05/17/2019 21:35:01 needed for thread 1
ORA-00289: suggestion : /u01/app/oracle/fast_recovery_area/PROD1/archivelog/2019_05_17/o1_mf_1_20_gfxg4821_.arc
ORA-00280: change 1354482 for thread 1 is in sequence #20

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/u01/app/oracle/fast_recovery_area/PROD1/archivelog/2019_05_17/o1_mf_1_20_gfxg4821_.arc
ORA-00279: change 1354485 generated at 05/17/2019 21:35:03 needed for thread 1
ORA-00289: suggestion : /u01/app/oracle/fast_recovery_area/PROD1/archivelog/2019_05_17/o1_mf_1_21_gfxg4994_.arc
ORA-00280: change 1354485 for thread 1 is in sequence #21

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/u01/app/oracle/fast_recovery_area/PROD1/archivelog/2019_05_17/o1_mf_1_21_gfxg4994_.arc
ORA-00279: change 1354488 generated at 05/17/2019 21:35:05 needed for thread 1
ORA-00289: suggestion : /u01/app/oracle/fast_recovery_area/PROD1/archivelog/2019_05_17/o1_mf_1_22_gfxg4tg3_.arc
ORA-00280: change 1354488 for thread 1 is in sequence #22

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/u01/app/oracle/fast_recovery_area/PROD1/archivelog/2019_05_17/o1_mf_1_22_gfxg4tg3_.arc

ORA-00279: change 1374493 generated at 05/17/2019 21:35:22 needed for thread 1
ORA-00289: suggestion : /u01/app/oracle/fast_recovery_area/PROD1/archivelog/2019_05_17/o1_mf_1_23_gfxg8rm0_.arc
ORA-00280: change 1374493 for thread 1 is in sequence #23

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
ORA-00279: change 1374793 generated at 05/17/2019 21:37:28 needed for thread 1
ORA-00289: suggestion : /u01/app/oracle/fast_recovery_area/PROD1/archivelog/2019_05_17/o1_mf_1_24_gfxg8spl_.arc
ORA-00280: change 1374793 for thread 1 is in sequence #24

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/u01/app/oracle/fast_recovery_area/PROD1/archivelog/2019_05_17/o1_mf_1_24_gfxg8spl_.arc
ORA-00279: change 1374796 generated at 05/17/2019 21:37:29 needed for thread 1
ORA-00289: suggestion : /u01/app/oracle/fast_recovery_area/PROD1/archivelog/2019_05_17/o1_mf_1_25_gfxgf9s2_.arc
ORA-00280: change 1374796 for thread 1 is in sequence #25

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/u01/app/oracle/fast_recovery_area/PROD1/archivelog/2019_05_17/o1_mf_1_25_gfxgf9s2_.arc
ORA-00279: change 1394799 generated at 05/17/2019 21:39:53 needed for thread 1
ORA-00289: suggestion : /u01/app/oracle/fast_recovery_area/PROD1/archivelog/2019_05_17/o1_mf_1_26_gfxj43y1_.arc
ORA-00280: change 1394799 for thread 1 is in sequence #26

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/u01/app/oracle/fast_recovery_area/PROD1/archivelog/2019_05_17/o1_mf_1_26_gfxj43y1_.arc
Log applied.
Media recovery complete.

The recovery process

2.6.3 打开数据库

SQL> alter database open;

Database altered.

2.6.4 验证数据

SQL> select count(*) from henry;

  COUNT(*)
----------
     6

原文地址：https://www.cnblogs.com/askscuti/p/jhqs03.html

时间： 2024-10-12 03:11:36

己亥清爽恢复系列之数据文件3篇：非核心数据文件物理损坏或丢失（无备份恢复）的相关文章

无备份恢复(归档模式)

无备份恢复表空间前提是归档存在[[email protected] ~]$ rman target / Recovery Manager: Release 10.2.0.5.0 - Production on Tue Aug 5 10:02:46 2014 Copyright (c) 1982, 2007, Oracle.  All rights reserved. connected to target database: NETDATA (DBID=348346524) RMAN> list

己亥清爽恢复系列之数据文件4篇：DROP表后如何恢复（非闪回技术）

己亥清爽系列说明:清爽系列是作为恢复系列的基础篇,基于FS(File System)文件系统的手工还原恢复,也叫基于用户管理的还原恢复,来自于博客园AskScuti. 实验说明:你不小心Drop掉了一张表数据,且没能及时反应过来,后面才恍然大悟,想利用闪回Drop技术进行闪回操作,可发现表空间被挤占,导致回收站里改表已被清空.如何进行手工不完全还原恢复操作.注:在数据文件.控制文件.在线日志和归档日志都完整的情况下. 基于版本:Oracle 11gR2 11.2.0.4 AskScuti 概念说

屌炸天实战 MySQL 系列教程（四）【秒杀七年经验 LowB工程师】 主从复制、读写分离、模拟宕机、备份恢复方案生产环境实战

第一篇:屌炸天实战 MySQL 系列教程(一) 生产标准线上环境安装配置案例及棘手问题解决 第二篇:屌炸天实战 MySQL 系列教程(二) 史上最屌.你不知道的数据库操作 第三篇:屌炸天实战 MySQL 系列教程(三)你不知道的 视图.触发器.存储过程.函数.事物.索引.语句 第四篇:屌炸天实战 MySQL 系列教程(四) 主从复制.读写分离.模拟宕机.备份恢复方案生产环境实战 去年公司有一个七年PHP开发经验的工程师,想要跳槽. 去国内某知名互联网公司面试后,被虐惨了,非要我给他讲讲什么是主从

Influx Sql系列教程九：query数据查询基本篇二

前面一篇介绍了influxdb中基本的查询操作,在结尾处提到了如果我们希望对查询的结果进行分组,排序,分页时,应该怎么操作,接下来我们看一下上面几个场景的支持 在开始本文之前,建议先阅读上篇博文: 190813-Influx Sql系列教程八:query数据查询基本篇 0. 数据准备 在开始查询之前,先看一下我们准备的数据,其中name,phone为tag, age,blog,id为field > select * from yhh name: yhh time age blog id name

赋能云HBase备份恢复 百T级别数据量备份恢复支持

云HBase发布备份恢复功能,为用户数据保驾护航.对大多数公司来说数据的安全性以及可靠性是非常重要的,如何保障数据的安全以及数据的可靠是大多数数据库必须考虑的.2016 IDC的报告表示数据的备份(data-protection)和数据恢复(retention)是Nosql的最基础的需求之一. 为什么需要云HBase备份恢复???我们希望云HBase支持备份和恢复功能,主要原因: 用户直接访问操作数据库,可能存在安全风险:项目存在合规以及监管的强需求:对数据库恢复数据到任意时间点(归档到任意时间

Oracle备份恢复简单过程以及中间的坑.

Oracle 冷备: 貌似需要dbca创建一致的oracle instance 服务器配置版本尽量相同,安装路径相同. 关闭Oracle服务 将oracle app 目录下的oradata以及有快速闪回区的话中的control文件复制到新的服务器里面 注意是完全一致的目录 如果有自己的业务库的数据 也得移动到相同的目录中, 启动恢复到数据库的数据库服务, 如果正常立即可用. 热备: exp expdp imp impdp rman 暂时不写了 用的少. exp/imp 的方式速度较慢 但是兼容性

mysql用户管理、常用sql语句、mysql数据库备份恢复

mysql用户管理 1.新增用户user1,并设置密码为123456 mysql> grant all on *.* to 'user1'@'127.0.0.1' identified by '123456'; #创建user1用户并授予其所有权限"*.*"(通配符) #第一个*:表示所有的数据库 #第二个*:表示所有的表 #127.0.0.1表示来源IP,指的只有这个IP可以连接:'%':代表所有的ip #identified by 设置密码 2.对user1用户进行授权管理

ORACLE 11G没有备份文件参数文件在异机通过rman备份恢复找回被误删的数据

背景:          同事误删除线上数据,所以需要从备份中找回数据恢复.真实屋漏偏逢连夜雨.船迟又遇打头风,前两天备份的磁盘坏块,现在只有rman全备的.bak文件,没有控制文件和参数文件,所以现在需要考虑的是如何根据bak文件在备份数据库上恢复数据,从中找出被误删的数据. 1 通过catalog start with''的方式来恢复 1.1手动创建控制文件 CREATE CONTROLFILE REUSE set DATABASE"powerdes" RESETLOGS ARCH

ORACLE 11G没有备份文件參数文件在异机通过rman备份恢复找回被误删的数据

背景:          同事误删除线上数据.所以须要从备份中找回数据恢复. 真实屋漏偏逢连夜雨.船迟又遇打头风.前两天备份的磁盘坏块,如今仅仅有rman全备的.bak文件,没有控制文件和參数文件,所以如今须要考虑的是怎样依据bak文件在备份数据库上恢复数据,从中找出被误删的数据. 1 通过catalog start with''的方式来恢复 1.1手动创建控制文件 CREATE CONTROLFILE REUSE set DATABASE"powerdes" RESETLOGS AR