Upgrade, Data Guard, and Restore Points

Flashback Database is the best way to protect your Oracle Database during upgrade. It requires that you create restore points before the upgrade. If the upgrade fails, getting back to the starting point is easy and fast.

Enterprise Edition

It requires Enterprise Edition, but so does Data Guard. So it is not an issue here.

Guaranteed Restore Points

The restore points that you create to protect your Oracle Database upgrade should be guaranteed restore points. This ensures that you can always go back to the starting point. If you run out of disk space in your Fast Recovery Area (FRA), the database will halt and thus not jeopardize your fallback plan. The alternative to regular restore points is that the database will overwrite flashback logs to maintain operation, which is not desirable in this situation. You are relying on the restore point as your fallback.

Order of Creation

Always follow this order when creating restore points:

  1. All standby databases
  2. Primary database

The SCN of the restore points on the standby database must be the same or lower than on the primary database.

Imagine this scenario:

SCN Primary Standby
100 Restore point created
105 Restore point created
110 Upgrade starts
200 Upgrade fails

To flashback:

Primary Standby
Flash back standby database to SCN 100
Flash back primary database to SCN 105
Open primary database with resetlogs. Creates a new incarnation as of SCN 105
Roll forward standby database from SCN 101 to 105 and follow new incarnation

If the restore point on the standby database was created at SCN 106, then the primary database is already at a new incarnation (as of SCN 105). The standby database can’t follow and needs to be completely rebuilt.

Primary Database

When you upgrade with AutoUpgrade, it will create a guaranteed restore point for you. It is the default behavior.

The restore point created by AutoUpgrade protects the primary database only.

Standby Database

Always create the restore points on the standby database:

From the docs:

Restore points that are created on a primary database are automatically replicated to the standby database. The restore points created on the standby database are called replicated restore points. Irrespective of whether a restore point on the primary database is a guaranteed restore point or a normal restore point, the corresponding replicated restore point is always a normal restore point.

By design, all replicated restore points are not guaranteed; even if it was guaranteed on the primary database. When you protect a standby database during upgrade, you want the restore point to be guaranteed; thus, you must create them manually.

To create a restore point on the standby database, you must cancel redo apply:

SQL> alter database recover managed standby database cancel;
SQL> create restore point STBY_GRP guarantee flashback database;
SQL> alter database recover managed standby database disconnect from session;

If you forget to cancel redo apply, you run into:

SQL> create restore point STBY_GRP guarantee flashback database;
create restore point STBY_GRP guarantee flashback database
*
ERROR at line 1:
ORA-38784: Cannot create restore point 'STBY_GRP'.
ORA-01153: an incompatible media recovery is active

Remove Restore Points

Don’t forget to remove the restore points after the upgrade. Do so when you have run your tests, and you are sure you won’t go back to the old release:

SQL> drop restore point STBY_GRP;
  • The order of removal is not important
  • It does not require downtime to remove the restore points

If you instruct AutoUpgrade to remove the restore point after upgrade (drop_grp_after_upgrade), it will happen only on the primary database. You must manually remove the restore points from the standby database.

Failure to remove the restore points will eventually fill up the FRA bringing the database to a complete halt.

Other Blog Posts in This Series

3 thoughts on “Upgrade, Data Guard, and Restore Points

  1. Hi Daniel,

    My database is 10gR2 (10.2.0.4) + ASM. DB size is more than 15TB. There is no Data Guard. I want to upgrade to 19c. Can I do as following steps:
    – Add new diskgroup DATA_NEW
    – Using RMAN for creating Rolling Forward Image Copies into new diskgroup DATA_NEW
    – Stop all application
    – Update image copy to lastest status
    – Mount ASM diskgroup DATA to 19c-server
    – Execute Upgrade manually.

    Is this solution feasible ? Can i use the image copy for backup in case upgrade failure ?

    Regards,

    Like

    1. Hi,
      It’s not possible to directly upgrade from 10.2.0.4 to 19c. You need to pass by 11.2.0.4 first. You can use image copies to spin up a copy of the database, but you can also settle with Flashback Database as a fallback mechism.

      Perhaps it is easier to use Data Pump? If you do, please ensure that you install the Data Pump bundle patch on the 19c Oracle Home before the import. Be sure to visit our Data Pump webinars and pay attention to things like statistics.

      Regards,
      Daniel

      Liked by 1 person

  2. Hi Daniel,

    Thanks for your response soon.

    I’ve seen all videos about Data Pump on Youtube of Oracle Channel. They’re very usefull. But using Data Pump will take alot of downtime.

    Using Flashback Database is one of my options. But upgrading on itself can be risky, specially upgrading 2 stages. So, I think about image copy. It is a physical full backup and easy to re-build original database with less risky.

    Regards,
    Tri Tuc

    Liked by 1 person

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.