如何调整DB2数据库性能实用技巧分享
如何调整DB2数据库性能实用技巧分享，呵呵，废话就多说了，看资料了，可能对你有有所帮助，学习咯
1.SQLCOSTANALYSIS
许多情况下，一个简单的SQL就可能让DB2系统处于尴尬的状态。调整参数也不能解决此问题。由于DBA很难去改变这些垃圾SQL的现状，所以留给DBA的就是下面的情况：
(1).Changeoraddindexes
(2).Changeclustering
(3).Changecatalogstatistics.
注：一个SQL语句的cost=每次执行的资源代价*执行的次数。
目前，DBA面临的挑战就是要找到那些有很高cost的语句，并且尽力去减少它的代价。可以借助DB2Explain工具或者DB2UDBSQLEventMonitor数据来分析SQL语句的代价。尤其是对SQLEventMonitor的数据分析，但这么做需要耗费很大的精力和时间。
一般DBA的流程是：
(1).CreateanSQLEventMonitor,writetofile:
$>db2"createeventmonitorSQLCOSTforstatementswriteto..."
(2).Activatetheeventmonitor(besureamplefreediskspaceisavailable):
$>db2"seteventmonitorSQLCOSTstate=1"
(3).Lettheapplicationrun.
(4).Deactivatetheeventmonitor:
$>db2"seteventmonitorSQLCOSTstate=0"
(5).UsetheDB2-supplieddb2evmontooltoformattherawSQLEventMonitordata(hundredsofmegabytesoffreediskspacemayberequireddependingonSQLthroughputrates):
$>db2evmon-dbDBNAME-evmSQLCOST
>sqltrace.txt
(6).Browsethroughtheformattedfilescanningforunusuallylargecostnumbers,atime-consumingprocess:
$>moresqltrace.txt
(7).Undertakeamorecompleteanalysisoftheformattedfilethatattemptstoidentifyuniquestatements(independentofliteralvalues),eachuniquestatement’sfrequency(howmanytimesitoccurred),andtheaggregateofitstotalCPU,sort,andotherresourcecosts.Suchathoroughanalysiscouldtakeaweekormoreonjusta30-minutesampleofapplicationSQLactivity.
为了以最快的速度找到相应的SQL，我们可以考虑上文讲过的一些方法：
针对第4个tip：计算每个交易从一个table里面取出的行数。如果数值很高，就可以找到相应的语句。
针对第3个tip：计算每个tablespace的asynchronousreadpercentageandphysicalI/Oreadrates.如果一个tablespace有很高的asynchronousreadpercentage和高于平均的physicalI/Oreadrates,那么有可能这个tablesapce里面有tablescan情况。从catalog中可以找寻tablespace中相应的table(如果一个tablespace上只有一个表，那么很容易定位了)，然后从SQLEventMonitor中寻找相关的table。这样也可以缩小范围。
观察DB2Explain信息，寻找可疑的地方。有时候，经常执行的、而且是代价比较低的语句也会疯狂占用系统资源！
很多时候，我们可以充分借助工具！这样能省时省力。
StayinginTune
需要特别注意的是，性能优化不能仅仅只是消除那些好的SQL语句，也要保证合理的物理构架，确保高性能的结果、内存分配在pool和heap中，I/O都在DISk之间平衡分布。
2.BUFFERPOOLOPTIMIZATION
目前一般的系统内存都可以达到2G,4G,8G了，但是DB2缺省的IBMDEFAULTBP只有16M。在此情况下，一般可以建立一个bufferpool给SYSCATSPACEcatalogtablespace,一个bufferpool给TEMPSPACEtablespace,至少两个BP_RANDandBP_SEQ.随机存取的Tablespaces应该有一个bufferpool来应付随机的objectives,这就是BP_RAND.顺序存取的Tablespaces(withasynchronousprefetchI/O)应该建立一个bufferpool给sequentialobjectives,BP_SEQ.也可以建立其它的bufferpools，这要根据应用来说。比如可以建立一个足够大的bufferpool来存放热点经常存取的数据。有时候需要为大的table建立单一的bufferpool.
太小的bufferpool会导致大量的、不必要的物理I/O。太大的bifferpool有可能会产生系统paging，增加不必要的CPU管理内存开销。
bufferpool的大与小是相对的，一个系统的bufferpool大小应该"合适的"！当达到diminishingreturn达到时，就是合适的。如果不是使用自动工具，应该有条理的测试bufferpool性能，比如命中率，I/O次数，物理I/O读的比率，直到达到合适状态。当然，应用是变化的，所以最优状态不是不边的，也是要定期的评估。
3.TABLESPACEANALYSIS
tablespacesnapshot对理解哪些数据被访问和怎么访问的有很大的价值。
db2"getsnapshotfortablespacesonDBNAME"
对每一个tablespace，要注意：
Whatistheaveragereadtime(ms)?
Whatistheaveragewritetime(ms)?
WhatpercentageofthephysicalI/Oisasynchronous(prefetched)vs.synchronous(random)?
Whatarethebufferpoolhitratiosforeachtablespace?
Howmanyphysicalpagesarebeingreadeachminute?
Howmanyphysicalandlogicalpagesarebeingreadforeachtransaction?
对所有的tablespaces,注意：
Whichtablespaceshavetheslowestreadandwritetimes?Why?
Containersonslowdisks?Arecontainersizesunequal?
AretheAccessattributes,asynchronousversussynchronousaccess,consistentwithexpectations?