基于时间点的不完全恢复的例子(r6笔记第9天)

说到不完全恢复,一般有三种场景,基于时间点的不完全恢复,基于scn的不完全恢复,基于cancel的不完全恢复。 三种情况都是不完全恢复采用的方式,而不完全恢复都是在完全恢复的过程中出现了这样那样的错误,数不胜数,基本就是归档,redo损坏丢失,控制文件丢失,备份的问题,手工失误等等。 我们可以举一个不完全恢复的案例,其实在实际操作的过程中还是有一些值得总结和学习的地方。 第一步准备基本的数据。目前我们可以看到在表空间data上只有一个表new_recover

SQL> select owner,segment_name,segment_type from dba_segments where  tablespace_name='DATA';
OWNER    SEGMENT_NAME    SEGMENT_TYPE
TEST       NEW_RECOVER         TABLE

里面有一些数据。

SQL> select count(*)from test.new_recover;
  COUNT(*)
----------
       4667

第二步开始热备份,为了明白整个过程,我们手工来完成这个不完全恢复。 使用下面的语句生成热备份的动态sql select 'alter tablespace '||tablespace_name||' begin backup;' from dba_tablespaces where l ogging='LOGGING'; 然后拷贝物理文件到指定的备份目录即可。 拷贝完成之后,使用下面的语句声明完成了热备份 select 'alter tablespace '||tablespace_name||' end backup;' from dba_tablespaces where l ogging='LOGGING'; 第三步我们开始删除表空间data,然后停掉数据库开始尝试恢复。 drop tablespace data including contents and datafiles; shut immediate 删除之后,不要担心自己没记下时间戳,其实在数据库日志里面会有记录。 Sun Jul 26 19:29:37 2015 drop tablespace data including contents and datafiles Deleted file /u02/ora11g/oradata/TEST/data01.dbf Completed: drop tablespace data including contents and datafiles Sun Jul 26 19:29:54 2015 第四步我们开始尝试还原数据文件 我们把数据文件从热备份的路径还原到数据文件的路径下 startup mount !cp xxxx/hot_backup/*.dbf /u02/ora11g/oradata/TEST 第五步我们可以尝试开始基于时间点的恢复,基于时间点的这种恢复就是不完全恢复了,因为时间点之后的数据变更就会丢失。

SQL> recover database until time '2015-07-26 19:29:37'; Media recovery complete. 恢复的过程很快就会完成。这个时候删除的数据文件还没有体现在控制文件里面,在v$datafile里也看不到。

SQL>  Select name from v$datafile;
NAME
--------------------------------------------------------------------------------
/u02/ora11g/oradata/TEST/system01.dbf
/u02/ora11g/oradata/TEST/sysaux01.dbf
/u02/ora11g/oradata/TEST/undotbs01.dbf
/u02/ora11g/oradata/TEST/testdata.dbf

第6步我们把数据库使用resetlogs的方式打开

SQL> alter database open resetlogs;
Database altered.

这个时候去查看v$datafile就会发现多了一个陌生的文件。但是从名字我们看出来提示我们是曾经丢失的一个文件,但是不知道怎么回事就给恢复回来了。

SQL>  select name from  v$datafile;
NAME
--------------------------------------------------------------------------------
/u02/ora11g/oradata/TEST/system01.dbf
/u02/ora11g/oradata/TEST/sysaux01.dbf
/u02/ora11g/oradata/TEST/undotbs01.dbf
/u02/ora11g/product/11.2.0/dbhome_1/dbs/MISSING00004
/u02/ora11g/oradata/TEST/testdata.dbf

这个时候去尝试ls -l查看文件是否存在,发现没有这个文件。 SQL> !ls -l /u02/ora11g/product/11.2.0/dbhome_1/dbs/MISSING00004 ls: /u02/ora11g/product/11.2.0/dbhome_1/dbs/MISSING00004: No such file or directory 我们先把这个文件给rename一下。

alter database rename file '/u02/ora11g/product/11.2.0/dbhome_1/dbs/MISSING00004' to '/ora11g/oradata/TEST/data01.dbf';

Database altered. 第七步我们开始恢复这个数据文件 恢复的时候很可能提示你选择恢复的方式,我们还是选择auto

SQL> recover datafile '/u02/ora11g/oradata/TEST/data01.dbf';
ORA-00279:  change 970750 generated at 07/26/2015 19:26:36 needed for thread 1
ORA-00289:  suggestion  :
/u02/ora11g/product/11.2.0/dbhome_1/dbs/arch1_1_886076275.dbf
ORA-00280:  change 970750 for thread 1 is in sequence #1

Specify log: {<RET>=suggested | filename | AUTO |  CANCEL}
auto
Log applied.
Media recovery  complete.

恢复完成之后,查看v$recover_file看看是否还有其它数据文件需要恢复。

SQL> select *from v$recover_file;

no rows selected 恢复之后查看表空间的状态,显示是online,但是实际上还不是。

SQL> select tablespace_name,status from dba_tablespaces;
TABLESPACE_NAME                STATUS
------------------------------  ---------
SYSTEM                          ONLINE
SYSAUX                          ONLINE
UNDOTBS                         ONLINE
TEMP                            ONLINE
DATA                            ONLINE
TESTDATA                        ONLINE

因为这个时候我们查看数据还是有问题的。

SQL> select count(*)from test.new_recover;
select count(*)from  test.new_recover
                         *
ERROR at line 1:
ORA-00376:  file 4 cannot be read at this time
ORA-01110: data file 4:  '/u02/ora11g/oradata/TEST/data01.dbf'

第八步我们把表空间置为Online,整个恢复的过程就完成了。

SQL> alter tablespace data online;
Tablespace altered.
SQL> select count(*)from test.new_recover;
  COUNT(*)
----------
       4667

在整个不完全的恢复过程中碰到了不少的Ora错误,有些错误是自己的问题从一个演变为另外一个错误,最终导致不可恢复。不管怎么样从这个过程中还是能够看到在数据恢复的过程中,oracle还是做了很多的工作来保证了数据恢复成为可能。

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2015-07-26

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏james大数据架构

android之数据存储之SQLite

          SQLite开源轻量级数据库,支持92-SQL标准,主要用于嵌入式系统,只占几百K系统资源此外,SQLite 不支持一些标准的 SQL 功能...

21490
来自专栏企鹅号快讯

带你认识一下mysql中数据库information

information_schema 大家在安装或使用MYSQL时,会发现除了自己安装的数据库以外,还有一个information_schema数据库。 inf...

22780
来自专栏互联网杂技

修改数据表(列操作)

前面有介绍数据的增删改查,是针对具体的数据表格里面的数据; 下面是对列的操作; 修改表名 alter table test rename test1; -...

366110
来自专栏安全

phpMyAdmin 4.7.x CSRF 漏洞利用

phpMyAdmin是个知名MySQL/MariaDB在线管理工具,phpMyAdmin团队在4.7.7版本中修复了一个危害严重的CSRF漏洞(PMASA-20...

35370
来自专栏乐沙弥的世界

手动清理Oracle审计记录

a、对于Oracle 11g,审计功能默认被开启,因此如果在必须启用的情况下应考虑性能影响; b、开启审计的情况下,建议将审计从system或sysaux表...

22420
来自专栏乐沙弥的世界

ORA-31623: a job is not attached to this session via the specified handle

    在使用Oracel Datapump API时碰到ORA-31623(a job is not attached to this session via...

13330
来自专栏数据库新发现

关于checkpoint cnt和checkpoint scn

SQL> alter session set events 'immediate trace name CONTROLF level 10';

15620
来自专栏数据和云

从商用到开源:15个维度,全面剖析DB2与MySQL数据库的差异

编辑手记 MySQL是目前最流行的开源数据库,由于其部署方便,运维简单,被广泛用于互联网的各个领域。随着整体IT架构的变更,传统的金融,电信业务,也逐渐走上从商...

68870
来自专栏Hadoop实操

CM启动报InnoDB engine not found分析

将/tmp目录权限修改为777,重启mysql和cloudera-scm-server服务

46050
来自专栏乐沙弥的世界

Oracle 闪回特性(Flashback Version、Flashback Transaction)

--==========================================================

8620

扫码关注云+社区

领取腾讯云代金券