Skip to main content
Marios PavlidisPrincipal DBA
Financial Services

Oracle RAC Migration and Data Guard Implementation — Financial Services

Lead Database Architect and Migration Lead

Scope

  • Migration assessment and compatibility analysis for Oracle 11g to 19c
  • RAC design including node sizing, interconnect specification, and ASM disk group layout
  • Active Data Guard standby configuration at DR site
  • Performance baseline capture and post-migration comparison
  • Cutover procedure design with rollback capability
  • DBA team knowledge transfer and runbook development

Outcomes

  • Zero unplanned downtime during migration window
  • Reduction in planned failover time from 45 minutes to under 8 minutes
  • Active Data Guard enabled read offload for reporting workloads, eliminating a separate reporting replica
  • Post-migration query performance within 5% of baseline on critical paths
Oracle 19cReal Application ClustersData GuardActive Data GuardOracle ASMRMANOracle LinuxNetApp

Background

A financial services organisation was running Oracle 11g Release 2 on a two-node active/passive configuration. The environment was approaching end of extended support, and the existing HA model did not meet the revised RTO requirements set during a business continuity review.

The requirements for the new environment were:

  • Oracle 19c (long-term support release)
  • Active-active RAC at the primary site for local HA
  • Active Data Guard at the DR site for site-level protection
  • RTO target: under 15 minutes for any single-component failure
  • Zero data loss for planned failovers

Approach

Assessment Phase

The assessment covered schema compatibility, deprecated features, and SQL plan stability risks. Oracle’s Database Pre-Upgrade Information Tool was run against the production environment, and a test upgrade was performed against a refreshed copy of production to validate compatibility and capture any required remediation.

Particular attention was given to:

  • PL/SQL packages using deprecated or removed features
  • Statistics gathering and plan management implications of moving to the 19c optimizer
  • Application connection pooling configuration for RAC service-based connections

Architecture Design

The RAC design used two nodes at the primary site, each with its own compute and local SSD storage layer, connected via a dedicated 10Gbps interconnect network. Oracle ASM managed the shared storage (SAN via NFS), with separate disk groups for data, FRA, and OCR/voting.

Active Data Guard was configured with Maximum Availability protection mode — synchronous redo transport to the standby, allowing planned switchover with zero data loss and failover with near-zero data loss under most network conditions.

Migration Execution

The migration used an RMAN duplicate approach:

  1. Backup of 11g source database
  2. Duplicate to a new 19c single-instance environment for compatibility testing
  3. Performance testing and SQL plan management (SQL Plan Baselines captured from 11g AWR data)
  4. Full production duplicate to the new 19c RAC environment during a maintenance window
  5. Incremental RMAN synchronisation to minimise the final cutover window
  6. Application connection string update and validation
  7. Data Guard standby synchronisation

Cutover

The planned cutover window was 4 hours. Actual cutover took 2 hours 40 minutes, with the remainder held as contingency. Rollback was available for the first 90 minutes of the window if a critical issue was identified.

Lessons Learned

SQL plan regression risk is real: Several queries regressed under the 19c optimizer despite SQL Plan Baselines. Pre-testing with production-representative data and a stabilisation period before cutover is essential.

RAC service configuration matters: Applications not configured to use RAC services correctly do not benefit from load balancing and do not reconnect cleanly after node failure. Service configuration should be tested as a first-class concern, not an afterthought.

Active Data Guard read offload requires application awareness: The reporting team needed query routing updated to point to the standby listener. This was a coordination task that required more lead time than anticipated.