Maximizing Application Continuity with Oracle Transparent Application Continuity

Maximizing Application Continuity with Oracle Transparent Application Continuity

Understanding Oracle Transparent Application Continuity

In today's fast-paced and complex technology landscape, ensuring the seamless operation of applications is crucial for businesses. This is where Oracle Transparent Application Continuity (TAC) comes into play. TAC is a feature that provides continuous and uninterrupted user experiences during planned or unplanned outages, ensuring that no user transaction is lost or rolled back due to failures.

The Core Functionality of Oracle Transparent Application Continuity

At its core, TAC captures the state of in-flight user transactions and replays them against the database, ensuring that no data is lost during a failure. This means that regardless of the underlying issues, be it a server failure, network glitch, or database outage, TAC ensures that users can continue their transactions seamlessly without any disruption.

How Does Oracle Transparent Application Continuity Work?

Starting with Oracle Database19c, Transparent Application Continuity (TAC) transparently tracks and records session and transactional state so the database session can be recovered following recoverable outages. This is done with no reliance on application knowledge or application code changes, allowing TAC to be enabled for your applications. Application transparency and failover are achieved by consuming the state-tracking information that captures and categorizes the session state usage as the application issues user calls.

STEPS FOR USING APPLICATION CONTINUITY :-

  1. Return Connections to the Connection Pool When using an Oracle connection pool, such as Universal Connection Pool (UCP) or OCI Session Pool, or ODP.Net Unmanaged Provider or when using WebLogic Active GridLink and also RedHat JBoss, request boundaries are embedded for you. The application must return the connection to the Oracle connection pool on each request to obtain request boundaries
  2. FAILOVER_RESTORE on the ServiceThe attribute FAILOVER_RESTORE should be set on your database service. FAILOVER_RESTORE=AUTO for TAC. All modifiable parameters are restored automatically by using a wallet
  3. Restore Original Function Values Support for keeping the original results of Oracle functions is provided for SYSDATE, SYSTIMESTAMP, SYS_GUID, sequence.NEXTVAL, CURRENT_TIMESTAMP and LOCALTIMESTAMP. Identity sequences are supported for owned sequences in SQL. If the original values are not kept and different values are returned to the application at replay, replay is rejected. Oracle Database 19c KEEPs the original values for SQL automatically. If you are using PLSQL, then GRANT KEEP for application users, and the KEEP clause for a sequence owner.
  4. Side Effects : When a database request includes an external call such as sending MAIL or transferring a file then this is termed a side effect. When replay occurs, there is a choice as to whether side effects should be replayed. Many applications want to repeat side effects such as journal entries, and sending mail. For Application Continuity side effects are replayed (and may be disabled using disableReplay). Conversely, as Transparent Application Continuity is on by default, TAC does not replay side effects.

USE DATABASE SERVICE

This cannot be the default database service or the default PDB service (the service with the same name as the database or PDB). , Need to create Database Service with high availability features: FAN, Draining and Application Continuity so Your application must connect to a service to use the high availability features: FAN, Draining and Application Continuity

Server-Side Steps for Services :-

srvctl add service -db mydb -service TACSERVICE -pdb mypdb –preferred inst1 - available inst2 -failover_restore AUTO -commit_outcome TRUE -failovertype AUTO - replay_init_time 600 -retention 86400 -notification TRUE -drain_timeout 300 - stopoption IMMEDIATE -role PRIMARY

CONFIGURE URL OR CONNECTION STRING FOR HIGH AVAILABILITY Client Side :-

Oracle recommends that your application uses the following connection string configuration for successfully connecting at basic startup, failover, switchover, and fallback.

Alias (or URL) = (DESCRIPTION = (CONNECT_TIMEOUT= 90)(RETRY_COUNT=50)(RETRY_DELAY=3)(TRANSPORT_CONNECT_TIMEOUT=3) (ADDRESS_LIST = (LOAD_BALANCE=on) (ADDRESS = (PROTOCOL = TCP)(HOST=primary-scan)(PORT=1521))) (ADDRESS_LIST = (LOAD_BALANCE=on) (ADDRESS = (PROTOCOL = TCP)(HOST=secondary-scan)(PORT=1521))) (CONNECT_DATA=(SERVICE_NAME = gold-cloud))

要查看或添加评论,请登录

shouki khalid的更多文章

  • Upgrading Oracle Application Express (APEX)

    Upgrading Oracle Application Express (APEX)

    Preparation :- Ensure the new APEX version is compatible with your Oracle Database version. Review the release notes…

  • Oracle Database Flashback Technologies

    Oracle Database Flashback Technologies

    Oracle Database Flashback Technologies is a comprehensive range of tools for data recovery solutions that reverse human…

  • Client connection pooling

    Client connection pooling

    Client connection pooling in an Oracle database context refers to a method where a pool of database connections is…

  • Oracle Statspack

    Oracle Statspack

    Oracle STATSPACK (Statistics Package) is a performance diagnostic tool provided by Oracle to collect, store, and…

  • Disaster Recovery (DR) drill using Oracle Data Guard

    Disaster Recovery (DR) drill using Oracle Data Guard

    Performing a Disaster Recovery (DR) drill using Oracle Data Guard involves several best practices to ensure a…

    1 条评论
  • Oracle EBS R12 shared file system using oracle cloud FSS

    Oracle EBS R12 shared file system using oracle cloud FSS

    Creating a shared file system for Oracle E-Business Suite (EBS) R12 using Oracle Cloud File Storage Service (FSS)…

社区洞察

其他会员也浏览了