有几天没写了，呵呵！这几天比较忙，赶着做关于一个桌面搜索的软件。做了基于取消的不完全恢复和基于SCN的不完全恢复，一直没写成博客，现在可以补一下了。
先介绍一下：基于SCN 的不完全恢复是指将数据库恢复到某个特定的SCN 点的状态。当用户误执行了 drop table 或truncate table 之后，如果我们知道在这些操作点的SCN 的值，那么就可以使用基于SCN的不完全恢复方法了。
实验步骤如下：
1）先获取数据库当前的SCN值，模拟误删除实验表t1。
SQL> select current_scn from v$database;
CURRENT_SCN
-----------
2598485
SQL> drop table t1;
表已删除。
如上可知，误操作的SCN 的值大概为2598485 所以我们只要将数据库恢复到该SCN值即可。在实际的工作中DBA可以使用Logminer 确定误操作的SCN值。
2）关闭数据库，并加载。在恢复数据库时，要将数据库置于加载状态。
SQL> shutdown immediate
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> startup mount
ORACLE 例程已经启动。
Total System Global Area 535662592 bytes
Fixed Size 1334380 bytes
Variable Size 134218644 bytes
Database Buffers 394264576 bytes
Redo Buffers 5844992 bytes
数据库装载完毕。
3）复制所有数据库文件的备份，为了将数据库恢复到过去的scn点，必须复制所有数据文件备份。
SQL> @f:\sql\recover.sql--------我写的一个关于恢复的脚本。
注意，当复制数据文件备份时，必须确保备份文件的scn值小于要恢复到的scn值。所以使用以下查询，可以确定备份文件的SCN：
SQL> select file#,change# from v$recover_file;
FILE# CHANGE#
---------- ----------
1 2585567
2 2585567
3 2585567
4 2585567
5 2585567
6 2585567
已选择6行。
备份文件的SCN小于要恢复的SCN值。
4)执行不完全恢复。
SQL> recover database until change 2598485
完成介质恢复。
---注释：我做实验的时候，没有手工切换日志文件，所以没有显示：
指定日志: {=suggested | filename | AUTO | CANCEL} 这样的提示。
SQL> select * from t1;
select * from t1
*
第 1 行出现错误:
ORA-01219: 数据库未打开: 仅允许在固定表/视图中查询
5）执行了不完全恢复之后，必须以resetlogs 方式打开数据库，并检查恢复结果。SQL> alter database open resetlogs;
数据库已更改。
SQL> select * from t1;
NUM
----------
1
2
3
4
由此可知恢复成功。
6）当然执行了resetlogs之后，建议进行数据库的全备份。
SQL> archive log list
数据库日志模式 存档模式
自动存档 启用
存档终点 f:\app\yang\archive2
最早的联机日志序列 1
下一个存档日志序列 1
当前日志序列 1
SQL> alter database begin backup;
数据库已更改。
SQL> @f:\sql\hotbak.sql----关于备份的脚本
SQL> alter database end backup;
数据库已更改。
SQL> alter database backup controlfile
2 to 'f:\lib\control.ctl' reuse;
数据库已更改。
SQL> alter system archive log current;------保持一致性。这一步，有时容易忽略
系统已更改。
