之前写过的一篇 Linux/ext3：DB2扩展表空间导致的Latch等待现象1
那次是表空间扩容导致的SQLO_LT_SQLB_POOL_CB__readLotch latch等待，那属于正常现象。
最近遇到了缩表空间也出现类似现象，后面再难以重现了，只重现过一次。 正常情况下表空间缩容是很快的（如果高水位已经降下来了）。问题的现象如下：
1. 发出 "alter tablespace xx reduce max"之后，表空间状态立即变成 0x10080000，即 Move in Progress + DMS Rebalance in Progress，而且持续很久。 【正常缩容的话，表空间只是 Move in progress， 并不会在 Rebalance in progress持续太久。】
2. 真正的缩容线程是在后台执行的，这期间一直占用一个latch： SQLO_LT_SQLB_POOL_CB__readLotch。
3. 其他的监控函数，比如mon_get_database()，会由于等待 SQLO_LT_SQLB_POOL_CB__readLotch 而HANG住。
4. 其中latch holder（即缩容线程）的stack如下：
<StackTrace>
ftruncate
sqloSetFileSize
_Z21sqlbPostRebalanceWorkP12SQLB_POOL_CBPK9SQLP_LSN8P12SQLB_GLOBALSbb
_Z16sqlbAlterPoolActtP9SQLP_LSN8P12SQLB_GLOBALS
_Z8sqldmpndP8sqeAgentiPcP9SQLP_LSN8PmP15SQLD_RECOV_INFO
_Z8sqlptpplP8sqeAgenti
_Z8sqlpxcm1P8sqeAgentP15SQLXA_CALL_INFOi
_Z12sqlrrcom_dpsP8sqlrr_cbiiP15SQLXA_CALL_INFO
_Z8sqlrrcomP8sqlrr_cbii
_Z22sqlbEMReduceContainersP12SQLB_POOL_CBjP9sqeBsuEdu
_Z22sqlbLockAndMoveExtentsP12SQLB_POOL_CBbjP9sqeBsuEdu
_Z28sqlbExtentMovementEntryPointP9sqeBsuEduPv
_Z26sqleIndCoordProcessRequestP8sqeAgent
_ZN8sqeAgent6RunEDUEv
_ZN9sqzEDUObj9EDUDriverEv
sqloEDUEntry
clone
</StackTrace>
..
<LatchInformation>
Holding Latch type: (SQLO_LT_SQLB_POOL_CB__readLotch) - Address: (0x7fd86402ffa0), Line: 5598, File: /view/db2_v105fp8_linuxamd64_s160901_special_37374/vbs/engn/include/sqlbistorage_inlines.h HoldCount: 1
Holding Latch type: (SQLO_LT_preventSuspendIOLotch) - Address: (0x202647c28), Line: 14789, File: sqlbpool.C HoldCount: 1
Holding Latch type: (SQLO_LT_SQLB_POOL_CB__ptfLotch) - Address: (0x7fd864028fa0), Line: 1157, File: sqlbptf.C HoldCount: 1
</LatchInformation>5. 其中一个 Latch waiter 的stack如下，它当时正在运行mon_get_database():
<StackTrace>
semop
_ZN17SQLO_SLATCH_CAS6418getConflictComplexEm
_ZN17SQLO_SLATCH_CAS6411getConflictEm
_Z21sqlbLatchPoolR_inlineP12SQLB_POOL_CBibiPKc
_ZN31sqlrwFilteredTablespaceIterator7executeEv
_Z23sqlrwGetDatabaseMetricsP8sqlrr_cbPPvPl
_Z30sqlrwGetWLMTableFunctionResultP8sqlrr_cbP20sqlrw_rpc_tf_requestPPvPlb
_Z36sqlrwGetWLMTableFunctionMergedResultjPPv
_Z29sqlerTrustedRtnCallbackRouterjPPv
monGetDatabase_v105fp4
sqloInvokeFnArgs
_Z19sqlriInvokerTrustedP10sqlri_ufobP21sqlriRoutineErrorIntfb
_Z18sqlriInvokeInvokerP10sqlri_ufobb
_Z8sqlriutfP8sqlrr_cb
_Z11sqlri_tfopnP8sqlrr_cbP9sqlri_tao
_Z8sqlriopnP8sqlrr_cbP9sqlri_taoPi
_Z7sqlritaP8sqlrr_cb
_Z15sqlriSectInvokeP8sqlrr_cbP12sqlri_opparm
_Z27sqlrr_process_fetch_requestP14db2UCinterface
_Z10sqlrr_openP14db2UCinterfaceP15db2UCCursorInfo
_Z16sqljs_ddm_opnqryP14db2UCinterfaceP13sqljDDMObject
_Z21sqljsParseRdbAccessedP13sqljsDrdaAsCbP13sqljDDMObjectP14db2UCinterface
_Z10sqljsParseP13sqljsDrdaAsCbP14db2UCinterfaceP8sqeAgentb
_Z17sqljsDrdaAsDriverP18SQLCC_INITSTRUCT_T
_ZN8sqeAgent6RunEDUEv
_ZN9sqzEDUObj9EDUDriverEv
sqloEDUEntry
clone
</StackTrace>
<LatchInformation>
Waiting on latch type: (SQLO_LT_SQLB_POOL_CB__readLotch) - Address: (0x7fd86402ffa0), Line: 11499, File: sqlrw_wlm_tf.C
Holding Latch type: (SQLO_LT_SQLB_RuntimeBPDefs__rtBPLatch) - Address: (0x7fd86321ddc0), Line: 24104, File: sqlrw_wlm_tf.C HoldCount: 1
Holding Latch type: (SQLO_LT_SQLB_PTBL__pool_table_latch) - Address: (0x7fd79f1706f0), Line: 2941, File: /view/db2_v105fp8_linuxamd64_s160901_special_37374/vbs/engn/include/sqlbistorage_inlines.h HoldCount: 1
</LatchInformation>原因：
根据stack，IBM认为是卡在了操作系统函数ftruncate上，但SUSE认为这个函数正常情况下应该很快，ftruncate函数只是修改文件的属性，并不会实际操作文件的内容，所以，其执行速度理论上将和文件大小的关系不大。
但是，在实际操作中，目标文件往往是活动数据，可能会有其他程序的占用等情况，这一般会导致ftruncate执行中的lock检查不能通过，需要等待。并且，一般文件越大，可能的占用或者受到其他文件目录操作的影响就更大，所以，实际操作中，经常会表现为，文件越大，可能操作时间越长。
而如果是一个独立的文件系统（没有其他访问）上的一个文件进行ftruncate，则文件的实际大小对操作的影响几乎可以忽略了。
结论：
无结论，表空间缩容在业务量较大的系统上，还是每次缩一点吧。