前段时间在检查表空间使用情况时发现db file free space的大小大于file的大小。导致在toad下看到的使用率为负的，考虑到应该是10G的一个bug, 因为这个表空间前段时间删除了大量的数据，后又导进来许多数据。

经过验正，真是的Bug，Bugno: 5083393

OS是RHEL4 Update 4

SYS @orcl>select * from v$version;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Prod
PL/SQL Release 10.2.0.3.0 - Production
CORE 10.2.0.3.0 Production
TNS for Linux: Version 10.2.0.3.0 - Production
NLSRTL Version 10.2.0.3.0 - Production

SQL> SELECT a.tablespace_name,b.FILE_NAME, b.size_kb, a.free_kb,
2 ROUND((a.free_kb/b.size_kb),2) "FREE"
3 FROM (SELECT tablespace_name,FILE_id,
4 SUM(bytes) free_kb
5 FROM DBA_FREE_SPACE
6 GROUP BY tablespace_name,FILE_id ) a,
7 (SELECT tablespace_name,file_id,FILE_NAME,
8 bytes size_kb
9 FROM DBA_DATA_FILES e) b
10 WHERE a.tablespace_name = b.tablespace_name AND a.file_id=b.file_id
11 AND a.tablespace_name='PBRSPACE';

TABLESPACE_NAME FILE_NAME SIZE_KB FREE_KB FREE
------------------------------ ------------------------------ ---------- ---------- ----------
PBRSPACE /oradata/orcl/PBRSPACE01.dbf 2097152000 2114650112 1.01
PBRSPACE /oradata/orcl/PBRSPACE02.dbf 2147483648 1045299200 .49
PBRSPACE /oradata/orcl/PBRSPACE03.dbf 2147483648 1027604480 .48

SQL> SELECT b.NAME,b.bytes/1024/1024 "total size",SUM(a.bytes/1024/1024) "extent size" FROM DBA_SEGM
ENTS a, v$datafile b,v$tablespace c
2 WHERE a.relative_fno=b.FILE# AND b.ts#=c.ts#
3 AND c.NAME='PBRSPACE'
4 GROUP BY b.NAME,b.bytes/1024/1024;

NAME total size extent size
------------------------------ ----------------- -----------
/oradata/orcl/PBRSPACE01.dbf 2000 2097.75
/oradata/orcl/PBRSPACE02.dbf 2048 1655.375
/oradata/orcl/PBRSPACE03.dbf 2048 381.75

而且已分配的数量也>datafile的大小了。

我purge recyclebin后就正常了。

SQL> SELECT a.tablespace_name,b.FILE_NAME, b.size_kb, a.free_kb,
2 ROUND((a.free_kb/b.size_kb),2) "FREE"
3 FROM (SELECT tablespace_name,FILE_id,
4 SUM(bytes) free_kb
5 FROM DBA_FREE_SPACE
6 GROUP BY tablespace_name,FILE_id ) a,
7 (SELECT tablespace_name,file_id,FILE_NAME,
8 bytes size_kb
9 FROM DBA_DATA_FILES e) b
10 WHERE a.tablespace_name = b.tablespace_name AND a.file_id=b.file_id
11 AND a.tablespace_name='PBRSPACE';

TABLESPACE FILE_NAME SIZE_KB FREE_KB FREE
---------- ------------------------------ ---------- ---------- ----------
PBRSPACE /oradata/orcl/PBRSPACE01.dbf 2097152000 2049703936 .98
PBRSPACE /oradata/orcl/PBRSPACE02.dbf 2147483648 1069285376 .5
PBRSPACE /oradata/orcl/PBRSPACE03.dbf 2147483648 1068564480 .5

SQL> SELECT b.NAME,b.bytes/1024/1024 "total size",SUM(a.bytes/1024/1024) "extent size" FROM DBA_SEGM
ENTS a, v$datafile b,v$tablespace c
2 WHERE a.relative_fno=b.FILE# AND b.ts#=c.ts#
3 AND c.NAME='PBRSPACE'
4 GROUP BY b.NAME,b.bytes/1024/1024;

NAME total size extent size
-------------------------------------------------- ---------- -----------
/oradata/orcl/PBRSPACE01.dbf 2000 81.25
/oradata/orcl/PBRSPACE02.dbf 2048 1639.375
/oradata/orcl/PBRSPACE03.dbf 2048 381.75

在网上也查了相关的资料

================================
此问题解决办法:

----设想:
因为oracle 10g 里设有回收站功能,它能记录非常SYS,SYSTEM的drop操作.
而设置的大小为:2G(设想)
会记录到dba_recyclebin/user_recyclebin/recyclebin

----测试现象:
当从数据库里删除大于2G的表时(没有增加purge参数),那就回出现表空间里的部分数据文件的使用率为负数.

----解决办法 :
1. 增大db_file_recovery_file_dest_size 2G的大小,(如果没有在安装时设置大小,那显示数为0)
若没有在安装时设置,那数据库里默认设置还是2G,当在删除(drop操作时),数据库会使用该用户的表空间来保存DROP可恢复数据,
用表空间的一定空间来保存.(注意:表空间的变化量)

2.删除数据库里的dba_recyclebin/user_recyclebin/recyclebin里面的记录,那OEM就能正常显示.

================================
疑问:

如果有OEM出现这样的数据文件使用率为负数的问题,
那oracle 怎样再去使用与计算表空间的使用呢?

如果不能正确解决这个问题,那日后再继续时,很可以会出错误,会导致数据库不能正常使用,
所以认为,这是数据库的一个BUG,需要oracle 更改这一计算方式或过程,就此问题还在进一步去研究.
Bug 5083393