DB2性能优化- REORG慢的分析

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了DB2性能优化- REORG慢的分析，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含3243字，纯文字阅读大概需要5分钟。

内容图文

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的速度很慢

2.       找到正在执行的语句，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 的重组耗费的时间会较长）

 

3.       去掉longlobdata, 再次REORG

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

 

 

总结：

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

1.       查看DB2的诊断日志(db2diag.log)及DB2的管理通知日志（db2inst1.nfy），看是否有报错，如果有报错信息，可根据对应的报错信息了解目前可分析的问题方向。

2.       如果数据库有报错，根据报错信息对可造成此问题的原因做出假设；如果数据库没有报错，则结合系统各项指标分析可能的原因。

3.       对做出的假设做一步步推论，论证所有可能性，并从中找出根本的原因。

DB2性能优化- REORG慢的分析

标签：数据库   DB2   

本文系统来源：http://blog.51cto.com/5063935/2074301

内容总结

以上是互联网集市为您收集整理的DB2性能优化- REORG慢的分析全部内容，希望文章能够帮你解决DB2性能优化- REORG慢的分析所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端

---