Step‑by‑Step Migration of a 2‑Node Oracle 11gR2 RAC to New Hardware with Active Data Guard

Project Background

The goal is to migrate an existing 2‑node Oracle 11gR2 RAC database to new hardware (new servers and storage) by deploying Active Physical Standby Data Guard, while also adding a second standby RAC cluster in the production environment.

Technical Architecture

The architecture consists of the primary RAC cluster, a physical standby RAC cluster, and the network configuration required for Data Guard communication.

Implementation Process

A high‑level flow diagram of the implementation steps is shown below.

Pre‑Implementation Preparation

Primary Site : The existing database is already the ADG primary.

Standby Site :

Install and configure dual‑node Linux.

Install and configure dual‑node Oracle 11g Grid Infrastructure.

Install and configure dual‑node Oracle 11g RAC software.

Implementation Steps

Adjust Existing Environment Update /etc/hosts to add SCAN IP resolution for the four hosts.

Configure Primary RAC Parameters

Check that Force Logging is enabled.

Create standby redo logs (review existing redo log composition).

Modify Data Guard‑related initialization parameters.

Create Standby Database PFILE Create a temporary backup directory and generate the PFILE.

Update tnsnames.ora Modify the network service file to include the standby entries.

Backup the Primary Database Run the full backup script shown below.

Prepare Standby RAC Database

Create required directories.

Copy backup files.

Copy password files (Data Guard requires identical passwords on both sides).

Create parameter files.

Adjust environment variables.

Add the standby entry to tnsnames.ora.

Create Physical Standby Database

Test connections on all primary and standby nodes.

Start the standby instance to MOUNT state.

Recover the database.

Verify parameters.

Create online redo and standby redo logs, then restart the database.

Register the standby database in the OCR.

Enable log apply and verify its progress.

Physical Switchover

Shutdown one node of the RAC to perform the switchover.

Consider operations such as avoiding large transactions, checking existing transactions, reviewing alert logs, and ensuring only one instance remains primary.

Execute the switchover commands (illustrated in the diagram).

Verify that log apply is progressing on both primary and standby.

Post‑Switchover Data Confirmation In theory the physical standby and primary are identical; the switchover does not cause data loss. Nevertheless, perform checks such as verifying data consistency, confirming redo log application, and ensuring no orphan transactions remain.

Impact Assessment

During role switching, database start/stop operations are required; avoid performing the switch while large transactions are running to minimize downtime. Typical switchover time is under three minutes, after which client connection strings must be updated.

Emergency Rollback Measures

If an exception occurs that would cause unacceptable downtime, abort the ADG switchover and reschedule. Should the physical standby encounter unrecoverable errors, revert it back to primary using the rollback steps illustrated below.

Lessons Learned (Pitfalls)

During testing, a previously existing single‑node ADG was omitted, leading to an unexpected situation during the switchover, as shown in the following screenshot.