归档模式下四种完全恢复的场景(r6笔记第8天)

时间:2022-05-04
本文章向大家介绍归档模式下四种完全恢复的场景(r6笔记第8天),主要内容包括其使用实例、应用技巧、基本知识点总结和需要注意事项,具有一定的参考价值,需要的朋友可以参考一下。

在数据的备份恢复中,基本都在使用rman来做了,但是从数据库的内部原理来说,对于介质恢复,其实还是做两件事,restore和recover. restore是一个类似物理文件的复制,而recover则在数据库后台根据scn做相关的数据恢复。 在归档模式下,一般有下面四种场景可以做完全恢复,当然前提还是在有备份的情况下。 我们可以不依赖rman来手工完成备份恢复的这些过程。因为手工的过程其实也不复杂。 手工备份恢复,那么备份就是热备了。如果连归档没开,就会报出下面的错误。

SQL>  alter tablespace data begin backup;
alter tablespace data begin  backup
*
ERROR at line 1:
ORA-01123: cannot start online backup; media  recovery not  enabled

启用归档胡,我们可以使用动态sql来生成热备的语句,我们过滤了temp表空间,因为是不需要的。

select 'alter  tablespace '||tablespace_name||' begin backup;' from dba_tablespaces where  logging='LOGGING'
alter tablespace SYSTEM begin backup;
alter tablespace  SYSAUX begin backup;
alter tablespace UNDOTBS begin backup;
alter  tablespace DATA begin backup;
alter tablespace TESTDATA begin  backup;

然后拷贝物理文件到一个指定目录。 最后使用end backup来完成热备。这个过程比较常规,也比较简单。 有了备份,我们来看看四种完全恢复的场景。我们都可以手工破坏。 第一种是数据open状态,普通数据文件损坏的情况。 假定test用户下的表test是存储在表空间data上的。

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

我们手工破坏一下。 SQL> !rm /u02/ora11g/oradata/TEST/data02.dbf 然后做一个全局检查点,这个时候原来可访问的表就报错了。

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

我们可以尝试offline表空间,但是因为数据文件丢失,所以offline失败

SQL> alter tablespace data  offline;
alter tablespace data offline
*
ERROR at line 1:
ORA-01191:  file 4 is already offline - cannot do a normal offline
ORA-01110: data file  4: '/u02/ora11g/oradata/TEST/data02.dbf'

需要使用offline immediate,不会去写入检查点。

SQL> alter tablespace data offline  immediate;
Tablespace altered.

这个时候我们可以从热备份中找到对应的文件走还原。 SQL> !cp /u02/ora11g/oradata/hot_bak/data02.dbf /u02/ora11g/oradata/TEST

然后就是恢复。 SQL> recover tablespace data; Media recovery complete. 恢复完成之后把表空间置为online SQL> alter tablespace data online;

Tablespace altered.

这个时候表又可以访问了。

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

第二种场景时在数据库关闭的状态下,系统文件,undo表空间之类的文件损坏。 我们删除几个系统数据文件。 [ora11g@oel1 TEST]$ rm system01.dbf [ora11g@oel1 TEST]$ rm sysaux01.dbf [ora11g@oel1 TEST]$ rm undotbs01.dbf 然后启库的时候肯定会报错。

SQL> startup
ORACLE instance  started.
Total System Global Area  209235968 bytes
Fixed Size                   1335528 bytes
Variable Size             125832984 bytes
Database  Buffers           75497472 bytes
Redo Buffers                6569984  bytes
Database mounted.
ORA-01157: cannot identify/lock data file 1 - see  DBWR trace file
ORA-01110: data file 1:  '/u02/ora11g/oradata/TEST/system01.dbf'

这个时候问题也很明显,简单检查一下就会发现系统数据文件不存在。 这个时候直接从热备处拷贝系统文件 SQL> !cp /u02/ora11g/oradata/hot_bak/system01.dbf /u02/ora11g/oradata/TEST 然后直接恢复数据文件即可。 SQL> recover datafile 1; Media recovery complete. 完成之后可以尝试启库,会发现另外几个数据文件丢失,方法也是类似的,还原,恢复。

SQL> !cp /u02/ora11g/oradata/hot_bak/sysaux01.dbf   /u02/ora11g/oradata/TEST
SQL> !cp /u02/ora11g/oradata/hot_bak/undo* /u02/ora11g/oradata/TEST
SQL> recover datafile 2;
Media recovery complete.
SQL> recover  datafile 3;
Media recovery complete.
SQL> alter database open;
Database  altered.

第三种场景是在停库的时候,删除了普通数据文件。这个时候操作还是存在一定的差别。 我们还是手工破坏 [ora11g@oel1 TEST]$ rm data02.dbf 然后启库的时候肯定会报错。

SQL> startup
ORACLE instance started.
Total System Global Area  209235968 bytes
Fixed Size                   1335528 bytes
Variable Size             125832984 bytes
Database  Buffers           75497472 bytes
Redo Buffers                6569984  bytes
Database mounted.
ORA-01157: cannot identify/lock data file 4 - see  DBWR trace file
ORA-01110: data file 4: '/u02/ora11g/oradata/TEST/data02.dbf'

我们简单检查一下就会发现对应的表空间是DATA

SQL> select name from v$tablespace where ts# in (select ts# from  v$datafile where file#=4);
NAME
------------------------------
DATA
这个时候因为数据库在mount阶段,还做不了offline的操作,直接可以还原数据文件,做数据恢复。
SQL>  !cp /u02/ora11g/oradata/hot_bak/data02.dbf /u02/ora11g/oradata/TEST
SQL>  recover tablespace data;
Media recovery complete.
SQL> alter database open;
Database  altered.

第四种场景是数据库open阶段,新增的数据文件损坏 这个时候我们可以简单模拟一下,创建1个数据文件。

SQL> create tablespace testdat datafile '/u02/ora11g/oradata/TEST/testdata.dbf' size 5M;

Tablespace created. SQL> conn test/test Connected. SQL> create table testdat tablespace testdat as select *from all_objects;

Table created. 然后我们立马删除这个数据文件,这个时候数据文件不在备份集中,是无法做还原的。 SQL> !rm /u02/ora11g/oradata/TEST/testdata.dbf

我们刷新buffer cache,然后这个表就瞬间不能访问了。

SQL> conn / as  sysdba
Connected.
SQL> alter system flush buffer_cache;
System altered.
SQL> select count(*)from test.testdat
                          *
ERROR at line 1:
ORA-01116: error in opening database file  5
ORA-01110: data file 5:  '/u02/ora11g/oradata/TEST/testdata.dbf'
ORA-27041: unable to open  file
Linux Error: 2: No such file or directory
Additional information:  3

这个时候没有备份,我们直接尝试恢复是不行的。

SQL> recover datafile 5;
ORA-00283:  recovery session canceled due to errors
ORA-01124: cannot recover data file 5  - file is in use or recovery
ORA-01110: data file 5:  '/u02/ora11g/oradata/TEST/testdata.dbf'

我们首先需要把对应的表空间给offline SQL> alter tablespace testdat offline immediate;

Tablespace altered.

然后尝试创建一个空的数据文件来恢复 SQL> alter database create datafile '/u02/ora11g/oradata/TEST/testdata.dbf';

Database altered.

恢复数据文件

SQL> recover datafile 5;
Media recovery  complete.

SQL> alter tablespace testdat online;
Tablespace altered.

这个时候恢复完成之后,表又可以访问了。

SQL> select count(*)from test.testdat;
  COUNT(*)
----------
      5877