备份、备份、备份啊亲......呜呜呜！！！

--Oracle闪存
--第一步、找到对表操作的具体时间
select r.FIRST_LOAD_TIME,r.* from v$sqlarea r order by r.FIRST_LOAD_TIME desc ;
--第二步根据上面找出的时间作为条件、创建一张新表、表结构为你操作的那张表将闪存数据闪回
create table t_table_recove --新表
as
select * from t_table --你操作的那张表
as of timestamp to_timestamp('2012-12-05/09:35:54','yyyy-mm-dd hh24:mi:ss');



--如过你记得具体是几分钟前操作的可以创建一张临时表
create table t_table_recove --临时表
as  select * from t_table --你操作的那张表
where 1=0;
--将查询数据插入临时表
insert into t_table_recove select * from t_sys_client  as of timestamp sysdate-10/1440;    --10分钟之前的数据  

闪存也不是万能的、它有大小限制、空间满了会对以前的闪存进行覆盖。如果在操作频繁的平台上、早上的闪存数据、下午就找不回来了！
我就是这样一个活生生的案例！
今天早上接到一个要修改某张表中某个字段的工单！
于是哥就稀里糊涂的更新了！

update TABLE1 o set (o.字段,o.字段,o.字段,
o.字段,o.字段,o.字段,o.字段,o.字段
) =(select t.字段,t.字段,t.字段,t.字段,t.字段,t.字段,t.字段,t.字段
from TABLE2 t where t.字段 = o.字段);

TABLE2中的数据跟TABLE1中的数据并不是完全匹配的！
TABLE1中有的数据、TABLE2中不一定有、而且还是有1千多条没有！
这样的后果就造成了、语句执行完毕后、TABLE1中的一些(在TABLE2中没有对应的1千多条数据)记录、要更新的那几个字段全部为空了！
当时没有备份、匆匆的从TABLE2中提取了一条数据作为条件在TABLE1查询完毕后、看了一下那一条数据没有问题、就这样不管了！
后来下午在查询TABLE1的时候、突然发现了有些以前有的字段信息为空了、就去数据库看看肿么回事、一看就吓哥哥一跳啊！
闪存是闪不回来了、因为数据已经被覆盖了。
他妹的、没备份的亏哥哥不是第一次吃了！
肿么就不记事呢、只有得明天找DBA给看看了、o(︶︿︶)o 唉！
不晓得备份的程序员不是好程序员！修改完毕不即时全面测试的程序员更不是好的程序员！
奶奶的、上次没备份是删除的Weblogic工程里面用户上传的文件跟图片！

这次是数据库、完了完了......