在一个数据库中发现了一个异常增大的对象，经检查改对象为BITMAP索引。
在数据库中执行下面的脚本，发现了一个异常增大的对象：
SQL> SELECT SEGMENT_NAME, SEGMENT_TYPE, SUM(BYTES)/1024/1024/1024 G
2 FROM USER_SEGMENTS
3 GROUP BY SEGMENT_NAME, SEGMENT_TYPE
4 HAVING SUM(BYTES)/1024/1024/1024 > 15;
SEGMENT_NAME SEGMENT_TYPE G
------------------------------ ------------------ ----------
TU_ORD_ORDER_ZJ_K_CODE INDEX 16.7539215
检查该对象的详细信息：
SQL> SELECT INDEX_NAME, INDEX_TYPE FROM USER_INDEXES
2 WHERE INDEX_NAME = ’TU_ORD_ORDER_ZJ_K_CODE’;
INDEX_NAME INDEX_TYPE
------------------------------ ---------------------------
TU_ORD_ORDER_ZJ_K_CODE FUNCTION-BASED BITMAP
这个对象是一个基于函数的BITMAP索引。一般来说，BITMAP索引的大小要远远小于普通索引，而这里索引的大小达到了16G，远远超过表本身的大小，这里肯定存在问题。通过对DBMS_SPACE包中SPACE_USAGE过程的封装，检查这个对象的空间使用情况：
SQL> create or replace procedure p_space_usage (p_segment_name in varchar2,
2 p_segment_type in varchar2 default ’TABLE’,
3 p_segment_owner in varchar2 default user,
4 p_partition_name in varchar2 default ’’) as
5 v_unformatted_blocks number;
6 v_unformatted_bytes number;
7 v_fs1_blocks number;
8 v_fs1_bytes number;
9 v_fs2_blocks number;
10 v_fs2_bytes number;
11 v_fs3_blocks number;
12 v_fs3_bytes number;
13 v_fs4_blocks number;
14 v_fs4_bytes number;
15 v_full_blocks number;
16 v_full_bytes number;
17 begin
18 dbms_space.space_usage(upper(p_segment_owner), upper(p_segment_name), upper(p_segment_type), v_unformatted_blocks,
19 v_unformatted_bytes, v_fs1_blocks, v_fs1_bytes, v_fs2_blocks, v_fs2_bytes, v_fs3_blocks, v_fs3_bytes,
20 v_fs4_blocks, v_fs4_bytes, v_full_blocks, v_full_bytes, upper(p_partition_name));
21
22 dbms_output.put_line(’unformatted_blocks is ’ || v_unformatted_blocks);
23 dbms_output.put_line(’unformatted_bytes is ’ || v_unformatted_bytes);
24 dbms_output.put_line(’fs1_blocks is ’ || v_fs1_blocks);
25 dbms_output.put_line(’fs1_bytes is ’ || v_fs1_bytes);
26 dbms_output.put_line(’fs2_blocks is ’ || v_fs2_blocks);
27 dbms_output.put_line(’fs2_bytes is ’ || v_fs2_bytes);
28 dbms_output.put_line(’fs3_blocks is ’ || v_fs3_blocks);
29 dbms_output.put_line(’fs3_bytes is ’ || v_fs3_bytes);
30 dbms_output.put_line(’fs4_blocks is ’ || v_fs4_blocks);
31 dbms_output.put_line(’fs4_bytes is ’ || v_fs4_bytes);
32 dbms_output.put_line(’full_blocks is ’ || v_full_blocks);
33 dbms_output.put_line(’full_bytes is ’ || v_full_bytes);
34 end;
35 /
Procedure created.
SQL> SET SERVEROUT ON SIZE 10000
SQL> EXEC P_SPACE_USAGE(’TU_ORD_ORDER_ZJ_K_CODE’, ’INDEX’, ’NDMAIN’)
unformatted_blocks is 2038268
unformatted_bytes is 16697491456
fs1_blocks is 0
fs1_bytes is 0
fs2_blocks is 139652
fs2_bytes is 1144029184
fs3_blocks is 0
fs3_bytes is 0
fs4_blocks is 0
fs4_bytes is 0
full_blocks is 13365
full_bytes is 109486080
PL/SQL procedure successfully completed.
问题已经很显然了，这个基于函数的BITMAP索引包含了大量的unformatted blocks，造成大量空间的浪费，而实际上索引所需要的空间并没有这么大。
检查METALINK，发现Oracle处理ASSM表空间的BITMAP索引存在空间浪费的bug，详细bug描述参考：Bug No. 2915226。
Oracle给出了一个例子来重现这个bug：
SQL> SELECT TABLESPACE_NAME, SEGMENT_SPACE_MANAGEMENT
2 FROM DBA_TABLESPACES
3 WHERE TABLESPACE_NAME = ’USERS’;
TABLESPACE_NAME SEGMEN
------------------------------ ------
USERS AUTO
SQL> CREATE TABLE T (ID NUMBER NOT NULL, BITMAP_COL NUMBER NOT NULL);
表已创建。
SQL> INSERT INTO T SELECT ROWNUM, MOD(ROWNUM, 2) FROM DBA_OBJECTS;
已创建31016行。
SQL> CREATE BITMAP INDEX IND_B_T_BIT ON T(BITMAP_COL) TABLESPACE USERS;
索引已创建。
SQL> BEGIN
2 FOR I IN REVERSE 1..1000 LOOP
3 UPDATE T SET BITMAP_COL = 1
4 WHERE BITMAP_COL = 0 AND ID = I;
5 END LOOP;
6 END;
7 /
PL/SQL 过程已成功完成。
SQL> SET SERVEROUT ON SIZE 1000000
SQL> EXEC P_SPACE_USAGE(’IND_B_T_BIT’, ’INDEX’)
unformatted_blocks is 93536
unformatted_bytes is 766246912
fs1_blocks is 0
fs1_bytes is 0
fs2_blocks is 8211
fs2_bytes is 67264512
fs3_blocks is 0
fs3_bytes is 0
fs4_blocks is 0
fs4_bytes is 0
full_blocks is 18
full_bytes is 147456
PL/SQL 过程已成功完成。
这个结果和这里碰到的问题几乎完全一致，只不过这个例子是人为构造bug的产生，而数据库中则是由于正常修改在某些情况下触发了这个bug，检查当前的表空间信息：
SQL> SELECT INDEX_NAME, TABLESPACE_NAME FROM USER_INDEXES
2 WHERE INDEX_NAME = ’TU_ORD_ORDER_ZJ_K_CODE’;
INDEX_NAME TABLESPACE_NAME
------------------------------ ------------------------------
TU_ORD_ORDER_ZJ_K_CODE INDX
SQL> SELECT SEGMENT_SPACE_MANAGEMENT FROM USER_TABLESPACES
2 WHERE TABLESPACE_NAME = ’INDX’;
SEGMEN
------
AUTO
这个Bug在10.1.0.2被修正，对于9.2.0.2以上的版本，可以直接下载编号为2915226的patch来解决这个问题