归档模式下四种完全恢复的场景

在数据的备份恢复中，基本都在使用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/TESTSQL> ！cp /u02/ora11g/oradata/hot_bak/undo* /u02/ora11g/oradata/TESTSQL> 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" 我们简单检查一下就会发现对应的表空间是DATASQL> 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更多Oracle相关信息见Oracle 专题页面 http://www.linuxidc.com/topicnews.aspx？tid=12本文永久更新链接地址