TimesTen的那些常见误区

Oracle TimesTen In-Memory Database（简称TimesTen IMDB或TT）是一种业界领先的内存中关系数据库，它是Oracle的一款战略性产品。已有几千个客户部署了TimesTen IMDB，事实证明这种产品技术加快了应用程序的响应速度，因此适用于性能关键的联机实时应用程序。TimesTen IMDB可作为独立的内存中数据库或者为Oracle数据库的高速缓存子集在应用程序层提供实时数据管理；TimesTen IMDB 通常与应用程序一起部署在中间层，能够满足微秒级的快速响应需求。

鉴于TT没有那么普及，大部分公司的都是遇到问题随手拉个Oracle工程师临时处理；网络上的资料也比较零碎，大部分都是来自官方文档的一些简单翻译，笔者也是一直从事Oracle相关工作，2012年某移动BOSS系统割接有幸接触到TT内存数据库，之后便与之结缘；这几年磕磕碰碰，总结了一些客户经常会问到、运维中常见且容易引发故障的问题，这里分享给大家，希望对一线奋战的兄弟们能有所帮助。

 

?   内存数据库需要很大的内存

?   数据均存储在内存中

?   内存数据库性能与磁盘IO无关

?    TT处理速度很快

?   事务日志理解误区

?   查询无需提交

?   并行参数带来的回忆

?   缓存代理背后的秘密

 

内存数据库需要很大的内存

你或许也会和其他同事、客户有一样的疑问，TT内存库是不是需要很大的内存？自己虚拟需要多大的内存才可以搭建TT内存数据库学习环境？

有这样的疑问很多是受Oracle这个大家伙的影响，Oracle最少都是GB的内存，现在运行Oracle数据库的主机内存几百GB甚至上TB的都不少见，加上内存库数据都是存储在内存中，所以容易认为需要很大内存才能搭建内存数据库环境也比较正常；其实TT属于轻量级的关系型数据库，TT本身只需要几十MB的内存就可以运行，再加上最小的数据存储空间为32MB和临时空间等，一百多MB的内存空间就可以搭建一个TT内存数据库学习环境了。
－－－－create by TangYun[汤云]－－－－－－

当然，TT内存数据库，操作都是在内存中完成的，实例运行过程中会将所有的数据加载到内存中，数据量有多大，就需要多大的内存。

数据均存储在内存中

近两年在移动、电信、航空、电网做售前支持的时候，客户都会问到内存数据库的数据均存储在内存中，一旦内存释放数据是不是就没有了？

客户有这样的疑问也是正常的，数据安全是客户最关系的问题嘛，数据没了，再快顶个卵用。

数据存储在内存中这个概念本来就是一个误区，正确的说法应该是数据加载在内存中，所有操作在内存中完成的；当然实例运行时数据也是“存储”在内存中；但实际内存数据库的数据是存储在永久存储中，而且还存储了两份，即TT内存数据库的两个检查点(checkpoint)文件，所以不用担心内存释放后数据就没了。

内存数据库将数据镜像加载到内存中，所有外部请求操作在内存中来完成，并通过日志缓冲区(Log Buffer)记录所有的变化，由后台进程flusher写入到事务日志(Trans Log)中；再在每个设置的检查点时间间隔将事务日志中的变化写入到检查点文件中。

内存数据库性能与磁盘IO无关

TT内存数据库的所有操作都是在内存中完成的，所以内存数据库的性能与存储IO无关，我开始接触TT也是这么认为的；大概也是这个原因，除了某家买IBM P780、DS8000系列存储像买白菜一样的移动客户外采用DS8000系列的存储来支撑TT运行外；其他移动、电信、电网等运营商都使用比较普通甚至滤旧的主机和存储来支撑TT的运行，当然不是该移动钱多任性才使用DS8000系列的存储来支撑TT的运行，而是有大师指导的。－－－－create by TangYun[汤云]－－－－－－

正是TT内存数据的所有操作都是在内存中完成，处理速度非常之快；但是为了保证数据的永久性，TT内存数据库的所有DML操作也会像Oracle一样写“Redo”，区别在于Oracle是在一定条件下触发将Log Buffer中的变化写入Redo，比如commit、达到1MB、Log Buffer 1/3满、每隔3秒等；而TT则由Flusher后台进程实时将Log Buffer 中的内容实时刷入事务日志中。所以，当并发量比较大、或者是批量更新时，磁盘IO会直接影响TT的性能。同时，由于TT采用设定的时间将事务日志的内容写入检查点文件，写入检查点文件期间，将会消耗大量的磁盘IO，这也是我们在规划中需要将事务日志文件和检查点文件放在不同的磁盘中，并控制检查点文件写入速度的原因。

磁盘IO还与Duplicate、实例恢复等有直接的联系；磁盘IO能力直接影响实例恢复时长。

TT处理速度很快

无论是开发、运维的兄弟还是客户，没有过深入的理解，大家思维都会受到10倍于Oracle的速度所影响；没错，Oracle自称TT内存库TT采用更优化的算法，处理速度十倍于Oracle物理数据库，不过这是有前提的，在短小事务的查询下，特别是高并发环境中，TT内存数据库的处理速度很快，我们在某电网、电信都做过测试，基本平均达到5~8倍的Oracle处理速度。但是，对于大批量数据处理或者复杂查询，TT的处理能力就显得没有那么大优势了，甚至处理能力不及Oracle数据库的处理能力；经常会遇到开发或者客户在TT批量更新几百万、几千万的数据，最后花费了比Oracle更长的时间才完成，然后跑来问我，为什么我在TT里处理比Oracle还慢。－－－－create by TangYun[汤云]－－－－－－

在运维中还经常会遇到开发的同事执行大批量事务或者长事务导致TT性能急剧下降的情况，有时候甚至导致TT夯住或实例实效的情况发生；TT对事务的回滚处理能力更是远不如Oracle数据库，TT虽然也是Read Commit的隔离机制，但是却没有Undo段的概念，对事务的回滚是依赖于事务日志来完成，所以TT对事务回滚的处理能力远比Oracle的回滚能力要弱，而且对性能消耗较大。

事务日志理解误区

事务日志(Transaction Log)，类似Oracle的Redo Log，与Oracle的Redo Log不同的是TT的事务日志是顺序写的，Oracle的Redo Log是循环写的；本来很容易理解，但不知道是不是由于“日志”这个词在作怪，还是有客户和运维的兄弟让悲剧发生或差点让悲剧发生。2014年初某移动，由于事务日志所在的存储空间爆满，客户直接清除大部分事务日志，TT实例Crash；2014年低某电信也是由于事务日志所在的存储空间爆满，客户将事务日志移动到别的磁盘上，TT实例Crash，还让运维工程师拼命的尝试将TT拉起来却屡试不爽。－－－－create by TangYun[汤云]－－－－－－

不同的是，第一个客户清除了事务日志，没有给自己留下任何的后路；第二个客户却给自己留了一条生路。后来与客户闲聊时候也有问起，为什么他们会删除事务日志，他们给我的答案都是一样的：“这些日志都是用于主备复制用的，现在主节点日志爆满影响了业务，故障恢复后再重建备机就好了”，呵呵！

在做规划或者实际运维过程中，我们一定要和客户及其他参与运维同事解释清楚事务日志的作用及其重要性、如何判断事务日志写入检查点文件的进度等，避免对事务日志的理解不正确造成悲剧发生。

查询无需提交

无论是开发人员还是运维圈子，Oracle数据库思维对小伙伴们的影响都是非常大，小伙伴们都拥有丰富的Oracle常识，但是毕竟TT是Oracle公司收养的孩子，流着不一样血液，虽然在11g版本Oracle公司对TT进行大量的“调教”，但是仍存在着很多不一样的特性。

Oracle思维会给我们在TT内存数据库使用中带来很多误区，最为典型误区就是查询无需提交；在我支持的项目中，也不乏查询没有提交导致重大故障的，2013年9月某移动由于业务变更，新增对核心表的查询没有提交，导致部分区域业务受到影响。2014年4月某电信由于月底出账期间对TT核心库表进行统计信息收集，导致全省业务受到影响，源头正是由于业务查询均没有提交。－－－－create by TangYun[汤云]－－－－－－

下面通过实验对比执行一条简单查询，Oracle数据库和TT内存库持有锁的情况：

a、  Oracle端执行查询，会话持有锁的情况：

Session 1:

SQL> select tid from ty.tangyun;

 

  TID

----------

   1

 

Session 2:

SQL> select l.sid,l.type,l.id1,l.id2,l.lmode,l.request,l.block from v$lock l,v$session s where l.sid=s.sid and s.type='USER';

 

no rows selected

 

b、  TT端执行查询，会话持有锁的情况：

Session 1:

Command> set AutoCommit 0;

Command> prepare select tid from tangyun;

Command> execute;

Command> commit;

 

Session 2:

$ ttxactadmin ty

2015-12-22 02:13:23.589

/ttchk/tt1122/DataStore/TYINFO/tyinfodata

TimesTen Release 11.2.2.7.4－－－－create by TangYun[汤云]－－－－－－

Outstanding locks

PID     Context            TransID     TransStatus Resource  ResourceID           Mode  SqlCmdID             Name

Program File Name: ttIsqlCmd

3352    0x968b9c0             1.4      Active      Database  0x01312d0001312d00   IX    0 

                                                   Command   35029544             S     35029544

1 outstanding transaction found

对比Oracle数据库和TT内存库执行一条简单的查询持有锁的情况，不难发现Oracle数据库执行查询并未持有锁，而TT内存库执行查询会持有一种Command S锁，要想释放锁资源必须提交以结束事务，可以在TT内存库中查询也是需要提交的。

并行参数带来的回忆

2014年3月份，我的一个同事做内存数据库碎片整理的一个工程实施，这本是一个非常成熟，做过上百次的小工程，却引发了严重的重大故障；工程操作非常简单，就是采用ttMigrate全库导出，－－－－create by TangYun[汤云]－－－－－－重建TT内存库后再全库导入即可；工程实施的兄弟却临时加了并行参数“-numThreads”触发TT内存库Bug 17056944(该Bug已经在11.2.2.6.0版本修复)，导致数据导入时，某张核心表有400多万行记录没有导出成功，悲剧的是实施的兄弟可能认为工程比较成熟、实施的次数也比较多，实施完成后并未对操作日志详细检查。

这里提到这个Case，主要是想提醒一下TT内存库没有Oracle那么成熟，使用时需要更加的细心，不熟悉的功能或特性一定要先做测试。同时也是为了回忆一下这种惨痛的教训，实施时为了节约一点时间临时改动实施方案，实施完成后未进行详细检查，这些都是几分钟的操作，却让客户损失惨重，开发商一个16个人的Team修复了三天三夜，我也因此陪了三天两夜。

TT非常的稳定，维护工作也非常少，很多客户半年都是没有出现过问题，所以经常会有客户或者运维的兄弟说到他们的TT内存库都好几个月没管了；但是，TT内存库一般运行的都是非常核心的业务，我们必须做好实时监控、定期进行深度巡检，变更前必须做好充分的验证测试，避免类似这种一次粗心，将客户满意度、整个Team的付出从1到0转变的悲剧发生。

缓存代理背后的秘密

高速缓存组(Cache Group)本来是TT内存库比较核心的组件，但使用的客户却不多，这可能和业务特点有关，也可能和技术经验有关，没有人研究自然就不会有人使用；不过高速缓存组其实非常的简单，特别是只读缓存组其实就是Oracle物化视图的化身，实现的机制、逻辑都与物化视图一致，稍做一些个性化而已。

高速缓存组与物化视图的不同之处是两者在源端和目标端的通信链路，物化视图一般采用的是DB LINK，TT采用的是缓存代理(Cache Agent)，这里所指的不同不是网络协议的不同，而是运维操作思维上差异。物化视图采用DB LINK进行通信，目标端的所有操作均会响应到源端，比如重建物化视图、在某张基表新增一个或多个目标端物化视图等；而TT的目标端操作会“延迟” 响应到源端。这也是TT高速缓存组异于Oracle物化视图的地方，没有对官方文档的详细里面，我们比较容易用Oracle的思维去理解高速缓存组维护的动作，这也是使用高速缓存组比较引发故障的地方，由于目标端操作的“延迟” 响应到源端，导致源端和目标端注册信息不一致，源端数据无法及时同步到目标端，引发故障。下面是某移动重建高速缓存组引发的故障：

1、  删除原高速缓存组

2、  修改缓存组缓存的字段并重建缓存组(这里删除了原缓存组中的一个字段)

3、  重建缓存组并装载数据

下一个刷新时间点，新重建的缓存组由于无法进行增量刷新，尝试进行全量刷新，将源端日志全部清空，还将原来装载的目标端高速缓存组数据清空，故障发生。

2015-06-25 09:08:24.35 Warn: ORA: 7995908: ora-7995908-5141-refresh06398: Datastore: ABMDATA A full autorefresh will be performed for Incremental autorefresh table XX.XXXXXX because change log table "TT"."TT_05_143327_L" on Oracle has been truncated－－－－create by TangYun[汤云]－－－－－－

2015-06-25 09:08:24.60 Err : ORA: 7995908: ora-7995908-5141-raStuff07291: Datastore: TYDATA Column count does not match for cached table

故障的解决办法非常简单，重新启动缓存代理并重新装载数据即可，重启缓存代理后bookmarker线程中的高速缓存组列表会进行重新初始化，注册信息得到修正，但是因为数据已经丢失，所以需要重新装载后才能进行正常的增量刷新。

TT官方文档明确说明高速缓存组的操作步骤，需先停止缓存代理(Cache Agent)再进行高速缓存组的创建或删除，操作完成后启动缓存代理后进行数据初始化；这里不难理解，停止缓存代理自然就与Oracle端没有了通信，高速缓存组的注册其实不是在创建或者删除动作中的步骤，其实是在启动缓存代理的动作中完成的。

 

Created by Tony.Tang [TangYun]2016.3.3

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

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/24930246/viewspace-2026702/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/24930246/viewspace-2026702/