xu5762173

[i=s] 本帖最后由 xu5762173 于 2016-5-31 15:13 编辑 重组分区表REORG TABLE tabname [ALLOW NO/READ ACCESS] [ON DATA PARTITION partname]REORG INDEXESALL FOR TABLE tabname [ALLOWNO/READ/WRITE ACCESS] [ON

IBM可能把db2在中国的一线支持卖给浪潮, 浪潮能做的就像现在很多oracle的服务提供商一样, level 1支持最终用户, 搞不定的还是得找ibm的二线三线.中国企业想完全接手db2,was等,目前国内企业没有那么强的能力, 一个软

表的数据部分和索引部分可以放到不同页大小的表空间上.迁移到新建的表空间从9.7开始可以使用ADMIN_MOVE_TABLE第一种 提供目标表的数据,索引和大对象的表空间名call sysproc.admin_move_table('DB2INSTT','TAB1','DAT

回复 zhenda 连续两次去查询相同的操作时,buffpool中已经有第一次的数据了, 所以第二次会很快. 使用过程中有感觉db2batch很不靠谱么?

LS正解,之前的公司就所有系统都买了1颗cpu的license,但都是几十颗cpu在跑,这事IBM团队都知道

恩,I/O确实存在问题,接手这套系统的时候已经跑了五六年,规划之初客户就把很多高访问的容器堆在两个riad10上,日志也都在这上面. 上面batch抓出来的信息是在每周最繁忙的时候,这个时候汇总大量数据,这一块确实有调优

回复 mdkii mkdii您好, 现在发现,很多表连接都有这个问题select t1.c1,t2.c1 from t1,t2 where t1.c2=t2.c2 and t1.c3=t2.c3 and t2.c4='aaa' 类似这样的SQL,t1和t2连接时多于一个条件,t2有本地谓词t1都走表扫

回复 topicis 用死锁时间监控器找出SQL,再跟开发人员探讨

回复 drdb2 OK,I'll find all sqls about this table , and try to eliminate them in test environment. Thank you

是的,IO瓶颈是正确的. 这是周五下午的统计,同步结算等操作大量堆积.主要集中在两个raid10上,8块磁盘上