oracle某张表size暴涨问题分析处理

问题描述：客户一系统中的一张业务表突然暴涨，由原本的40M左右，涨到现在的4G，但数据量没有多大变化，一直维持在5W左右。

oracle版本：10.2.0.4

操作系统：aix6.1

初步分析：由于客户坚信是暴涨，而不是由于平时的dml操作导致碎片过大，所以我怀疑是有大的insert插入操作撑大了表，后来又做了delete，但没有释放高水位线。

通过查看该表历史统计信息的情况，发现9.11晚上22:00该表大小还是正常的40m，但9.14:晚上22:00时候的统计信息，该表就变成4G的大小了。

继而我怀疑就是在这个时间段做了大量的insert操作。。。

然后找客户确认。。没有做过这种操作。。。

于是生成各个时间点的awr报告，没有发现涉及到该表的insert/delete/update操作。。。

于是查看归档日志切换情况。。。发现该时间段内并没有出现归档明显增多情况。。。。。。这么多个于是后，于是我醉了。。。。。。。

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

搞了一上午没有查出来原因，一肚子郁闷去吃饭了，一边走一边想，莫不是bug？？？

越想越有可能，抓紧刨完饭就回来查，果然看到类似情况：

http://www.itpub.net/forum.php?mod=viewthread&tid=1348905&highlight=&page=3

这个遇到了一个索引暴涨的情况，于是顺着这哥们提供的metalink文章号，找到了相关文档，并用如语句检测了下出问题的表，发现确实存在很多未格式的数据块。

set serveroutput on
exec dbms_output.enable(1000000);
declare
  unf number;
  unfb number;
  fs1 number;
  fs1b number;
  fs2 number;
  fs2b number;
  fs3 number;
  fs3b number;
  fs4 number;
  fs4b number;
  full number;
  fullb number;
  own dba_tables.owner%type;
  tab dba_tables.table_name%type;
  yesno varchar2(3);
  type parts is table of dba_tab_partitions%rowtype;
  partlist parts;
  type cursor_ref is ref cursor;
  c_cur cursor_ref;
begin
  own:=upper('&owner');
  tab:=upper('&table_name');
  dbms_output.put_line('--------------------------------------------------------------------------------');
  open c_cur for select partitioned from dba_tables 
where owner=own and table_name=tab;
  fetch c_cur into yesno;
  close c_cur;
  dbms_output.put_line('Owner:     '||own);
  dbms_output.put_line('Table:     '||tab);
  dbms_output.put_line('------------------------------------------------');
  if yesno='NO'
  then
    dbms_space.space_usage(own,tab,'TABLE',unf,unfb,fs1,fs1b,fs2,fs2b,fs3,fs3b,fs4,fs4b,full,fullb);
    dbms_output.put_line('unf: '||unf||' fs1: '||fs1||' fs2: '||fs2||' fs3: '||fs3||' fs4: '||fs4||' full: '||full);
  else
    open c_cur for select * from dba_tab_partitions 
      where table_owner=own and table_name=tab;
    fetch c_cur bulk collect into partlist;
    close c_cur;
    for i in partlist.first .. partlist.last
    loop
      dbms_space.space_usage(partlist(i).table_owner,partlist(i).table_name,'TABLE 
PARTITION',unf,unfb,fs1,fs1b,fs2,fs2b,fs3,fs3b,fs4,fs4b,full,fullb,partlist(i).partition_name);
      dbms_output.put_line('Partition: '||partlist(i).partition_name);
      dbms_output.put_line('unf: '||unf||' fs1: '||fs1||' fs2: '||fs2||' fs3: '||fs3||' fs4: '||fs4||' full: '||full);
    end loop;
  end if; 
  dbms_output.put_line('--------------------------------------------------------------------------------');
end;
/

输出信息如下：

unf:524558

fs1:12

fs2:893

fs3:791

fs4:6957

full:6448

--------------------------------------------------------------

unf即unformatted blocks  ，

可参照下面两个文档：

Table/Index (partition) Growth Is Far More Than Expected (Doc ID 729149.1)

Sudden Increase in Unformatted Blocks (Doc ID 469985.1)

大致原因就是采用assm的自动段管理方式会产生该bug，9i起就有该bug出现，oracle说是影响版本到10.2.0.3，后来发现10.2.0.4基础版本也受到影响，

需要升级到10.2.0.4.3，该bug才被fixed掉。

关于什么情况会触发该bug，oracle也很光棍，直接说：It's unknown exactly what triggers the problem.

哈哈，老子不知道为啥出现这个bug玩意。。

遇到了就拜拜财神爷吧

由于没有单纯的bug小补丁了，要打patch的话，需要打patch set

具体打不打patch，还是要客户那定夺。。。。