在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.
在广东移动的运维期间就出现过由于定期的监控剩余最大连续空闲内存段,造成对业务的影响。
下面通过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.