Fw: 10.2.0.4.0里请慎用压缩表

10.2.0.4.0里请慎用压缩表

By cui hua on August 17, 2009 5:49 PM

http://dbsnake.com/cgi-bin/mt/mt-search.cgi?blog_id=1&tag=10.2.0.4.0%20compress%20table%20bug&limit=20

10.2.0.4.0上请慎用压缩表，很有可能会丢数据的。

 

Bug 7123643 UPDATE TO A COLUMN IN A COMPRESSED TABLE RESULTS IN DATA LOSS 对这个问题也有描述。

 

其实我很早就知道这个bug，只是我从来没有重现过，今天，我终于重现了上述bug。

 

如下是完整的重现过程：

SQL> conn caipra/acca@ipratest;

Connected to Oracle Database 10g Enterprise Edition Release 10.2.0.4.0

Connected as caipra

 

SQL> create table t1 as select * from saldat;

 

Table created

 

SQL> select count(*) from t1;

 

  COUNT(*)

----------

    111303

 

SQL> create table t2 compress as select * from t1;

 

Table created

 

SQL> select count(*) from t2;

 

  COUNT(*)

----------

    111303

 

SQL> select count(*) from (select * from t1 minus select * from t2);

 

  COUNT(*)

----------

         0

 

SQL> update t1 set sdapgc=0.5;

 

111303 rows updated

 

SQL> update t2 set sdapgc=0.5;

 

111303 rows updated

 

SQL> commit;

 

Commit complete

 

SQL> select count(*) from (select * from t1 minus select * from t2);

 

  COUNT(*)

----------

      5430

 

SQL> select t.sdaamm,t.* from t2 t where sdaprf='000' and sdafrm='962' and sdatkt='4369256';

 

 SDAAMM SDAPRF SDAFRM SDATKT   SDACHK         SDASEQ SDABTH SDASUB SDASRC SDASTY SDATKY SDAGDS SDASTA SDAAGT   SDATIO SDATII

......-省略显示部分内容

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

        000    962    4369256       6         BSP  Y 962 4369255       2      2 N

 

SQL> select t.sdaamm,t.* from t1 t where sdaprf='000' and sdafrm='962' and sdatkt='4369256';

 

 SDAAMM SDAPRF SDAFRM SDATKT   SDACHK         SDASEQ SDABTH SDASUB SDASRC SDASTY SDATKY SDAGDS SDASTA SDAAGT   SDATIO SDATII

......-省略显示部分内容

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

 200908 000    962    4369256       6 BSP Y      962    4369255       2      2 N

 

从结果里我们可以看到，t2是压缩表，t1和t2开始的时候是没有区别的，这体现在：

SQL> select count(*) from (select * from t1 minus select * from t2);

 

  COUNT(*)

----------

         0

 

当我同时将t1和t2的字段sdapgc修改为0.5后，这时候，区别就出来了，这体现在：

SQL> select count(*) from (select * from t1 minus select * from t2);

 

  COUNT(*)

----------

      5430

 

原来是没有区别的，现在是一共有5430条记录有区别。

 

在上述测试的最后，我们随便找了一条有区别的记录。

可以从结果里看到：

表t1里sdaprf='000' and sdafrm='962' and sdatkt='4369256'的那条记录的sdaamm的值是200908。

表t2里sdaprf='000' and sdafrm='962' and sdatkt='4369256'的那条记录的sdaamm的值是null。

 

也就代表着，t2现在可能已经丢数据了（至少select的结果是这样），这正是Bug 7123643里描述的那样。