闪回flashback#ocp试验#

formatuu

　　闪回是oracle恢复革命性的功能，相对于不完全恢复，它有着快速简单的特点，缺点是仅可以处理逻辑，对于像数据文件删除等物理错误不可处理（表空间删除之后controlfile里面对表空间的记录也消失，因此不能闪回）。闪回flashback的反义词是恢复recover。
Flashback Database 功能非常类似与RMAN的不完全恢复， 它可以把整个数据库回退到过去的某个时点的状态， 这个功能依赖于Flashback log 日志。 比RMAN更快速和高效。 因此Flashback Database 可以看作是不完全恢复的替代技术。 但它也有某些限制：

1. Flashback Database 不能解决Media Failure， 这种错误RMAN恢复仍是唯一选择
2. 如果删除了数据文件或者利用Shrink技术缩小数据文件大小，这时不能用Flashback Database技术回退到改变之前的状态，这时候就必须先利用RMAN把删除之前或者缩小之前的文件备份restore 出来， 然后利用Flashback Database 执行剩下的Flashback Datbase。
3. 如果控制文件是从备份中恢复出来的，或者是重建的控制文件，也不能使用Flashback Database。
    否则有报错“ORA-38727: FLASHBACK DATABASE 需要当前的控制文件。”
4. 使用Flashback Database锁能恢复到的最早的SCN， 取决与Flashback Log中记录的最早SCN。  
Flashback Database 架构  
Flashback Database 整个架构包括一个进程Recover Writer(RVWR)后台进程，Flashback Database Log日志 和Flash Recovery Area。一旦数据库启用了Flashback Database， 则RVWR进程会启动，该进程会向Flash Recovery Area中写入Flashback Database Log， 这些日志包括的是数据块的 " 前镜像(before image)"， 这也是Flashback Database 技术不完全恢复块的原因。
　　应用的前提条件
　　a，归档模式
　　b，flashback_on启动
　　SYS@jsce>select flashback_on from v$database;
　　FLASHBACK_ON
------------------
NO

　　show parameter retention--1440分，即一天
　　用户对表数据的修改操作，都记录在撤销表空间中，这为表的闪回提供了数据恢复的基础。例如，某个修改操作在提交后被记录在撤销表空间中，保留时间为900秒，用户可以在这900秒的时间内对表进行闪回操作，从而将表中的数据恢复到修改之前的状态。
　　问：如果这900s内没有操作其他的，是不是可以更长？

　　v$flashback_database_log可以看闪回多久

　　一、闪回数据库
　　查询当前的scn
　　SYS@ncbeta>select current_scn from v$database;
CURRENT_SCN
-----------
    3625299
　　删除scott下的emp表 --ddl语句本身就 隐含了commit，drop table 不需要commit

　　闪回数据库，找回emp
　　报错，需要mount下（基本所有的数据恢复都需要mount下）

　　SYS@ncbeta>flashback database to scn 3625299;open之后需要resetlogs
　　闪回到时间：
　　 Flashback database to timestamp to_timestamp('12-01-13 15:26:34','yy-mm-dd hh24:mi:ss');

　　scoot的emp恢复

　　补充：scn和time的转换可以如下操作：
　　SYS@ncbeta>Select to_char(scn_to_timestamp(3625299),'YYYY-MM-DD HH24:MI:SS') from dual;
TO_CHAR(SCN_TO_TIME
-------------------
2013-01-21 11:10:54
　　二、闪回表  此操作不需要mount
　　原理：恢复来自undo_tablespace
　　
　　首先要启动表的行移动特性
　　SCOTT@ncbeta>select  ROW_MOVEMENT from user_tables where table_name='EMP';
ROW_MOVE
--------
DISABLED
　　
SCOTT@ncbeta>alter table emp enable row movement;
表已更改。
sys下找到现在数据库的scn： 3632069

　　对emp表进行insert操作--14行变成15行，xs是新加入
　　
　　后来发现错误，闪回表--闪回确实快
　　SCOTT@ncbeta>flashback table emp to scn 3632069;
　　
　　闪回表需要考虑的事情

1.         FLASHBACK TABLE命令作为单一的事务执行，会得到一个单一的DML锁

2.         表的统计数据不会被闪回

3.         当前的索引和从属的对象会被维持

4          系统表不能被闪回

5        不能跨越DDL操作

6        会被写入警告日志

7         产生撤销和重做的数据

　　比如2统计数据，user_tables 有一个NUM_ROWS字段，在insert表之后，统计的和总数对应不上
　　
　　
　　使用analyze分析之后，可以解决这个问题
　　SCOTT@ncbeta>analyze table emp compute statistics;

　　对于删除表，可以使用to before drop来闪回
　　SCOTT@ncbeta>flashback table emp to before drop;

　　在闪回模式打开之后，删除的操作在闪回区都有放映 --需要回滚段满了之后才会更新

　　删除的表在回车站，被改名，如果要彻底删除可以使用drop table xx purge

　　三、闪回版本查询（查询变化）
　　
　　闪回查询只能查看到特定时间点的表中的数据，但不能完整地查看到在两个时间点之间表中数据的变化情况。而闪回版本查询就提供了这样的功能，它提供来一个审计各个行的数据改变的功能，它能找到所有已经提交了的操作及其操作时间、结果。所以闪回版本查询在某种程度上可以替代精细审计功能和LogMiner工具的功能。
　　只要是在撤销段中现有的数据都可以被用于闪回版本查询。因此，最大可用的版本依赖于undo_retention初始化参数的设置。由于该参数不是强制性的，所以如果想保证在该参数所设置的时间内不会覆盖撤销段中已经提交的数据，就需要给撤销表空间设置RETENTION GUARANTEE选项。
　　
　　可以查询一段时间内字段的变化，比如应用于股票
　　首先在scott下面查询当前scn
　　SCOTT@ncbeta>select timestamp_to_scn(SYSTIMESTAMP) as scn from dual;
       SCN
----------
   3634862
　　这个时候
　　EMPNO ENAME             SAL
------ ---------- ----------
    22 xs               8000
　　之后update




select sal,
versions_starttime,
versions_endtime,
versions_xid,
versions_operation
from emp versions between scn  3636070  and     3636113
where empno = '22';

　　测试时出现“ORA-30052: 下限快照表达式无效”错误，原因是指定的时间范围不在 UNDO_RETENTION 的撤销范围内（比如说你指定了是2小时之前的时间，
　　而 UNDO_RETENTION < 7200）。
　　备注：关于undo_retention和retention guarantee
　　undo_retention参数的作用是用来控制当transaction被commit后，undo信息的保留时间。这些undo信息可以用来构造consistent read以及用于一系列的闪回恢复，而且足够的undo信息还可以减少经典的ORA-01555 Snapshot too old（快照太旧，长时间查询过程中还未过期的撤销数据已被覆盖造成）。这个参数的默认值为900（秒），这是一个noguarantee的限制，也就是说我将undo_retention=900,原本以为在一个事务提交后，之前的撤销数据还可以保存900秒才可以被别的事务覆盖，殊不知当有其他的事务处理过程中需要undo空间的时候，恰恰这个时候undo表空间没有足够的空间了，而且我们没有开启自动扩展，且由于我们的retention是noguarantee的，所以事务就会忽略这种retention的时间限制而直接覆盖我们的undo信息，这种结果下其实在很多情况下是不希望看到的。Oracle 10g后新增了一个参数guarantee，可以强制oracle来保护undo信息，也就是说即使新的事务需要undo空间的时候，即使undo的空间不足，这个session也不会强制覆盖由undo_retention所保护的undo信息，而且这个新增事务会因为undo空间的不足而报一个错而推出。




10g 中RETENTION GUARANTEE 的作用 :
1、先解释下undo_retention
设置undo_retention，保证commit 后的数据在undo
segment中保留多长时间。但是并不能保证commit后的undo 信息在undo_retention的时间内一定不被覆写，当undo
segment不够时，还是会覆盖已commit的undo 信息。

2、如果需要保证在undo_retention时间内undo 信息一定不被覆写的话，可以对undo segment设置RETENTION
GUARANTEE。但是这个参数受到undo_retention和undo size的限制。如果undo size
太小，undo_retention设置太久，设置retention guarantee 时就会报错：

ORA-30036: unable to extend segment by 8 in undo tablespace
'UNDOTBS2'

3、设置该参数
  alter tablespace undotbs2 retention
guarantee;
    撤销该参数
  alter tablespace undotbs2
retention noguarantee;





2013-01-22 14:50:45更新：

update操作之后需要commit，写入redo log，系统才能识别

　　select sal,ename, versions_xid
from emp versions between scn minvalue and maxvalue
where empno = '22';



四、闪回事务查询

闪回事务查询其实是闪回版本查询的扩充或继续。它提供了一种查看事务级数据库变化的方法。通常需要首先借助闪回版本查询查出其事务版本号，然后再进行闪回事务的查询。

flashback_transaction_query
　　select sal,ename, versions_xid
from emp versions between scn minvalue and maxvalue
where empno = '22';

　　发现更新错误，通过xid查询sql及undo sql
　　select xid, start_scn, to_char(start_timestamp, 'yyyy-mm-dd hh24:mi:ss') starttime, undo_sql
from flashback_transaction_query where xid='06000200F2060000' and table_name='EMP';

　　undo_sql: update "SCOTT"."EMP" set "SAL" = '5600' where ROWID = 'AAAR3sAAEAAAACTAAB';--变为原来的5600