今天在检查数据库报告时发现了这样一条记录:
- Large object Report OWNER SEGMENT_NAME SEGMENT_TYPE TABLESPACE Size_Mb ---------- ----------------------------- ------------- ---------- ---------- BOSSMGR BIN$FzMEZaDyQK3gRAADuow9AA== TABLE BOSSMGR 25075 |
在Oracle10g的回收站里,竟然有一个大小为25G的对象,想着手手动释放这个空间,首先检查回收站内的相关对象:
[@more@]SQL> select tablespace_name,sum(bytes)/1024/1024 from dba_free_space TABLESPACE_NAME SUM(BYTES)/1024/1024 6 rows selected. SQL> select * from (
10 rows selected. |
清空最大的对象:
SQL> purge table bossmgr.SMS_ORG_9966_MT_BB; Table purged. |
我们注意到此时的dba_free_space空间并未发生变化:
SQL> select tablespace_name,sum(bytes)/1024/1024 from dba_free_space TABLESPACE_NAME SUM(BYTES)/1024/1024 6 rows selected. |
变化发生在dba_free_space视图的构成上。在Oracle10g中,如果启用flash drop功能,在drop表时,数据库不会直接删除,而是将其放在回收站中,当空间出现短缺时,才会逐渐回收这部分空间。当对象删除之后,这部分空间会记入free space,也就是说被包含在dba_free_space的查询结果之中。
我们看一下这个视图的变化,在Oracle9i之中,这个视图构建如下:
SQL> set long 9999 TEXT |
而在Oracle10g中,这个视图增加了关于recyclebin的部分:
SQL> set long 9999 TEXT |
这就是Oracle10g的回收站(recyclebin)和自由空间管理的变化。
在Oracle10g中,有时候查询dba_free_space视图异常缓慢,就是因为recyclebin中对象太多的缘故。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/35489/viewspace-999002/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/35489/viewspace-999002/