Oracle与TimesTen内存数据库Cache Group同步效率与TimesTen主备数据同步机制研究

　　随着企业级信息系统一体化建设不断完善，信息基础设施和软硬件快速扩充，信息系统复杂度大幅提高，数据量呈几何倍数急剧增长，集中式数据中心、大规模数据容灾中心建设，结构化与非结构化数据存储扩容等使电力企业信息逐步显现出大容量、多种类、快速处理和高时效性的特征。而应用系统一贯采用的传统关系型数据库（RDBMS）在应付海量数据、大规模用户、高并发、web2.0网站等方面显得力不从心，难以满足大数据的处理需求。

　　为引入内存数据库技术，为研究确保数据的持久性和高可用性为前提，满足高并发、高时效的应用需要，需要研究内存库的同步能力。TimesTen内存数据库的同步技术分为异步模式和同步模式，异步模式即无须等待接收方响应，直接处理下一个事务；同步模式即等待接收方返回的响应信息再处理下一个事务。同步模式分为同步友好模式和同步非友好模式两种。异步模式侧重于主节点数据变化时，能够高速同步到备节点而不影响主节点的性能，而同步模式侧重于主备节点数据的一致性；研究Oracle到TimesTen的数据同步及TimesTen同步模式和异步模式同步技术的优缺点。

术语定义

 

缩写	全称/定义
TT	TimesTen内存数据库
同步模式	同一时间点主备事务一致
异步模式	同一时间点主备事务可能不一致
主日志	主节点当前日志文件序号
备日志	备节点当前日志文件序号
主节点	互为主备模式内存库的主节点
备节点	互为主备模式内存库的备节点

 

研究范围

内存库研究与应用项目数据同步机制研究主要包括：

研究项目	研究项目内容说明
Oracle到TT数据同步效能研究	研究指定刷新间隔时间内Oracle到TT数据同步的极限同步能力
两种同步模式主备同步效能研究	研究异步模式、同步友好模式及同步非友好模式主备同步的极限同步能力

研究Oracle到TT的同步效能

     Oracle到TimesTen数据同步机制研究采用直接对Oracle端业务表进行直接更新的方式，按照事务大小进行对比，比如1万行记录、2万行记录、3万行记录、4万行记录、5万行记录、10万行记录、15万行记录、20万行记录、30万行记录……，观察是否能及时刷新完成，统计更新相应的记录数刷新到TimesTen端需要的时间，计算指定刷新间隔时间内的极限刷新能力。

Oracle到TT数据同步研究

    Oracle端到TT端同步步骤大致为【Oracle端数据更新】→【TT端根据刷新间隔触发刷新】→【根据Oracle日志表关联查询基表数据】→【提取基表查询结果】→【写入TT端内存库】→【刷新完成】，详细刷新研究结果如下【表4.2在Oracle端更新不同数据量研究】。

【表4.2在Oracle端更新不同数据量研究】

根据【表4.2在Oracle端更新不同数据量研究】刷新研究结果可以得知，当Oracle更新数据量小于15万行记录时，无论是查询+数据提取+数据写入均能在刷新间隔内完成。 

根据【表4.2在Oracle端更新不同数据量研究】刷新研究结果可以得知，即使Oracle多次更新10万、15万行记录时，均能再刷新间隔内完成；结合前期的运维经验和Oracle官方理论，只要Oracle端性能满足，并将每张同步到TT端的CacheGroup表的刷新间隔设置为不同时间值，当Oracle更新数据量小于15万行记录时，均能在刷新间隔内完成。

根据【表4.2在Oracle端更新不同数据量研究】刷新研究结果可以得知，当Oracle更新数据量为20万时，刷新在1分钟内完成；当Oracle更新数据量为30-50万时，刷新均能在2分钟左右完成。

根据【表4.2在Oracle端更新不同数据量研究】刷新研究结果可以得知，当Oracle更新数据量为80万时，刷新耗时约为3分钟18秒；当Oracle更新数据量为100万时，刷新耗时约为5分钟21秒；当Oracle更新数据量为350多万时，刷新耗时约长达44分钟9秒左右，而且当Oracle端刷新为80万、100万、350万时，无论是刷新总时间、查询时间、提取时间、写入时间均并非简单的成倍增长，而是呈近指数增长，同时需要消耗大量的Oracle资源。

综合上述研究分析，指定的刷新间隔时间30秒内，基表大小约为600MB，极限刷新能力约为Oracle端更新15万行记录。

研究TT三种同步模式同步效能

     内存库研究与应用项目主备同步效能的研究主要包括异步模式主备同步效能、同步友好模式主备同步效能、同步非友好模式主备同步效能的研究。

TT异步模式主备同步效能

【5.1异步模式主备同步效能】

表【5.1异步模式主备同步效能】研究输出结果为每10秒输出一次。 

根据【5.1异步模式主备同步效能】异步主备同步研究结果可以得知，当主节点分别更新230.2MB和233.3MB时，均能在20秒内同步到备节点，即平均每分钟主节点产生700MB左右的日志大小能从主节点同步到备节点，不存在日志堆积。

根据【5.1异步模式主备同步效能】异步主备同步研究结果可以得知，当主节点两次更新702.6MB时，均能在30秒内同步到备节点，即平均每分钟主节点产生1.36GB左右的日志大小能从主节点同步到备节点，不存在日志堆积。

根据【5.1异步模式主备同步效能】异步主备同步研究结果可以得知，当主节点两次更新3805.2MB时，出现日志堆积，耗时240秒同步到备节点，即平均每分钟约同步951.3MB。

根据【5.1异步模式主备同步效能】异步主备同步研究结果可以得知，当主节点两次更新6159.3MB时，出现日志堆积，耗时400秒同步到备节点，即平均每分钟约同步923.9MB。

综合上述研究分析，异步模式下TT主备同步极限值约为1GB，即主节点每分钟产生小于1GB的事务日志时，事务日志能正常同步到备节点，不影响主备同步；当主节点每分钟产生事务日志大于1GB时，将出现日志堆积，影响主备正常同步。

TT同步模式主备同步效能

主备同步研究计划采用业务表编写DML脚本，研究同步模式（友好及非友好）及异步模式，

针对3个模式，分别采用直接对TT主节点更新(增删改)的方式，按照事务日志生成速度进行对比，比如1M/S,5M/S,10M/S……，观察TT数据库同步进程是否会出现日志堆积。

TT同步友好模式主备同步效能

【5.2.1.1同步友好模式主备同步效能】

表【5.2.1.1同步友好模式主备同步效能】研究输出结果为每10秒输出一次。 

根据【5.2.1.1同步友好模式主备同步效能】同步友好模式主备同步研究结果以及研究加压过程中，可以得知，同步模式与日志堆积无直接关系，与事务的大小及设置超时时间有直接关系，当主节点的事务较大（研究中更新10万行记录，约38MB），而且此时内存库较忙时就会出现【5.2.1.2事务超时报错信息】错误，同时同步模式将转回异步模式，由于该设置为友好同步模式，所以此时主节点的事务会提交，继续下一个事务的处理；当下一个事务提交时，TT会尝试将异步模式转会同步模式。

【5.2.1.2事务超时报错信息】

Source File: cmdutil.c on line number 1375

SQL State: S1T00

Native Error Code: 6003

Error Message: [TimesTen][TimesTen 11.2.1.9.7 ODBC Driver][TimesTen]TT6003: Lock request denied because of time-out

Details: Tran 9.9001 (pid 151658) wants Xn lock on rowid BMUFVUAAAAAAFTbF5g, table FMISMAIN.WF_PENDINGITEMINFO2. But tran 8.1536 (pid 266292) has it in Xn (request was Xn). Holder SQL (update FMISMAIN.WF_PENDINGITEMINFO2 set POSTID='NNDW',YHDM=1211 where rownum<=100000) -- file "tindex.c", lineno 4457, procedure "sbTixNext()"

The command failed.

TT同步非友好模式主备同步效能 

【5.2.2.1同步非友好模式主备同步效能】

根据【5.2.2.1同步非友好模式主备同步效能】同步非友好模式主备同步研究结果以及研究加压过程中，可以得知，同步模式与日志堆积无直接关系，与事务的大小及设置超时时间有直接关系，当主节点的事务较大（研究中更新10万行记录，约38MB），而且此时内存库较忙时就会出现【5.2.2.2事务超时报错信息】错误，同时同步模式将转回异步模式，由于该设置为非友好同步模式，所以此时主节点的事务不会提交，等待下一个提交或者回滚指令，如果接收不到下一个指令将会一直处于等待状态；当下一个事务提交时，TT会尝试将异步模式转会同步模式。表【5.2.2.1同步非友好模式主备同步效能】研究输出结果为每10秒输出一次。

【5.2.2.2事务超时报错信息】

Source File: cmdutil.c on line number 1375

SQL State: S1T00

Native Error Code: 6003

Error Message: [TimesTen][TimesTen 11.2.1.9.7 ODBC Driver][TimesTen]TT6003: Lock request denied because of time-out

Details: Tran 9.9001 (pid 151658) wants Xn lock on rowid BMUFVUAAAAAAFTbF5g, table FMISMAIN.WF_PENDINGITEMINFO2. But tran 8.1536 (pid 266292) has it in Xn (request was Xn). Holder SQL (update FMISMAIN.WF_PENDINGITEMINFO2 set POSTID='NNDW',YHDM=1211 where rownum<=100000) -- file "tindex.c", lineno 4457, procedure "sbTixNext()"

The command failed.

 

Source File: command.c on line number 1881

SQL State: S1000

Native Error Code: 8170

Error Message: [TimesTen][TimesTen 11.2.1.9.7 ODBC Driver][TimesTen]TT8170: Receipt or commit acknowledgement not returned in the specified timeout interval -- file "xact.c", lineno 5963, procedure "sbXactCommit"

The command failed.

 

TT内存库数据同步研究结论

Oracle到TT数据同步总结

    通过对Oracle端数据变更同步到TT端同步效能的研究，Oracle端到TT端的同步能力与Oracle查询时间、提取时间及写入TT的时间相关；结合前期的运维经验和Oracle官方理论，只要Oracle端性能满足，并将每张同步到TT端的CacheGroup表的刷新间隔设置为不同时间值，指定的刷新间隔时间30秒内，基表大小约为600MB，当Oracle更新数据量小于15万行记录时，均能在刷新间隔内完成。

TT主备数据同步总结

    通过对TT主备的同步模式和异步模式的数据同步效能研究，异步模式下TT主备同步极限值约为1GB，即主节点每分钟产生小于1GB的事务日志时，事务日志能正常同步到备节点，不影响主备同步；当主节点每分钟产生事务日志大于1GB时，将出现日志堆积，影响主备正常同步。同步模式下，同步效能与日志堆积无直接关系，与事务的大小及设置超时时间有直接关系，当主节点的事务较大将会出现备节点提交超时，同时同步模式将转回异步模式，如果设置为友好同步模式，主节点事务会提交并继续下一个事务的处理；如果设置为同步非友好模式，主节点的事务不会提交，等待下一个提交或者回滚指令，如果接收不到下一个指令将会一直处于等待状态；当下一个事务提交时，TT会尝试将异步模式转会同步模式。

内存库数据同步结论

    综合以上对Oracle到TT端的数据同步及TT主备数据同步的研究，结合TT内存库的理论及前期运维经验，只要Oracle端资源充足，TT的Cache功能能够很好的满足Oracle端到TT数据同步；当Oracle批量业务更新，Oracle到TT端的同步效能将呈非线性（近指数）下降的趋势，需要将大批量业务拆成小事务进行处理，分批提交；对于异步模式，TT主备同步的极限能力为每分钟同步1GB事务日志；同步模式的同步效能与事务的大小及设置超时时间有直接关系，同步友好模式下，备节点事务超时，主节点将会提交，结束该事务并继续下一个事务处理；非同步友好模式下，备节点事务超时，主节点将处于等待状态，阻塞排队事务的处理。
－－－－－－－－－－－－－－－－－－－－End－－－－－－－－－－－－－－－－－－－－－－－
原文链接：http://blog.itpub.net/24930246/viewspace-1418875/