Maintenance of a High Availability DB System

Oracle maintains a high availability DB systems using a rolling maintenance process that has minimal downtime. The maintenance starts within two hours of the Maintenance window start time that you define for the DB system.

The rolling maintenance process involves the following steps and does not require any input from you:

  1. One of the secondary nodes is removed from the replication group.
  2. The maintenance process is performed on the selected node and returned to the replication group when the maintenance completes.

    The maintenance process waits for the upgraded secondary to catch up with the transactions that occurred while it was being upgraded, before proceeding with the maintenance of the remaining secondary.

  3. The remaining secondary node is removed from the replication group.
  4. The maintenance process is performed on the selected node and returned to the replication group when the maintenance completes.

    The maintenance process waits for the upgraded secondary to catch up with the transactions which occurred while it was being upgraded, before proceeding with the maintenance of the primary.

  5. Existing connections to the primary are closed and no new connections are permitted. The primary node is removed from the group and one of the upgraded secondary nodes is promoted to primary. It is during this step that a brief period of downtime occurs before the newly promoted primary resumes connections.
    Note

    The current primary placement changes to the new primary. The preferred primary placement remains unchanged.
    Note

    The current binary log file name and position of the new primary may be different from the old primary. As the binary logs of each instance are managed independently, each transaction recorded in the binary logs may be written to a different binary log file and position in different instances.
  6. The maintenance process is performed on the old primary node and returned to the replication group as a secondary node. No switchback is performed to avoid additional downtime. If needed, you can perform a manual switchover at a convenient time.
Note

If the highly available DB system has an active inbound replication channel, the channel will be paused for the duration of the upgrade and resume when the upgrade finishes.