即使误drop表(未使用purge参数)也不会影响长时间未完成的select语句结果!
是不是很神奇,本文通过实际操作展示给出这个现象背后的小秘密。
这个现象的背后秘密就是:回收站。在回收站功能开启的情况下,长时间运行的select语句伊然可以通过读取回收站中的数据完成数据的检索。
1.创建实验表T,并在其中初始化大量数据
sec@ora10g> create table t as select * from all_objects;
Table created.
sec@ora10g> insert into t select * from t;
24560 rows created.
sec@ora10g> /
49120 rows created.
sec@ora10g> /
98240 rows created.
sec@ora10g> /
196480 rows created.
sec@ora10g> /
392960 rows created.
sec@ora10g> /
785920 rows created.
sec@ora10g> commit;
Commit complete.
sec@ora10g> select count(*) from t;
COUNT(*)
----------
1571840
2.在个session中进行select操作
sec@ora10g> select * from t;
……此处省略大量不断的输出数据……
3.在全新开启另外一个session完成下述动作
1)drop表T
sec@ora10g> drop table t;
Table dropped.
2)使用v$session_longops查看当前执行的message信息
sec@ora10g> select sid,serial#,message,time_remaining
2 from v$session_longops
3 where time_remaining > 0
4 /
Time
SID SERIAL# MESSAGE Remaining
------- ------- ------------------------------------------------------------------------------- ---------
1848 15232 Table Scan: SEC.BIN$hFitti/9oEbgQAB/AQAgDw==$0: 6268 out of 22351 Blocks done 151
可见,读取的就是回收站中的数据。
sec@ora10g> select * from tab;
TNAME TABTYPE CLUSTERID
------------------------------ ------- ----------
BIN$hFitti/9oEbgQAB/AQAgDw==$0 TABLE
sec@ora10g> select OBJECT_NAME,ORIGINAL_NAME,TYPE,OPERATION,DROPTIME from USER_RECYCLEBIN order by DROPTIME,ORIGINAL_NAME;
OBJECT_NAME ORIGINAL_NAME TYPE OPERATION DROPTIME
------------------------------ -------------- ------ --------- -------------------
BIN$hFitti/9oEbgQAB/AQAgDw==$0 T TABLE DROP 2010-04-16:10:00:18
4.当个session执行完之后再重复执行select语句将会报错。
sec@ora10g> select * from t;
select * from t
*
ERROR at line 1:
ORA-00942: table or view does not exist
5.小结
这里是回收站帮上了忙,不过更值得思考的是在实行“危险性动作”之前一定要三思而后行。
Good luck.
secooler
10.04.26
-- The End --
【RECYCLEBIN】误drop 表后长时间运行的select查询仍可完成数据检索现象的探秘
分享好友
分享这个小栈给你的朋友们,一起进步吧。
订阅须知
• 所有用户可根据关注领域订阅专区或所有专区
• 付费订阅:虚拟交易,一经交易不退款;若特殊情况,可3日内客服咨询
• 专区发布评论属默认订阅所评论专区(除付费小栈外)