DB2 性能诊断、调优 performance
db2 list utilities show detail
display the list of active utilities to standard output on current instance;
LIST UTILITIES SHOW DETAIL Type = BACKUP Database Name = DWDB Partition Number = 16 Description = offline db Start Time = 09/17/2012 13:28:30.575198 State = Executing Invocation Type = User Throttling: Priority = Unthrottled Progress Monitoring: Estimated Percentage Complete = 1 Total Work = 747868852768 bytes Completed Work = 10738136885 bytes Start Time = 09/17/2012 13:28:30.575211
if running utilities are suspected to cause some performance, decrease the priority of the running utilities by command set util_impact_priority
db2 set util_impact_priority for 1 to 10
snapshot utility，snap_表函数，已经不再推荐，推荐用新的监控表函数sysproc.mon_get_，管理视图sysibmadm.
DB2 monitoring: Migrate from snapshot monitor interfaces to in-memory metrics monitor interfaces
http://www.ibm.com/developerworks/data/library/techarticle/dm-1407monitoring/index.html
hot index：
mon_get_index():
db2 "select T.tabschema, T.tabname,T.iid, T.index_scans, T.index_only_scans from table(mon_get_index(null,null,null)) as T"
syscat.indexes:
clusterratio, clusterfactor，表示data与index的聚集程度。有时候即使有index但不走index，跟这个有关系。
lastused,表示最近一次用到该index的时间，insert,update,delete对index的维护不会更新该时间，default是“0001-01-01”,update async within 24 hours.
pctfree:叶子页空闲的百分比，默认10%，用于将来的插入，一旦叶子页满，会进行拆页操作，高i/o,代价很大。
索引本质：B+树，平衡数，以空间换I/O
索引的目的：1、利用index提供的指针直接访问数据记录；
2、索引是有序的，可以避免排序；
3、完全索引扫描，避免访问基表；
索引并不是一定会被引用：
1、表很小，索引的代价比表扫描还高；
2、要访问表的大部分数据（>70%）,还不如表扫描；
3、索引的集聚度很低
索引的创建：
DMS,必须在建表语句中指定index所在的表空间。SMS,表和索引在同一表空间
db2advis工具推荐需要创建的index
索引的维护：
1、一个表太多的索引，维护的代价很大,每次DML都要维护一次所有的index；
2、offline reorg表时，最后阶段会rebuild索引；
3、online reorg表时，对索引进行维护，不会rebuild。
mon_get_table():
table_scans:
rows_read:
rows_updated:
rows_inserted:
rows_deleted:
overflow_accesses:
overflow_creates:
snapshot for tables to find hot table(rows returned/rows read)
syscat.tables：
status：C = Set integrity pending; N = Normarl ; X = inoperative
create_time: 表的创建时间，日常巡检，比对有没新表创建；可以间接看出数据库的创建时间；
alter_time: 表最近一次的alter时间；
stats_time: 最后一次统计信息更新时间；
invalidate_time: 最后一次invalidate时间；
lastused: 最后一次用到该table的时间，async update within 24 hours；
card: total rows;
fpages: total number of pages;
npages: total number of pages where rows resides
overflow: number of overflow records;
datacapture: N = not participate in Data Replication
Y = participate in Data Replication excluding LOB
L = participate in Data Replication including LOB
append_mode: N = insert into available space
Y = insert into the bottom of the table
===========================================================================================
合理设计表：
一、范式、反范式
第一范式：元素不可分割；
第二范式：元素不可重复；
第三范式：元素不可冗余（不可推导出）；
但是，范式仅仅从纯数据的角度考虑，没有顾及到访问数据的应用的性能问题。表与表之间的连接还是很耗资源的（cpu，i/O,memory）
反范式：
冗余（派生列）:以空间换时间；
标记字段：减少I/O，只是逻辑标记（如删除，更新状态等）
===========================================================================================
二、生产环境，不设置表与表之间的参照完整性，不使用trigger，不使用存储过程procedure，不使用特定于该DB产品的SQL技术。DB仅仅是为了存放数据，应用逻辑全部在应用层实现，便于迁移。
===========================================================================================