BASIC压缩使用旧算法压缩直接路径加载(INSERT /*+ APPEND */ INTO x SELECT ...或CREATE TABLE x AS SELECT...或SQL Loader with DIRECT=TRUE等)上的块,不需要额外的开销。对基本压缩行的更新会导致立即解压缩和行链接,所以如果您的段得到任何更新,您真的不想使用它。由于它不压缩常规/缓冲插入,如果不是直接路径加载,它的唯一用途是重新组织(移动)已经加载的表或分区,然后压缩它,通常是为了保存空间,尽管它 * 也 * 可以 * 通过减少读取段所需的I/O来帮助在I/O吞吐量较低的非Exhibition系统上执行全表扫描(以在数据库层用于解压缩的额外CPU为代价)。
高级或OLTP压缩旨在为传入数据提供压缩,其中插入是传统的/缓冲的和分散的(例如,INSERT INTO x VALUES...)。它通过推迟压缩直到块中有足够的数据使其值得压缩来实现。它可以压缩块中由不同会话在不同时间单独插入的行,使其成为不同的算法,即使存在一些相似之处。它还保留了默认的PCTFREE 10,而不是像BASIC压缩那样将其重写为PCTFREE 0,这也会导致不同的压缩比。它的压缩比通常略低于或最多与BASIC相当。更新一个块中的多个OLTP压缩行将很快耗尽PCTFREE空间,并导致链接,因此您不希望在有大量更新的表上出现这种情况。最后,也是最有问题的,这是一个额外的成本选项,需要非常昂贵的高级压缩选项(ACO)。甲骨文的审计将是一个讨厌的惊喜,如果他们发现这一点,你还没有支付它。总的来说,我认为它的好处(这是微薄的)被它的负面影响所压倒,在这样一个高成本,它是不值得的(海事组织)。 这是一份详细讨论它的白皮书,尽管它当然是营销照明,所以有点过于积极: Advanced Compression Whitepaper 在Example中,有一组用于混合列压缩(HCC)的类型(Query Low,Query High,Archive Low,Archive High),它们在压缩单元(CU)内压缩列为主的数据,以获得比BASIC更好的压缩率。此外,更新不会立即链接-初始更新将在新块中将行迁移到OLTP,只有在同一行的第二次更新时才会发生链接。不过,对于需要大量更新的表,最好不要使用HCC压缩。以前HCC压缩只会发生在直接路径加载(像BASIC)上,但是在12.2中他们增强了它,所以任何数组插入(INSERT SELECT)都可以被压缩,即使没有使用append提示。在Example的世界中,HCC远比BASIC或OLTP更受欢迎。 总之,Oracle的所有压缩算法都是不同的,用于不同的目的,并且可以预期产生不同的压缩比。测试你的数据(足够多的数据,比如至少一百万行)是确定每个选项将如何执行的唯一方法。如果你想更深入地挖掘并进入杂草,你总是可以用相同的数据对不同压缩的块进行块转储,并比较数据如何存储在每个块中。
----
Number of blocks used (compressed) : 640
Number of blocks used (uncompressed) : 1408
Number of rows in a block (compressed) : 203
Number of rows in a block (uncompressed) : 92
Compression ratio : 2.2
Compression type : "Compress Advanced"
----
Number of blocks used (compressed) : 1583
Number of blocks used (uncompressed) : 10837
Number of rows in a block (compressed) : 632
Number of rows in a block (uncompressed) : 92
Compression ratio : 6.8
Compression type : "Compress Query High"
----
Number of blocks used (compressed) : 2611
Number of blocks used (uncompressed) : 10837
Number of rows in a block (compressed) : 383
Number of rows in a block (uncompressed) : 92
Compression ratio : 4.1
Compression type : "Compress Query Low"
----
Number of blocks used (compressed) : 1560
Number of blocks used (uncompressed) : 10837
Number of rows in a block (compressed) : 641
Number of rows in a block (uncompressed) : 92
Compression ratio : 6.9
Compression type : "Compress Archive High"
----
Number of blocks used (compressed) : 1501
Number of blocks used (uncompressed) : 10837
Number of rows in a block (compressed) : 666
Number of rows in a block (uncompressed) : 92
Compression ratio : 7.2
Compression type : "Compress Archive Low"
----
2条答案
按热度按时间bpzcxfmw1#
BASIC压缩使用旧算法压缩直接路径加载(
INSERT /*+ APPEND */ INTO x SELECT ...
或CREATE TABLE x AS SELECT...
或SQL Loader withDIRECT=TRUE
等)上的块,不需要额外的开销。对基本压缩行的更新会导致立即解压缩和行链接,所以如果您的段得到任何更新,您真的不想使用它。由于它不压缩常规/缓冲插入,如果不是直接路径加载,它的唯一用途是重新组织(移动)已经加载的表或分区,然后压缩它,通常是为了保存空间,尽管它 * 也 * 可以 * 通过减少读取段所需的I/O来帮助在I/O吞吐量较低的非Exhibition系统上执行全表扫描(以在数据库层用于解压缩的额外CPU为代价)。高级或OLTP压缩旨在为传入数据提供压缩,其中插入是传统的/缓冲的和分散的(例如,
INSERT INTO x VALUES...
)。它通过推迟压缩直到块中有足够的数据使其值得压缩来实现。它可以压缩块中由不同会话在不同时间单独插入的行,使其成为不同的算法,即使存在一些相似之处。它还保留了默认的PCTFREE 10
,而不是像BASIC压缩那样将其重写为PCTFREE 0
,这也会导致不同的压缩比。它的压缩比通常略低于或最多与BASIC相当。更新一个块中的多个OLTP压缩行将很快耗尽PCTFREE空间,并导致链接,因此您不希望在有大量更新的表上出现这种情况。最后,也是最有问题的,这是一个额外的成本选项,需要非常昂贵的高级压缩选项(ACO)。甲骨文的审计将是一个讨厌的惊喜,如果他们发现这一点,你还没有支付它。总的来说,我认为它的好处(这是微薄的)被它的负面影响所压倒,在这样一个高成本,它是不值得的(海事组织)。这是一份详细讨论它的白皮书,尽管它当然是营销照明,所以有点过于积极:
Advanced Compression Whitepaper
在Example中,有一组用于混合列压缩(HCC)的类型(Query Low,Query High,Archive Low,Archive High),它们在压缩单元(CU)内压缩列为主的数据,以获得比BASIC更好的压缩率。此外,更新不会立即链接-初始更新将在新块中将行迁移到OLTP,只有在同一行的第二次更新时才会发生链接。不过,对于需要大量更新的表,最好不要使用HCC压缩。以前HCC压缩只会发生在直接路径加载(像BASIC)上,但是在12.2中他们增强了它,所以任何数组插入(
INSERT SELECT
)都可以被压缩,即使没有使用append提示。在Example的世界中,HCC远比BASIC或OLTP更受欢迎。总之,Oracle的所有压缩算法都是不同的,用于不同的目的,并且可以预期产生不同的压缩比。测试你的数据(足够多的数据,比如至少一百万行)是确定每个选项将如何执行的唯一方法。如果你想更深入地挖掘并进入杂草,你总是可以用相同的数据对不同压缩的块进行块转储,并比较数据如何存储在每个块中。
zwghvu4y2#
您可以使用
DBMS_COMPRESSION.GET_COMPRESSION_RATIO
过程估计压缩比,如下所示:DBMS_COMPRESSION.GET_COMPRESSION_RATIO
不支持DBMS_COMPRESSION.COMP_BASIC
。您可以手动压缩表/分区并比较大小。这里有一个示例结果:
您获得的压缩比取决于表中的数据结构。行或列中是否有许多不同的值,这也取决于数据类型。