B Patching, Upgrading, and Downgrading Databases in an Oracle Data Guard Configuration
These topics address how to upgrade and downgrade an Oracle database when a physical or logical standby database is present in the Oracle Data Guard configuration.
Before You Patch or Upgrade the Oracle Database Software
Before you patch or upgrade your Oracle Database software, review the prerequisites for different use case scenarios.
-
If you are using the Oracle Data Guard broker to manage your configuration, follow the instructions in Oracle Data Guard Broker
-
Use procedures described in these topics in conjunction with other upgrade procedures and guidelines provided in Oracle Database Upgrade Guide.
-
Check for
NOLOGGING
operations. IfNOLOGGING
operations have been performed then you must update the standby database. -
Make note of any tablespaces or data files that need recovery due to
OFFLINE IMMEDIATE
. Before starting an upgrade, tablespaces or data files should be recovered, and either online or offline. -
In an Oracle Data Guard configuration, all physical and snapshot standby databases must use a copy of the password file from the primary database. Password file changes done on the primary database are automatically propagated to standby databases. Password file changes are events such as 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.
Note:
If there are cascaded standbys in your configuration, then those cascaded standbys must follow the same rules as any other standby, but should be shut down last, and restarted in the new home first.
Related Topics
Patching Oracle Database with Standby First Patching
Oracle Data Guard Standby-First Patch Apply provides support for different database home software between a primary database and its physical standby database(s).
This support is provided for the purpose of applying and validating Oracle patches and patch bundles in rolling fashion with minimal risk to the primary database. For example, with Data Guard Standby-First Patch Apply you apply a database home patch first to a physical standby database. The standby is used to run read-only workload, or read-write workload if it is a snapshot standby, for testing and evaluation of the patch. After passing evaluation, the patch is then installed on the primary system with greater assurance of the effectiveness and stability of the database home patch.
Oracle Data Guard Standby-First Patch Apply is supported only for certified interim patches and patch bundles (for example, Patch Set Update, or Database Patch for Exadata) for Oracle Database 11.2.0.1 and later, on both Oracle Engineered Systems (e.g. Exadata, SuperCluster) and non-Engineered Systems. A patch and patch bundle that is Data Guard Standby-First certified states the following in the patch README:
Data Guard Standby-First Installable
The following types of patches are candidates to be Data Guard Standby-First certified:
-
Database home interim patches
-
Exadata bundle patches (e.g. Monthly and quarterly database patches for Exadata)
-
Database patch set updates
Patches and patch bundles that update modules that may potentially disrupt the interoperability between primary and physical standby systems running different database home software are not certified “Data Guard Standby-First Installable” and do not state so in the patch README.
Oracle patch sets and major release upgrades do not qualify for Data Guard Standby-First Patch Apply. For example, upgrades from 11.2.0.2 to 11.2.0.3 or 11.2 to 12.1 do not qualify. Use the Data Guard transient logical standby rolling upgrade process for database patch sets and major releases.
Additionally, as of Oracle Database 11g Release 2 (11.2.0.1), a physical standby database can be used to install eligible one-off patches, patch set updates (PSUs), and critical patch updates (CPUs), in rolling fashion. For more information about this functionality, see the My Oracle Support note 1265700.1 at http://support.oracle.com
.
Upgrading Oracle Database with a Physical Standby Database in Place
These steps show how to upgrade to Oracle Database when a physical standby database is present in the configuration.
Note:
If the database being upgraded is a member of an Oracle Data Guard broker configuration, then before proceeding, you must disable fast-start failover and shut down the broker. For information about how to do this, see Oracle Data Guard Broker .Upgrading Oracle Database with a Logical Standby Database in Place
These steps describe the traditional method for upgrading your Oracle Database software with a logical standby database in place.
Note:
Using SQL Apply to Upgrade the Oracle Database presents an alternative method to perform an upgrade with a logical standby database in place in a rolling fashion to minimize downtime. Use the steps from only one method to perform the complete upgrade. Do not attempt to use both methods or to combine the steps from the two methods as you perform the upgrade process.
Perform the following steps to upgrade to Oracle Database 12c Release 2 (12.2) when a logical standby database is present in the configuration. These steps assume that the primary database is running in MAXIMUM PERFORMANCE
data protection mode.
Related Topics
Modifying the COMPATIBLE Initialization Parameter After Upgrading
When you upgrade to a new release of Oracle Database, certain new features might make your database incompatible with your previous release.
Oracle Database enables you to control the compatibility of your database with the COMPATIBLE
initialization parameter.
After the upgrade is complete, you can increase the setting of the COMPATIBLE
initialization parameter to the maximum level for the new Oracle Database release. When you are certain that you no longer need the ability to downgrade your database back to its original version, set the COMPATIBLE
initialization parameter based on the compatibility level you want for your new database.
In an Oracle Data Guard configuration, if you decide to increase the setting of the COMPATIBLE
initialization parameter after upgrading, then it is important that you perform the following steps in the order shown (be sure the standby database has a COMPATIBLE
setting equal to, or higher than, the primary):
-
Increase the value of the
COMPATIBLE
initialization parameter on all standby databases in the configuration first, as follows:-
Ensure that apply is current on the standby database(s).
-
On one instance of each standby database, execute the following SQL statement:
ALTER SYSTEM SET COMPATIBLE=<value> SCOPE=SPFILE;
-
If Redo Apply or SQL Apply is running, then stop them.
-
Restart all instances of the standby database(s).
-
If you previously stopped Redo Apply or SQL Apply, then restart them.
-
-
Increase the value of the
COMPATIBLE
initialization parameter on the primary database, as follows:-
On one instance of the primary database, execute the following SQL statement:
ALTER SYSTEM SET COMPATIBLE=<value> SCOPE=SPFILE;
-
Restart all instances of the primary database.
-
See Also:
-
Oracle Database Upgrade Guide for more information about compatibility settings
Downgrading Oracle Database with No Logical Standby in Place
Perform these steps to downgrade Oracle Database in an Oracle Data Guard configuration that does not contain a logical standby database.