统计数据(1) - 收集的时机

我这边有一个这样的情况，调用存储过程出现死锁。
过程是这样的：
1、调用load命令装载数据（每次装载100万），
2、装载完用jdbc调用存储过程对装载的数据走业务处理。
当以上的过程并发有4个以上的时候（不同的任务，装载不同的目标表），调用存储过程是报死锁异常。
DB2 SQL Error: SQLCODE=-911, SQLSTATE=40001, SQLERRMC=2
请问大家有没有遇到这样的问题？收起

有点道理收起

16楼言之有理，可惜我们作为运维难以了解全部，统计数据收集本身就对DB产生一些负载，时间点难。收起

个人感觉，runstat最重要的前提是了解业务，知道这些表示干什么的，有什么使用上的特性，数据量变化的特点，然后才能有针对性的开展。一般的DBA要管理很多数据库，如果一一都要了解，确实难度很大。收起

我们都是夜里做，但有时候还是会遇到夜里调度load的情况，就很容易死锁收起

Good question, right on time.
Statistics can "bite" you if not dealing with properly收起

自动统计收集在大系统里感觉不是那么好用，还是有计划的手动收集比较好。
怎么做计划就得根据需要了。

理想状态是当数据的变化对统计有一定影响的时候就收集。
除了上面提到的LOAD外，很多操作都需要及时的进行统计收集。

增加INDEX，那么可以只对这个索引进行收集。
RUNSTATS ON TABLE TAB FOR INDEX IDX

执行REORG后，也需要统计收集。
这是因为执行REORG会影响CLUSTER状态，特别是需要使用DETAILED选项进行收集的时候。

如果20%以上的数据被更新就需要进行统计收集了。（个人经验）收起

回复 10# liuhch0709

good strategy. I like it.
auto stats 是所谓“trust IBM 的 dummy法" :P收起

auto runstats，表多了的确会出现锁系统表的情况，不过也是偶尔出现，基本是系统load很大的时候会出现.收起

我们之前是使用db2自动收集统计信息，数据量小的时候不存在太大的性能影响。但系统运行了16个月左右，由于数据量大，加之db2决定autorunstats的时间也不好预测并加以控制。所以在前端时间，出现白天业务高峰期的时候对数据量最大的几张表进行进行自动收集统计信息，且持续时间非常长！导致全省系统并发性非常低。
所以之后我们采取的策略：
1 业务涉及多的且变动最大的表（这些表每天都涉及到大量的数据插入和更新操作）进行定期手动收集，并限制允许时的资源进行限制。我们是每晚都执行这些表的统计信息收集。
2 对一些数据量大的变动小的表（比如我们业务中的个人信息表基本是1年变动一次，其他时候变动非常小），基本在每年变动大批量变动的时候，在变动的同时就直接做一个统计信息的更新。
3 对一些数据量小并且基本不变动（一般变动都是维护人员操作的变动，业务只涉及到查询的表），更新一次统计信息后就不再管了。

俺说的是我们系统的实际维护情况哈，开始数据量小的时候，我觉得使用db2的自动统计收集还不错。但数据量大了的话对性能还是很有影响的。各位大神觉得我们这方案有什么不足给指点指点哈！收起