flashback drop后表空间不足直接删除回收站中删除表所占空间的演示(二)
_space where tablespace_name='TEST1' group by tablespace_name;
TABLESPACE_NAME FREESPACE
--------------- ----------
TEST1 14 ---表空间空闲空间14M，回到test9插入数据前的状态
SQL>show recyclebin;
ORIGINAL NAME RECYCLEBIN NAME OBJECT TYPE DROP TIME
---------------- ------------------------------ ------------ -------------------
TEST9 BIN$5hvFkoUf4jjgQKjA0wFMJg==$0 TABLE 2013-09-11:21:41:00
SQL> select count(*) from "BIN$4LABIoAgQQ7gQFXeqEBxZg==$0";
COUNT(*)
----------
72553
5.建一个占空间大的新表，发现回收站中删除表test9已经被彻底删除。
SQL> create table test3 tablespace test1 as select * from dba_objects;
Table created
SQL> select * from tab;
TNAME TABTYPE CLUSTERID
------------------------------ ------- ----------
TEST3 TABLE
SQL> select segment_name,segment_type,tablespace_name,extents,bytes/1024 KB from dba_segments where segment_name like 'TEST3%';
SEGMENT_NAME SEGMENT_TYPE TABLESPACE_NAME EXTENTS KB
--------------- ------------------ --------------- ---------- ----------
TEST3 TABLE TEST1 24 9216 ----这里因为创建的表空间是15M，第一次创建的表是9M大小并删除到回收站。此时再创建一个9M的表，原表删除后只是标记为删除，剩余的6M不足以容纳现在创建的TEST3的9M，所以会删除回收站中的BIN$表。
SQL> select tablespace_name,bytes/1024/1024 mb from dba_free_space where tablespace_name='TEST1';
TABLESPACE_NAME MB
--------------- ----------
TEST1 5
6.此时执行闪回DROP，报这个错：
SQL> flashback table test9 to before drop;
flashback table test9 to before drop
ORA-38305: object not in RECYCLE BIN
7.在test1表空间再创建一个9M大约的表，此时才会自动扩展表空间大小----这一步实验好像意义不大。验证最前面的观点。
SQL> create table test4 tablespace test1 as select * from dba_objects;
Table created
SQL> select tablespace_name,bytes/1024/1024 mb from dba_free_space where tablespace_name='TEST1';
TABLESPACE_NAME MB
--------------- ----------
SQL> select file#,name,bytes/1024/1024 MB from v$datafile where file#=7;
FILE# NAME MB
---------- -------------------------------------------------------------------------------- ----------
7 /u01/app/oracle/oradata/bys001/test1.dbf 19