ASP源码.NET源码PHP源码JSP源码JAVA源码DELPHI源码PB源码VC源码VB源码Android源码
当前位置:首页 >> 数据库 >> DB2 >> DB2进行压缩的最佳实践

DB2进行压缩的最佳实践

来源:网络整理     时间:2017-03-16     关键词:

本篇文章主要介绍了" DB2进行压缩的最佳实践",主要涉及到方面的内容,对于DB2感兴趣的同学可以参考一下: 内容提要这篇文章的目的是交流使用 DB2 的深度压缩解决方案的最佳实践。这个最佳实践允许你使用更少的数据面页来存储数据。数据库压缩的好处是:使用更少的存储存储以...

内容提要
这篇文章的目的是交流使用 DB2 的深度压缩解决方案的最佳实践。这个最佳实践允许你使用更少的数据面页来存储数据。数据库压缩的好处是:
使用更少的存储
存储以更低的速度被消耗
根据你的环境,有可能提高性能。
本文也提到了行压缩是如何适应更大的压缩策略背景的,包括值压缩和备份压缩。这里会讨论包括什么时候,在使用或不使用自动创建字典(ADC)DB2 9.5 功能情况下对行压缩实施最佳实践。一些 IBM 客户正在使用深度压缩功能,并且这些最佳实践已经使数据库体积的减小幅度达到过 50 个百分点,响应时间也提高了 20 个百分点。
总结的最佳实践:
评估压缩率以判断应该压缩哪张表
使用离线表重组来创建一个压缩字典并压缩整张表
除非必要,否则不要在表重组的时候集群数据
通过自动创建字典来减少使用表重组
把大型表迁移到一个压缩格式
控制压缩表的增长
监控并测量行压缩的有效性
释放已分配的表空间
压缩简介
压缩一张表有两个步骤。第一步是让一张表符合压缩条件,这由创建或更改一张表时使用 COMPRESS YES 子句完成。第二步是对要压缩的表的值建立一个字典。根据你使用的 DB2 版本,压缩字典有不同的含义。
一旦这两个条件达到,存储在这张表中的数据就可以被压缩。
每个表对象都有它自己的压缩字典。这意味着压缩字典是为每个数据分区创建的(无论是表分区或数据库分区)。结果就是,DB2 产品可以适应变化的数据就像你转入一个新分区。压缩是依赖于特定分区数据的。
建立压缩字典
基于你使用的 DB2 产品版本的级别来建立压缩字典有不同的方法:
DB2 9.1:主要方法是通过重组表。第二种方法是通过使用 INSPECT 实用工具,你可以在线创建压缩字典。
DB2 9.5:主要方法是通过数据来填充表。一旦表拥有了足够的数据,在表增加到 1-2 兆字节,就会自动创建字典。另外一种创建压缩字典的方法是通过 LOAD REPLACE 命令。
考虑在什么时候使用压缩的条件
你需要检查你的数据库以判断在这个数据库中的哪张表可以作为压缩的候选者。数据压缩最初是节约存储(在现有未压缩表上)和优化未来存储增长。你可以在数据库里的表上,在你希望随着时间增长的表上找到存储的“痛点”,或者二者皆有。 自然,最大的表很容易作为进行压缩的候选,但是也不要忽视小表。如果你有成百上千个小表,你或可能会体会到对大量小表进行压缩得到的总的效果带来的好处。“大”和“小”表的条件是:你的数据库设计将决定上万张表或者几百万行是“大”或“小”。
你应该考虑这张表中数据的典型行为。只读的表很适合压缩。如果表只有少数更新也可以是很好的候选。那些经过大量更改和操作的表可能不适合压缩。请考虑使用一个测试环境来对如何对候选表进行压缩运行基准测试。
低于 100KB 的小表可能不适合压缩,因为有可能节省的空间或许不能抵消压缩字典的存储需求。
一旦你决定了数据库中的哪张表适合行压缩,你应该决定每张表将使用什么方式来进行数据压缩。
在数据库中,以下表不能被压缩:
编目表
声明的全局临时表
系统临时表
行压缩和表数据复制不兼容。也就是说你不能在使用 DATA CAPTURE CHANGES 子句的同时使用 COMPRESS YES 子句。
行压缩只适用于行数据存储。这个意思是数据不是直接存储在数据行中的将不能被压缩:
索引
PureXML 是存在单独的对象中的 - XML 数据不能被压缩(除非 INLINE LENGTH 子句被使用并且 XML 数据足够小在一行数据中能容纳)
LOBs 是存储在单独的对象中 – LOB 数据不能被压缩
LONGs 也是存储在一个单独的对象中 – LONG 数据不能被压缩
一张表上的平均未压缩行大小对数据库设计使用大行标识符(RIDs)来说非常重要。普通 RIDs 在一个页上有 256 行的限制。这个页面限制在启用了压缩后很容易达到。 使用大 RIDs 让一张表中允许更多被压缩的行。同样的大 RIDs 也允许表变得更大。
复杂的查询倾向于顺序的操作行。有了行压缩,每个页面可以容纳更多的行。因此在进行了数据压缩的数据库的查询的工负载在访问相同的数据量的时候只需要比以前更少的 I/Os 。对于以离散的形式查询的数据,由于结果集只有很少的行(就像一个 OLTP 系统),压缩的效果就可能并不很好。
行压缩在受到 I/O 限制的环境中运行最佳,这个环境有空闲 CPU 周期并且可以被用来对行执行压缩以及解压。此功能在有复杂 select 查询 DSS 工作负载(I/O 查询大多数是顺序并有规律)下工作得非常好。
执行压缩操作,用户数据在 INSERT 和 DELETE 操作后产生的结果写入日志的记录很少。但是在压缩后一些 UPDATE 日志记录却可能比压缩前要大很多。当一个压缩后的行被更新的时候,就算解压后的记录长度没有变化,压缩后也可能发生变化。一个不同数字符号可能用于表示行更新后的版本。你也可以最小化日志压缩。 那些经常更新的列应该集中并存放在一起(见 http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/topic/com.ibm.db2.luw.admin.dbobj.doc/doc/c0024496.html)。
评估压缩率
在压缩表数据之前,你可以使用 INSPECT ROWCOMPESTIMATE 实用工具来对每个候选表评估节约存储的好处。当你运行这个实用工具并且只希望评估而并不真正创建压缩字典,这张表不该被允许压缩。也就是说,这张表应该已经在创建时设置或之后更改为 COMPRESS NO(这是创建表时的默认值)。在运行 INSPECT 实用工具之前,表中必须有数据。如果表已经启用了压缩功能,那么运行 INSPECT ROWCOMPESTIMATE 实用工具完成已评估的存储节约并建立一个放置在表中的压缩字典。关于这个创建压缩字典的方法将在后面讨论。
对于还没有启用压缩的表,运行 INSPECT 实用工具来评估的压缩率。
DB2 INSPECT ROWCOMPESTIMATE TABLE NAME table_name RESULTS KEEP file_name 
然后运行命令:
db2inspf file_name output_file_name 
这个命令转换检查结果的二进制输出文件到一个叫 output_file_name 的可读的文本文件。这个文件包含使用行压缩页面节约的百分比的评估结果。
如果你使用一个现有表,DB2 9.5 产品有一个方法使用管理函数来评估压缩节约。为了在一个没有压缩过的现有表上判断行压缩的好处,又可以使用这个 SQL 语句:
SELECT * FROM TABLE
(SYSPROC.ADMIN_GET_TAB_COMPRESS_INFO( ‘ schema ’ , ‘ table_name ’ , ‘ mode’ )) AS T 
在这个 SQL 语句中,模式可以是 REPORT 或 ESTIMATE 。
使用 REPORT,你可以查看在创建压缩字典时的信息。如果表没有压缩字典,这个模式将不可用。这些信息也包括压缩节约的页面数目、什么时候创建压缩字典、用什么方法来创建压缩字典、平均行压缩率以及其他的信息。
使用 ESTIMATE 同样可以提供 REPORT 模式提供的信息,不过如果你继续进行行压缩,这张表中的数据也被抽样以了解有多少数据将被压缩。由于数据会被添加和更改,使用 RUNSTATS 和 ESTIMATE 模式是评估压缩影响的好办法。
可以对当前模式中的特定表的 ESTMATE 模式使用 SQL 管理函数 ADMIN_GET_TAB_COMPRESS_INFO 。 通过指定,你可以缩短在表上收集信息所需要的时间并限制使用的系统资源。如果你在运行 SQL 语句的时候没有包含‘表名’,那么将对这个模式下面的所有的表都进行压缩评估。如果你同时省略了模式和‘表名’,你将得到对整个数据库中的所有表的压缩评估。
这个 SQL 语句是用来判断压缩哪张表的好方法。你可以在某个特定模式下的所有表中选择表名以及节约页面的百分比。然后对节约页面的百分比用 ORDER BY 子句来找出从压缩中受益最多的表。如果你把这各表函数和 SYSCAT.TABLES 编目表进行连接,然后用增加的‘ npages ’值乘这张表所在的表空间的 PAGESIZE,再乘节约的百分比,最后你就可以计算出使用压缩节约出来的 gigabytes 数。你应该也看到了表的存储将会从压缩中得到最大的节约。
压缩使用表重组
一旦你决定了要压缩某个现有表,一个方法是对表启用压缩然后使用表重组命令来建立压缩字典。 当一个压缩字典建立好以后,及那个从实用程序堆中分配一个 10MB 在临时缓存里的空间,用于保存这个运算法则用于创建压缩字典的样本数据。
在重组、创建压缩字典时数据压缩也同时完成,这个过程中表处于离线状态。
表中的所有数据行都可以成为创建压缩字典的样本。在压缩之前,表的现有数据应该可以代表将在之后整个生命周期中插入的所有数据。
REORG TABLE 命令中添加了两个新的关键字,以使创建压缩字典变得更加容易了。默认关键字 KEPPDICTIONARY 用于检查用于判断这张表中是否已经有一个字典存在。如果压缩字典已经存在,它将在重组数据的时候被使用。如果不存在一个字典,就创建一个。如果没有字典存在,RESETDICTIONARY 关键字是指示创建一个新的压缩字典,如果有一个就覆盖它。
一旦表启用了压缩并通过重组表创来建了压缩字典,这张表中所有的数据都会被压缩而且从现在开始所有插入的数据也都将被压缩。
除非万不得已不要在重组数据过程中进行数据集群
使用 scan-sort 类型的 REORG 比使用 index-scan 类型的 REORG 创建压缩字典要更有效。此外,根据测试。当有相似的数据时,在对数据表的 10% 数据建立压缩字典的压缩率和对所有数据建立压缩表的压缩率是差不多的。
要是你想重组你的数据库并通过特定的索引来 re-cluster 它,你可以在一张表上运行应用了 scan-sort 或 index-scan 方法的完整 REORG 。在 REORG 命令中指定了一个索引的情况下,数据库管理器就已经默认使用 scan-sort 方法。这会进行表扫描并在内存中对结果排序(尽管有可能通过一个临时表空间溢出到磁盘)。 Index-scan REORG 方法需要显式的指定 INDEXSCAN 关键字;它不会排序,因为他是按照索引的顺序。然而,index-scan 方法需要对这张表在临时表空间中创建一个影子复制,并为索引中

以上就介绍了 DB2进行压缩的最佳实践,包括了方面的内容,希望对DB2有兴趣的朋友有所帮助。

本文网址链接:http://www.codes51.com/article/detail_4222699.html

相关图片

相关文章