上回说到某运营商客户的核心系统数据库从IBM AIX小型机环境迁移到某国产数据库一体机，同时数据库版本从11g直接升级为19c。在上月已经实现两个地市迁移到一体机的19c上，尽管过程顺利完成，但是从实操过程中，亦暴露了TimesTen Cache Group重建速度较慢，存在操作时间超时的风险。因此，有必要对此过程进行优化。

TimesTen（简称TT）是Oracle开发的一个内存关系型数据库。它支持SQL并提供了响应时间极短且吞吐量极高的应用程序，可满足各行业高性能和高吞吐量应用程序的需求。同时，TT与Oracle DB的整合性非常好，与其他内存缓存（如Redis等）不同，它提供了原生的Cache Group机制，可以实现Oracle DB中的表与TT内存库的表的实时同步，无需程序过多干预。

Cache Group是在TT中cache的Oracle数据表的一个集合。

Cache Group里的多张子表（child tables）要与主基表（root table）有外键约束关系，且一个Cache Group只能有一张基表（root table）。一个data store可以有多个Cache Group；一个data store里，一张表只能cache在一个Cache Group里。

Cache Group一般可分为两种类型：TT自动管理（System-managed）和用户管理（User-managed）。

其中TT自动管理又有建立三种类型的Cache Group：

在我们的实践中，主要使用只读Read Only形态的Cache Group为主。因为在此应用中，Cache Group的作用是将Oracle数据库中涉及用户的信息同步到TT中，为在TT中运行的计费程序提供用户相关信息。

在数据迁移过程中，我们使用GoldenGate已经将11g数据库中的两个地市的schema迁移到X86一体机的Oracle 19c数据库中。升级的大致示意图如下：

其中数据库架构中有两个TT的集群，每个TT集群都有若干套主备架构的TT内存数据库。物理Oracle数据库与TT内存库之间使用Cache Group机制同步物理库中的若干关键表到内存库中。

2）实际操作步骤大致如下

检查后台数据，发现几个数据量较大的库表加载缓慢，只加载了整表大概三分之一的数据。

TT的Cache Group重建速度比预期要慢得多，造成四个步骤实际操作时间超时完成。由于后续工程中的迁移数据量远比本次迁移大，为了后续割接可以顺利地在工程计划时间窗口内完成，我们需要对这个过程进行分析和优化。

首先，我们怀疑问题是否出现在TT主机和网络之间，但问题是之前的TT Cache Group也是在此网络和主机之中。经过详细测试我们也确实排除了这个可能。

我们重新将问题目光聚焦于新环境的X86平台19c数据库当中。于是我们调用了Cache Group重建前面多个时间片的Oracle AWR报告，看看有什么收获。果然，在AWR报告中发现当时Oracle有明显的GC等待事件堆积情况。

在RAC环境，有Cache Fusion（内存融合）机制，可以实现多节点的缓存数据共享，如果比较频繁，就会有大量的GC相关等待事件。说白了GC等待就是跨节点访问内存数据，引起在RAC节点间通过网络进行节点内存之间的数据复制。针对这个问题，我们分析认为此事件发生的主要原因是，平时这些数据TT Cache Group数据同步都在11g双节点RAC数据库节点2上。而迁移到Oracle 19c 6节点的RAC后，数据同步会分散在多个节点执行，就会有过多的GC等待。

而普遍处理GC等待的处理方法，基本都是分割应用，或者分割表，尽量避免频繁的多节点数据访问。因此，优化TT Cache Group加载问题也可以遵从这个思路。回顾我们的割接方案，实际上可以得到一个非常简单的分割方法。因为我们迁移到19c上的数据已经按照schema做好了业务隔离，所以在创建Cache Group的时候也按照schema去划分就可以了。

根据这个思路，我们细化了重建TT Cache Group的步骤，将创建JY和SW两份数据的创建TT Cache Group放在单独的RAC节点中执行。RAC节点间的数据访问就不会有冲突和重复，借此降低GC等待的发生概率。大致如下示意图:

确定优化方案之后，经过后续的测试，效果良好，总体同步时间有明显的缩短。在后续的一次三地市割接中启用此优化方案，将Cache Group重建的时间压缩到原来的1/3左右，此问题得到有效解决。

TT Cache Group的重建是大量数据读取的过程，每个表的Cache Group重建需要遍历一次该表的所有数据。由于两个TT集群中又涉及多套TT库，每个TT库都需要重建Cache Group，所以相关数据会有大量的读取操作。

如果不对数据读取进行隔离和拆分的情况下，就会对数据读取分散到RAC的所有节点中，也就出现我们第一次割接工程中出现的问题，大量的GC等待的情况。

因此，必要的数据规划不但是业务应用需要注意，在一些特殊的场景下，也是必须单独进行优化的。