IT其它Db2reorg

db2什么时候需要做REORG?

操作系统版本: AIX 7.1
数据库版本 : DB2 V9.7
问题:
当前使用串行REORG的脚本,维护时间需要大约8个小时;
改用并行的REORG的脚本,维护时间仍然需要大约6个小时;
恢复到使用串行的REORG脚本,并观察系统资源消耗情况,一开始REORG速度很快,但过了不久后,到达了REORG比较慢的表此时使用topas查看系统资源,发现资源消耗下降到一个较低的值,如IO吞吐量低,KBPS:5.6K。
请问,从哪些方面分析是否需要reorg,跟longlobdata有关?

参与15

2同行回答

jieapjieap项目经理杭州
什么是REORG?我们知道,数据库中有许多表的存在,而我们可能会经常地需要对表数据进行增删改等操作,经过一系列更改后,逻辑上连续的数据可能会位于不连续的物理数据页上,在许多插入操作创建了溢出记录时尤其如此。按这种方式组织数据时,数据库管理器必须执行其他读操作才能访问顺...显示全部

什么是REORG?

我们知道,数据库中有许多表的存在,而我们可能会经常地需要对表数据进行增删改等操作,经过一系列更改后,逻辑上连续的数据可能会位于不连续的物理数据页上,在许多插入操作创建了溢出记录时尤其如此。按这种方式组织数据时,数据库管理器必须执行其他读操作才能访问顺序数据。而在删除大量行后,也需要执行其他的读操作。

REORG(重组)表的操作会整理数据碎片来减少浪费的空间,并对行进行重新排序以合并溢出记录,从而加快数据访问速度并最终提高查询性能。

什么时候需要做REORG?

当数据库里某个表中的记录变化量很大时,则需要在表上做REORG操作来优化数据库性能。

针对数据库对象的大量操作,如反复地删除表,存储过程,会引起系统表中数据的频繁改变,在这种情况下,也要考虑对系统表进行REORG操作。

完整的REORG表的过程

一个完整的REORG表的过程应该是由下面的步骤组成的:

RUNSTATS -> REORGCHK -> REORG -> RUNSTATS -> BIND或REBIND

注: 执行此部分命令前需要连接数据库

此处我们就不对REORG做过多介绍,此次主要分享造成REORG慢的原因。

情景:

某电信网络发票系统每周五晚上9点开始做数据库维护,包括REORG,RUNSTAT,REBIND,维护时间需要大约10 个小时,期间会影响系统正常作业。经优化脚本生成详细维护日志,检查维护部分表的REORG时间过长。整个数据库大小为500GB。

操作系统版本:AIX 7.1

数据库版本 :DB2 V9.7

问题:

当前使用串行REORG的脚本,维护时间需要大约10个小时;

改用并行的REORG的脚本,维护时间仍然需要大约9个小时;

恢复到使用串行的REORG脚本,并观察系统资源消耗情况,一开始REORG速度很快,但过了不久后,到达了REORG比较慢的表此时使用topas查看系统资源,发现资源消耗下降到一个较低的值,如IO吞吐量:

理想的吞吐量

当前REORG 慢的吞吐量

分析:

  1. 首先查看DB2的诊断日志(db2diag.log)及DB2的管理通知日志(db2inst1.nfy),均没有发现报错;
  2. 列举有可能造成REORG时数据量低的原因

1)表空间参数限制(PREFETCH)读写速度

2)操作系统参数瓶颈

3)存储性能瓶颈

4)DB2 Bug

5)数据损坏

下一步计划方向

-操作系统

-存储

-DB2

-网络

-内存

既然我们是负责数据库的,那就先由数据库入手,

解决:

  1. 从DB2入手,监控DB2的监控进度

db2pd -d sample -reorg

观察CurCount字段增长,增长慢的话表示REORG的速度很慢

  1. 找到正在执行的语句,REORG语句db2 reorg table schema.tablename longlobdata

DB2 9.7 中表重组功能也相应做了扩充,REORG 命令多了 LONGLOBDATA 参数。LONGLOBDATA 参数只对 long 和 LOB 列有效。 默认情况下是不启用 LONGLOBDATA 的,因为对 long 和 LOB 列的重组很消耗时间。

官方说明请查看以下链接:

https://www.ibm.com/developerworks/cn/data/library/techarticles/dm-1008kongzh/index.html

我们知道DB2表普通数据和LONG/LOB数据是分开存放的,普通数据只存放有LONG/LOB的数据指针和长度,而且在处理LOB数据都是按记录逐条解析,所以REORG时按记录逐条解析就会变得很慢。(如果需要转换分开存放的 LOB 到内联的 LOB 就要使用这个参数;当表特别大时,LOB 的重组耗费的时间会较长)

  1. 去掉longlobdata, 再次REORG

REORG的时间由原来的6个小时下降到10分钟,系统吞吐量也恢复到理想状态。

总结:

这里列举一下数据库出现问题时的初步解决思路——

  1. 查看DB2的诊断日志(db2diag.log)及DB2的管理通知日志(db2inst1.nfy),看是否有报错,如果有报错信息,可根据对应的报错信息了解目前可分析的问题方向。
  2. 如果数据库有报错,根据报错信息对可造成此问题的原因做出假设;如果数据库没有报错,则结合系统各项指标分析可能的原因。
  3. 对做出的假设做一步步推论,论证所有可能性,并从中找出根本的原因。

这篇文章说的很好,你可以看看。

收起
互联网服务 · 2019-08-02
浏览7997
anikikonganikikong课题专家组数据库运维工程师中国民生银行
表和索引碎片太多才需要reorg。db2是有工具reorgchk帮你检查的。还有就是必须reorg的场景,例如增加列,扩长度,修改列类型等。没必要天天做,定期检查需要做再做。还有其他替代方案,admin move table也可以...显示全部

表和索引碎片太多才需要reorg。db2是有工具reorgchk帮你检查的。还有就是必须reorg的场景,例如增加列,扩长度,修改列类型等。没必要天天做,定期检查需要做再做。还有其他替代方案,admin move table也可以

收起
银行 · 2019-08-06

提问者

liujiacai
其它广州大厦
擅长领域: 数据库云计算服务器

相关问题

相关资料

相关文章

问题状态

  • 发布时间:2019-08-02
  • 关注会员:4 人
  • 问题浏览:9385
  • 最近回答:2019-08-06
  • X社区推广