最近处理的一个案例，问题是在线备份显著慢。
看了下db2diag.log里面的backup性能统计信息， 发现发现备份时间主要来至于最大表空间bm用于I/O时间， 也就是bm从容器读数据的时间：
备注： 怎样看backup性能统计信息，可以参考这个文档
https://www.ibm.com/developerworks/community/blogs/DB2PerfTips/entry/backup_statistics?lang=en
初步断定表空间IO读存在瓶颈， 期间甚至怀疑过表空间有大量碎片导致IO瓶颈：
http://www-01.ibm.com/support/docview.wss?uid=swg21678274
后来又收集了一把堆栈信息(db2pd -stack all), 有如下发现：
1） 负责读最大表空间的是 db2bm.658129.0， 它的 5个stack里面有 4个在等SQLO_LT_SQLB_POOL_CB__readLotch，还有一个在做I/O read:
2）SQLO_LT_SQLB_POOL_CB__readLotch 的所有者一般是page cleaner, page cleaner 有50%的stack要么在等AIO, 要么在等SQLO_LT_SQLB_POOL_CB__readLotch（所有者是别的page cleaner）
分析到这里，基本已经可以明确AIO性能存在问题，导致bm与page cleaner的latch争用，从而导致在线备份慢。
AIX实现AIO有两种方式：
1. 通过AIO collectors， 即通过调用 aio_nwait() collects completed I/O requests for ALL threads in the same process，page cleaner的call stack 大概会是：
sqloLioCollectNBlocks
-> sqloLioAIOCollect
-> sqloWaitEDUWaitPost
2. 通过IOCP, 使用 I/O completion ports to capture results of various AIO operations，page cleaner的call stack 大概会是：
sqloLioCollectNBlocks
-> sqloLioAIOCollect
-> sqloGetMultipleCompletionStatus
(会调 AIX function GetQueuedCompletionStatus）
AIO collector是一种古老的，低效率的AIO方式， 除非有特殊原因，我们建议使用iocp方式。 要使用iocp, 首先得在AIX层级配置好iocp：
相关文档：
https://www.ibm.com/support/knowledgecenter/zh/SSEPGG_11.1.0/com.ibm.db2.luw.admin.perf.doc/doc/t0054518.html
AIX 没开iocp 的话，db2会用AIO collectors， 如果开了iocp, Db2会默认使用iocp。检查了系统配置，发现iocp确认在AIX已经打开，那为什么还在用AIO collectors呢（从下面stack红色部分确认的）？
最后发现没有用iocp是因为有这个设置： DB2_USE_IOCP=OFF
$ db2set -all
[i] DB2_ENABLE_THREAD_UNLOCK_EXTENDED=YES
[i] DB2_HADR_ROS=ON
[i] DB2_USE_IOCP=OFF <---!!
在AIX/Db2较老版本（5.x, 6.x 10.1及更老）， 存在一些AIX/Db2的APAR导致使用iocp出现一些问题，所以那时候通过DB2_USE_IOCP=OFF关闭iocp的使用。而后面升级了AIX 和 Db2，也就忘了把这个开关去掉了。其实， 对于Db2 10.5及以上， AIX 7.x， 我们是建议使用IOCP的。
根据我的经验， database snapshot里面如果 “Buffer pool data writes ” 和 "Asynchronous pool data page writes" 相差较多， 那么使用iocp 有助于 page cleaner 性能。
