Oracle闪回原理测试（三）(r12笔记第16天)

对于Oracle的闪回，很多朋友也问过问，到底是怎么玩的？如果自己做过一些闪回数据库的操作，就会发现这个功能非常强悍。

Flashback DML的操作其实还蛮容易理解的，但是Flashback DDDL那可就是另外一个level了，我们大概了解一下MySQL里面的闪回就会发现，真要实现无缝的全闪回，确实有很多的细节和场景需要考虑。而Oracle作为一个成熟的商业软件，是不希望我们了解很多底层的细节的，用着好就行，所以如果你想得到一些闪回更细节的东西，这个渠道就非常的窄，我们之前也测试了两期，做了一些简单的对比，这一期就做一些基本的突破，对闪回原理做出进一步的解读。

这个尝试来源于今天的一个维护更新，今天早间的时候，会按照季度的业务要求DBA做一个统一的批量查询，得到一些数据供审计和策划的同学分析，提前给出一些解决方案，这个事情是大概一周前提的了，而悲剧的是今天到了公司才想起了有这么一回事。而这个时候数据已经被当日的数据更新了，想要得到早间指定时间段的数据就尤为关键，当然我还算是胸有成竹，因为这个备库我开了闪回。所以我可以很快闪回到指定的近期任意时间点，也算是闪回化解了这样一次尴尬的境地。

当然我在处理问题的时候，还不忘看看闪回的原理，记录日志，其实主要是我对闪回特性的充分自信，要不手心里早都冒汗了。

首先确认数据库角色和状态之后，我关闭数据库，准备从mount状态闪回，避免重启数据库。

下面的错误值得注意，在close这个操作时，还是需要保证数据库的日志应用是终止的，即MRP为停止状态。

SQL> alter database close; alter database close * ERROR at line 1: ORA-10457: cannot close standby database due to active media recovery

我们选择快捷的命令方式，直接关闭日志应用，然后关闭数据库。

SQL> recover managed standby database cancel; Media recovery complete. SQL> alter database close; Database altered.

这个操作完成之后，扫了一眼redo和控制文件，已经更新了时间，闪回工作迫在眉睫。我把数据库闪回到了几个小时之前的一个时间点。

SQL> flashback database to timestamp to_timestamp('2017-03-27 07:20:00','yyyy-mm-dd hh24:mi:ss'); Flashback complete.

这个过程持续时间很短，所有数据文件的时间戳都更新到了当前的时间点，而其实数据已经闪回到了几个小时之前。

当然下面的一段日志吸引了我。

Mon Mar 27 10:19:24 2017 flashback database to timestamp to_timestamp('2017-03-27 07:20:00','yyyy-mm-dd hh24:mi:ss') Flashback Restore Start Flashback Restore Complete Flashback Media Recovery Start started logmerger process Parallel Media Recovery started with 24 slaves Flashback Media Recovery Log /U01/app/oracle/fast_recovery_area/SGCDB2/archivelog/2017_03_27/o1_mf_1_10600_dfjjm98t_.arc Flashback Media Recovery Log /U01/app/oracle/fast_recovery_area/SGCDB2/archivelog/2017_03_27/o1_mf_1_10601_dfjonfly_.arc Mon Mar 27 10:19:43 2017 Incomplete Recovery applied until change 234220253426 time 03/27/2017 07:20:01 Mon Mar 27 10:19:43 2017 Flashback Media Recovery Complete Completed: flashback database to timestamp to_timestamp('2017-03-27 07:20:00','yyyy-mm-dd hh24:mi:ss')

上面的几处红字需要格外注意，里面出现了归档日志文件，这个就需要再提一下。我们可以通过日志看出，整个闪回的工作其实分为两大部分，restore和recover，这个和正常恢复数据如出一辙。但是差别也很明显，因为闪回日志是记录的数据变化的逆操作，所以从10:30闪回到7:20,那么这个过程就是10:30-> 7:20左右。

注意我提到的这个7:20是左右，当然要偏左一些，偏右证明数据还太新了。Restore的这个过程会应用到闪回日志。其实在Oracle中存在一个概念叫做Flashback barrier interval,默认是是30分钟会往闪回日志里写入SCN的标示纪录。所以10:30->7:20的操作你也可以理解为大体是按照10:30->10:00->9:30->9:00->8:30->8:00->7:30->7:00这样的过程。

完成了基本的还原之后，我们要到达指定时间点的状态，这就需要使用归档文件或者重做日志了，这里的重点就是Flashback Recover的过程了。我们可以通过上面的日志看到，其实应用了两个日志文件，序列号为10600和10601，这个过程该如何更好的验证呢。可以通过如下的SQL来做一个基本的分析，当然这个语句还不够严谨。主要思路就是根据v$archived_log来确定一个边界范围。

set linesize 150 pagesize 100 with maxlogchg as (select max(first_change#) c1 from v$archived_log where first_change#<=234220253426) select name,sequence#,first_change#,next_change# from v$archived_log,maxlogchg where first_change#>=maxlogchg.c1 and first_change#<=234220253426;

整个数据闪回之后，我们就穿越到了之前的一个时间点，可以做我们需要的操作了。

整个查询的过程持续时间很短，但是得到的这个数据就尤为重要了。根据业务运行一些查询脚本，此处省略查询的SQL语句。

完成之后，我们只需要alter database close,然后正常open就会更新到最新的一个时间点的数据状态。

SQL>alter database close; SQL>alter database open SQL> recover managed standby database disconnect from session; Media recovery complete. 这个过程的日志其实省略了一些东西，我想也是为了避免给用户带来困扰，因为在日志里反反复复recover,可能会让用户有些疑惑，而我们也可以通过另外一个隐含参数（_flashback_verbose_info）来得到更加详细的日志信息。

默认得到的正常日志如下：

Mon Mar 27 10:40:06 2017 ALTER DATABASE RECOVER managed standby database disconnect from session Attempt to start background Managed Standby Recovery process (gcdb) Mon Mar 27 10:40:06 2017 MRP0 started with pid=28, OS id=139822 MRP0: Background Managed Standby Recovery process started (gcdb) started logmerger process Mon Mar 27 10:40:11 2017 Managed Standby Recovery not using Real Time Apply Parallel Media Recovery started with 24 slaves Waiting for all non-current ORLs to be archived... All non-current ORLs have been archived. Media Recovery Delayed for 180 minute(s) (thread 1 sequence 10601) Completed: ALTER DATABASE RECOVER managed standby database disconnect from session

通过如上的日志，你看不到很多潜在的recover操作。而整个过程而言却又是必须的。

通过这个过程我们可以大体看出，整个闪回的过程不是孤立，完全依赖于闪回日志，而同时也是一个Flashback Restore和Flashback Recover的过程。