TimesTen内存数据库体系结构

一、TimesTen介绍
     Oracle TimesTen In-Memory Database（以下简称TimesTen IMDB）是一种业界领先的内存中关系数据库，它是Oracle的一款战略性产品。已经有成千个客户部署了TimesTen IMDB，事实证明这种产品技术加快了应用程序的响应速度，因此适用于性能关键的联机实时应用程序。TimesTen IMDB 可作为独立的内存中数据库或者为Oracle 数据库的高速缓存子集在应用程序层提供实时数据管理。TimesTen IMDB 通常与应用程序一起部署在中间层。TimesTen 能够满足微秒级的快速响应需求。
     自1998 年以来，TimesTen 一直用在生产系统中，重点满足对其有关键需求的特定纵向市场和细分市场的需求。其中包括用于网络和通信服务（例如实时开单、移动电话一键通、收入保障和呼叫处理）的系统。其它依赖TimesTen 进行实时数据管理的性能关键的系统还包括：华尔街和其它金融中心的安全交易系统和市场数据分发平台，用于经营航空公司、优化工作流流程和支持大型呼叫中心的经营系统，以及对大型企业中的关键事件进行监视和采取措施的系统。
TimesTen的应用范围不但可横向贯穿整个企业，而且可纵向扩展到其它实时应用系统（如银行和国防）。
TimesTen提供了行业中独有的内存中技术来支持各种实时业务。它具有以下功能：
? 为企业和嵌入式应用程序提供实时性能
? 在应用程序层提供高可用性
? 通过扩展Oracle 数据库来提高应用程序性能
? 提供与Oracle 数据库的兼容性和交互操作性
二、Oracle TimesTen产品
2.1. TimesTen产品
? 产品：Oracle TimesTen In-Memory Database
– 选件：Cache Connect to Oracle
– 选件：Replication - TimesTen to TimesTen
? TimesTen 是一种业界领先的内存中关系数据库
– 来自Oracle 的一款战略性产品
– 经数万个已部署客户检验的可靠技术
? TimesTen 以性能关键的实时联机应用程序为目标，用于加快应用程序的响应速度
? TimesTen 在中间层或应用程序层提供实时数据管理
– 作为独立的内存中数据库
– 作为Oracle 数据库的高速缓存
2.2. TimesTen选件
– 除了基线产品外，Oracle TimesTen 产品线中还有两个可选产品：Cache Connect to Oracle和Replication - TimesTen to TimesTen；前者结合了Oracle TimesTen IMDB 的响应性与Oracle Database and Real Application Clusters (RAC) 的可伸缩性，后者则被多数客户用于实现应用程序层高可用性策略。
– Cache Connect to Oracle 产品选件是一个实时动态数据高速缓存系统。它包括了TimesTen IMDB 技术和数据交换技术。这两种技术合二为一，使应用程序可以将TimesTen Data Store的实时性能与Oracle DB 的大存储容量组合起来。Cache Connect to Oracle 结合了TimesTen 的响应性与Oracle Database and Real Application Clusters (RAC) 的可伸缩性。
– Replication - TimesTen to TimesTen 产品选件可以在TimesTen Data Store之间进行实时数据复制；可用于实现应用程序层高可用性或负载分担策略。
-  Replication - TimesTen to TimesTen产品选件与Cache Connect to Oracle 产品选件完全兼容。
2.3. IMDB基线产品
使用TimesTen IMDB 时，在对存储执行任何操作之前，整个Data Store（每个元素及其数据）都会加载到内存中。TimesTen IMDB的设计目的就是对内存布局进行优化。与等效的传统磁盘优化型关系数据库操作相比，TimesTen Data Store操作的代码路径短了很多。如图所示，应用程序可与TimesTen类库关联，这样Data Store会嵌入应用程序中。这称为直接连接模式，因为应用程序运行在Data Store所驻留的系统上。同一个Data Store可由来自多个应用程序进程的连接以及同一个进程中多个线程的连接共享。远程应用程序可通过客户机/服务器模式访问同一个Data Store。

? 内存中的RDBMS
- 内存中的完整数据库
- 标准访问：ODBC/JDBC、SQL92
- 与Oracle DataBase兼容
? 优异的性能
- 即时响应时间
- 高吞吐量
-可嵌入
? 持久性和永久性
- 数据库在磁盘上持续存在
- 具有ACID属性的事务处理
? 实时服务
- 无阻塞的联机操作
- 实时数据库更改通知
- 几乎无需管理
     访问TimesTen Data Store的应用程序与访问其它关系数据库管理系统(RDBMS) 的应用程序类似，因为TimesTen使用了标准的应用程序编程接口(API)、开放数据库连接(ODBC)、Java 数据库连接(JDBC)和SQL-92。TimesTen IMDB 的设计允许通过编程方式管理Data Store。安装只需要占用几分钟的时间。管理也极其简单，因为不需要数据库管理员(DBA) 的参与。
数据库优势互补:
数据库特性 Oracle Database 10/11g Oracle TimesTen In-Memory Database
数据模型 关系：SQL 关系：SQL
目标应用程序 关键任务 关键任务
优化 以磁盘为中心 以内存为中心
典型部署 数据库层 应用程序层
体系结构 客户机/服务器 直接数据访问
响应时间 毫秒 微秒
数据容量 数十TB 数十GB
可伸缩性 SMP/群集不受限制 SMP良好 
     上表将Oracle 数据库与TimesTen IMDB 进行了对照比较。这两种数据库有很多相似之处。但是，TimesTen 并不只是将整个Data Store放到了内存中和避免了I/O。TimesTen IMDB 还包含了经过优化的数据结构和算法，因而可充分利用数据始终在内存中这一事实，以求最大程度地减少处理应用程序的SQL 请求所必须执行的指令数。TimesTen IMDB 速度得以提高源于较短的指令路径，这是以内存为中心进行优化的核心所在，而不仅仅是避免了I/O。形成TimesTen优异性能的另一个主要因素是其体系结构，这个体系结构把应用程序与TimesTen 库以及内存中Data Store本身紧密关联起来。这种紧密关联称为直接数据访问，它消除了应用程序与数据间的网络连接。内存优化与直接数据访问结合，可使TimesTen 的响应时间实现以百万分之一秒（即微秒）计。当然，相应的不足之处是Data Store必须全部驻留在内存中，这在当前环境中意味着几十个GB 的容量。Oracle 数据库与TimesTen IMDB 的另一个不同之处是在可伸缩性方面。Oracle 数据库具有卓越的伸缩能力，特别是在增加RAC选件之后更是如此。TimesTen IMDB在多处理器系统上的伸缩能力也很好，但没有RAC之类的群集解决方案。
三、TimesTen应用范围
3.1. 用于嵌入式应用程序
   TimesTen应用已经广泛应用于通信、证券、游戏、旅游、移动等行业。
在嵌入式环境中：
? 要求实时处理事务处理操作
? 几毫秒都举足轻重
? 要求可预测响应时间（高峰时不会拥堵）
? 正常情况下有大量事务处理（例如，5000万~10000万个订户）
? 每秒可捕获数万个事件
? 要求达到99.999% 的可用性
3.2. 企业TimesTen应用
在企业中：
? 实时事务处理
- 需要提高订单的执行和匹配速度（更好的价格意味着更多的利润）
- 需要实时更新帐户余额
- 需要对用户登录进行验证和授权
- 每秒可捕获数万个事件
? “准”实时服务
- 需要执行实时数据分析才能做出实时决策（例如，是否应通过实行价格促销来提高销量？）
- 对最终用户请求的响应能达到可接受速度（返回结果集的时间以秒计而不是以分钟计）
快速响应：
     一般的响应时间为11 微秒，TimesTen 处于直接连接模式时，对简单事务处理（如“检索客户配置文件”）来说，这基本上等同于即时响应了。更新TimesTen IMDB 中的记录大约要用30 微秒。因此，相对于多数企业软件的设计中心，TimesTen 拥有几个数量级的优势。
简言之，TimesTen 已经过优化，可以低延迟地实时提供快速的响应。


可扩展的商品平台：
    快速响应时间带来的必然结果就是极高的事务处理吞吐率。此图表显示了在同一平台上使用一个、二个或四个CPU 时，不同操作下产生的不同吞吐量。图表的右侧显示：在使用4 个CPU 的系统上，每秒可产生超过250,000 次的读操作；在使用一个CPU 的系统上，每秒的读操作将近100,000 次。图表的左侧显示：在使用4 个CPU 的系统上，每秒可更新的行数超过70,000 行。写操作所需的处理比读操作多，因为要记录更新。
对这种廉价平台来说，这种吞吐量已经非常出色了。但是，数据库全放在内存中时，如果系统发生崩溃，数据库安全吗？本课稍后将讨论TimesTen 如何确保数据的永久性。
3.3. TimesTen使用方案
      TimesTen被广泛应用于电信、证券、电网等行业，下图为TimesTen IMDB的三个基本使用方案；这三种方案可以单独使用，也被企业混合结合在一起使用。
 
? 应用程序可以访问高速缓存了一个Oracle 数据库子集的TimesTenData Store。
? 应用程序可以使用具有或不具有复制选项的TimesTen独立Data Store。在此方案中，TimesTen Data Store是记录事务处理的数据库，并且应用程序请求路径中没有到后端数据库的直接连接。
? 多个应用程序可以各自拥有各自的内存中Data Store来高速缓存来自Oracle数据库中的数据。
四、TimesTen内存结构
         TimesTen的内存结构由内存结构、文件结构及后台进程三个部分组成。其中内存结构包括Data Store、日志缓存和临时空间，通过Data Manager直接与数据库引擎（ODBC/JDBC Driver）直接交互；文件结构包括两个检查点文件、事务日志文件和配置文件；后台进程包括守护进程（Deamon）、子守护进程（SubDeamon）及可选进程（Replication、Cache Agent）组成。
    
4.1. TimesTen内存结构
4.1.1. Data Store
    Data Store，数据库所有数据的保存区域。
4.1.2. 日志缓存
    日志缓存（LogBuffer），用于暂时存储记录Data Store变更的日志。
4.1.3. 临时数据区域
   临时数据区域，临时存储执行计划等数据的共享区域，排序等操作临时使用。
4.2. TimesTen文件结构
4.2.1. 检查点(Checkpoint)文件
     检查点(CheckPoint)文件保存了两个互为备份的DsName.ds0和DsName.ds1,可以理解为Oracle的数据文件，是内存数据库保存于磁盘的数据镜像。在Data Store启动时，将检查点文件的数据镜像装载到内存中，所以的事务处理在内存中完成；固定的时间间隔(可配置的时间间隔)进行检查点处理，将变化的数据块写入检查点文件，并删除已经写入检查点文件的事务日志文件。关闭内存数据库时，所有的变更会先写入检查点文件，最后将检查点文件镜像卸载到磁盘。
4.2.2. 事务日志文件
      事务日志（Transation Log）文件,保存Data Store的数据变更；由检查点文件和事务日志共同保证TimesTen内存数据库的正常运行，否则Data Store将会crash。事务日志文件大小可配置，超过配置大小，自动生成新的日志文件；当所有持有日志(Replication、AWT、XLA)被释放后，只保留一个事务日志，其他已经应用的事务日志由后台进程清理。与检查点文件一起用于数据库的恢复，TimesTen没有Oracle健壮，一旦缺少事务日志将无法启动。
4.2.3. 配置文件和日志文件
     配置文件sys.odbc.ini用于记录各个DSN的参数，属于Data Store级别的参数均可以在该配置文件中配置；所有的DSN配置均放在该文件中，Data Store装载时会读取该配置文件中的相关配置；连接DSN时也会读取该文件中的信息。
     配置文件sys.ttconnect.ini用于客户端连接配置，与Oracle的tnsnames.ora相似。
     配置文件ttendaemon.options用于记录实例参数，时会读取该参数文件中的配置，修改该配置文件中的参数需要重启守护(Daemon)进程。
      TimesTen的日志信息和错误信息均是按实例记录，多个DSN日志信息和错误信息写在相同的ttmesg.log和tterrors.log中。
4.3. TimesTen后台进程
4.3.1. 主守护进程
    第一个核心进程是TimesTen 主守护程序。在系统中安装的每个TimesTen 实例上都运行了一个主守护程序进程。应用程序通过TimesTen ODBC 或JDBC 驱动程序建立了到主守护程序的“deadman”套接字连接。这样一来，如果在未显式关闭应用程序进程到Data Store的连接的情况下应用程序进程终止了，TimesTen的守护进程会执行相应的维护操作。
4.3.2. 子守护程序进程
     主守护程序衍生了子守护程序进程，用于管理内存中加载的Data Store。主守护程序不会访问单个Data Store。主守护程序进程启动时，就会启动可配置数量的子守护程序进程。某一Data Store加载到内存中后，主守护程序会分配空闲的子守护程序来管理该存储。每个活动的Data Store（已加载到内存中的存储）都有一个子守护程序进程。
     守护程序进程和子守护程序进程都不会参与处理单个事务处理，而是执行诸如监视死锁、冲刷事务处理日志缓冲区、事务回滚、处理过期数据、检查点以及在系统故障后恢复Data Store等任务。
     守护程序进程和子守护程序进程都在安装了TimesTen Data Manager并且驻留了其Data Store的系统上运行。请注意，由于Data Store驻留在共享内存中，因此这些进程不执行任何网络I/O 操作。远程连接或客户机连接会与TimesTen Server 进程（主守护程序的一个子进程）进行交互。
4.3.3. 可选进程
     Replication进程用于管理主备复制、AWT同步的复制进程，该进程会派生并并管理复制持有日志进程、XLA父进程、接受进程、传送进程、Failover进程以及复制监听进程等子进程。
     Cache Agent进程用于管理Cache Group同步的进程，实现TimesTen与Oracle之间的数据同步；该进程会派生并管理句柄进程、刷新时间管理进程、刷新进程以及清理进程等子进程。
     其他可选进程，FullBackup进程用于内存数据库全库备份、Bulkcp进程用于内存数据库数据导入导出、XLA进程用于Transaction Log的API接口进程。
4.4. 事务日志与持久性
? 所有事务处理都记录在内存中日志缓冲区，然后在一定的时间间隔(可配置)永久提交到磁盘上：
– 异步提交，后台日志冲刷程序不断地将数据永久提交到磁盘上。
– 永久提交，应用程序等待事务处理永久提交到磁盘。
? 自动检查点：系统会自动将Data Store的检查点保存到磁盘。
? 系统重启后，Data Store可从检查点文件加载到内存中：
– 重做检查点文件中不存在的事务处理。
? 磁盘至关重要，因为较快的磁盘可以获得更好的性能。
    TimesTen IMDB支持完整的事务处理语义。每个写入事务处理都会被记录，并且就事务处理永久性提供了两种选择：异步（先写缓冲区）提交和同步（直接写磁盘）提交。如果通过缓冲提交，那么，在事务处理提交到事务处理日志内存缓冲区后，控制权会立即返回应用程序。对于具有严格的响应时间要求（低延迟）的应用程序，缓冲提交最为适合。如果通过同步提交来提交事务处理，那么，事务处理会永久提交到磁盘，然后控制权会返回到应用程序。多数用户对其大多数事务处理都选择了缓冲提交，这些用户在发生了每个预定的事务处理，数量之后或者发生了关键事务处理之后，会通过手动发布一个永久提交对选定的事务处理，使用同步提交，从而强制将数据提交到磁盘上。TimesTen 事务处理日志管理器有一个后台日志冲刷程序线程，用于将日志缓冲区中的数据冲刷到磁盘。日志冲刷器可以连续操作并执行对磁盘的大量I/O 写入操作。
     虽然整个Data Store都在内存中，但事务处理日志文件和检查点文件却在磁盘上，从而保证了数据的持久性。检查点实际上是磁盘上的Data Store映像。TimesTen使用两个检查点文件镜像，提高了安全性，以防某个检查点操作正在进行时系统发生故障。
4.5. Data Store检查点
 
检查点文件的作用：
1、将内存中的Data Store写入磁盘
2、清理应用被应用的事务日志文件
3、每个检查点操作轮替写入两个检查文件中的其中一个
4、检查点文件与事务处理日志文件配合确保数据的永久性
     虽然Data Store是在内存中处理的，但它们不是过渡性的临时实体。检查点操作会将内存中Data Store的一个副本写入检查点文件，还会删除不需要的事务处理日志文件。检查点操作可配置为根据时间频率和事务处理日志文件量自动发生。TimesTen对每个Data Store都使用两个检查点文件。检查点操作会更新不是最近一致的那个文件，以确保磁盘上始终存在一个有效的检查点文件。只有上次写入检查点文件后已更新的Data Store页才会重新写入检查点文件。
      通过读取最近的一致检查点文件，然后应用自上次更新检查点文件后生成的事务处理日志文件中的事件记录，Data Store就会加载到内存中。Data Store可以设置自动卸载(手动卸载、总是不卸载)，如果所有连接断开时，设置自动卸载将会从内存中卸载该存储，Data Store每次从内存中卸载到存储，均会执行最终的检查点操作。
      如果Data Store非正常关闭或发生了系统故障，那么下一次存储加载到内存中时，就会根据最近的一致检查点文件以及自上次成功执行检查点操作后生成的事务处理日志文件中的事件记录来恢复存储。存储的管理子守护程序进程完成了存储恢复操作后，它会执行一次检查点操作。最近的检查点文件包括了所有已提交的事务处理，其中包括发生系统或Data Store故障时只记录在日志文件中的那些事务处理。
      在执行检查点操作过程中，如果一个特定日志文件中的所有事务处理在两个检查点文件中都有反映，但在此日志文件中或者属于某个未完成事务处理的任何较早日志文件中没有任何事件记录，则会删除该日志文件。
检查点文件:
     检查点文件包含执行检查点操作时内存中Data Store映像的一个快照。每个Data Store都有两个检查点文件DataStoreName.ds0 和DataStoreName.ds1。
事务处理日志文件每个Data Store都有一个或多个名为DataStoreName.logn 的事务处理日志文件，其中n 是一个从0 开始的整数，每次创建一个新日志文件，该数就会递增。日志文件包含每一个Data Store更新、提交和回退操作的事件记录。
     保留空间文件每个Data Store都有三个保留空间文件。这些文件的名称分别为DataStoreName.res0、DataStoreName.res1 和DataStoreName.res2。保留空间文件用于在事务处理日志文件所在的磁盘已满时回退事务处理。请注意，事务处理事件记录是在回退事务处理时生成的。
五、TimesTen数据访问
5.1. 在传统的磁盘优化型RDBMS 中查找一行数据
     所有传统的磁盘优化型关系数据库系统在访问数据时都会发生开销。具体实施会视系统而定，可能无法在此一一详细介绍。但是，所有的优化磁盘的RDBMS 在将数据移交到请求该数据的应用程序前，都必须从内存缓冲区检索其数据或将数据从磁盘检索到内存缓冲区。
     不管实施细节是什么，某类记录标识符必须转换成RDBMS 缓冲池中的内存地址。这里假定以前的数据请求已将有关数据放入内存。如果数据尚未放入内存中的缓冲池，则必须从磁盘读取数据，这比内存访问的速度慢很多。将记录标识符转换为缓冲池中的内存地址，这仅是产生优化磁盘的RDBMS中CPU大量开销的一个因素。
    当SQL查询处理器需要某一页的数据时，它会先在缓冲池中搜索内存中的该数据。如果数据在缓冲池中，则必须将其从池中复制出来以便进行后续处理。这种缓冲池的维护和管理操作加上其它的数据副本，显著地增加向应用程序提供数据所需的开销。


5.2. 在TimesTen中查找一行数据
     虽然在磁盘优化型数据管理解决方案中必须需要缓冲池，但在基于内存的数据管理中却不必一定需要缓冲池。TimesTen没有缓冲池，因为整个Data Store都驻留在内存中了。TimesTen访问某个行时，通过将CPU 消耗保持到最低优化了性能。因此，没有了大量耗费CPU 的行标识符计算，也没有了缓冲区管理器和缓冲机制的开销，而是尽可能使用内存地址来直接对数据进行内存寻址。检索数据的步骤大大减少了；与传统的磁盘优化型RDBMS 相比，CPU指令数减少了约九成。即使是对在内存中全部高速缓存的传统磁盘优化型RDBMS数据库，这也会导致大大地提高性能。

因此，内存中数据库的速度比较快不仅是因为它避免了磁盘I/O，还因为它减少了CPU 的消耗。查询处理中没有了磁盘I/O操作后，检索数据的唯一瓶颈就是CPU指令数。
5.3. 处理Data Store更新
 
? 为获得很高的事务处理吞吐量而优化事务处理日志管理器
? 所有连接按Data Store共享一个事务处理日志(包括日志缓冲区和日志文件)
? 应用程序开发人员可详细控制磁盘日志记录选项
      Data Store映射到应用程序的地址空间后，守护程序和子守护程序会在后台执行管理任务。执行查询时，TimesTen Data Manager（ODBC 或JDBC 驱动程序）会在内存中Data Store映像上处理查询。如果更新了Data Store（在表中插入、更新或删除行），则可通过将事务处理日志缓冲区的内容写入磁盘，使更新事务处理具有永久性。TimesTen会将事务处理更新写入Data Store和内存中日志缓冲区。Data Store管理子守护程序进程的后台日志冲刷程序线程会将事务处理日志缓冲区的内容频繁冲刷到最近的日志文件中。这种机制为并发事务处理更新进程提供了很高的并行度。
  当提交了事务处理并且日志缓冲区已满时，或者永久不断地提交一个事务处理时，日志缓冲区的内容也会写入最近的日志文件。如果最近的日志文件已满，则会创建一个新的日志文件。除了存储的后台日志冲刷程序线程外，应用程序还可以控制事务处理在磁盘上持续存在的时间，同时可灵活地选择是在每次提交事务处理后，还是在提交了一组事务处理后，将事务处理日志冲刷到磁盘。
5.4. TimesTen进程和直接连接模式
TimesTen Data Manager中的一个组件是一个与应用程序关联的共享库。TimesTen 数据存储驻留在单个连续的共享内存段中（或Microsoft Windows 系统上的共享映射中）。应用程序连接到Data Store时，数据库引擎或TimesTen类库会附加至共享内存段，并将该内存段映射到应用程序进程的地址空间。
 
     TimesTen还包含一些帮助程序进程（守护程序和子守护程序），用于协调共享内存段的创建，以及在应用程序之间建立Data Store共享。要防止应用程序Bug引起的数据损坏，
就必须要有这些帮助进程。
     TimesTen Data Manager 是指TimesTen ODBC 或JDBC 驱动程序与作为一个系统运行的守护程序和子守护程序进程的组合。TimesTen Data Manager 负责处理ODBC 或JDBC 函数调用以及应用程序对Data Store发布的SQL 语句。ODBC 或JDBC 驱动程序以及Data Store驻留在应用程序进程的地址空间中。
5.5. 客户机/服务器连接模式
      直接连接模式用于性能要求很高的应用程序，因为不存在降低性能的后端服务器进程。客户机/服务器连接模式通常用于性能要求不太高的应用程序，如报告生成器和图形用户界面(GUI) 监视程序等。
 
      TimesTen Server 是主守护程序的一个子进程。如果安装了TimesTen Server 组件，则Server 进程可配置为随主守护程序启动而自动启动，随主守护程序停止而自动停止。
      TimesTen Client组件由TimesTen Client ODBC和JDBC驱动程序组成，负责将TimesTen Client应用程序的请求传输到TimesTen Server进程。TimesTen Server进程负责将结果和状态信息发送回发出请求的客户机应用程序。客户机/服务器连接模式主要用于访问网络上的远程Data Store。它还可用于支持32位应用程序连接到本地64位Data Store，以及支持跨版本的本地和远程Data Store连接（例如，TimesTen 7.0 以前版本的应用程序可连接到TimesTen 7.0 版本的Data Store）。
      TimesTen Client 应用程序与TimesTen Client ODBC或JDBC驱动程序关联，而不与TimesTen Data Manager ODBC或JDBC驱动程序关联。与TimesTen Client 驱动程序关联的应用程序可以通过TCP/IP、共享内存进程间通信(IPC) 或UNIX 域套接字与TimesTen
Server进程进行通信。TCP/IP 可用于访问本地或远程Data Store，而共享内存IPC 和UNIX
域套接字仅可用于本地访问。
      由于Data Store位于内存中，网络客户机在该Data Store所在的系统上必须运行一个代理。TimesTen Server 进程就充当这个代理的作用。为了尽量减少突然终止的TimesTen Client应用程序连接对到Data Store的并发连接的影响，每个客户机连接都会衍生一个单独的专用TimesTen Server进程来管理其连接。
5.6. 第一个Data Store连接
 
应用程序在不活动的Data Store上建立第一个连接时会发生以下操作：
1. 应用程序会创建到TimesTen 主守护程序“deadman”连接。
2. 主守护程序会分配一个子守护程序来管理Data Store。
3. 分配的子守护程序创建存储的共享内存段。
4. 子守护程序将最近的一致的检查点文件加载到存储的共享内存段中。
5. 子守护程序通过应用自上次成功执行检查点操作以来生成的日志文件中的事务处理事件记录，使内存中存储达到最近的事务性一致状态。在这个阶段中，日志文件中的已提交事务处理将前滚，暂挂事务处理将回退。
6. 应用程序将共享内存段映射到自己的地址空间中。
应用程序连接到已加载到内存中的Data Store时，只需执行第1 步和第6 步。上图显示一个访问本地Data Store的直接连接。
5.7. 并发Data Store连接
 
     TimesTen Data Manager（（ODBC 或JDBC 驱动程序）是一个共享库，因此访问Data Store的所有应用程序都使用相同的代码在Data Store上处理操作。Data Store上的所有连接，不管是来自不同的应用程序进程，还是来自同一个应用程序进程的不同线程，都能访问同一个共享内存段。因此，其它所有并发连接可即时看见一个连接提交的事务处理更新。