Leveraging Oracle TAC and Rolling Patching in the AI-Driven Era

Chanaka Yapa Dec 18, 2025 3:08:19 PM

Introduction

We live in an era where businesses are powered by data, running their most critical systems on robust platforms such as Oracle Exadata Cloud@Customer and Oracle Exadata Cloud Service. Yet, after migration, many organizations tend to overlook the rich set of features these platforms provide. 

Even fundamental capabilities such as Oracle RAC’s Transparent Application Continuity (TAC) are often forgotten or left unconfigured. Think of it this way: if you buy a Ferrari, you don’t drive it like a regular car. You learn its features, understand its capabilities, and drive it like a Ferrari. The same mindset applies to Exadata – to get the most out of it, you need to leverage its advanced features fully.

Why Transparent Application Continuity (TAC) Matters

As AI continues to evolve at a rapid pace, new types of software vulnerabilities are constantly emerging, putting sensitive data at risk. As DBAs, it’s our responsibility to ensure systems remain secure, resilient, and up to date with the latest patches and security updates.

However, downtime during patching cycles is no longer acceptable for most modern businesses. Oracle addresses this challenge through rolling patching, allowing updates to be applied without taking the system offline. But to truly achieve zero application disruption, you need to ensure your applications are compatible with and configured for Transparent Application Continuity (TAC).

What Is Oracle Transparent Application Continuity (TAC)?

Oracle Transparent Application Continuity (TAC) is a powerful high-availability feature designed to protect user sessions from disruptions caused by planned maintenance, recoverable outages, or instance failures, without requiring any changes to application code.

When TAC is enabled, the database automatically replays in-flight transactions after a failure, preserving session state, database calls, and application context. This allows users to continue working as if nothing happened, making the entire recovery process completely transparent to both users and applications.

How TAC Enhances Availability

TAC builds upon Oracle’s Application Continuity (AC) feature, adding more intelligence and automation. It offers:

  • Transparent support for most applications using Oracle drivers
  • Protection against both planned and unplanned outages
  • Elimination of custom retry logic in applications
  • Seamless integration with Oracle RAC and Exadata environments

In simple terms, TAC keeps your applications running smoothly, even during database patching or failover operations. It ensures a consistent user experience, minimizes downtime, and helps your business maintain true high availability.

In this article, I will explain how to configure Transparent Application Continuity (TAC) for Oracle RAC. We implemented this solution for one of our customers who could not afford any application downtime due to the business-critical nature of their Exadata infrastructure during patching cycles. As part of the configuration, we also created dedicated services to properly segregate workloads and ensure optimal failover behavior.

To begin, we divided the services across RAC nodes to effectively separate workloads. The current services are shown below.

[oracle@exanode-01]$ srvctl status service -d TEST2_EXA
Service test2_uat_iap_srv is running on instance(s) TEST21
Service test2_uat_kaf_srv is running on instance(s) TEST22

TAC configuration

Here are the basic settings you can use to start testing this setup.

srvctl add service -d TEST2_EXA -s TEST2_UAT_KAF_SRV \
-r TEST22 \
-a TEST21 \
-failovertype AUTO \
-failover_restore AUTO \
-commit_outcome TRUE \
-failback YES \
-failovermethod BASIC

Describe parameters

Parameter Meaning
-d TEST2_EXA Specifies the database unique name where the service is being created. In this case, the service is for the database TEST2_EXA.
-s TEST2_UAT_KAF_SRV The service name being created – in this case, TEST2_UAT_KAF_SRV. Applications will connect using this service.
-r TEST22 Defines the preferred instance(s) for the service – i.e., where the service should normally run. Here, the preferred instance is TEST22.
-a TEST21 Defines the available instance(s) (standby/failover instances). If the preferred instance (TEST22) goes down, the service will failover to TEST21.
-failovertype AUTO Enables Application Continuity (AC) or Transparent Application Continuity (TAC). This allows automatic replay of in-flight transactions after a failure, maintaining session continuity.
-failover_restore AUTO Specifies that the session state is automatically restored after a successful replay – restoring PL/SQL package state, session context, etc.
-commit_outcome TRUE Ensures transaction outcome consistency. If a failure happens after a COMMIT, Oracle guarantees that the transaction outcome (committed or not) is correctly identified and replayed safely.
-failback YES When the preferred instance (TEST22) comes back online, the service will automatically move back to it.
-failovermethod BASIC Specifies TAF (Transparent Application Failover) behavior. BASIC means that the client reconnects to the failover instance when a connection loss occurs – simple but effective for many apps.

Using this method, whenever you patch Node 1, you can simply relocate the services to Node 2 to maintain continuity.

In modern ExaCS or ExaCC environments, you also have the option to temporarily increase OCPUs during the patching window. This helps minimize any performance impact on applications while one node is offline.

Below are the commands used to relocate a service.

-- node1 to node02
srvctl relocate service -d TEST2_EXA -s test2_uat_iap_srv -oldinst TEST21 -newinst TEST22
-- node2 to node01
srvctl relocate service -d TEST2_EXA -s test2_uat_kaf_srv -oldinst TEST22 -newinst TEST21

Note: I strongly recommend that database engineers and architects work closely with the application team to verify that there are no application-side disruptions before moving this approach into production.

 

Conclusion

High availability is no longer optional; it’s an essential requirement for any business operating in a data-driven world. Oracle Exadata platforms are engineered to deliver exceptional performance and resilience. Still, these benefits can only be fully realized when core features, especially those within Oracle Real Application Clusters (RAC), are properly implemented.

Transparent Application Continuity (TAC) is one of the most powerful RAC features available today. When enabled, it ensures that user sessions seamlessly survive node failures, planned maintenance, and rolling patching without requiring any application changes. This transforms routine maintenance into a zero-impact activity and allows businesses to stay secure and up to date without downtime.

By leveraging TAC, organizations unlock the true promise of Exadata and RAC: uninterrupted service, effortless scalability, and a smooth user experience, even in the face of disruptions. If you’ve invested in a high-performance system, make sure you’re using it to its fullest potential.