前言：之前说过一句话，备份有时候就是用于数据库的恢复，虽然很多时候都用不上。但是你永远不知道什么时候会用上，这就是备份的意义；
昨天晚上10点多的时候，突然朋友打电话过来，要帮忙做一个数据库基于时间点的恢复。
具体的业务场景是这样的：2015年2月7日12：00的时候有一个错误的操作，导致用户的数据被覆盖。但是由于各种原因，到21：00的时候才发现；现在需要恢复一个数据库到2015年2月7日的12：00：00；
整理了一下思路，就开始马上干活，不到一个小时整个数据库就恢复完成了。
因为时间过去了9个小时，所以业务肯定已经做了很多操作，所以不能恢复到目前的数据库上面，而要恢复到另外一台数据库上面（不管什么时候，都不建议直接覆盖恢复到目前的生产库上面）：
一、思考需要的资源
1.1 数据库的全备；
1.2 归档日志的备份；
1.3 另外一台用于恢复的机器（同样的操作系统、同一个版本的数据库、足够的空间）
二、当前可以提供的资源
2.1 该数据库每天5：00有做一个数据库全备；
2.2 目前有个测试系统用于开发的测试使用，符合操作系统、数据库版本、空间的要求；
2.3 由于要恢复到12：00，所以需要进行数据库归档日志的备份；
三、实际的操作如下：
3.1 手工进行归档日志和控制文件的备份
脚本：
| run{ |
3.2 传送参数文件、备份文件到测试
scp initorcl.ora oracle@192.168.0.10:/u01/app/oracle/product/OraDb11g_home1/dbs/ （参数文件测试机，最好是pfile文件）
scp *20150207 oracle@192.168.0.10:/backup/ （数据库全备和归档日志的备份到测试机的/backup这个文件夹）
3.3 按照pfile的内容创建相应的文件夹
mkdir -p /u01/app/oracle/admin/orcl/adump
mkdir -p /u01/app/oracle/oradata/orcl
mkdir -p /u01/app/oracle/fast_recovery_area/orcl
3.4 启动数据库到nomount状态
a、设置系统的环境变量，脚本： export ORACLE_SID=orcl
b、启动数据库到nomount状态，脚本：sqlplus > startup nomount;
3.5 进行控制文件的恢复，（需要指定最后备份的那个控制文件）
run
{
allocate channel ch1 device type disk;
restore controlfile from '/backup/orcl_CONTROL_21879_1_20150207';
release channel ch1;
}
3.6 启动到mount状态，进行数据库的restore;
run
{
allocate channel ch1 device type disk;
allocate channel ch2 device type disk;
alter database mount;
restore database from tag=TAG20150207T040022;
release channel ch1;
release channel ch2;
}
3.7 进行数据库基于时间点的recover;
run{
allocate channel ch1 device type disk;
allocate channel ch2 device type disk;
set until time "to_date('2015-02-07 12:00:01','yyyy-mm-dd hh24:mi:ss')";
recover database;
release channel ch1;
release channel ch2;
}
3.8 以read only的方式打开数据库
SQL> alter database open read only;
说明：一般进行不完全恢复的时候都是以resetlogs的方式打开数据库的，但是我们这里以read only的方式打开，是基于如下考虑的：虽然业务已经提供了要恢复的时间点，但是为了以防万一这个时间点有问题，我们以read only方式打开的时候，万一时间点不对，还可以继续往后进行recover，而且这个数据库也是用来查询的，不会进行数据操作；
3.9 在正式库上面创建一个dblink指向还原的这个数据库，这样便于业务人员可以直接在正式库上面进行有问题表的数据的比对；
总结：
1、以上就是整个恢复的过程，看似很简单，但是也许你并不知道，我每个月都有在做模拟的数据库的恢复，并记录各种场景使用的脚本，台上一分钟，台下很多功；
2、需要跟业务沟通清楚需要恢复的场景，避免做无用功，在做灾难恢复时的场景跟救火的场景很相似的，时间宝贵；
3、一般情景下是不建议任何人员直接连接数据库进行修改，因为太多的这种操作都是直接误操作数据库导致的；
4、还是强调一下数据库备份的重要性，备份总是要有的，万一哪天用到了；
........................................................................................................................................................................
本文作者：JOHN，某上市公司DBA，业余时间专注于数据库的技术管理，从管理的角度去运用技术。
ORACLE技术博客：ORACLE 猎人笔记 数据库技术群：367875324 （请备注ORACLE管理 ）
........................................................................................................................................................................
