Zero‑Downtime Oracle MAA Upgrade: From 11gR2 to 12c Using Transient Logical Standby

In this article, Tang Bo from the Chinese Academy of Sciences shares a step‑by‑step process for upgrading an Oracle MAA (Maximum Availability Architecture) system from Oracle 11gR2 (11.2.0.4) to Oracle 12c (12.1.0.2) while keeping front‑end services running.

1. Environment Overview

The target environment consists of four x86_64 servers (station11, station12, station13, station14). Stations 11 and 12 host a two‑node RAC primary database; stations 13 and 14 host the physical Data Guard standby. All servers already have the 12.1.0.2 Grid Infrastructure installed under /u01/app/12.1.0/grid, and the Oracle binaries for 11.2.0.4 are installed under /u01/app/11.2.0/grid. Images of the server layouts are shown throughout the article.

2. Upgrade Plan

The upgrade is divided into four main phases:

Upgrade all Grid Infrastructure (GI) components using two Data Guard switchover operations.

Convert the physical standby to a Transient Logical Standby so that the standby can run a higher software version than the primary.

Run the Oracle dbua tool on the logical standby to upgrade the database software.

Perform a final switchover, revert the original primary to a physical standby, and bring all instances back online.

The key to achieving near‑zero downtime is the logical‑standby conversion, which allows the standby to be upgraded while the primary continues to serve traffic.

3. Detailed Steps

3.1 Upgrade Grid Infrastructure (GI)

Two Data Guard switchover cycles are performed:

Disable the Data Guard Broker on the primary ( station11) and standby ( station13) using the provided SQL scripts.

Ensure flashback areas are correctly sized on both primary and standby.

Verify that the standby is in a healthy RECOVER MANAGED STANDBY DATABASE state.

After each switchover, the GI version is upgraded on the newly‑promoted primary.

3.2 Convert Physical Standby to Transient Logical Standby

The My Oracle Support Bulletin 949322.1 provides a Bash script physru.sh that automates the conversion. The script creates a flashback restore point ( PRU_0000_0001) on both databases, then runs DBMS_LOGSTDBY.BUILD to build the logical standby. Important notes:

The TNS entry used by the script must point to a single instance (no load‑balancing or failover).

Unsupported objects (e.g., tables owned by SYS, materialized‑view support tables, compressed tables, BFILE columns) are listed in physru_unsupported.log. If such objects exist, additional handling is required.

The script is designed to be run three times; the first two executions perform the conversion and initial data sync, the third completes the rolling patch.

3.3 Run DBUA on the Logical Standby

With the standby now logical, the dbua utility is launched from the Grid Infrastructure GUI on station13. The upgrade proceeds while the primary continues to accept transactions. After the upgrade, verification steps include checking the DATABASE_ROLE (should be TRANSIENT LOGICAL STANDBY) and confirming that recent DML on the primary is visible on the standby.

3.4 Final Switchover and Cleanup

After the logical standby is upgraded, a final Data Guard switchover makes the former standby the new primary. The original primary is flashback‑recovered to the restore point and returned to a physical standby role. Subsequent tasks include:

Re‑enable the Data Guard Broker.

Update the compatible parameter to 12.1.0.2.0 on both databases (after thorough testing).

Adjust /etc/oratab and .bash_profile files on all nodes to point to the new Oracle home.

Refresh listener configuration files ( listener.ora) on each server.

Run setasmgid as root to grant ASM access to the new binaries.

Verify that all instances are up, that the two test transactions (salary update and table creation) exist on both sides, and that the flashback restore points have been removed.

4. Summary

The complete upgrade from Oracle 11.2.0.4 MAA to 12.1.0.2 MAA was accomplished with only about two minutes of primary service downtime, effectively a zero‑impact migration. The process leveraged the physical‑to‑logical‑to‑physical standby conversion, the physru.sh script, and the Oracle Database Upgrade Assistant (DBUA). Attachments include the full physru_unsupported.log and zip files containing network configuration scripts and other utilities.

Key takeaways:

Transient Logical Standby enables rolling upgrades without stopping the primary.

Proper flashback configuration and restore points are essential for safe rollback.

Thorough testing of the compatible parameter change is required before production rollout.