由于银行业每年都需要进行年终决算，为了保证跨年当晚顺利完成决算，在年终决算之前都会有例行的数据库优化操作。目前行里业务的高速发展，数据积累较快。前几年使用例行数据库优化方案已经不完全适合新的形势但是今年这次优化也采取用了往年的操作步骤：当天为完成优化的需手动kill掉优化进程并force掉数据库进程。最后执行db2 "select distinct status from syscat.tables"查询数据库系统表检查是否所有表的状态正常，与预期的一样所有的表状态都是Normal，下班
就走人了。谁知道晚上批量时由于该表无法访问最终导致批量失败，造成严重的生产事故。为此笔者耿耿于怀了一整天~
那么到底是什么原因导致了批量失败呢?那又为什么之前几年均按照同样的方案操作都没有问题今年优化时却出现问题了呢？带着这个Problem，我周六一早就赶到公司针对这个问题，在测试环境进行了复现。研究表明reorg其实是分阶段进行的，如果你在index recreate阶段强制force掉该操作，那么会导致重建索引失败。而之前之所以没问题是因为数据量小，在索引重建失败后，一旦有业务来访问该表，他会首先给表加Z锁然后重建索引，重建完成后就可以允许正常业务访问。So这在数据量小的时候所有问题并不是问题，唯一的表象也就是应用在第一次访问时慢了而已。但是在海量数据的情况下显然会出现重大问题，由于我们优化的这个表目前存量数据约30亿条数据，当我们对其重建索引时采取force显然太过于经验主义了。因为当我们对重建索引失败的表进行访问时，他再次做重建索引的这项操作操作可能会历时数小时，这显然大大超过了批量维护窗口的时间限制，从而导致产生事故。
所以为了让广大博友不再犯像我类似的低级错误所以才有了此博文，同时也暴露了笔者的经验主义思维严重、学艺不精。那么下面我们就来彻底了解一下db2在做reorg操作时都是需要做哪些工作吧！
根据IBM官网介绍，我们在发出reorg命令时db2会经历Sort、Build、Replace IdxRecreate等4个阶段。
1、其中build阶段，使用表空间中空余空间（或指定表空间）临时生成一个表进行表的重组，即使中断也不会对原有表或索引产生影响；
2、replace阶段，也就是替换原表阶段是无法认为手工中断的，即使在此阶段发出了中断命令（CTRL+C）也对等此步骤完成后，索引未重创前才中断，此时会明确告诉用户索引未创建。
3、idxrecreate阶段，可以手工，同时明确告诉用户索引未创建。
我们可以通过以下手段监控reorg进度：
db2 get snapshot for tables on cbusdb|grep -ip tabname
db2pd -d cbusdb -utilities
以上完~~
另附一下近期遇到的一个小问题：关于数据insert性能提升的方法
1. 去除索引。
2. 去除约束。
3. 在 insert 语句中包括多行。
4. 采用 Append 模式
5. 屏蔽表的日志操作。
6. 采用并行写操作。
7. 采用严格的隔离级别
阅读(7245) | 评论(0) | 转发(0) |
