True Cache: Oracle’s New In-Memory Caching Architecture

Oracle 23ai introduces True Cache — a new read-only, in-memory cache tier that sits between your application and the primary Oracle Database. Think of it as a lightweight, always-consistent cache that speaks SQL.

What True Cache is NOT:

  • Not Redis or Memcached (those are key-value stores, not SQL-aware)
  • Not Oracle In-Memory Column Store (that’s inside the primary database)
  • Not a full read replica (it doesn’t write redo logs for all changes)

What True Cache IS:

A lightweight Oracle instance that maintains a hot subset of the primary database in memory, synchronized via redo log shipping. Applications connect to True Cache and run full SQL queries — with full Oracle SQL semantics — but reads are served from memory without hitting primary storage.

Architecture:

App ──► True Cache (in-memory, read-only SQL)
               │
               │ redo sync
               ▼
        Primary Database (read-write)

Key characteristics:

  • Consistent reads: True Cache uses the same SCN (System Change Number) mechanism as the primary. Reads are always consistent with the primary database.
  • Automatic sync: Changes in the primary are shipped via redo and applied to True Cache — similar to Active Data Guard, but lighter weight.
  • No storage footprint: True Cache doesn’t persist data to disk. It’s purely an in-memory acceleration layer.
  • Transparent to applications: Applications connect using standard Oracle drivers; no code changes needed.

Best use case: Read-heavy OLTP workloads where the working set fits in memory and read latency matters — product catalogs, session data, reference lookups.

True Cache is Oracle’s answer to the “put everything in Redis” trend, with the critical advantage of full SQL consistency guarantees.

HAIP Subnet Fliping Upon Link Down/Up Event

HAIP (High Availability IP) is Oracle’s private network redundancy feature in Grid Infrastructure. When a cluster has multiple private network interfaces, HAIP automatically bonds them, providing failover if one link goes down. Bug 29379299 reveals a critical flaw in how HAIP handles link recovery.

What happens:

  1. Both private network links are UP. HAIP is healthy.
  2. Link A goes DOWN. HAIP correctly fails over to Link B. All traffic continues on Link B.
  3. Link A comes back UP.
  4. Bug: Instead of staying on Link B (the current active link), HAIP “flips” — it attempts to reassign traffic to Link A, triggering a brief HAIP reconfiguration. During this reconfiguration, cluster interconnect traffic is interrupted, which can cause:
    • False node evictions (CSS thinks a node is dead due to missed heartbeats)
    • ORA-29740 (evicted by member) in database alert logs
    • Brief application outages even though both links are UP

Affected versions:

Oracle Grid Infrastructure 12.1.0.2 through 18c. Fixed in 19c starting with 19.4 RU.

Workarounds for older releases:

Option 1 — Disable HAIP and use OS-level bonding (bonding/teaming at the OS layer is more stable in most environments anyway):

# In GI home, set in crsconfig_params or run during install
-haip_no_config

Option 2 — Apply the one-off patch for Bug 29379299 (available for 12.1.0.2 and 12.2.0.1 through MOS).

Recommendation: If you’re on an affected version and your cluster has had mysterious node evictions following network maintenance or link flaps, check the CRS diagnostic logs ($GRID_HOME/log/<hostname>/cssd/ocssd.log) for HAIP reconfiguration events correlated with the eviction timestamps. This bug is the likely culprit.

+ASM1 Fails to Join +ASM2 During Rolling Upgrade from 12c to 19c

Bug 30452852 is a particularly nasty corner case in rolling Grid Infrastructure upgrades: after upgrading node 1 to 19c, the upgraded +ASM1 instance (running 19c) cannot join the cluster because +ASM2 is still running 12c — and the two versions cannot communicate properly in certain network configurations.

Scenario:

Node 1: Grid Infrastructure 19.3.0, +ASM1 — upgraded
Node 2: Grid Infrastructure 12.1.0.2, +ASM2 — still on 12c

During the rolling upgrade window, both ASM instances must briefly coexist. In a properly configured cluster, 19c ASM is backward-compatible with 12c ASM for this transition. Bug 30452852 causes that compatibility to break.

Symptoms:

  • +ASM1 crashes immediately after starting, citing I/O errors on voting disks
  • Alert log on node 1: GMON: detected ASM instance eviction — cannot reach quorum
  • crsctl stat res ora.asm -t shows +ASM1 OFFLINE, +ASM2 ONLINE

Technical cause:

The bug is in the inter-instance GMON (Global Membership Oracle Network) communication protocol. A version mismatch in the GMON handshake message format causes +ASM1 to interpret a valid 12c heartbeat as a corrupted packet and self-evict as a safety measure.

Workaround:

Before starting the upgrade:

# Set this parameter in ASM spfile or init.ora
_asm_compatibility_override = '12.1.0.2'

This tells 19c ASM to use the 12c-compatible message format during the transition. Remove it after both nodes are on 19c.

The fix is available in the 19.8+ patch set. If you’re running 19.3 or 19.5, this parameter workaround is essential for rolling upgrades in multi-node configurations.

ASM Fails to Start When Upgrading from 12.1.0.2 to 19.3.0

Continuing the ASM upgrade bug series from last week: Bug 30265357 is one of the most impactful RAC upgrade bugs you can encounter during a 12.1.0.2 to 19.3.0 Grid Infrastructure upgrade. It’s distinct from Doc ID 2606735.1 and deserves its own analysis.

What happens:

During the upgrade, after the 19c CRS stack starts on node 1, ora.asm (the ASM resource managed by CRS) fails to start. The ASM instance itself may be running as an OS process, but CRS cannot register or control it properly.

Error signatures in CRS logs:

CRS-2674: Start of 'ora.asm' on 'node1' failed
CRS-2632: There are no more servers to try to place resource 'ora.asm' on that is not already attempting to start
ORA-15077: could not locate ASM instance serving a required diskgroup

Root cause:

The 19c version of ocssd.bin (Cluster Synchronization Services) changes how ASM instance discovery works. During the crossgrade window (19c on node 1, 12c on remaining nodes), the CSS heartbeat mechanism and voting disk access patterns change in a way that causes the ASM resource to time out before completing its startup sequence.

Resolution:

  1. Apply the patch bundle that includes the fix for Bug 30265357 to all nodes before beginning the upgrade. The fix is included in 19.7+ RU bungets.
  2. If you’re already mid-upgrade: manually start ASM using srvctl start asm -n node1 and then attempt crsctl start res ora.asm — if successful, proceed with the rootupgrade.sh on remaining nodes.
  3. As a last resort: bounce the entire cluster and restart the upgrade from a clean state.

Always confirm the patch status with opatch lspatches | grep 30265357 before your maintenance window.