理解TimesTen错误日志信息"waiting for latch"

  在11.2.2.x版本TimesTen的实际运维中，经常会出现大量的"waiting for latch"的告警信息，直到11.2.2.8.0以后版本，针对latch进行了改进，期待11.2.2.8.0以后版本能有所改善；由于TimesTen中，latch等待的种类较多，每一种latch等待，代表着不通的性能问题，为了方便的理解，分别梳理各种“waiting for latch”的意思及优化方法：

1、waiting for latch "Command Dependency"

告警waiting for latch "Command Dependency"是一个比较乐观的告警信息，因为该告警信息一般是由于应用程序SQL未大量绑定变量语句引起，这个时候我们可以使用ttsqlcmdcacheinfo\2和ttsqlcmdcacheinfoget两个Built获取当前缓冲区的当前情况；

ttsqlcmdcacheinfo\2可以获取到当前缓冲区的SQL，通过分析SQL来判断应用是否使用绑定变量；ttsqlcmdcacheinfoget可以获取当前缓冲区SQL的数量和过期可释放的SQL的数量.

根据多个省的移动及电信计费系统运维的经验，系统在缓冲区的SQL量不多，在100～500之间，如果大于这个值，需要详细分析Command缓冲区，大多是因为应用未使用绑定变量引起。

该告警的解决方案只有通过应用绑定变量，消除硬解析，减少资源开销；同时，这里需要确认PrivateCommands参数是否设置，该参数默认是连接共享的，如果设置为1表示连接之间不进行共享，这样绑定变量的SQL在不同连接之间也不能相互共享。

告警日志例子：Warn:    : 16600: 28199/1002670e0: ConnId=28 (java) waiting for latch "Command Dependency"(7724594584), Holder=1038 (Deadlock Detector) PID 16610, now 1 secs

2、waiting for latch "Heap[N] - Perm"

这个告警信息大多时候是提示对OOL（out-of-line）字段的更新过于频繁，OOL一般都是长度大于255字段，这种长度较大的字段存放在TT中本来就是不推荐的，如果这样的字段还频繁的更新，说明在架构设计阶段没有进行详细的应用分析，解决方式就是减少对OOL字段的更新频率。

TimesTen对字段的存储分为in-line和out-line两种，一般默认采用in-line的存储方式，数据访问直接访问数据存储地址；当字段较大(比如：大于varchar2(255))，TimesTen将采用in-line存储一个类似指针地址的方式，并采用out-line存储实际数据，每次数据库访问通过先访问指针地址，在通过指针读取数据。

告警日志例子： Warn: : 23373: 10118/0x27ff350: ConnId=N (ConnName) waiting for latch "Heap[7] - Perm"(27008), Holder=155 (ConnName) PID 10191, now 1016ms

3、waiting for latch "Log Strand Insertion[n]"

告警信息信息waiting for latch "Log Strand Insertion[n]"提示LogBuffer的并行度较小，建议调整LogBufParallelism并行度的大小；当然，这里需要确认一下事务日志文件及事务日志缓冲区的大小配置是否合理。

告警日志例子：Warn: : 23373: 10118/0x28f8ad0: ConnId=N (ConnName) waiting for latch "Log Strand Insertion[0]"(8390890888), Holder=2038 (ConnName) PID 23379, now 1019ms

4、waiting for latch "Perm Block[n]"和"RefCnt[n]"

这两个告警信息，大多时候是因为热行争用（类似Oracle的热快争用）引起，包括热行的频繁读或者更新过于频繁。如果是Hash Index组织表，大部分时候由于Hash索引的PAGES参数配置不合理，可以调整PAGES参数缓解。

Hash索引的PAGES参数的计算可以参考：我的另外一篇博文《配置TimesTen内存数据库Hash索引的PAGES参数》

告警日志例子：Warn: : 23373: 24598/0x7f49700008c0: ConnId=N (ConnName) waiting for latch "Perm Block[160262936]"(160263032), Holder=5 (ConnName) PID 24598, now 1083ms

告警日志例子：Warn: : 2998: 7350/0xb7ce90: ConnId=56 (ConnName) waiting for latch "Perm RefCnt[901158320]"(901158728), Holder=54 (ConnName) PID 27611, now 1067ms

5、waiting for latch "Index OWNER.TABLENAME"

索引争用提示信息，大多时候是由于索引的更新或索引扫描过于频繁，这个错误在T-Tree索引中出现较为普遍，如果是T-Tree索引，这个版本引用了B+Tree索引，Oracle官方建议采用B+Tree索引代替T-Tree索引；如果是Hash Index大多时候是由于PAGES设置不合理引起的，可以使用ttcomputetabsizes计算表中的记录数进行设置PAGES参数。

TimesTen索引性能测试对比可以参考：我的另外一篇博文《TimesTen索引读取效率》 http://blog.itpub.net/24930246/viewspace-1414996/。

告警日志例子：Warn:    : 21823690: 27656286/1100db7f0: ConnId=111 (java) waiting for latch "Index ABM.IND_RATABLERESULATOR_ID"(2308680), Holder=211 (cdr_rating) PID 29229074, now 10 secs

6、waiting for latch"Lock Hash Bucket[3918]"

Bucket锁争用，这个告警一般都会同时伴随着waiting for latch "Index OWNER.TABLENAME"或者waiting for latch "Command Dependency"提示告警信息出现，一般都是由于PAGES参数设置不合理引起的；Bucket的数量是由于PAGES参数设置控制的，官方给出的Bucket的计算方式(PAGES*256)/20，我们可以根据应用更新的特点，适当将PAGES参数调整为稍微比count/256大，分散数据以减少Bucket争用。

告警日志例子：2015-01-01 09:40:04.98 Warn: : 21823690: 35651682/11017fbf0: ConnId=344 (dispatch) waiting for latch "Lock Hash Bucket[3918]"(128892388440), Holder=76 (ABM) PID 37683404, now 1 secs

7、waiting for latch "Heap[2] - Temp"

该告警信息有可能是临时内存空间分配较小，导致临时排序空间不足，可以通过monitor监控Temp_Size的大小，或者通过dssize观察Temp_Size高水位使用情况，如果是临时内存空间分配不足，建议调整临时内存空间大小；如果不是由于临时空间分配不足，该告警信息一般会伴随着其他告警信息同时存在，比如waiting for latch "Command Dependency"提示等，建议先解决waiting for latch "Command Dependency"提示再观察。

2015-01-01 10:25:06.99 Warn: : 21823690: 25034798/1102b6e30: ConnId=361 (TUXBAL_I) waiting for latch "Heap[2] - Temp"(128849029072), Holder=646 (TUXBAL) PID 36569144, now 1 secs

－－－－－－－－－－－－－－－－End－－－－－－－－－－－－－－－－－－－－－－－－－－－