TimesTen临时(内存)空间使用和调整临时(内存)空间

在TimesTen运维及项目前期规划过程中，需要对TimesTen临时空间进行计算，下面根据官方建议结合运维经验规划临时空间的分配：

1、官方对临时空间分配的计算方法：

TempSize = 14 MB + ceiling(PermSize / 8)

根据个人的运维经验，官方的计算方式比较适合于内存数据库大小在10~40GB比较合适，如果内存库分配较小或较大时建议做稍微调整。

当内存数据库分配小于10GB时，建议：TempSize = 200 MB + ceiling(PermSize / 8)

当内存数据库分配大于40GB时，建议根据应用需求将TempSize调整在5~6GB左右即可，分配太大只会浪费内存空间。

2、调整临时空间分配

TimesTen对临时空间的调整是比较麻烦的，需要重新将内存库卸载后修改sys.odbc.ini文件再重新装载才能有效。详细操作方式如下：

vi sys.odbc.ini

TempSize=64 ####修改TempSize参数的大小，值得庆幸的是TempSize是可以调大也可以调小的，该参数的单位是MB。

ttadmin−ramunloadDSN

Command> dssize m;

PERM_ALLOCATED_SIZE: 128

PERM_IN_USE_SIZE: 6.4296875

PERM_IN_USE_HIGH_WATER: 6.4296875

TEMP_ALLOCATED_SIZE: 64

TEMP_IN_USE_SIZE: 8.5068359375

TEMP_IN_USE_HIGH_WATER: 8.5693359375

ttadmin−ramloadDSN

操作非常简单，就是需要停止所有的业务，需要业务中断时间窗口。

3、关于TimesTen临时空间

问1、有办法释放临时空间的使用吗？

答：没有办法，重启内存数据库Data Store是唯一的办法。

问2、SQL commands会一直在临时(内存)空间保存和自动管理么？

答：是的，command cache就是一个SQL commands使用临时(内存)空间保存和自动管理的例子。

问3、有办法减少临时(内存)空间的使用么？

答：总的来说是可以的，TimesTen其实也是和Oracle一样通过唯一键值的方式进行识别的，通过绑定变量的方式可以减少硬编译。使用绑定变量可以对command cache重复利用，减少临时(内存)空间的使用。

问4、PrivateCommands=1是否会比PrivateCommands=0消耗更多的临时(内存)空间？

答：总的来说是可以的，如果有多个连接使用相同的SQL语句将会有一个在command cache中为每个SQL语句保留独特的副本。

0 (default) - Commands are shared with other connections.1 - Commands are not shared with any other connection.

问6、如果连接数超出设置的最大连接数时，是否会消耗更多的临时(内存)空间？

答：是的，连接数是由闩锁进行管理，如果超过了最大连接数，会由闩锁进行管理，而不单单是操作系统的提示信息，而闩锁正是由临时(内存)空间进行管理。自然也会影响系统的性能。值得注意的是，从11.2.2.x版本开始，超过最大连接数将会报超出最大连接数的错误，而不是由闩锁进行管理。

问7、有没有TimesTen的工具或者存储过程可以查询临时(内存)空间的使用情况？

答：没有，没有简单的工具可以查询临时(内存)空间的使用；只能通过ttracemon或dsmap工具协助分析，也可以通过monitor表和dssize或者ttSQLCmdCacheInfoGet进行参考分析。

1、分析Monitor表中的信息和Command Cache信息：

./ttIsql -connstr “dsn=” -e “monitor; dssize; call ttSQLCmdCacheInfoGet; exit;”

./ttIsql -connstr “dsn=” -e “dsize;exit;”

2、使用ttTraceMon抓取SQL及头文件信息：

./bin/tttracemon

level sql 5

level heap 5

outfile ./

3、使用dsMap工具分析

./ttIsql “dsn=” (to get shmid)

./unsupported/dsmap -all -shmid