Db2性能问题：临时表空间太大，导致连不上数据库
问题现象：
某Db2系统经常出现连不上数据库的情况（连库一直HANG住），过一段时间自己就好了。期间观察到有latch现象。于是收集了db2pd -latch和db2pd -stack all的数据。
数据分析：
1. 首先查看latch wait现象，有109个应用在等SQLO_LT_sqeLocalDatabase__dblatch，这个latch是连库所必须的, 就是因为等这个latch，所以连不上库：
qingsong@db2a:~$ grep -i SQLO_LT_sqeLocalDatabase__dblatch latch.out | wc -l
109
等这个latch的应用的stack显示在尝试连库：
<StackTrace>
-------Frame------ ------Function + Offset------
0x09000000078484FC sqloXlatchConflict + 0x70
0x09000000078486C0 sqloXlatchConflict@glue1AA + 0x78
0x0900000007A56F48 Start UsingLocalDatabase__8sqeDBMgrFP8SQLE_BWAP8sqeAgentRccP8sqlo_gmt + 0xC6C
0x0900000007A53510 AppStartUsing__14sqeApplicationFP8SQLE_BWAP8sqeAgentcT3P5sqlcaPc + 0x17C
0x0900000007A8B460 AppLocalStart__14sqeApplicationFP14db2UCinterface + 0x49C
0x0900000007994828 sqlelostWrp__FP14db2UCinterface + 0x3C
0x09000000079948D8 sqleUC engnInit__FP14db2UCinterfaceUs + 0x60
0x0900000007A94D80 sqleUC agentConnect + 0x2A8
0x0900000007A96294 sqljs ConnectAttach__FP13sqljsDrdaAsCbP14db2UCinterface + 0x104
0x0900000007A958E4 sqljs_ddm_accsec__FP14db2UCinterfaceP13sqljDDMObject + 0x340
0x0900000007A9550C sqljsParseConnect__FP13sqljsDrdaAsCbP13sqljDDMObjectP14db2UCinterface + 0x50
0x0900000007A95450 .sqljsParse.fdpr.clone.0__FP13sqljsDrdaAsCbP14db2UCinterfaceP8sqeAgentb + 0x1C
0x0900000007940BA4 @63@sqljsSqlam__FP14db2UCinterfaceP8sqeAgentb + 0x2D4
0x0900000007ACF5DC @63@sqljsDriveRequests__FP8sqeAgentP14db2UCconHandle + 0xB4
0x0900000007ACF290 @63@sqljsDrdaAsInnerDriver__FP18SQLCC_INITSTRUCT_Tb + 0x2D0
0x0900000007ACED1C sqljsDrdaAsDriver__FP18SQLCC_INITSTRUCT_T + 0x100
0x0900000007796D1C RunEDU__8sqeAgentFv + 0x2F4
0x0900000007793418 EDUDriver__9sqzEDUObjFv + 0xF4
0x090000000778A1CC sqloEDUEntry + 0x264
</StackTrace>
<LatchInformation>
Waiting on latch type: (SQLO_LT_sqeLocalDatabase__dblatch) - Address: (7800000002eb208), Line: 1013, File: sqle_database_services.C
</LatchInformation>
2. 再看hold这个latch的，都是同一个应用，200876，看看这个应用的stack:
xxxxxxxx.200876.000.stack.txt
<StackTrace>
-------Frame------ ------Function + Offset------
0x0900000000007758 stat64 + 0x18
0x0900000007983800 sqlofindn2 + 0x84
0x09000000082745AC sqlofindn2@glue1F2 + 0x7C
0x0900000007B8C20C next__13SQLB_FIND_BUFFPP16sqlo_filefindbuf + 0x24
0x0900000009283660 sqlb MonSMSGetContainerPages__FP12SQLB_POOL_CBiPUi + 0x214
0x0900000009564370 sqlb SnapshotTablespace__FRC16sqlm_bp_int_infoP16sqeLocalDatabaseCUiT3P15sqlm_tablespaceP19sqm_snapshot_bufferP16sqlm_header_infob + 0xB0
0x09000000092ABE98 @92@write_sqlm_ts__FPC16sqm_agent_entityP16 sqeLocalDatabaseCUiT3P19sqm_snapshot_bufferP16sqlm_header_info + 0x200
0x09000000092AB838 @92@snap_tspaces_for_db__FP16sqm_agent_entityP19sqm_snapshot_bufferP16sqeLocalDatabaseP14sqlm_collectedPCcCUiPP22sqlm_tablespace_headerP16sqlm_header_info + 0x420
0x0900000009512DB0 sqlmonssagnt__FUi13sqm_entity_idP6sqlmaiT1PvP14sqlm_collectedUsT7P5sqlca + 0xA8
0x090000000841D444 sqlmonssbackend__FP12SQLE_DB2RA_T + 0x22C
0x0900000008D9F2BC sqlesrvr__FP14db2UCinterface + 0x678
0x0900000007A4C6CC sqleMappingFnServer__FP5sqldaP5sqlca + 0x1D0
0x0900000007A4BFD4 sqlerKnownProcedure__FiPcPiP5sqldaT4P13sqlerFmpTableP8sqeAgentP5sqlca + 0x344
0x0900000007A25694 sqlerCallDL__FP14db2UCinterfaceP9UCstpInfo + 0x580
0x0900000007A25C64 .sqljs_ddm_excsqlstt.fdpr.clone.104__FP14db2UCinterfaceP13sqljDDMObject + 0xC0
0x090000000794213C sqljsParseRdbAccessed__FP13sqljsDrdaAsCbP13sqljDDMObjectP14db2UCinterface + 0x114
0x0900000007941EE4 .sqljsParse.fdpr.clone.0__FP13sqljsDrdaAsCbP14db2UCinterfaceP8sqeAgentb + 0x6DC
0x0900000007940BA4 @63@sqljsSqlam__FP14db2UCinterfaceP8sqeAgentb + 0x2D4
0x0900000007ACF5DC @63@sqljsDriveRequests__FP8sqeAgentP14db2UCconHandle + 0xB4
0x0900000007ACF290 @63@sqljsDrdaAsInnerDriver__FP18SQLCC_INITSTRUCT_Tb + 0x2D0
0x0900000007ACED1C sqljsDrdaAsDriver__FP18SQLCC_INITSTRUCT_T + 0x100
0x0900000007796D1C RunEDU__8sqeAgentFv + 0x2F4
0x0900000007793418 EDUDriver__9sqzEDUObjFv + 0xF4
0x090000000778A1CC sqloEDUEntry + 0x264
</StackTrace>
可以通过stack看到，它是在做表空间的snapshot，进一步来讲，MonSMSGetContainerPages是在 MONITOR SMS 表空间时获取容器（CONTAINER）的数据页（PAGE）。在Db2的设计中，snapshot是要获取dblatch的。所以，根据以上信息可以推断出连不上库的原因是临时表空间页数过多，导致snapshot获取它的容器信息时间过长，没有释放连库所需要的latch。
3. 再看一下其他应用的stack信息，搜索Temp关键字，发现有75个应用都在写临时表空间。可以由stack看到，是卡在了pwrite64，也就是写临时数据。
qingsong@db2a:~$ grep -i "sqldInsertTemp" -l *.stack.txt | wc -l
75
以xxxxxxxx.150760.000.stack.txt为例
<StackTrace>
-------Frame------ ------Function + Offset------
0x090000000002A678 pwrite64 + 0x38
0x09000000078AFC7C .sqloseekwrite64.fdpr.clone.29 + 0x134
0x09000000078AFABC sqloWriteBlocks + 0xD4
0x09000000078AF960 sqlbWriteBlocks__FP16SqlbOpenFileInfoPvlUlUiPUlP12SQLB_GLOBALS + 0x50
0x09000000078AE83C sqlbWritePageToDisk__FP11SQLO_IO_REQP16SqlbOpenFileInfoP12SQLB_GLOBALS + 0x190
0x09000000078AE60C sqlbWritePage + 0x100
0x09000000078AE45C sqlbWritePage@glue4FC + 0x78
0x09000000078D0728 .@71@sqlbCheckVictimSlot.fdpr.clone.1873__FP12SQLB_GLOBALSP15SQLB_BufferPoolP19SQLB_PAGE_VICTIM_CBP11SQLB_FIX_CBP8SQLB_BPDP13SQLB_BPD_BASEPP8SQLB_BPD + 0x1C
0x09000000078CEDF4 .sqlbFreeUpSlot.fdpr.clone.231__FP11SQLB_FIX_CBPUiPP8SQLB_BPD + 0xC68
0x09000000078CF1A0 sqlbGetVictimSlot__FP11SQLB_FIX_CBiPUiPP8SQLB_BPDUl + 0x250
0x09000000078D3970 .sqlb GetPageFromDisk.fdpr.clone.101__FP11SQLB_FIX_CBi + 0xD0
0x09000000078D637C sqlbfix__FP11SQLB_FIX_CB + 0xCC0
0x09000000078D6A68 @147@497002@sqlbFixPage__FP11SQLB_FIX_CBiUiT2 + 0x54
0x09000000078B5664 sqlbFixNextNewPage__FP11SQLB_FIX_CBbUiT3@glueDB2 + 0xE0
0x0900000007972D58 sqld AppendTempRow__FP8sqeAgentPciT3P8SQLZ_RIDP8SQLD_TCB + 0x2E0
0x0900000007972820 @101@sqld InsertTemp__FP8sqeAgentP8SQLD_TCBUlT3PP10SQLD_VALUEP8SQLZ_RID + 0x1B0
0x09000000078868C4 sqld RowInsert__FP8sqeAgentUsT2UcUliPP10SQLD_VALUEP13SQLD_TDATARECP8SQLZ_RID + 0x30
0x090000000A3016AC sqlri_hsjnFlushSinglePartition__FP8sqlrr_cbP11sqlri_hsjnoUiP20sqlri_hsjnTupleBlock + 0x97C
0x090000000A300188 @44@sqlri_hsjnFlushBlocks__FP8sqlrr_cbP11sqlri_hsjnoP18sqlri_shared_hsjnoPP20sqlri_hsjnTupleBlockliT6 + 0x5E8
0x09000000099F5DB8 sqlri_hsjnPartitionFull__FP8sqlrr_cbiP25sqlri_hsjnPartitionBucketP11sqlri_hsjnoP18sqlri_shared_hsjno + 0x43C
0x090000000788F824 sqlri_hsjnNewTuple__FP8sqlrr_cbP11sqlri_hsjno + 0x24
0x090000000788FF64 sqlrihsjnpd__FP8sqlrr_cb + 0x84
0x09000000078FD2EC sqldEvalDataPred__FP13SQLD_DFM_WORKPUlP10SQLD_DPRED + 0x240
0x09000000078FA970 sqldReadNorm__FP13SQLD_DFM_WORKl + 0x540
0x09000000078A0248 @101@sqldFetchNext__FP13SQLD_DFM_WORK + 0x190
0x09000000078A0938 sqldFetchNext__FP13SQLD_DFM_WORK@glueD8F + 0x74
0x09000000078A0B64 sqldfrd__FP13SQLD_DFM_WORK + 0x170
0x09000000078EB5C0 sqldfrd__FP13SQLD_DFM_WORK@glue5A9 + 0x74
0x09000000078EB400 sqldRowFetch__FP8sqeAgentP8SQLD_CCBUlT3PP10SQLD_VALUEP8SQLZ_RIDT3P12SQLD_ID_LISTP9SQLP_LSN8 + 0xF0
0x09000000078ECDEC sqlritaSimplePerm__FP8sqlrr_cb + 0x184
0x09000000078F3624 sqlriSectInvoke__FP8sqlrr_cbP12sqlri_opparm + 0x30
0x09000000080A8098 sqlrr_dss_router__FP8sqlrr_cb + 0x6F4
0x090000000937FAA8 sqlrr_subagent_router__FP8sqeAgentP12SQLE_DB2RA_T + 0x5CC
0x09000000086F0FE4 sqleSubRequestRouter__FP8sqeAgentPUiT2 + 0x3FC
0x09000000075E4F60 sqleProcessSubRequest__FP8sqeAgent + 0x2D5C
0x0900000007D05BEC RunEDU__8sqeAgentFv + 0xEC
0x0900000007793418 EDUDriver__9sqzEDUObjFv + 0xF4
0x090000000778A1CC sqloEDUEntry + 0x264
</StackTrace>
<LatchInformation>
Holding Latch type: (SQLO_LT_SQLB_POOL_CB__writeLatch) - Address: (7000000490fb838), Line: 2476, File: sqlbpacc.C HoldCount: 1
Holding Latch type: (SQLO_LT_SQLD_APP_CB__inDMSlatch) - Address: (700000027860098), Line: 7052, File: /view/db2_v97fp8_aix64_s130316/vbs/engn/include/sqldinlines.h HoldCount: 1
</LatchInformation>
结论
综上：所以问题应该是由 临时表空间过大->运行监控函数时间长，一直持有latch->新的应用不能连接。在HANG期间，一般建议至少要收集db2pd -eve和db2pd -stack all的数据，由于没有db2pd -eve的数据，看不到出问题时候的临时表空间使用量。不过，在后续的监控中，果然发现出问题时临时表空间使用量在疯狂增长。找到应用对应的SQL，并对其进行调优之后，问题消失。
另外，有一个类似的文章，是原IBM Db2开发人员郝庆运写的，也是由于临时表空间比较大，导致应用性能问题，如下：
https://www.ibm.com/developerworks/cn/data/library/ba-cn-db2-tempspace-oversize-performance/index.html
Db2性能问题：临时表空间太大，导致连不上数据库相关推荐
- mysql数据库建表失败_mysql数据库文件太大导致建表失败，如何避免
[求助]mysql数据库文件太大导致建表失败,如何处理? 目录下各文件大小如下: root /mbsc/mysql/data # ll total 120646812 -rw-rw---- 1 mys ...
- oracle 10g磁盘管理,Oracle 10g UNDO表空间过大导致磁盘空间不足的解决
在Oracle 10g数据库的应用中,出现了UNDO表空间过大导致磁盘空间不足而崩溃的现象(ORA-30036: unable to extend segment by 8 in undo table ...
- 临时表空间过大解决方法
临时表空间过大解决方法 解决临时表空间过大有两种方法,方法一增加临时表空间的大小,方法二重建临时表空间,解决临时表空间过大的问题. 方案一:增加临时表空间的大小 --1.临时表空间的使用情况 SELE ...
- oracle临时表空间暴涨,如何解决Oracle临时表空间过大
方案一:增加临时表空间的大小 1.临时表空间的使用情况题 SELECT D.tablespace_name, SPACE "SUM_SPACE(M)", blocks " ...
- Android图片太大导致无法正常显示
Android图片太大导致无法正常显示 原因 安卓中有个内存的限制,超过这个限制后资源是无法显示的 解决办法 在全局配置文件中进行对内存的配置[关键:android:largeHeap="t ...
- 图片太大导致 imageView无法显示
图片太大导致 imageView无法显示 项目中遇到预置大图,在imageView加载时显示不出来 从网络中收集资料,明白了原来imageView 在把图片填充到控件中,是通过分辨率(例如:720*1 ...
- 浏览器下载文件，读取BLOB字段会因为数据太大导致数据库连接connect超时关闭的解决方案...
读取BLOB字段会因为文件字段太大导致connect连接超时关闭而不能读全的情况的解决方案 方案一: 通过委托模式(类似这种),在Controller层的请求方法中实现事务层上的读取blob并转化成流 ...
- docker占用磁盘空间太大的解决办法
解决Docker占用磁盘空间太大的问题 docker system 命令 1.查看磁盘空间资源情况统计表 2.借助docker自带自动化清理工具进行清理(请自重) 手动清理 Docker 镜像(Ima ...
- mysql pid文件太大_mariadb /mysql表文件太大导致的数据库启动不了 | Think in Drupal
mariadb/mysql表文件太大导致的数据库启动不了 我们帮助客户部署的一个采集器程序,突然罢工了.采集后台打开不了,经过检查发现是使用的mariadb启动不了了. 任凭我们怎么修改MariaDB ...
- vue+cesium cesium数据量太大导致浏览器卡顿解决办法
vue+cesium cesium数据量太大 导致浏览器卡顿 解决办法 解决方案 : 不要把任何的cesium对象 放在data中监听,因为在data中的变量 , vue会劫持数据 , 导致迟缓. 解 ...
最新文章
- 基于K8S构建企业级Jenkins CI/CD平台实战（三） 之 带你实战Spring boot/Cloud 项目 CI/CD jenkins自动化构建、部署过程
- sql 定时同步两个数据库
- 内核版常见问题和精华贴总结（VER 0.1) [
- Linux下系统函数open,read,write，lseek函数
- Visual Studio 2015上安装Entity Framework Power Tools
- leetcode53 Maximum Subarray 最大连续子数组
- JS大小比较（＞、＜、＞=、＜=）运算符
- 低功耗电池电压ADC采样电路，墨水屏通电掉电控制电路，PMOS电子开关，可用于待机低功耗的项目
- Blender Python UV 学习
- android自定义ClockView
- 炸裂！手摸手教你如何吃透一个 Java 项目，yyds
- win10怎么更新显卡驱动_更新Win10设备驱动程序的4种方法，方便实用，你知道几种...
- 完整版28K易支付系统源码+第四方Oreo支付源码
- 【网络教程】sublime安装emmet后提示缺少pyv8的解决方案（如何手动安装pyv8）
- 解决Word多级列表章标题第一章与节标题1.1排序混乱问题
- 多次进行hdfs namenode -format命令时，启动DataNode自动死亡的原因
- 如何设置 RecyclerView Item内子控件点击事件
- Eigen内存分配器aligned_allocator
- 【以太网通信】PHY 芯片回环测试
- 高德地图自定义点标记大小_高德地图 自定义点标记 图标大小