MSSQL网站制作之9i新特征之Flashback Query的使用-----...

仓酷云

为了在某种程序上弥补这一缺陷，许多SQL命令都有一个DELAY_KEY_WRITE项。这个选项的作用是暂时制止MySQL在该命令每插入一条新记录和每修改一条现有之后立刻对索引进行刷新，对索引的刷新将等到全部记录插入/修改完毕之后再进行。恢复
用DBMS_FlashBACK包



DBMS_FLASHBACK包供应了以下几个函数：



ENABLE_AT_TIME：设置以后SESSION的闪回查询工夫

ENABLE_AT_SYSTEM_CHANGE_NUMBER：设置以后SESSION的闪回查询SCN

GET_SYSTEM_CHANGE_NUMBER：获得以后数据库的SCN

DISABLE：封闭以后SESSION的闪回查询



如：

SQL>selectdbms_flashback.get_system_change_numberfromdual;



GET_SYSTEM_CHANGE_NUMBER

------------------------

8053651

当将一个SESSION设置为闪回查询形式以后，后续的查询城市基于谁人工夫点大概SCN的数据库形态，假如SESSION停止，那末即便没有明白指定DISABLE，闪回查询也会主动生效。在SESSION运转在闪回查询形态时，是不同意举行任何DML和DDL操纵。假如要用DML操纵来举行数据恢复就必需利用PL/SQL游标（实在，这里也就是给我们供应了一个数据恢复的办法）。即便SESSION运转在闪回查询形式，SYSDATE函数也不会遭到影响，仍旧会前往以后准确的体系工夫。

上面我们用一个例子申明怎样利用DBMS_FLASHBACK包来恢单数据。

假定因为误操纵删除SCOTT.EMP表中的一切数据，如今我们要恢复。

SQL>deletefromemp;

14rowsdeleted.

SQL>commit;

Commitcomplete.

SQL>selectcount(*)fromemp;

COUNT(*)

----------

0

然后实行上面的SQL创立一个存储历程用于恢单数据

CREATEORREPLACEPROCEDUREprc_recoverempIS

CURSORc_empIS

SELECT*FROMscott.emp;

v_rowc_emp%ROWTYPE;

BEGIN

DBMS_FLASHBACK.ENABLE_AT_TIME(SYSTIMESTAMP-INTERVAL1DAY);

OPENc_emp;

DBMS_FLASHBACK.DISABLE;

LOOP

FETCHc_emp

INTOv_row;

EXITWHENc_emp%NOTFOUND;

INSERTINTOscott.emp

VALUES

(v_row.EMPNO,

v_row.ENAME,

v_row.JOB,

v_row.MGR,

v_row.HIREDATE,

v_row.SAL,

v_row.COMM,

v_row.DEPTNO);

ENDLOOP;

CLOSEc_emp;

COMMIT;

ENDprc_recoveremp;

SQL>executeprc_recoveremp;

PL/SQLproceduresuccessfullycompleted.

SQL>selectcount(*)fromemp;

COUNT(*)

----------

14

到此乐成停止，反省EMP表能够看到一切的数据已全体都恢复了。

备注：在存储过程当中我们创立了游标以后就将实行了DBMS_FLASHBACK.DISABLE，只

有如许我们才干在这个SESSION中举行DML操纵。不然将发生ORA-08182毛病，In

Flashbackmode,usercannotperformDMLorDDLoperations。

下面我们已先容了关于怎样的使用FlashbackQuery来恢复DML的误操纵，但都是基于工夫点（timestamp）的，实在呢，只管timestamp能够准确到毫秒，但是因为{oracle每隔5分钟会将发生的SCN对应一个TIME做纪录，也就是说一般只纪录了SCN,可是每5分钟会纪录SCNandTIME}(这段话必要深切的精细精美)，当接纳timestamp来做flashback的时分就有大概发生偏向，5分钟的出处是在于表SYS.SMON_SCN_TIME，我们能够观察一下：

该表的纪录一共是1440行，那来几行能够看看



THREADTIME_MPTIME_DPSCN_WRPSCN_BAS

---------------------------------------------------

110727725272003-12-3008052536

110727728342003-12-3008053330

110727731422003-12-3008054053

110727734462003-12-3008054845

能够看到，每行的timestamp差上5分钟摆布，实践上，每5分钟，SMON删除最旧的数据而且拔出以后的信息，这也就能够推算出为何不管你的UNDORETENTION设置多年夜，FlashbackQuery只能用5天(1440*5/24/60)。以是基于SCN的FlashbackQuery是最正确的

举个例子看看：

SQL>select*fromlyb;



未选定行

SQL>insertintolybvalues(1);



已创立1行。



SQL>commit;



提交完成。



SQL>selectdbms_flashback.get_system_change_numberfromdual;



GET_SYSTEM_CHANGE_NUMBER

------------------------

8058302



SQL>deletefromlyb;



已删除1行。



SQL>commit;



提交完成。



SQL>selectdbms_flashback.get_system_change_numberfromdual;



GET_SYSTEM_CHANGE_NUMBER

------------------------

8058379



SQL>select*fromlybasofscn8058302

2;



ID

----------

1

SQL>select*fromlybasofscn8058379

2;



未选定行

SQL>





以是说，基于scn的恢复才是可以做到准确！

固然，我们很分明碰到的成绩是，假如真实的误操纵，我那边会纪录scn啊？这里就计划到别的的一个oracle很好用的工具，logminer，下次先容！



注：SYS用户不同意实行DBMS_FLASHBACK包，将会发生ORA-08185毛病，

FlashbacknotsupportedforuserSYS



参考：

otn.oracle.com

asktom.oracle.com
Seraphim（张乐奕）的《使用FlashbackQuery恢复误操纵的数据》

对于update操作，event中依次记录旧行，新行的值。

对递归类的树遍历很有帮助。个人感觉这个真是太棒了！阅读清晰，非常有时代感。

对于微软系列的东西除了一遍遍尝试还真没有太好的办法

如果处理少量数据,比如几百条记录的数据,我不知道这两种情况哪个效率更高,如果处理大量数据呢?比如有表中有20万条记录.

分区表效率问题肯定是大家关心的问题。在我的试验中，如果按照分区字段进行的查询（过滤）效率会高于未分区表的相同语句。但是如果按照非分区字段进行查询，效率会低于未分区表的相同语句。

另一个是把SQL语句写到服务器端,就是所谓的SP(存储过程);

我们学到了什么？思考问题的时候从表的角度来思考问