[原]记一次使用flashback恢复数据，警惕自己不要浮躁，还是太嫩了
周五晚十点多，同事突然来电称操作CMS后台的时候不小心删除了很多记录（其实应该是这个CMS的逻辑问题），大概了解了情况以后，能初步判断为p_web表的2万多条数据被delete了，事发时间大概在9:30左右，这种场景几乎就是“专门”为flashback而设的了。
于是马上翻开书找到flashback那节书，先鄙视一下自己，以前所学的都还给书本了。
确认一下可以flashback的极限是多少
select
min(start_timestamp)
from
flashback_transaction_query
where
table_name='P_WEB'
and table_owner='CMS'
结果是前天的下午3点，比预期中的时间要长很多啊。
由于p_web表数据量不大，还不到100M，赶紧做个“备份”，免得突然犯浑把剩下的2万多条记录都整丢了，那就可以跳楼了：
create table p_web_bad as select * from p_web;
使用flashback query将9:20的数据放在一个p_web_20100507_0920表里面，让同事看看效果先：
create table p_web_20100507_0920
as
select
*
from
p_web
as of timestamp to_date('2010-05-07 21:20:00','yyyy-mm-dd hh24:mi:ss');
其实我也是笨，脱离了表现层的数据能看出什么呢？除了“感觉”上是正确的一点说服力也没有。
同事说这个数据没问题。为了进一步确定事发的准确时间点，使用flashback transaction query 将自8:30以来的所有undo操作列出，这样可以找出什么时候开始删除的了。
create table p_web_undo_20100507_2030
as
select
start_timestamp,operation,undo_sql
from
flashback_transaction_query
where
table_name='P_WEB'
and table_owner='CMS'
and start_timestamp>to_date('2010-05-07 20:30:00','yyyy-mm-dd hh24:mi:ss')
order by
start_timestamp desc
经过一个简单的查询从start_timestamp 能查出是21:39:04开始删除的，只要将flashback到21:38:00问题就OK了啦。
flashback table p_web
to timestamp to_date('2010-05-07 21:38:00','yyyy-mm-dd hh24:mi:ss');
此时，报了一个错：
ORA-08189: cannot flashback the table because row movement is not enabled
小问题，enable row movement 就是了
alter table p_web enable row movement;
我再闪（flashback）：
flashback table p_web
to timestamp to_date('2010-05-07 21:38:00','yyyy-mm-dd hh24:mi:ss');
shit！竟然出现了flashback的克星：
ora-01555 snapshot too old
明明前面查到可以flashback的时间很长的啊，莫非是前面几个大create table把undo内容刷走了，这也太快了吧@_@！
先不管了，我同事还在着急的等待，虽然没有催我，但是“弄丢”数据的心情我很清楚。
幸好前面创建了一个p_web_undo_20100507_2030表，里面有一对undo的sql，可以将被delete的数据再insert回去。
于是写了个简单的过程做这件事：
declare
v_undo_sql varchar2(4000);
CURSOR cur is select substr(undo_sql,1,length(undo_sql)-1) --将undo_sql最后那个分号去掉
from p_web_undo_20100507_2030 where operation='DELETE';
BEGIN
open cur;
loop
fetch cur into v_undo_sql;
EXIT when cur%NOTFOUND;
execute immediate v_undo_sql;
--dbms_output.put_line(v_undo_sql);
END LOOP;
CLOSE cur;
END delete_state ;
经过“漫长”的等待，终于将误删的数据恢复回来了。
经过这次数据恢复让我认识到：
1。虽然掌握了基本概念，但是熟练程度还不够，体现在临急翻书上。
2。实际操作经验欠缺，整个过程实际上没多少东西，但是却足足折腾了一个半小时。
3。前瞻性不足，这个数据库是我维护的，对于误操作删除数据这种问题应该要有所觉悟，就这个问题而言，我做的措施仅仅是扩大了undo表空间。
总的来说，就是太嫩了。