三种情况都是不完全恢复采用的方式，而不完全恢复都是在完全恢复的过程中出现了这样那样的错误，数不胜数，基本就是归档，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还是做了很多的工作来保证了数据恢复成为可能。
