记录删除后，数据块空间不释放，请大家帮忙看看分析一下

Yong Huang

原帖由 magic007 于 2010-8-9 10:48 发表
我估计用dbms_repair.segment_fix_status可以修复标记为FULL状态的BITMAP。但造成这个的原因我估计还是BUG。DELETE之后，没有将BMB中的数据标记正确，而块上的数据全部被DELETE之后，如果没有从FULL更改状态为其他状态，那永远就为FULL状态了。因为块只有在DML操作时才会作状态更改，而块上没有数据，因此不再可能有UPDATE和DELETE，而状态为FULL，又不能有INSERT。

要看你们的业务逻辑，是否是在INSERT之前DELETE数据？这个INSERT和DELETE是否在同一事务之中？

I checked the SR I opened a year ago. It was indeed dbms_repair.segment_fix_status that I ran to fix a similar issue. I read Bug 4660718 and found it. Read

https://support.oracle.com/CSP/m ... CH&id=4660718.8
https://support.oracle.com/CSP/m ... =BUG&id=4660718

The bug description note also mentions the parameter _minfree_plus. It would be implemented if you apply a patch. It's available in the database (without a patch) as of 11gR1.

Yong Huang

magic007

不知LZ的库是多少版本，是否满足Huang版提到的BUG的触发条件。

BTxigua

10204，bug的条件不满足。

BTxigua

昨天下午18点的时候，truncate了表。表恢复到initial大小：19M。晚上22点试了DBMS_SPACE_ADMIN.ASSM_SEGMENT_VERIFY。

SQL> select sysdate from dual;

SYSDATE
-----------
2010-8-9 22

SQL> select count(*) from ocs.OCP_PROCESS_CCR_LOG;

  COUNT(*)
----------
    226021

SQL> select extents,bytes from dba_segments where segment_name='OCP_PROCESS_CCR_LOG';

   EXTENTS      BYTES
---------- ----------
        97  101711872

SQL> exec DBMS_SPACE_ADMIN.ASSM_SEGMENT_VERIFY('OCS','OCP_PROCESS_CCR_LOG','TABLE',null,9);

PL/SQL procedure successfully completed

SQL>

貌似这个起作用了。从昨天晚上22点到现在空间没再增长。
当前的情况：
SQL> select sysdate from dual ;

SYSDATE
-----------
2010-8-10 9

SQL> select count(*) from ocs.OCP_PROCESS_CCR_LOG ;

  COUNT(*)
----------
    292958

SQL> select extents,bytes from dba_segments where segment_name='OCP_PROCESS_CCR_LOG';

   EXTENTS      BYTES
---------- ----------
        97  101711872

SQL>

BTxigua

exec DBMS_SPACE_ADMIN.ASSM_SEGMENT_VERIFY('OCS','OCP_PROCESS_CCR_LOG','TABLE',null,9);的dump结果

ORACLE_HOME = /oracle/app/oracle/product/10.2.0/db
System name:    AIX
Node name:      ocsdb2
Release:        3
Version:        5
Machine:        00CBEBA44C00
Instance name: ocs
Redo thread mounted by this instance: 1
Oracle process number: 235
Unix process pid: 959108, image: oracle@ocsdb2

*** 2010-08-09 22:30:17.026
*** ACTION NAMEÃüÁî´°¿Ú - н¨) 2010-08-09 22:30:17.019
*** MODULE NAMEPL/SQL Developer) 2010-08-09 22:30:17.019
*** SERVICE NAMEocs) 2010-08-09 22:30:17.019
*** SESSION ID2187.4966) 2010-08-09 22:30:17.019
Segment header [dba: 0x007082f8c, (file 28,block 536460)]
Segment object id: 198163; inc. no.: 0
*********
verifying extent map and tablespace bitmap consistency
---------
Verifying extent map and L1 bitmap blocks consistency in the segment
---------
Verifying consistency of segment header, L3, L2 and L1 bitmap blocks
---------
Verifying Segment HWM Consistency
Verifying High HWM information
Verifying Low HWM information
---------
Verifying consistency of hwm information in segment header and L1 bitmap block
---------
Verifying segment header and seg$ information consistency of the segment
---------

BTxigua

原帖由 magic007 于 2010-8-10 00:48 发表
我估计用dbms_repair.segment_fix_status可以修复标记为FULL状态的BITMAP。但造成这个的原因我估计还是BUG。DELETE之后，没有将BMB中的数据标记正确，而块上的数据全部被DELETE之后，如果没有从FULL更改状态为其他状态，那永远就为FULL状态了。因为块只有在DML操作时才会作状态更改，而块上没有数据，因此不再可能有UPDATE和DELETE，而状态为FULL，又不能有INSERT。

要看你们的业务逻辑，是否是在INSERT之前DELETE数据？这个INSERT和DELETE是否在同一事务之中？

insert和delete是互不相干的。
应用专门写了个imp程序用来insert日志信息。后来发现这个表涨的太快了，写了个定时任务来清理，delete 15分钟之前的记录。

Yong Huang

> 10204，bug的条件不满足。

The database I had the problem on is 10.2.0.4. Sometimes the version numbers in the bug should be taken with a grain of salt.

> 昨天下午18点的时候，truncate了表。表恢复到initial大小：19M。晚上22点试了DBMS_SPACE_ADMIN.ASSM_SEGMENT_VERIFY。

You lost a precious opportunity to truly verify the integrity of the metadata blocks. A truncate may well have "fixed" your problem already.

Wait till next time you have the problem and don't rush to truncate.

Yong Huang

[ 本帖最后由 Yong Huang 于 2010-8-10 15:19 编辑 ]

BTxigua

>You lost a precious opportunity to truly verify the integrity of the metadata blocks. A truncate may well have "fixed" your problem already.

Wait till next time you have the problem and don't rush to truncate.

事实上，我不是第一次truncate这个表了，在半年之前，我已经truncate过这个表了。只是上次truncate的时候我没有注意到这个问题，不知道是在truncate之前就存在这个问题，还是truncate之后才冒出来的。

这个问题我也拖了一个多月了，metalink也一直没有得到答复，所以拿出来请教大家。最近因为业务要调整，所以必须做清理了，所以就做了truncate了。

从这两天的数据看，貌似没有出现原来的情况了？不知道是truncate起作用了，还是verify起作用了。
SQL> select extents ,bytes from dba_segments where segment_name='OCP_PROCESS_CCR_LOG';

   EXTENTS      BYTES
---------- ----------
       125  131072000

SQL> SELECT COUNT(*) FROM OCP_PROCESS_CCR_LOG;

  COUNT(*)
----------
    290912