Oracle Life: June 26, 2006 Archives

June 26, 2006

作者:eygle

出处:http://blog.eygle.com

上周了解了一下IBM的压缩技术,打算对比一下Oracle的表压缩技术做点研究,先讨论一下Oracle的表压缩技术.

从Oracle9iR2开始，Oracle推出了压缩表技术（table compression），用于压缩数据表中的重复数据，以节省存储空间，压缩技术倾向于在数据仓库中使用。

压缩在数据块级生效，当数据表定义为压缩时，数据库在每个数据块上保留空间存储重复数据的单个拷贝，保留空间被称为符号表（symbol table）。此后在具体行上不必再存储这些重复数据，只需要存放指向符号表相应数据的指针，存储空间因此得以节省。

关于压缩表的基本介绍，参考OTN上的文档:
http://www.oracle.com/technology/oramag/oracle/04-mar/o24tech_data.html

我们看一下简单的测试:

[oracle@jumper oracle]$ sqlplus eygle/eygle

SQL*Plus: Release 9.2.0.4.0 - Production on Mon Jun 26 16:07:24 2006

Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning option
JServer Release 9.2.0.4.0 - Production

SQL> create table test (c1 varchar2(20),c2 varchar2(20));

Table created.

SQL> begin
2 for i in 1 .. 10000 loop
3 insert into test values('eygle','test');
4 end loop;
5 end;
6 /

PL/SQL procedure successfully completed.

SQL> create table test_compress compress as select * from test;

Table created.

SQL> select table_name,COMPRESSION from user_tables where table_name like 'TEST%';

TABLE_NAME COMPRESS
------------------------------ --------
TEST DISABLED
TEST_COMPRESS ENABLED

SQL> analyze table test compute statistics;

Table analyzed.

SQL> analyze table test_compress compute statistics;

Table analyzed.

我们看一下两个表的空间使用情况:

SQL> select table_name,blocks,EMPTY_BLOCKS from user_tables
2 where table_name like 'TEST%';

TABLE_NAME BLOCKS EMPTY_BLOCKS
------------------------------ ---------- ------------
TEST 28 4
TEST_COMPRESS 18 6

SQL> select (28-4)/(18-6) from dual;

(28-4)/(18-6)
-------------
2

我们看到，压缩表只使用了常规表一半的空间。

我们转储一下数据块，看一下压缩表的存储结构：

SQL> select segment_name,file_id,block_id,blocks from dba_extents
2 where segment_name='TEST_COMPRESS';

SEGMENT_NAME FILE_ID BLOCK_ID BLOCKS
-------------------- ---------- ---------- ----------
TEST_COMPRESS 3 17 8
TEST_COMPRESS 3 25 8
TEST_COMPRESS 3 33 8

SQL> alter system dump datafile 3 block 20;

System altered.

找到跟踪文件：

SQL> @gettrcname.sql

TRACE_FILE_NAME
-------------------------------------------------------------------
/opt/oracle/admin/eygle/udump/eygle_ora_20984.trc

查看内容，首先看一下块头信息:

data_block_dump,data header at 0xaa84e7c
===============
tsiz: 0x1f80
hsiz: 0x5d2
pbl: 0x0aa84e7c
bdba: 0x00c00014
76543210
flag=-0------
ntab=2
nrow=727
frre=-1
fsbo=0x5d2
fseo=0x1144
avsp=0x1a
tosp=0x1a
r0_9ir2=0x0
mec_kdbh9ir2=0x1
r1_9ir2=0x0
76543210
flag_9ir2=-------C
fcls_9ir2[3]={ 0 32768 32768 }
0x1c:pti[0] nrow=1 offs=0
0x20:pti[1] nrow=726 offs=1
0x24:pri[0] offs=0x1f72
0x26:pri[1] offs=0x1f6d

我们看到这个Block中的ntab =2 也就是存在2张表，从下面可以找到table 0的信息:

tab 0, row 0, @0x1f72
tl: 14 fb: --H-FL-- lb: 0x0 cc: 2
col 0: [ 5] 65 79 67 6c 65
col 1: [ 4] 74 65 73 74
bindmp: 02 d6 02 cd 65 79 67 6c 65 cc 74 65 73 74

这个table 0只有一条记录，就是我们之前所说的符号表。

此后的记录才是真实数据，每条数据记录包含一个指针，指向符号表：

tab 1, row 0, @0x1f6d
tl: 5 fb: --H-FL-- lb: 0x0 cc: 2
col 0: [ 5] 65 79 67 6c 65
col 1: [ 4] 74 65 73 74
bindmp: 2c 00 01 02 00
tab 1, row 1, @0x1f68
tl: 5 fb: --H-FL-- lb: 0x0 cc: 2
col 0: [ 5] 65 79 67 6c 65
col 1: [ 4] 74 65 73 74
bindmp: 2c 00 01 02 00

这里的bindmp就是指针。

关于压缩表存储结构的进一步探讨可以参考:

biti_rainy 的关于 9iR2 的 compress table 的研究
http://www.itpub.net/showthread.php?threadid=197403

fuyuncat 的数据段压缩（Data Segment Compression）浅析
http://fuyuncat.itpub.net/post/5203/45991

压缩表显然是通过CPU换取存储，存储的缩减必然导致存储和查询时压缩和解压缩的CPU消耗。
但是，I/O操作得以节约，我们看一下对以上2个表执行全表扫描的比较：

SQL> set autotrace on
SQL> select count(*) from test;

COUNT(*)
----------
10000

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=4 Card=1)
1 0 SORT (AGGREGATE)
2 1 TABLE ACCESS (FULL) OF 'TEST' (Cost=4 Card=10000)

Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
31 consistent gets
0 physical reads
0 redo size
379 bytes sent via SQL*Net to client
503 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed

SQL> select count(*) from test_compress;
COUNT(*)
----------
10000

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=3 Card=1)
1 0 SORT (AGGREGATE)
2 1 TABLE ACCESS (FULL) OF 'TEST_COMPRESS' (Cost=3 Card=10000)

Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
17 consistent gets
0 physical reads
0 redo size
379 bytes sent via SQL*Net to client
503 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed

压缩表的一致性读只有17，较常规表的31大大减少。

压缩表是为数据仓库设计的特性，所以并不适合OLTP系统，在发生更新时，压缩表会因行链接而迅速扩展空间使用。
请看简单测试:

SQL> update test_compress set c1='oracle' where rownum <10;

9 rows updated.

SQL> commit;

Commit complete.

SQL> analyze table test_compress compute statistics;

Table analyzed.

SQL> select table_name,blocks,EMPTY_BLOCKS from user_tables
2 where table_name like 'TEST%';

TABLE_NAME BLOCKS EMPTY_BLOCKS
------------------------------ ---------- ------------
TEST 28 4
TEST_COMPRESS 24 0

具体可以参考wanghai 的文章: compress table
http://wzwanghai.spaces.msn.com/blog/cns!56626E237AFBD116!206.entry

Posted by eygle at 3:27 PM | Comments (0) | TrackBack

10g New Feature:MAXTRANS参数已经废弃

作者:eygle

出处:http://blog.eygle.com

此前写过两篇文章,介绍ITL竞争的模拟,有朋友在留言版上留言无法模拟,经过询问,得知在Oracle10g上无法再现我的试验结果.

首先猜测是Oracle10g的处理方式不同,我决定动手来验证一下,首先在Oracle9i中,创建一个测试表,设置MAXTRANS参数,结果如下:

SQL> connect eygle/eygle
Connected.
SQL> CREATE TABLE EYGLE_ITL
2 (C1 NUMBER,
3 C2 VARCHAR2(10)
4 )
5 INITRANS 1 MAXTRANS 1
6 /

Table created.

SQL> select table_name,INI_TRANS,MAX_TRANS from user_tables where table_name='EYGLE_ITL';

TABLE_NAME INI_TRANS MAX_TRANS
------------------------------ ---------- ----------
EYGLE_ITL 1 1

而在Oracle10g中,我们注意到MAXTRANS参数的设置已经无效:

[oracle@danaly ~]$ sqlplus eygle/eygle

SQL*Plus: Release 10.2.0.1.0 - Production on Mon Jun 26 11:59:20 2006
Copyright (c) 1982, 2005, Oracle. All rights reserved.

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, Oracle Label Security, OLAP and Data Mining Scoring Engine options

SQL> CREATE TABLE EYGLE_ITL
2 (C1 NUMBER,
3 C2 VARCHAR2(10)
4 )
5 INITRANS 1 MAXTRANS 1
6 /

Table created.

SQL> select table_name,INI_TRANS,MAX_TRANS from user_tables where table_name='EYGLE_ITL';

TABLE_NAME INI_TRANS MAX_TRANS
------------------------------ ---------- ----------
EYGLE_ITL 1 255

我们注意到，不管如何设置，最终的MAX_TRANS都是255。

查阅Oracle手册得到如下说明：

Note:In earlier releases of Oracle Database, the MAXTRANS parameter limited the number of transaction entries that could concurrently use data in a data block. This parameter has been deprecated.

Oracle Database now automatically allows up to 255 concurrent update transactions for any data block, depending on the available space in the block.
The database ignores MAXTRANS when specified by users only for new objects created when the COMPATIBLE initialization parameter is set to 10.0 or greater.

也就是说在Oracle10g中，对于单个数据块，Oracle缺省最大支持255个并发，MAXTRANS参数被废弃。

这就是网友在10g上无法模拟我的结果的原因。

总结一下：当我们想要找到一个答案时，步骤可能很简单，只需要动手，思考。懒惰是要不得的，要知道天道酬勤。

Posted by eygle at 3:25 PM | Comments (0) | TrackBack