High Availability

How to patch Data Guard Environments on Oracle Cloud with Minimal Downtime

Introduction

Oracle Data Guard provides synchronous data replication to standby databases to ensure zero data loss in case of a disaster. In addition, the standby database can be used to offload RMAN backups, serve read-only and read-mostly workloads, and ensure high availability for planned maintenance.

This blog post provides the steps needed to patch Data Guard environments on Oracle Cloud with zero downtime. We define the scope of patching here as applying Release Updates (RUs), which are always RAC rolling and Standby-First installable.

Patching in Oracle Cloud

Cloud Tooling (Web Console, OCI CLI, APIs) provides automated procedures to patch your Oracle Databases. VM DB Systems are patched in-place, while Exadata Cloud Service databases are patched out-of-place by moving the database to another Oracle Home. For simplicity, we will refer to both as “patching” in this blog post.

Custom Database Software Images enables you to include one-off patches to the Release Update (RU) to apply them at once.

When you patch a standby database, the Cloud Tooling recognizes the database role and does not run datapatch. Datapatch requires the database to be open in read-write mode as it makes updates to the Data Dictionary.

The Environment

We will consider different environments:

  • Single instance primary and single instance standby databases.
  • Oracle RAC primary and Oracle RAC standby databases.

Single Instance Databases

To ensure zero downtime, a role switch is required:

  1. Patch the standby database via Cloud Tooling. The Cloud Tooling recognizes the standby role, updates the Database Home (the Oracle Software binaries), but does not run datapatch.
  2. Initiate a switchover via Cloud Tooling. The standby with higher Database Home version becomes the primary. During switchover, applications usually encounter a brownout period of about 1-2 minutes when using Application Continuity.
  3. Patch the new standby via Cloud Tooling. The Cloud Tooling recognizes the standby role, updates the Database Home, but does not run datapatch. At this point, both primary and standby have the updated Database Home, but the Data Dictionary is not yet up to date. This is not an issue from the operating perspective. But bugs are not fixed and new features are not available until datapatch is run and the Data Dictionary is updated. There is no time limit to run datapatch, but you need to run it eventually.
  4. Run datapatch manually on the primary database. The Data Dictionary updates will be automatically replicated on the standby by the Redo Apply process.
  5. Optional: initiate a second switchover via Cloud Tooling to revert the roles to the initial configuration.

If you have a maintenance window anyway and can afford downtime during the patching process, then no role switches are needed:

  1. Patch the standby database via Cloud Tooling. The Cloud Tooling recognizes the standby role, updates the Database Home, but does not run datapatch.
  2. Patch the primary database via Cloud Tooling. The Cloud Tooling recognizes the primary role and runs datapatch. The Data Dictionary updates wil be automatically replicated on the standby by the Redo Apply process. While patching the primary, your database will not be available for applications.

Oracle RAC Databases

For Oracle RAC databases, there is no need for role switches to achieve zero downtime. The Database Homes are updated in a rolling manner, one node at a time, ensuring the database is available for applications through the remaining nodes. Finally, datapatch runs while the database is open in read-write mode and available for operations.

  1. Patch the standby database via Cloud Tooling. The Cloud Tooling will patch all nodes in a rolling manner, which still matters if you are using Active Data Guard for reporting purposes. The standby role will be recognized and no datapatch will be run.
  2. Patch the primary database via Cloud Tooling. The Cloud Tooling will patch all nodes in a rolling manner and eventually applies datapatch. The Data Dictionary updates wil be automatically replicated on the standby by the Redo Apply process.

Indeed, applications do not even suffer from a short brownout like with Data Guard switchover, as database services on Oracle RAC environments are instantly relocated to other nodes and continue serving application requests. Follow Oracle’s best practices for Application Continuity.

Considerations

  • It is recommended to run datapatch as soon as possible. However, it is not an issue to have the Database Homes with a higher version than Data Dictionary.
  • For both single instance and Oracle RAC environments, ALWAYS patch the standby first. If you patch the primary first, the Cloud Tooling will run datapatch, and the Data Dictionary on the standby will get updated via the Redo Apply process, which leads to have a newer Data Dictionary than the Database Home on the standby site. You can still patch the standby afterwards, but if you encounter an outage on the primary in the meantime and need to switch over, you will run into issues and downtime until fixing the situation.
  • Redo Apply is automatically disabled and re-enabled when Primary or Standby are patched.

Conclusion

Data Guard environments using single instance databases can be patched with zero downtime by patching the standby database first, switching over, and patching the new standby. This process requires running datapatch manually on the primary database.

Data Guard environments using Oracle RAC databases do not require a role switch to achieve zero downtime, as patches are applied in a rolling manner, one node at a time.

Keep in mind, whatever configuration you have, patch the STANDBY FIRST.

Further Reading

Would you like to get notified when the next post is published?