数据库管理-第181期 23ai:惊喜的全功能缓存True Cache-1基础概念（20240504）

本文链接：https://blog.csdn.net/yhw1809/article/details/138439185

数据库管理181期 2024-05-04

数据库管理-第181期 23ai:惊喜的全功能缓存True Cache-1基础概念（20240504）
- 1 基本概念
- 2 True Cache的好处
- 3 规划True Cahce
- 4 True Cache配置模式
- - 4.1 Uniform Configuration
  - 4.2 Partitioned Configuration
  - - 4.2.1 True Cache Configuration with colocation_tag
    - 4.2.2 Partitioned Configuration with Multiple Services
- 5 搭建流程
- 总结

数据库管理-第181期 23ai:惊喜的全功能缓存True Cache-1基础概念（20240504）

作者：胖头鱼的鱼缸（尹海文）
Oracle ACE Associate: Database（Oracle与MySQL）
PostgreSQL ACE Partner
10年数据库行业经验，现主要从事数据库服务工作
拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证
墨天轮MVP、认证技术专家、年度墨力之星，ITPUB认证专家、专家百人团成员，OCM讲师，PolarDB开源社区技术顾问，OceanBase观察团成员
圈内拥有“总监”、“保安”、“国产数据库最大敌人”等称号，非著名社恐（社交恐怖分子）
公众号：胖头鱼的鱼缸；CSDN：胖头鱼的鱼缸（尹海文）；墨天轮：胖头鱼的鱼缸；ITPUB：yhw1809。
除授权转载并标明出处外，均为“非法”抄袭

其实吧，这个功能在去年还是23c就已经知晓了，昨天凌晨正式更名成Oracle Database 23ai，是时候又翻出来玩玩了。

1 基本概念

True Cache是一个在Oracle数据库之前的in-memory和只读的缓存。和Oracle ADG类似，True Cache是一个仅需很少磁盘的主库（Primary database）的全功能只读数据副本。
True Cache是用于应对大规模数据库连接和快速低延迟访问数据，适用于读远多于写的场景，通过True Cache读取数据不会对主库产生任何影响。同一般缓存不同的是，True Cache自动将最频繁访问的数据至于缓存之中，并确保与主库、统一缓存的其他对象以及其他缓存保持一致。同时可以缓存Oracle数据库的所有对象和数据类型（包括JSON）。
Oracle数据库的安全策略同样适用于True Cache，因此可以控制对缓存的访问。这使得可以不将敏感数据放入缓存之中。

2 True Cache的好处

True Cache带来了多项面向于应用程序开发和性能的好处：

从主数据库卸载查询，提高了可扩展性和性能
在应用程序附近部署True Cache，减少应用程序响应时间和网络延迟。这对于数据库由于数据驻留要求（数据合规）而位于与应用程序不同的位置的情况尤其有利
在多个True Cache中划分数据来创建一个大的in-memory区域。所有True Cache中缓存数据的总大小可能比单个主库或缓存大得多
自动维护缓存数据内容
对应用程序透明，简化了开发和维护

3 规划True Cahce

需要配置足够大的内存来将最频繁访问的数据至于缓存之中
True Cahce仍需要一定的很小的磁盘空间用于存放standby redo日志文件。配置文件诸如控制文件、参数文件和临时数据文件会自动创建。
True Cache是不可直接更新的只读缓存，但是DML重定向可以间接的更新缓存

4 True Cache配置模式

4.1 Uniform Configuration

在uniform配置中，可以部署多个，使用统一True Cache数据库应用服务的完全相同的True Cache。客户端会话会平均分发到各个要用用相同数据集的True Cache中。

上面使用uniform配置的示例有以下一些元素：

一个主库(PRIMDBI)
两个True Cache(TCDB1I, TCDB2I)
一个远程监听(remote listener: sales_rl)
两个应用程序

当True Cache启动时，FAL_CLIENT参数将设置为本机True Cahce的网络名称(TCDB1I或TCDB2I)，而FAL_SERVER参数将设置为主库的网络名称(PRIMDBI)。如果应用程序人工管理连接，通过True Cache数据库的应用服务发送使用True Cache的查询至True Cache，而使用主库的应用服务发送其他的查询和更新操作至主库。

为了实现更高的应用程序透明度，可以使用JDBC方法，并将主数据库应用服务与True Cache数据库应用服务相关联。上面示例的数据库应用服务：

主库(PRIMDBI)运行一个名为SALES的数据库应用服务
两个True Cache(TCDB1I, TCDB2I)共享一个名为SALES_TC的数据库应用服务

通过将主库应用服务（SALES）的TRUE_CACHE_SERVICE参数设置为SALES_TC，可以将这两个服务关联起来。应用程序的代码只需要了解主数据库应用服务（SALES）。要使用SALES_TC数据库应用程序服务，应用程序将更改SALES JDBC连接的setReadOnly标志（TRUE或FALSE）。
True Cache和主库共享一个远程监听sale_rl。如果有多个True Cache并服务与同一个数据库应用服务，监听将自动将会话分发并负载均衡到每个缓存。

4.2 Partitioned Configuration

在partitioned配置中，数据是分散在不同的True Cache中，即每个缓存存放不同的数据子集。所有True Cache的叠加起来的缓存数据量可能远大于主库或uniform配置的缓存数据量。

4.2.1 True Cache Configuration with colocation_tag

使用COLOCATION_TAG的partitioned配置和uniform配置类似，不同的是应用程序将网络别名配置在CONNECT_DATA参数的COLOCATION_TAG中，这将不会使用到负载均衡。监听将尝试使用有COLOCATION_TAG配置的所有连接发送到同一个True Cache中。
上面使用COLOCATION_TAG的partitioned配置示例有以下一些元素：

一个主库(PRIMDBI)
两个True Cache(TCDB1I, TCDB2I)
一个远程监听(remote listener: sales_rl)
两个应用程序
– COLOCATION_TAG配置为US的会话将至True Cache(TCDB1T)
– COLOCATION_TAG配置为EUROPE的会话将至True Cache(TCDB2T)

为了实现更高的应用程序透明度，可以使用JDBC方法，并将主数据库应用服务与True Cache数据库应用服务相关联。上面示例的数据库应用服务：

主库(PRIMDBI)运行一个名为SALES的数据库应用服务
两个True Cache(TCDB1I, TCDB2I)共享一个名为SALES_TC的数据库应用服务

4.2.2 Partitioned Configuration with Multiple Services

上面的示例中，partitioned配置中的每个True Cache使用不同的数据库应用服务缓存不同的数据，有以下一些元素：

一个主库(PRIMDBI)
两个True Cache(TCDB1I, TCDB2I)
一个远程监听(remote listener: sales_rl)
两个应用程序分别连接到不同的数据库应用服务(SALES和HR)

当True Cache启动时，FAL_CLIENT参数将设置为本机True Cahce的网络名称(TCDB1I或TCDB2I)，而FAL_SERVER参数将设置为主库的网络名称(PRIMDBI)。如果应用程序人工管理连接，通过True Cache数据库的应用服务发送使用True

为了实现更高的应用程序透明度，可以使用JDBC方法，并将主数据库应用服务与True Cache数据库应用服务相关联。上面示例的数据库应用服务：

主库(PRIMDBI)运行一两个数据库应用服务：SALES和HR
两个True Cache与两个不同的数据库应用服务关联：
– TCDB1I与SALES_TC关联
– TCDB2I与HR_TC关联

通过将主库应用服务(SALE和HR)的TRUE_CACHE_SERVICE参数分别设置为SALES_TC和HR_TC，可以将这两组服务关联起来。应用程序的代码需要了解主数据库应用服务（SALES和HR）。要使用SALES_TC和HR_TAC数据库应用程序服务，应用程序将更改SALES JDBC连接的setReadOnly标志（TRUE或FALSE）。
True Cache和主库共享一个远程监听sale_rl。