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−ramunload DSN
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−ramload DSN
操作非常简单，就是需要停止所有的业务，需要业务中断时间窗口。
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