在TimesTen的维护中，监控TimesTen剩余的最大连续内存块是非常有必要的，但是Oracle在TimesTen中只提供了有一个存储过程来 查看TimesTen内存数据库的剩余最大连续空闲内存段，而且该存储过程还会引起内存数据库瞬间Hang住，我们都知道TimesTen一般承载的业务 都是实时性要求非常高的，这种瞬间Hang住有可能会造成业务影响，所以我们在维护过程中要尽可能的避免频繁的查看TimesTen的剩余最大连续空闲内 存段，而且采用监控内存使用情况，在内存变化较大时再去查看剩余最大连续空闲内存段。

在广东移动的运维期间就出现过由于定期的监控剩余最大连续空闲内存段，造成对业务的影响。
下面通过TimesTen提供的TraceMon工具分析查看剩余最大连续空闲内存段引起瞬间Hang的原因：
1、查看剩余最大连续空闲内存段的方式
call ttblockinfo;
2、使用TraceMon工具Debug跟踪call ttblockinfo的执行过程
---打开latch的level 4
$ tttracemon tytt
Trace monitor; empty line to exit
Trace> flush
Trace> dump
0 records dumped
Trace> level sql 4
Trace> level latch 6
Trace> level xact 4
Trace> outfile 1.log
---在新窗口中执行查询剩余最大连续空闲内存段
Command> call ttblockinfo;
< 111, 1, 130092264, 130092264 >
1 row found.
---进入TraceMon，关闭Trace
Trace> flush
Trace> outfile 0;
Trace> level sql 0
Trace> level latch 0
Trace> level xact 0
Trace> show
AGING        ... 0
API          ... 0
ASYNCMV      ... 0
AUTOREFRESH  ... 0
CG           ... 0
CGRID        ... 0
CGRIDC       ... 0
CKPT         ... 0
DBG0         ... 0
DBG1         ... 0
DEADLOCK     ... 1
EE           ... 0
ERR          ... 1
FLOW         ... 0
HEAP         ... 0
IX           ... 0
IXGC         ... 0
LATCH        ... 0
LOB          ... 0
LOCK         ... 0
LOG          ... 0
LOGF         ... 0
MEM          ... 0
OPT          ... 0
ORACON       ... 0
PLOAD        ... 0
PREP         ... 0
PT           ... 0
REPL         ... 0
SM           ... 0
SQL          ... 0
TEST         ... 0
TRACE        ... 0
XA           ... 0
XACT         ... 0
INTERRUPT    ... 0
Trace>
3、下面来看一下Debug的输出
13:36:43.804    1379 LATCH    4L    2C   3544P sbHeapLatchGet 0x2aaab7f12378 ok
13:36:43.804    1380 LATCH    4L    2C   3544P sbLockBucketLatchGet 0x085f43d8 ok
13:36:43.804    1381 LATCH    4L    2C   3544P sbHeapLatchGet 0x2aaab7f12378 ok
13:36:43.804    1382 XACT     3L    2C   3544P sbXactCommit(E): xactId: 2.3 cacheUpdate: 0 xact.c:6137
13:36:43.804    1383 XACT     3L    2C   3544P sbXactBegin(E): xactId: 2.4
13:36:43.804    1384 LATCH    4L    2C   3544P sbLockBucketLatchGet 0x08603648 ok
13:36:43.804    1385 LATCH    4L    2C   3544P sbInternalLockLatchGet 0x2aaab8527ef8 ok
13:36:43.804    1386 SQL      4L    2C   3544P execEnvGet: Got preallocated env 140887960
13:36:43.804    1387 SQL      3L    2C   3544P Opening: call ttblockinfo
13:36:43.804    1388 LATCH    4L    2C   3544P sbDbLatchGet 0x2aaaaacd0f78 ok                     <====DB latch get
13:36:43.821    1389 LATCH    4L    2C   3544P sbPermAllocLatchGet 0x2aaaaacd12b8 ok
13:36:43.821    1390 SQL      4L    2C   3544P Fetching: call ttblockinfo
13:36:43.832    1391 SQL      4L    2C   3544P Fetching: call ttblockinfo
13:36:43.832    1392 SQL      4L    2C   3544P Closing: call ttblockinfo
13:36:43.832    1393 LATCH    5L    2C   3544P sbDbLatchRel 0x2aaaaacd0f78 ok                     <====DB latch get
13:36:43.832    1394 SQL      4L    2C   3544P sbEeEnvRet: Returned env 140887960
13:36:43.832    1395 LATCH    4L    2C   3544P sbLockBucketLatchGet 0x08603648 ok
13:36:43.832    1396 XACT     3L    2C   3544P sbXactCommit(E): xactId: 2.4 cacheUpdate: 0 xact.c:6137
13:36:43.832    1397 XACT     3L    2C   3544P sbXactBegin(E): xactId: 2.5
13:36:43.832    1398 XACT     3L    2C   3544P sbXactCommit(E): xactId: 2.5 cacheUpdate: 0 xact.c:6137
13:36:43.901    1399 LATCH    4L  135C   3401P sbLogStrandInserterLatchGet 0x2aaab823c7b0 ok
13:36:43.901    1400 LATCH    4L  135C   3401P sbLogBufFlushinfoLatchGet 0x2aaaaacd3338 ok
13:36:44.003    1401 LATCH    4L  135C   3401P sbLogStrandInserterLatchGet 0x2aaab823c7b0 ok
13:36:44.003    1402 LATCH    4L  135C   3401P sbLogBufFlushinfoLatchGet 0x2aaaaacd3338 ok
13:36:44.110    1403 LATCH    4L  135C   3401P sbLogStrandInserterLatchGet 0x2aaab823c7b0 ok

可以看到执行call ttblockinfo时，需要持有DbLatch，这样所有需要申请内存访问的请求都将会等待。
注：TraceMon非常耗资源，特别是CPU，所以在生产系统中要谨慎，尽量避免整库Debug，可以采用单个连接进行Debug的方式。
=======================End========================================