20080116
非归档模式下，冷备份直接将备份的文件restore就可以，归档模式下需要把该丢失的表空间设为offline drop,然后restore以后再设为online,其中alter system switch logfile是切换日志文件，但是既然alter system archive log current就可以了可以回复单个tablespace,单个datafile或者整个。
说明：
1、不完全恢复最好备份所有的数据，冷备份亦可，因为恢复过程是从备份点往后恢复的，如果因为其中一个数据文件的时间戳(SCN)大于要恢复的时间点，那么恢复都是不可能成功的。
2、不完全恢复有三种方式，过程都一样，仅仅是recover命令有所不一样，这里用基于时间的恢复作为示例。recover database until time '某个时间'
3、不完全恢复之后，都必须用resetlogs的方式打开数据库，建议马上再做一次全备份，因为resetlogs之后再用以前的备份恢复是很难了。
4、以上是在删除之前获得时间，但是实际应用中，很难知道删除之前的实际时间，但可以采用大致时间即可，或可以采用分析日志文件(logmnr)，取得精确的需要恢复的时间。
5、一般都是在测试机后备用机器上采用这种不完全恢复，恢复之后导出/导入被误删的表回生产系统
基于RMAN的回复获得SCN 删除测试表，在删除之前，便于测试，继续插入数据并应用到归档，并获取删除前的scn号
SQL> select max(ktuxescnw * power(2, 32) + ktuxescnb) scn from x$ktuxe;
开始恢复到改变点SCN 31014
RMAN> run{
2> allocate channel c1 type disk;
3> restore database;
4> recover database until scn 31014;
5> sql 'ALTER DATABASE OPEN RESETLOGS';
6> release channel c1;
7> }
说明：
1、RMAN也可以实现不完全恢复，方法比OS备份恢复的方法更简单可靠
2、RMAN可以基于时间，基于改变与基于日志序列的不完全恢复，基于日志序列的恢复可以指定恢复到哪个日志序列，如
run {
allocate channel ch1 type disk;
allocate channel ch2 type 'sbt_tape';
set until logseq 1234 thread 1;
restore controlfile to '$ORACLE_HOME/dbs/cf1.f' ;
replicate controlfile from '$ORACLE_HOME/dbs/cf1.f';
alter database mount;
restore database; recover database; s
ql "ALTER DATABASE OPEN RESETLOGS";
}
3、与所有的不完全恢复一样，必须在mount下，restore所有备份数据文件，需要resetlogs
4、基于改变的恢复比基于时间的恢复更可靠，但是可能也更复杂，需要知道需要恢复到哪一个改变号(SCN)，在正常生产中，获取SCN的办法其实也有很多，如查询数据库字典表(V$archived_log or v$log_history)，或分析归档与联机日志(logmnr)等。
今天做了两个不同的实验，首先我建立了一张test1的表，插入2行数据，然后直接在OS下cp出来，然后shutdown了以后，删除原有的那个atu表空间，启动了以后startup了就发现缺少文件，但是restore做了一下就是把cp出来的东西在cp回去，发觉还是启动不了，应该是做的冷备份，没有做其他任何动作，没有recover修复，所以不明白，最后索性做了次全恢复。这点不明白了，难道是我开了归档模式的缘故？但是归档模式下也不应该会这样啊。第二次做了一个回复，同上的步骤，提示无法找到该表空间的时候，找到他的file#，然后做一次alter database datafile .. offline drop;继续alter database open;这个以后数据库就能起来但是没有atu这个表空间，于是乎在cp回来，修复下recover datafile..;然后alter database datafile .. online；(..表示的是改datafile的号码)，然后做下select是和cp出去的时候是一样的。其实很奇怪，为什么这么说呢，因为有归档日志的缘故，所以你做回复后肯定是你在commit的时候是一样的。
评论