从底向上第六篇--compress for oltp真正压缩的阈值触发条件

sundog315

从底向上第一篇--了解DML操作
从底向上第二篇--了解行迁移
从底向上第三篇--了解index的compress
从底向上第四篇--了解行链接
从底向上第五篇--了解表的压缩属性
从底向上第六篇--compress for oltp真正压缩的阈值触发条件
从底向上第七篇--超255列表的存储
从底向上第八篇--伪造基于ASSM表空间的数据块

在Oracle 11.2里，新增加了compress for oltp压缩方式，Oracle声称这种方式是专为OLTP系统定制的，其原理图如下：

Oracle has put in a significant amount of work to minimize this overhead for OLTP Table Compression.  Oracle compresses blocks in batch mode rather than compressing data every time a write operation takes place. A newly initialized block remains uncompressed until data in the block reaches an internally controlled threshold. When a transaction causes the data in the block to reach this threshold, all contents of the block are compressed. Subsequently, as more data is added to the block and the threshold is again reached, the entire block is recompressed to achieve the highest level of compression.

简而言之
1.插入数据，非压缩
2.达到内部阈值，触发压缩
3.block空闲空间继续可以插入数据，非压缩
4.达到内部阈值，触发压缩
。。。
直到没有压缩的余地

这里，主要讨论是这个阈值到底是什么？真的像Oracle所言是内部控制的么？还是我们可以进行调整的？

测试过程如下：
C:\Users\Administrator>sqlplus /nolog

SQL*Plus: Release 11.2.0.1.0 Production on 星期五 5月 28 10:00:03 2010

Copyright (c) 1982, 2010, Oracle.  All rights reserved.

SQL> conn test/test
已连接。
SQL> create table t compress for oltp as select * from dba_objects where 1=0;

表已创建。

SQL> insert into t
  2  SELECT * FROM
  3  ( SELECT * FROM dba_objects ORDER BY dbms_random.value )
  4  WHERE rownum <71;

已创建70行。

SQL> commit;

提交完成。

SQL> alter system checkpoint;

系统已更改。

SQL> select header_file,header_block,blocks from dba_segments where segment_name='T';

HEADER_FILE HEADER_BLOCK     BLOCKS                                             
----------- ------------ ----------                                             
          4          130          8                                             

SQL> alter system dump datafile 4 block 133;

系统已更改。


Block header dump:  0x01000085
Object id on Block? Y
seg/obj: 0x105a2  csc: 0x00.2913fa  itc: 2  flg: E  typ: 1 - DATA
     brn: 0  bdba: 0x1000080 ver: 0x01 opc: 0
     inc: 0  exflg: 0

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x000a.01c.000004de  0x00c070df.0163.23  --U-   69  fsc 0x0000.002913fb
0x02   0x0001.013.000004e0  0x00c071fe.0174.37  --U-    1  fsc 0x0000.00291458
bdba: 0x01000085
data_block_dump,data header at 0xe238264
===============
tsiz: 0x1f98
hsiz: 0x9e
pbl: 0x0e238264
     76543210
flag=--------                                     --非压缩
ntab=1
nrow=70
frre=-1
fsbo=0x9e
fseo=0x448
avsp=0x3aa                                    --938
tosp=0x3aa

SQL> insert into t
  2  SELECT * FROM
  3  ( SELECT * FROM dba_objects ORDER BY dbms_random.value )
  4  WHERE rownum = 1;

已创建 1 行。

SQL> commit;

提交完成。

SQL> alter system checkpoint;

系统已更改。

SQL>
SQL> alter system dump datafile 4 block 133;

系统已更改。

Block header dump:  0x01000085
Object id on Block? Y
seg/obj: 0x105a2  csc: 0x00.29146c  itc: 2  flg: E  typ: 1 - DATA
     brn: 0  bdba: 0x1000080 ver: 0x01 opc: 0
     inc: 0  exflg: 0

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x0007.013.000004e5  0x00c06f04.01c3.01  C---    0  scn 0x0000.0029146c
0x02   0x0008.008.00000579  0x00c0b16b.0205.02  --U-    1  fsc 0x0000.0029146e
bdba: 0x01000085
data_block_dump,data header at 0xe238264
===============
tsiz: 0x1f98
hsiz: 0x160
pbl: 0x0e238264
     76543210
flag=-0------                                                 --触发了压缩操作
ntab=2
nrow=147
frre=-1
fsbo=0x160
fseo=0xc40
avsp=0xae0
tosp=0xae0
        r0_9ir2=0x0
        mec_kdbh9ir2=0xa
                      76543210
        shcf_kdbh9ir2=----------
                  76543210
        flag_9ir2=--R-L-OC        Archive compression: N
                fcls_9ir2[7]={ 0 32768 5 6 7 8 10 }
                perm_9ir2[14]={ 6 12 0 13 8 7 9 10 11 1 2 3 4 5 }

到这里，是否觉得有点眼熟？pctfree？

SQL> drop table t purge;

表已删除。
SQL> create table t pctfree 20 compress for oltp as select * from dba_objects where 1=0;

表已创建。

SQL> insert into t
  2  SELECT * FROM
  3  ( SELECT * FROM dba_objects ORDER BY dbms_random.value )
  4  WHERE rownum < 64;

已创建63行。

SQL> commit;

提交完成。

SQL> alter system checkpoint;

系统已更改。

SQL> alter system dump datafile 4 block 135;

系统已更改。

Block header dump:  0x01000087
Object id on Block? Y
seg/obj: 0x105a3  csc: 0x00.29155c  itc: 2  flg: E  typ: 1 - DATA
     brn: 0  bdba: 0x1000080 ver: 0x01 opc: 0
     inc: 0  exflg: 0

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x0008.009.0000057f  0x00c0b16b.0205.10  --U-   59  fsc 0x0000.0029155d
0x02   0x000a.018.000004de  0x00c070e0.0163.06  --U-    4  fsc 0x0000.002915b6
bdba: 0x01000087
data_block_dump,data header at 0x8bc8264
===============
tsiz: 0x1f98
hsiz: 0x90
pbl: 0x08bc8264
     76543210
flag=--------
ntab=1
nrow=63
frre=-1
fsbo=0x90
fseo=0x736
avsp=0x6a6                              --1702
tosp=0x6a6

SQL> insert into t
  2  SELECT * FROM
  3  ( SELECT * FROM dba_objects ORDER BY dbms_random.value )
  4  WHERE rownum = 1;

已创建 1 行。

SQL> commit;

提交完成。

SQL> alter system checkpoint;

系统已更改。

Block header dump:  0x01000087
Object id on Block? Y
seg/obj: 0x105a3  csc: 0x00.2915e1  itc: 2  flg: E  typ: 1 - DATA
     brn: 0  bdba: 0x1000080 ver: 0x01 opc: 0
     inc: 0  exflg: 0

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x000a.01f.000004e2  0x00c070e3.0163.01  C---    0  scn 0x0000.002915e1
0x02   0x0006.004.00000686  0x00c073d3.01c0.05  --U-    1  fsc 0x0000.002915e3
bdba: 0x01000087
data_block_dump,data header at 0x8bc8264
===============
tsiz: 0x1f98
hsiz: 0x13e
pbl: 0x08bc8264
     76543210
flag=-0------                                           --又压缩了
ntab=2
nrow=132
frre=-1
fsbo=0x13e
fseo=0xeb4
avsp=0xd76
tosp=0xd76
        r0_9ir2=0x0
        mec_kdbh9ir2=0x7
                      76543210
        shcf_kdbh9ir2=----------
                  76543210
        flag_9ir2=--R-L-OC        Archive compression: N
                fcls_9ir2[5]={ 0 32768 32768 32768 32768 }
                perm_9ir2[14]={ 6 12 4 13 8 7 9 10 11 0 1 2 3 5 }

根据上面的测试，我很怀疑Oracle就是将OLTP压缩的过程放入了pctfree的处理过程内部，而不像Oracle所说的那么神秘，是靠什么internal threshold。

[ 本帖最后由 sundog315 于 2010-6-25 14:52 编辑 ]

viadeazhu

http://space.itpub.net/15415488/viewspace-616769

其实就是pctfree，我记得有白皮书提到这个的。

sundog315

白皮书里应该是没有的。

Yong Huang

原帖由 sundog315 于 2010-5-30 08:13 发表
白皮书里应该是没有的。

Here's what I find.

http://www.oracle.com/global/de/ ... 11gr2_workshop2.pdf

p.91

"PCTFREE reached: Compression!"

Also, right after Tom answered somebody's question about 11g advanced compression:

http://asktom.oracle.com/pls/ask ... N_ID:69076630635645

"most inserts will not be impacted, only the insert that takes the block over 'pctfree' and would normally take it off the freelist would."
"updates - see insert in this section. If the update would cause the block to exceed pctfree and be removed from the freelist, the compression is done first."

Yong Huang

sundog315

我也在其他的文档里找到了这个。呵呵。
whatever，Oracle在白皮书里的Internal controlled threshold还是让人感觉到很逗。

Yong Huang

原帖由 sundog315 于 2010-5-30 18:19 发表
Oracle在白皮书里的Internal controlled threshold还是让人感觉到很逗。

Sometimes white papers intentionally do not reveal the real "secret" not because they want to, but because the "secret" may change to something else and Oracle doesn't want to trouble themselves to remember to tell us the change. If it's true in this case, then there's a possibility that in future versions of Oracle, this threshold may indeed change to something other than pctfree.

Yong Huang

sundog315

原帖由 Yong Huang 于 2010-6-1 01:34 发表


Sometimes white papers intentionally do not reveal the real "secret" not because they want to, but because the "secret" may change to something else and Oracle doesn't want to trouble themselves to remember to tell us the change. If it's true in this case, then there's a possibility that in future versions of Oracle, this threshold may indeed change to something other than pctfree.

Yong Huang

很有道理！