Oracle True Cache in Oracle AI Database 26ai provides an interesting way to scale read workloads beyond the Primary while keeping cached data current through redo apply. In this article, we take a closer look behind the scenes at its architecture, processes, startup behavior, and monitoring.

To make the discussion easier to follow, the article is organized into the following sections:

Introduction

Oracle True Cache brings database caching into the Oracle Database architecture itself. It is a read-only cache that can service SQL using data held in its buffer cache, fetch missing blocks from the Primary, and keep cached blocks current through physical redo apply.

The following Oracle blogs already cover different aspects of what True Cache provides and how to use it:

This article follows a slightly different path: looking at what can be observed from the database and operating system once True Cache is running.

The starting point is familiar territory. True Cache uses physical redo, Remote File Server (RFS), managed recovery, and real-time apply—concepts immediately recognizable from Oracle Data Guard. Oracle itself describes cached blocks as being maintained through redo apply in a manner similar to Data Guard real-time apply.

Redo apply, however, explains how cached blocks are kept current; it does not explain how True Cache obtains a block that is not already in the cache. When a required block is missing, True Cache must obtain it from the Primary. This introduces an additional set of processes and communication paths alongside the familiar redo transport and apply infrastructure.

By following the True Cache startup sequence, Oracle diagnostic messages, Oracle dynamic performance views, operating-system processes, and the TCP connections between the two databases, we can see those additional pieces come together.

A Familiar Foundation: Data Guard and True Cache

Before looking at the True Cache-specific processes, it helps to start with something familiar: an Oracle Data Guard physical standby.

A physical standby maintains a physical copy of the Primary database. Redo generated on the Primary is transported to the standby, where the Remote File Server (RFS) receives it and Managed Recovery (MRP) applies the changes. With Active Data Guard, the standby can remain open read-only while redo apply continues, allowing queries to be serviced from the standby database.

True Cache uses several of these same foundations. Redo is transported from the Primary, RFS receives it, and managed recovery applies the changes. In fact, as we will see later from the startup logs, Oracle starts Managed Recovery and Real-Time Apply when the True Cache instance opens.

The important difference is what True Cache is maintaining.

A physical standby maintains a complete physical copy of the database. True Cache is designed as a cache and does not require the entire database to be present in its cache. When an application requests data that is already cached, it can be serviced locally. When the required block is not available, True Cache can obtain that block from the Primary and cache it.

This means that alongside the familiar redo transport and apply path, True Cache needs an additional mechanism for requesting and receiving database blocks from the Primary.

The following diagram provides an overview of this architectural relationship.

Inside the True Cache Architecture

At a high level, True Cache brings together two mechanisms: the familiar redo transport and apply and an additional block request and transfer used when data is required by the cache.

When a True Cache database is opened, it establishes its relationship with the Primary and starts managed recovery. Redo generated on the Primary is transported to True Cache, received by RFS, and applied through managed recovery. This keeps blocks already present in True Cache consistent with changes occurring on the Primary.

The cache itself is populated according to demand. When an application reads data that is already available in the True Cache buffer, the read can be satisfied locally. When the required block is not available, True Cache must obtain it from the Primary.

This requires an additional communication path between the two databases.

The two paths have distinct roles: redo apply keeps cached data current, while block fetch brings missing blocks from the Primary into True Cache.

In addition to the familiar redo transport and apply processes, True Cache introduces additional processes to support on-demand block fetching. These processes provide the request and data-transfer channels between True Cache and the Primary.

Let’s look at these processes and how they work together.

With that basic architecture established, we can now look at how these mechanisms appear in a running True Cache environment.

True Cache-Specific Processes

The block-fetch mechanism introduces four additional process roles across True Cache and the Primary.

FCH — Data Request Sender
FCH runs on the True Cache instance. Its role is to send data requests to the Primary when True Cache needs blocks that are not available locally.  

RCVR — Data Request Receiver
RCVR runs on the Primary. It is the receiving side of the FCH request channel and receives data requests coming from True Cache.

DSNDR — Data Block Sender
DSNDR runs on the Primary and sends requested data blocks back to the True Cache instance.

DTS — Data Transfer Server / Data Block Receiver
DTS runs on True Cache and receives the blocks sent by the Primary’s DSNDR process.  

Together, these processes provide the additional request and block-transfer channels required for True Cache to fetch data from the Primary on demand.

True Cache Startup and Processes

With the architecture in place, let’s see how it appears in a running environment.

For the examples that follow:

DatabaseRoleDGID
ORCLPrimary database237082307
ORTCTrue Cache3445036602

The alert logs from both databases provide a useful starting point because they allow us to follow activity on the True Cache and correlate it with what happens on the Primary.

ORTC: True Cache Opens and Recovery Starts

When ORTC is opened, the alert log first identifies it explicitly as a True Cache database and identifies its Primary:

True Cache mounted.
ALTER DATABASE OPEN
True Cache opening with primary at ortc.us.oracle.com:1521/ORCL.

log_archive_config is set and Managed Recovery is then started:

ALTER SYSTEM SET log_archive_config='DG_CONFIG=(orcl)' SCOPE=MEMORY;
Starting Managed Recovery process for TRUE CACHE
Background Managed Recovery process started for TRUE CACHE

RFS connections begin appearing shortly afterward:

Background Managed Recovery process started for TRUE CACHE
rfs (PID:509954): krsr_rfs_atc: Identified database type as 'TRUE CACHE': Client is Foreground 
rfs (PID:509959): krsr_rfs_atc: Identified database type as 'TRUE CACHE': Client is ASYNC rfs (PID:509965): krsr_rfs_atc: Identified database type as 'TRUE CACHE': Client is FAL]

Finally, recovery enters Real-Time Apply:

Serial Media Recovery started
MRP0 (PID:509951): Managed Recovery starting Real Time Apply

This part of the startup is immediately recognizable from Data Guard: RFS, FAL, Managed Recovery and Real-Time Apply are all present.

ORTC: The Data Request Side

On True Cache, Oracle starts the FCH data request sender:

kradcm_fch_main: True Cache: FCH data request sender process (TT02 PID:509982) started

FCH then establishes a connection to ORCL:

kradcm_fch_connect_primary: FCH (PID:509982): trying to establish connection to primary ortc.us.oracle.com:1521/ORCL

kradcm_fch_connect_primary: FCH (PID:509982) connection established to primary ortc.us.oracle.com:1521/ORCL

Once the connection is established, FCH sends a request to the Primary to start DSNDR. Oracle subsequently reports that DSNDR was started on the Primary by RCVR PID 687942, with the operation initiated by FCH PID 509982.

kradcm_start_dsndr_from_adc: FCH (PID:509982): Message primary DGID:237082307 to start DSNDR for True Cache DGID:3445036602

kradcm_start_dsndr_from_adc: True Cache: DSNDR process successfully started in primary DGID:237082307 by RCVR PID:687942, initiated by FCH (PID:509982)

We can now switch to the ORCL alert log and see the other side of this activity.

ORCL: The Primary Creates the True Cache Block Service

At almost exactly the same point in time, the Primary reports starting RCVR process:

ALTER SYSTEM SET log_archive_dest_state_2='ENABLE' SCOPE=MEMORY SID='orcl';
True Cache:
kradcm_start_dsndr_from_primary: True Cache: RCVR primary data request receiver process (rmi PID:687942) for True Cache DGID:3445036602 started for DEST_ID:2 by FCH (PID:509982)

There are two useful pieces of information here.

The process is running on the Primary : RCVR - PID 687942
And Oracle explicitly identifies the FCH that caused it to be started:  FCH PID:509982
That is the same FCH PID we just saw on ORTC.

Oracle then reports DSNDR starting on the Primary, followed by DSNDR establishing its connection to the True Cache instance.

kradcm_dsndr_main: True Cache: DSNDR primary data block sender process (TT03 PID:687945) for True Cache DGID:3445036602 started for DEST_ID:2DSNDR subsequently establishes its connection back to True Cache:

kradcm_connect_to_adc: True Cache DSNDR (PID:687945): Establishing connection to True Cache DGID:3445036602 CONNECTION:ortc.us.oracle.com:1523/ORTC

kradcm_connect_to_adc: True Cache DSNDR (PID:687945): Successfully connected to True Cache DGID:3445036602 CONNECTION:ortc.us.oracle.com:1523/ORTC

These Primary-side messages give us the other half of the architecture: RCVR receives True Cache data requests and DSNDR provides the data-block sending side.

ORTC: DTS Appears

At almost the same time, the True Cache alert log reports starting DTS process:

kradcm_callback: True Cache: DTS data block receiver process (rmi PID:509985) started for primary DGID:237082307 DSNDR PID:687945

Notice how the two alert logs correlate

ORTC                                      ORCL
----                                      ----

FCH starts PID 509982
       ------------------------------->   RCVR starts
                                          PID 687942
                                          by FCH PID 509982

                                          DSNDR starts
                                          PID 687945.
       <-------------------------------   DSNDR connects
                                          back to ORTC
DTS starts PID 509985
associated with
DSNDR PID 687945

At this stage the alert logs have given us four additional process roles:

DatabaseProcessObserved PIDPurpose
ORTCFCH / TT02509982Data request sender
ORCLRCVR / rmi687942Data request receiver
ORCLDSNDR / TT03687945Data block sender
ORTCDTS / rmi509985Data block receiver

Viewing Startup Events in V$DATAGUARD_STATUS

The alert log is excellent for understanding what happened during startup, but Oracle exposes many of these messages through V$DATAGUARD_STATUS.

SELECT dest_id,
       facility,
       message
FROM   v$dataguard_status
WHERE  facility = 'True Cache'
   OR  error_code != 0
   OR  message LIKE '%TRUE%'
ORDER BY timestamp;

ORTC:

FACILITY             MESSAGE
-------------------- -------------------------------------------------------
Log Apply Services   Starting Managed Recovery process for TRUE CACHE
Log Apply Services   Background Managed Recovery process started for TRUE CACHE
Remote File Server   Identified database type as 'TRUE CACHE':Client is Foreground
Remote File Server   Identified database type as 'TRUE CACHE':Client is ASYNC
Remote File Server   Identified database type as 'TRUE CACHE':Client is FAL
True Cache           FCH data request sender process (TT02 PID:509982) started
True Cache           DSNDR process successfully started in primary
                     DGID:237082307 by RCVR PID:687942,
                     initiated by FCH PID:509982

True Cache           DTS data block receiver process
                     (rmi PID:509985) started from primary
                     DGID:237082307 DSNDR PID:687945

This makes V$DATAGUARD_STATUS useful for following the transition from the familiar Data Guard recovery components to the True Cache-specific block service.

The Primary exposes the corresponding True Cache activity as well:

ORCL:

FACILITY    MESSAGE
----------- ---------------------------------------------------------------
True Cache  Processed True Cache open requestfor DGID:3445036602 PID:509926
True Cache  RCVR primary data request receiver process(rmi PID:687942)
            for True Cache DGID:3445036602
            started for DEST_ID:2 by FCH (PID:509982)

True Cache  DSNDR primary data block sender process(TT03 PID:687945)
            for True Cache DGID:3445036602 started

True Cache  DSNDR (PID:687945): Establishing connection to True Cache
            DGID:3445036602

True Cache  DTS data block receiver process startedon True Cache 
            DGID:3445036602 PID:509985

Mapping the Processes with V$DATAGUARD_PROCESS

SELECT pid,
       name,
       dgid,
       client_pid,
       role
FROM   v$dataguard_process
WHERE  role LIKE 'True Cache%'
ORDER BY role;

ORTC:

PID     NAME  DGID       CLIENT_PID  ROLE
------  ----  ---------  ----------  -----------------------------
509985  rmi   237082307  687945      True Cache data block receive
509982  TT02  237082307  0           True Cache data request send

ORCL:

PID     NAME  DGID        CLIENT_PID  ROLE
------  ----  ----------  ----------  -------------------------------
687945  TT03  3445036602  0           True Cache data block send
687942  rmi   3445036602  509982      True Cache data request receive

Now the process placement becomes very clear. The process relationships reported by Oracle can also be verified at the operating-system level. Using ss -tnp on both servers shows the TCP connections associated with these PIDs

                   ORTC                              ORCL

            FCH / TT02                        RCVR / rmi
             PID 509982  ------------------->  PID 687942
        data request send                    data request receive


            DTS / rmi                         DSNDR / TT03
             PID 509985  <-------------------  PID 687945
        data block receive                    data block send


ORTC
ESTAB 0      0               10.65.44.109:64166          10.65.44.99:1521  users:(("ora_tt02_ortc",pid=509982,fd=8))
ESTAB 0      0      [::ffff:10.65.44.109]:1523  [::ffff:10.65.44.99]:11418 users:(("oracle_509985_o",pid=509985,fd=13))

ORCL
ESTAB 0      0               10.65.44.99:11418          10.65.44.109:1523  users:(("ora_tt03_orcl",pid=687945,fd=8))
ESTAB 0      0      [::ffff:10.65.44.99]:1521  [::ffff:10.65.44.109]:64166 users:(("oracle_687942_o",pid=687942,fd=14))

Redefining the Architecture with PIDs

Monitoring True Cache

V$DATABASE — Verify the Database Role

A quick way to confirm that the instance is operating as True Cache is V$DATABASE:

Oracle introduces a new DATABASE_ROLE value, TRUE CACHE, specifically identifying the database as a True Cache instance. When operational, the database is opened READ ONLY WITH APPLY, allowing read-only access while redo continues to be applied from the Primary.

SELECT name,
       db_unique_name,
       database_role,
       open_mode
FROM   v$database;

NAME DB_UNIQUE_NAME DATABASE_ROLE OPEN_MODE
____ ______________ _____________ ____________________
ORCL ORTC           TRUE CACHE    READ ONLY WITH APPLY

V$TRUE_CACHE — Monitoring True Cache Health.

V$TRUE_CACHE provides a simple starting point for checking the relationship between the True Cache database and its Primary. The STATUS column describes the current status of the True Cache configuration. If there is an issue with the configuration, this column provides information about the issue; otherwise, it reports HEALTHY.

TRUE CACHE:

SQL> select my_dg_id,remote_dg_id,dest_id,true_cache_name,
primary_name,status from v$true_cache ;

MY_DG_ID   REMOTE_DG_ID DEST_ID TRUE_CACHE_NAME PRIMARY_NAME STATUS
__________ ____________ _______ _______________ ____________ _______
3445036602    237082307       0 ORTC            orcl         HEALTHY

PRIMARY:

SQL> select my_dg_id,remote_dg_id,dest_id,true_cache_name,
primary_name,status from v$true_cache ;

    MY_DG_ID    REMOTE_DG_ID    DEST_ID TRUE_CACHE_NAME    PRIMARY_NAME    STATUS
____________ _______________ __________ __________________ _______________ ________
   237082307      3445036602          2 ORTC               orcl            HEALTHY

V$DATAGUARD_STATUS — True Cache Messages, Warnings, and Errors

The next level is V$DATAGUARD_STATUS includes a True Cache facility for messages associated with True Cache activity.

TRUE CACHE:

SELECT dest_id,
       facility,
       severity,
       error_code,
       message
FROM   v$dataguard_status
WHERE  facility = 'True Cache'
   OR  error_code != 0
ORDER BY timestamp;

DEST_ID FACILITY           SEVERITY ERROR_CODE MESSAGE
_______ __________________ ________ __________ ______________________________________________________________________________________________________________
      0 True Cache         Control           0 FCH data request sender process (TT02 PID:509982) started
      0 True Cache         Control           0 DSNDR process successfully started in primary DGID:237082307 by RCVR PID:687942, initiated by FCH (PID:509982)
      0 True Cache         Control           0 DTS data block receiver process (rmi PID:509985) started from primary DGID:237082307 DSNDR PID:687945

PRIMARY:

SELECT dest_id,
       facility,
       severity,
       error_code,
       message
FROM   v$dataguard_status
WHERE  facility = 'True Cache'
   OR  error_code != 0
ORDER BY timestamp;
 
DEST_ID FACILITY                  SEVERITY          ERROR_CODE MESSAGE                                                                                                      
__________ _________________________ ___________ _____________ _______________________________________________________________________________________________________________________________________
         0 True Cache                Control                 0 Processed True Cache open request for DGID:3445036602 PID:505673                                             
         0 True Cache                Control                 0 Processed version check for DGID:3445036602 PID:509926                                                       
         0 True Cache                Control                 0 Processed True Cache open request for DGID:3445036602 PID:509926                                             
         0 True Cache                Control                 0 Processed True Cache open request for DGID:3445036602 PID:509926                                             
         2 True Cache                Control                 0 RCVR primary data request receiver process (rmi PID:687942) for True Cache DGID:3445036602 started for DEST_ID:2 by FCH (PID:509982)
         2 True Cache                Control                 0 DSNDR primary data block sender process (TT03 PID:687945) for True Cache DGID:3445036602 started             
         2 True Cache                Control                 0 DSNDR (PID:687945): Establishing connection to True Cache DGID:3445036602 CONNECTION:ortc.us.oracle.com:1523/ORTC
         2 True Cache                Control                 0 DTS data block receiver process started on True Cache DGID:3445036602 PID:509985

V$DATAGUARD_PROCESS — True Cache Processes

V$DATAGUARD_PROCESS takes us one level deeper and shows the processes currently associated with the True Cache roles. The view exposes several roles associated with True Cache:

  • True Cache data request receive              
  • True Cache data request send
  • True Cache data block receive
  • True Cache data block send
  • True Cache control
SELECT pid,
       name,
       dgid,
       client_pid,
       role
FROM   v$dataguard_process
WHERE  role LIKE 'True Cache%'
ORDER BY role;

TRUE CACHE:

PID    NAME DGID      CLIENT_PID ROLE
______ ____ _________ __________ _____________________________
509985 rmi  237082307     687945 True Cache data block receive
509982 TT02 237082307          0 True Cache data request send

PRIMARY:

      PID NAME             DGID    CLIENT_PID ROLE
_________ _______ _____________ _____________ __________________________________
   687971 rmi        3445036602        509807 True Cache control
   961284 rmi        3445036602        855398 True Cache control
   687945 TT03       3445036602             0 True Cache data block send
   687942 rmi        3445036602        509982 True Cache data request receive

V$TRUE_CACHE_STAT — Runtime Metrics

Oracle provides V$TRUE_CACHE_STAT specifically for True Cache statistics. The view brings several aspects of True Cache runtime behavior together: cache hit ratios, redo transport/apply lag, cache prewarming, and the latency of different block-fetch modes.

NAME                         VALUE            UNIT                         TIME_COMPUTED
____________________________ ________________ ____________________________ ___________________  
Flash buffer hit ratio       0.00             percentage ratio             08/21/2026 18:57:00
RAM buffer hit ratio         0.00             percentage ratio             08/21/2026 18:57:00
True Cache hit ratio         0.00             percentage ratio             08/21/2026 18:57:00
apply finish time            +00 00:00:00.000 day(2) to second(3) interval 08/21/2026 18:57:00
apply lag                    +00 00:00:00     day(2) to second(0) interval 08/21/2026 18:57:00
estimated startup time                        second                       08/21/2026 18:57:00
list of blocks fetch latency 37896            micro seconds per request    08/21/2026 18:57:00
multiblock fetch latency     8877             micro seconds per request    08/21/2026 18:57:00
prewarm progress             100.00           percentage completed         08/21/2026 18:57:00
single block fetch latency   8991             micro seconds per block      08/21/2026 18:57:00
transport lag                +00 00:00:00     day(2) to second(0) interval 08/21/2026 18:57:00

apply lag – Apply lag is a measure of the degree to which the data in True Cache lags behind the data in the primary database, due to delays in propagating and applying redo to True Cache.

list of blocks fetch latency – The average latency of True Cache while fetching blocks from the primary database in list of blocks fetch mode.

multiblock fetch latency – The average latency of True Cache while fetching blocks from the primary database in multiblock fetch mode.

prewarm progress – The current progress of True Cache prewarming its own buffer cache by proactively fetching the list of blocks remembered from the last warmed up state, that is, from the previous instance lifetime.

single block fetch latency – The average latency of True Cache while fetching blocks from the primary database in single block fetch mode.

transport lag – Transport lag is a measure of the degree to which the transport of redo to True Cache lags behind the generation of redo on the primary database. If there are one or more redo gaps on True Cache, the transport lag is calculated as if no redo has been received after the beginning of the earliest redo gap.

Note: The apply finish time and estimated startup time metrics are not meaningful on a True Cache and can be ignored.

V$DATAGUARD_STATS — Transport Lag and Apply Lag

Because True Cache uses the Data Guard redo transport and recovery infrastructure, the familiar V$DATAGUARD_STATS view is also useful for monitoring redo synchronization with the Primary. In this snapshot, both transport and apply lag are zero, indicating that True Cache was keeping pace with the Primary at the time of measurement.

SELECT name,
       value,
       unit,
       time_computed,
       datum_time
FROM   v$dataguard_stats
WHERE  name IN ('transport lag', 'apply lag');
NAME          VALUE        UNIT                         TIME_COMPUTED       DATUM_TIME
_____________ ____________ ____________________________ ___________________ ___________________
transport lag +00 00:00:00 day(2) to second(0) interval 08/21/2026 19:03:49 08/21/2026 19:03:47
apply lag     +00 00:00:00 day(2) to second(0) interval 08/21/2026 19:03:49 08/21/2026 19:03:47

V$SYSSTAT — True Cache Block Activity

For cumulative True Cache activity, we can turn to V$SYSSTAT:

At this point the instance had issued 4,857 block requests to the Primary. The identical value for message count request send is also interesting in this snapshot, while 10,038 blocks had been fetched as part of prewarming.

NAME                                                           VALUE
______________________________________________________________ _______
True Cache: block requests to preferred primary                      0 
True Cache: block requests to primary                             4857
True Cache: blocks fetched for prewarm                           10038
True Cache: blocks served from primary to True Cache                 0
True Cache: message count data send                                  0
True Cache: message count request send                            4857
True Cache: message roundtrip time data send                         0
True Cache: message roundtrip time request send                9997373
True Cache: potentially current buffer made CR                       0
True Cache: potentially current buffer made current                  0
True Cache: primary CR block cleanout done for True Cache            0
True Cache: primary current block cleanout done for True Cache       0
True Cache: proactive fetched blocks for high availability           0
NameDescription
TrueCache: block requests to preferred primaryNumber of block-fetch requests sent to the preferred Primary Oracle RAC instance based on object or undo affinity.
TrueCache: block requests to primaryTotal number of block-fetch requests sent to the Primary database.
True Cache: message roundtrip time data sendCumulative round-trip messaging time, in microseconds, for the Primary instance sending data blocks to True Cache.
True Cache: message roundtrip time request sendCumulative, elapsed, round-trip messaging time in microseconds of this True Cache sending data block fetching requests to the primary database.
True Cache: message count data sendTotal number of messages sent by the Primary to True Cache when returning data blocks.
True Cache: message count request sendTotal number of messages sent by True Cache to the Primary requesting data blocks.
True Cache potentially current buffer made currentCount of data blocks arriving at True Cache as potentially current buffers due to timing conditions, and later confirmed to be real current buffers, so redo will continue to apply.
True Cache potentially current buffer made CRCount of data blocks arriving at True Cache as potentially current buffers due to timing conditions, and later deemed to be good only as consistent read buffers, so they will be aged out.

.

True Cache Wait Events

The following True Cache-related wait events are used for block fetching and concurrency.

NAMEWAIT_CLASS
True Cache: fetch request slotConcurrency
True Cache: background process idleIdle
True Cache: single block fetchUser I/O
True Cache: multiblock fetchUser I/O
True Cache: list of blocks fetchUser I/O
enq: MR – True Cache OperationsOther

Viewing Wait Events from AWR

The following AWR snapshot was captured during a workload of 16 concurrent sessions, each requesting data from different regions of the same table through the True Cache instance.

During this workload, both True Cache: multiblock fetch and True Cache: single block fetch appear among the top foreground wait events. Multiblock fetch accounted for 3,463 waits and 116.7 seconds of total wait time, while single-block fetch accounted for 2,429 waits and 41.6 seconds

.

The Instance Activity Statistics section provides another view of the same workload. True Cache issued 5,914 block requests to the Primary, and True Cache: message count request send also increased to 5,914. This is a useful example of how the statistics introduced earlier can be correlated with wait activity during a known workload.

Final Thoughts

True Cache builds on familiar Oracle mechanisms such as redo transport, RFS, managed recovery, and Real-Time Apply, but adds another layer of processing to support its role as a database cache. Following the startup sequence shows how the additional FCH, RCVR, DSNDR, and DTS processes come together to provide the on-demand block request and transfer path between True Cache and the Primary.

More importantly, True Cache provides enough instrumentation to observe these mechanisms as they operate. The alert logs and dynamic performance views expose the process relationships, cache activity, redo state, block-fetch statistics, and waits, giving us a practical way to understand what True Cache is doing and investigate its behavior when something does not look right.

Author

  • Jomon Jacob is a Senior Principal Advanced Services Engineer in Oracle Customer Success Services (CSS) – Tech Delivery. With over 17 years at Oracle , he specializes in Oracle Cloud Infrastructure (OCI), Oracle Exadata, engineered systems, database technologies, performance optimization, and high availability. Through the Oracle Blog, Jomon shares practical insights, best practices, and real-world experiences to help customers and engineers get the most from Oracle technologies.