3、数据查询

　　为了比较不同条件下的查询结果，我们进行了4种组合的查询。分别是：单进程不压缩，并行不压缩，单进程压缩，并行压缩，每种测试做2遍，取较快的一遍的结果。

--用来压缩表的语句，并行参数可加快速度，但并不改变被move的表的并行度
alter table CUSTOMER move compress parallel 32;
alter table LINEITEM move compress parallel 32;
alter table NATION move compress parallel 32;
alter table ORDERS move compress parallel 32;
alter table PART move compress parallel 32;
alter table PARTSUPP move compress parallel 32;
alter table REGION move compress parallel 32;
alter table SUPPLIER move compress parallel 32;

--压缩前字节数
SQL> set numw 20
SQL> select segment_name,sum(bytes) from user_segments where segment_name not like '%EXT%' group by segment_name order by 1;

SEGMENT_NAME                 SUM(BYTES)
------------------ --------------------
CUSTOMER                      281804800
LINEITEM                     7730102272
NATION                            65536
ORDERS                       1874067456
PART                          278986752
PARTSUPP                     1367867392
REGION                            65536
SUPPLIER                       16646144

--压缩后
SEGMENT_NAME                  SUM(BYTES)
------------------- --------------------
CUSTOMER                       248643584
LINEITEM                      5389484032
NATION                             65536
ORDERS                        1566310400
PART                           207290368
PARTSUPP                      1251344384
REGION                             65536
SUPPLIER                        17301504

 　　从上面表的占用空间可见，对于tpc-h数据，因为dbgen生成的数据比较随机，又是符合第3范式的，冗余较少，Oracle压缩的效果不太明显。节约的I/O有限,像SUPPLIER表大小反而增加了，还增加了解压的负担。

　　下面是各组查询测试结果：

▲表1 TPC-H cale=10未压缩和压缩数据的测试对比，单位：秒

　　可见无论是否压缩，并行查询比单进程都有几倍或十几倍的提高，具体提高的倍数和查询的类型和机器的CPU个数有关。用来测试的机器有8个逻辑CPU,在不压缩的情况下能提高大约5倍，在压缩的情况下，单进程的性能比不压缩更差，所以光看提高的倍数是不够的，还要看查询的实际时间比。

　　从上述数据我们还可以得出单进程和并行分别查询压缩和非压缩数据的差异：

▲表2 TPC-H scale=10压缩前后数据的测试对比，单位：倍

　　如上表所示，从合计时间看，单进程压缩比不压缩反而速度降低了20%，而并行条件下，则有30%的性能提高。从单个查询看，压缩和不压缩互有胜负，这跟前面我们列出的压缩文件大小有关，如果I/O没有变化或者更大，那么加上解压开销，查询速度下降也是必然的。