There are several points to consider before beginning to patch or upgrade your Oracle Database software.

• If you are using the Oracle Data Guard broker to manage your configuration, follow the instructions in the Oracle Data Guard Broker manual for information about removing or disabling the broker configuration.

• The procedures described in these topics are to be used in conjunction with the ones contained in the Oracle Database Upgrade Guide.

• Check for nologging operations. If nologging operations have been performed then you must update the standby database. See Recovering After the NOLOGGING Clause Is Specified for details.

• Make note of any tablespaces or data files that need recovery due to OFFLINE IMMEDIATE. Tablespaces or data files should be recovered and either online or offline prior to upgrading.

• In an Oracle Data Guard configuration, all physical and snapshot standby databases must use a copy of the password file from the primary database. As of Oracle Database 12c Release 2 (12.2.0.1) , password file changes done on the primary database are automatically propagated to standby databases. (Password file changes include when an administrative privilege (SYSDG, SYSOPER, SYSDBA, and so on) is granted or revoked, and when the password of any user with administrative privileges is changed.)

  Far sync instances are an exception to the automatic updating feature. Updated password files must still be manually copied to far sync instances because far sync instances receive redo, but do not apply it. When a password file is manually updated at a far sync instance, the redo containing the same password changes from the primary database is automatically propagated to any standby databases that are set up to receive redo from that far sync instance. The password file is updated on the standby when the redo is applied.

These steps show how to upgrade to Oracle Database when a physical standby database is present in the configuration.

1. Review and perform the standard preupgrade preparation tasks described in Oracle Database Upgrade Guide.
2. Install the new release of the Oracle software into a new Oracle home on the physical standby database and primary database systems, as described in Oracle Database Upgrade Guide
3. Shut down the primary database.
4. Shut down physical standby databases.
5. Stop all listeners, agents, and other processes running in the Oracle homes that you want to upgrade (Source Oracle homes). Perform this step on all nodes in an Oracle Real Application Clusters (Oracle RAC) environment.
6. In the new Oracle home (Target Oracle home), restart all listeners, agents, and other processes that you stopped in the source Oracle home
7. Mount physical standby databases on the target Oracle home (upgraded version).

   Caution:

   Do not open standby databases until the primary database upgrade is completed.

   See Start the Physical Standby Database for information on how to start a physical standby database.

8. Start Redo Apply on the physical standby databases.

   Note:

   By default, AutoUpgrade disables log shipping. If you have modified your AutoUpgrade configuration file to enable log shipping, then modify your AutoUpgrade configuration file to set the AutoUpgrade locally modifiable global parameter defer_standby_log_shipping to no. For example: upg1.defer_standby_log_shipping=no
   See Start the Physical Standby Database for information on how to start Redo Apply.
9. Upgrade the primary database. Physical standby databases are upgraded when the redo generated by the primary database as it is upgraded is applied to standbys.
10. Open the upgraded primary database.
11. If Oracle Active Data Guard was being used before the upgrade, then you must reenable it after upgrading.

    See Real-time query

12. (Optional) When ready. modify the COMPATIBLE initialization parameter.

    Note:

    On Microsoft Windows platforms, it is necessary to use the ORADIM utility to delete the database service (for the old database version), and to create a new database service for the new database version. You must replace the OracleServiceSID on both the primary and standby servers.

These steps describe the traditional method for upgrading your Oracle Database software with a logical standby database in place.

1. Set the data protection mode to MAXIMUM PERFORMANCE at the primary database, if needed:

   SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;
   

2. On the primary database, stop all user activity and defer the remote archival destination associated with the logical standby database (for this procedure, it is assumed that LOG_ARCHIVE_DEST_2 is associated with the logical standby database):

   SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER SCOPE=BOTH;
   SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
   

3. Stop SQL Apply on the logical standby database:

   SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
   

4. On the primary database install the newer release of the Oracle software. .
5. On the logical standby database, install the newer release of the Oracle software.

   Note:

   Steps 4 and 5 can be performed concurrently (in other words, the primary and the standby databases can be upgraded concurrently) to reduce downtime during the upgrade procedure.

6. On the upgraded logical standby database, restart SQL Apply. If you are using Oracle RAC, start up the other standby database instances:

   SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
   

7. Open the upgraded primary database and allow users to connect. If you are using Oracle RAC, start up the other primary database instances.

   Also, enable archiving to the upgraded logical standby database, as follows:

   SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;
   

8. Optionally, reset to the original data protection mode if you changed it in Step 1.
9. Optionally, modify the COMPATIBLE initialization parameter.

When you upgrade to a new release of Oracle Database, certain new features might make your database incompatible with your previous release.

Perform these steps to downgrade Oracle Database in an Oracle Data Guard configuration that does not contain a logical standby database.

1. Ensure that all physical standby databases are mounted, but not open. Do not open the standby database(s) until all redo generated by the downgrade of the primary database has been applied.
2. Start Redo Apply, in real-time apply mode, on the physical standby database(s).
3. Downgrade the primary database using the procedure described in Oracle Database Upgrade Guide, keeping the following in mind:

   • At each step of the downgrade procedure where a script is executed, execute the script only at the primary database. Do not perform the next downgrade step until all redo generated by the execution of the script at the primary database has been applied to each physical standby database.

   • At each step of the downgrade procedure where an action other than running a script is performed, perform the step at the primary database first and then at each physical standby database. Do not perform the next downgrade step at the primary database until the action has been performed at each physical standby database.

4. If it becomes necessary to perform a failover during a downgrade, perform the failover and then continue with the downgrade procedure at the new primary database.

Perform these steps to downgrade Oracle Database in an Oracle Data Guard configuration that contains a logical standby database or a mixture of logical and physical standby databases.

1. Issue the following command at the primary database (database P, for the sake of this discussion) before you downgrade it:

   SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY;
   

   Database P is no longer in the primary database role.

2. Wait for all standby databases in the configuration to finish applying all available redo. To determine whether each standby database has finished applying all available redo, run the following query at each standby database:

   SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
    
   SWITCHOVER_STATUS
   -----------------
   TO PRIMARY
   

   Do not continue on to step 3 until the query returns a value of TO PRIMARY for all standby databases in the configuration.

3. Downgrade the logical standby databases using the procedures described in Oracle Database Upgrade Guide, keeping the following in mind:

   • At each step of the downgrade procedure where a script is executed, execute the script only at the logical standby databases. Do not perform the next downgrade step until all redo generated by executing the script at the logical standby database that was most recently in the primary role (database P) has been applied to each physical standby database.

   • At each step of the downgrade procedure where an action other than running a script is performed, first perform the step at the logical standby database that was most recently in the primary role (database P), and then perform the step at each physical standby database. Do not perform the next downgrade step at the logical standby database that was most recently in the primary role (database P) until the action has been performed at each physical standby database.

4. After the logical standby that was most recently in the primary role (database P) has been successfully downgraded, open it, and issue the following command:

   SQL> ALTER DATABASE ACTIVATE LOGICAL STANDBY DATABASE;
   

   Database P is now back in the primary role.

5. At each of the logical standby databases in the configuration, issue the following command (note that the command requires that a database link back to the primary exist in all of the logical standby databases):

   SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE NEW PRIMARY
   prim_db_link;