rue Cache 是 26ai 里比较骚的一个特性：它是个没有数据文件的 Oracle 实例，只跑在内存里，通过 redo 实时同步主库数据，专门给读流量做缓存层。听起来像 ADG 的只读备库，但 ADG 是有数据文件的，True Cache 是真"无盘"。

4.1 无盘实例怎么保证一致性

True Cache 实例启动时只加载控制文件和日志文件（其实日志也是内存映射），数据块完全靠从主库传过来的 redo 流实时构建。它的核心技术叫"Cache Fusion over Redo"，就是把 RAC 里的 Cache Fusion 机制搬到单实例备库上。主库每次 DML 产生的 redo，通过高速网络（建议 25GbE RDMA）推到 True Cache，True Cache 的 Recovery 进程在内存里重演这些 redo，构建脏块。

这里有个关键参数：TRUE_CACHE_LAG_TOLERANCE，默认 1000ms。意思是如果 True Cache 落后主库超过 1 秒，查询就会被重定向到主库。我们测下来，在万兆以太网上，日常延迟 5-20ms；但一旦主库搞个大事务（比如 DELETE 500 万行），redo 量暴增，True Cache 的内存写速度跟不上，延迟能飙到 800ms，接近阈值。

4.2 压测：大事务下的缓存失效风暴

-- 主库执行大事务
BEGIN
    FOR i IN 1..5000000 LOOP
        DELETE FROM log_table WHERE create_time < SYSDATE - 365;
        IF MOD(i, 100000) = 0 THEN COMMIT; END IF;
    END LOOP;
END;
/

-- True Cache 端监控延迟
SELECT instance_name, true_cache_lag_ms, redo_apply_rate_mb
FROM V$TRUE_CACHE_STATISTICS;
-- 正常：lag_ms = 12, apply_rate = 450MB/s
-- 大事务时：lag_ms = 780, apply_rate = 120MB/s（内存分配瓶颈）

实验结论：True Cache 不适合做主库的"唯一读副本"，它更适合做热点数据的二级缓存。比如电商的库存查询，90% 的读落在 10% 的热数据上，True Cache 把这 10% 兜住，剩下的冷查询回落到主库或 ADG。另外，True Cache 的内存必须比热数据集大 30% 以上，否则内存淘汰（LRU）会和 redo 应用抢 CPU，延迟会更难看。