You can update Oracle Database deployed with Oracle Data Guard by using OPatchAuto,
To simplify the patching process, Oracle recommends that you use Oracle Fleet Patching and Provisioning for databases deployed with Oracle Data Guard. If you do not use Oracle Fleet Patching and Provisioning, then DBCA is also a good option to use. As an alternative, you can also use OPatchAuto.
Note:
As a best practice to simplify maintenance and avoid potential issues, Oracle strongly recommends that you perform database maintenance using a new Oracle home and out-of-place patching. This is the preferred deployment choice for patching operations.- Checks and Prerequisites for Using OPatch and OPatchAuto
Download the patch, and before you perform software maintenance, review the guidelines and prerequisites for your planned deployment scenario. - Check System Requirements
Before you start OPatch, check to ensure that you have required environment dependencies. - Detect and Resolve Interim Patch Conflicts in the Grid Home
You must detect and resolve any interim (one-off) patch conflicts before running OPatchAuto in the Oracle Real Application Clusters database homes, and in the Oracle Grid Infrastructure Grid home. - Run OPatch System Space Check
Check if enough free space is available on theORACLE_HOME
file system for the patches that you want to apply. - Update Software on Databases with Oracle Data Guard Using OPatchAuto
After any patch conflicts are resolved, you can proceed with updating your software manually using OPatchAuto. - Load Modified SQL Files into the Database
When you use OPatch to perform database maintenance, you must run thedatapatch
tool manually so that the tool can load modified SQL files into the database. - Upgrade Oracle Recovery Manager Catalog
If you are using the Oracle Recovery Manager, then the catalog needs to be upgraded. - Known Issues
Learn how to find if an issue you have encountered while running OPatch is a known issue. - Documentation Accessibility
Checks and Prerequisites for Using OPatch and OPatchAuto
Download the patch, and before you perform software maintenance, review the guidelines and prerequisites for your planned deployment scenario.
Note:
Before starting to apply a maintenance Release Update or interim patch, Oracle strongly recommends that you take a backup of any Oracle home binaries, Grid home binaries, and the central Oracle Inventory (oraInventory that can be affected by the update). For further information, see:
Download and Unzip the Patch
Oracle recommends that you download and use the latest released OPatch version. Download the latest version from My Oracle Support:
My Oracle Support patch 6880880
You unzip the patch as the owner of the Oracle software binaries. This is the Oracle user for Oracle Database and Oracle Real Application Clusters (Oracle RAC).
ORACLE_HOME/OPatch
For exact instructions to install OPatch, follow the readme included with the tool download.
See Also:
For detailed OPatch documentation, including any known issues, see:
Guidelines for OPatch or OPatchAuto Maintenance
Release Updates (RUs) from
Automated Release Update (ARU) or My Oracle Support are cumulative. That is, the
content of all previous RUs for a given software release are included in the latest
RU. To increase performance by deleting inactive patches, Oracle recommends that you
run OPatch with the listorderedinactivepatches
and
deleteinactivepatches
options. For more information, see:
To use OPatch or OPatchAuto to install the latest software update for your Oracle software, the software home must have the latest release software already installed. For example, to install the latest RU for Oracle Database 23ai, you must first have installed Oracle Database 23ai in the Oracle home where you want to apply the most recent RU. You can find more information about your patch requirements and options in the Download Reference for software updates:
Patches typically include Java Development Kit (JDK) fixes released since the previous RU, and will update the JDK in the Oracle home.
The UTL_URI.ESCAPE
function
is now compliant with RFC 3896 and will treat "#
" as a reserved
character. For more information, see:
Deployment Guidelines for Oracle RAC or Oracle Grid Infrastructure
To deploy RUs or patches manually, you can use OPatchAuto. These updates can be installed as rolling patches for Oracle Grid Infrastructure or Oracle RAC.
Caution:
Do not attempt to use OPatch to patch software in an Oracle Grid Infrastructure home (Grid home).You no longer require a separate Oracle Database Embedded JVM (OJVM) RU bundle patch. OJVM fixes can now be applied as rolling updates to Oracle RAC, and are included in the Database RU bundles. For more information, See:
Primary Note for Database Proactive Patch Program (Doc ID 888.1)
Validating the Oracle Inventory on Oracle Grid Infrastructure and Oracle RAC Cluster Members
Before beginning patch application, check the consistency of inventory information for the Grid home and each Oracle home that you plan to patch. Run this command as the respective Oracle home owner to check the consistency, where <ORACLE_HOME> is the Oracle home or Grid home:
$ <ORACLE_HOME>/OPatch/opatch lsinventory -detail -oh <ORACLE_HOME>
If this command succeeds, then it lists the Oracle components that are installed in the home. Save the output so that you have the status of the inventory before you start the patch application.
If this command fails, then contact Oracle Support for assistance.
Deployment Guidelines for Oracle Data Guard
To deploy RUs and patches in Oracle homes deployed with Oracle Data Guard, you can use OPatchAuto. For information about how to apply updates in homes configured with Oracle Data Guard, and how to reduce downtime, see:
Oracle Patch Assurance - Data Guard Standby-First Patch Apply (Doc ID 1265700.1)
For the latest Update with Security Fixes that should be used on Client-Only installations, refer to the Critical Patch Update (CPU) Program Patch Availability Document (PAD) section on Oracle Database for the cycle in which you are interested.
Check System Requirements
Before you start OPatch, check to ensure that you have required environment dependencies.
Ensure that the $PATH
definition has the following
executables:
make
ar
ld
nm
The location of these executables depends on your operating system. On
many operating systems, they are located in /usr/ccs/bin
. Ensure
that your path environment includes the location of the executables. For example:
export PATH=$PATH:/usr/ccs/bin
Parent topic: OPatchAuto Maintenance for Oracle Data Guard
Detect and Resolve Interim Patch Conflicts in the Grid Home
You must detect and resolve any interim (one-off) patch conflicts before running OPatchAuto in the Oracle Real Application Clusters database homes, and in the Oracle Grid Infrastructure Grid home.
Oracle recommends that you use the "Patch Recommendations and Patch Plans" features on the Patches & Updates tab in the My Oracle Support search results page for a patch search. These features are the fastest and easiest way to determine whether you have interim patches in the Oracle home that conflict with a Release Update (RU), and to obtain the conflict resolution patches that you will require. The "Patch Recommendations and Patch Plans" features work in conjunction with the My Oracle Support Configuration Manager. You can find recorded training sessions for these features on My Oracle Support:
My Oracle Support How-to Video Training Series (Doc ID 603505.2)
If you choose not to use My Oracle Support Patch Plans, then My Oracle Support Conflict Checker tool enables you to upload an OPatch inventory and check the patches that you want to apply to your environment for conflicts.
For details about using this tool, see:
The procedure to use the tool is as follows:
-
Download the patch from My Oracle Support. Patches are zip archive file format files in the form
<patchnumber>_<version>_<platform>.zip
, where<patchnumber>
is the eight-digit number of the patch,<version>
is the release of the Oracle software for which the patch is provided, and<platform>
is the operating system platform for which the patch can be applied. For example:p12345678_23.0.0.0.0_Linux-x86-64
. -
Unzip the patch, and use the OPatch command
opatch prereq CheckConflictAgainstOHWithDetail
to find if any currently installed interim patches conflict with the patch being installed. For example, if the patch isp12345678_23.0.0.0.0_Linux-x86-64
:unzip p12345678_23.0.0.0.0_Linux-x86-64.zip cd p12345678_23.0.0.0.0_Linux-x86-64 opatch prereq CheckConflictAgainstOHWithDetail -ph ./
-
Review the report. If there are conflicts, then the report indicates the patches that conflict and the patches that are a superset.
-
Resolve the patch conflicts for each conflicting patch. Determine if a conflict resolution patch is already available, and if you need to request a new conflict resolution patch or if the conflict may be ignored. If you require additional conflict resolution patches, then you must wait until they become available before proceeding further.
To resolve patch conflicts, use the following My Oracle Support document:
After you resolve patch conflicts, or receive any interim conflict resolution patches, you can proceed with updating your Oracle software.
Example 1-1 Manually Running Conflict Check for Oracle Grid Infrastructure
To run conflict checks manually, you have to run opatch
with the prereq
flag for each of the Grid home component installed
interim patches. For example, suppose the patch name is
p12345678_23.0.0.0.0_Linux-x86-64
and the unzipped patch
location is /usr/home/oracle/OPatch
. Checks for the Grid home can
be similar to the following:
% $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /usr/home/oracle/patch/p12345678_23.0.0.0.0_Linux-x86-64/% ARU_Database_SubPatchTrackingBug %
% $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /usr/home/oracle/patch/p12345678_23.0.0.0.0_Linux-x86-64/% ARU_OCW_SubPatchTrackingBug %
% $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /usr/home/oracle/patch/p12345678_23.0.0.0.0_Linux-x86-64/% ARU_ACFS_SubPatchTrackingBug %
% $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /usr/home/oracle/patch/p12345678_23.0.0.0.0_Linux-x86-64/% ARU_RHP_SubPatchTrackingBug %
% $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /usr/home/oracle/patch/p12345678_23.0.0.0.0_Linux-x86-64/% ARU_TOMCAT_SubPatchTrackingBug %
% $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /usr/home/oracle/patch/p12345678_23.0.0.0.0_Linux-x86-64/% ARU_DBWLM_SubPatchTrackingBug %
Note:
-
For HP-UX Itanium and Linux on IBM System z platforms, the last two checks in the previous example do not need to be done.
-
For the Oracle or Grid home, as the software home user:
% $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /usr/home/oracle/patch/p12345678_23.0.0.0.0_Linux-x86-64/% ARU_Database_SubPatchTrackingBug % % $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /usr/home/oracle/patch/p12345678_23.0.0.0.0_Linux-x86-64/% ARU_OCW_SubPatchTrackingBug %
The report will indicate the interim patches that conflict with the patch
p12345678_23.0.0.0.0_Linux-x86-64
and the interim patches
for which patch p12345678_23.0.0.0.0_Linux-x86-64
is a
superset.
Parent topic: OPatchAuto Maintenance for Oracle Data Guard
Run OPatch System Space Check
Check if enough free space is available on the
ORACLE_HOME
file system for the patches that you want to
apply.
The UPGRADE CATALOG
command must be entered twice to confirm the
upgrade.
Enter the following commands:
-
For the Oracle Grid Infrastructure home (Grid home), as the Grid user:
-
Create file
/tmp/patch_list_gihome.txt
with the following content (in this example, the patch location is/usr/home/oracle/patch/OPatch
):% cat /tmp/patch_list_gihome.txt /usr/home/oracle/patch/OPatch/p12345678_23.0.0.0.0_Linux-x86-64/% ARU_Database_SubPatchTrackingBug % /usr/home/oracle/patch/OPatch/p12345678_23.0.0.0.0_Linux-x86-64/% ARU_OCW_SubPatchTrackingBug % /usr/home/oracle/patch/OPatch/p12345678_23.0.0.0.0_Linux-x86-64/% ARU_ACFS_SubPatchTrackingBug % /usr/home/oracle/patch/OPatch/p12345678_23.0.0.0.0_Linux-x86-64/% ARU_RHP_SubPatchTrackingBug % /usr/home/oracle/patch/OPatch/p12345678_23.0.0.0.0_Linux-x86-64/% ARU_TOMCAT_SubPatchTrackingBug % /usr/home/oracle/patch/OPatch/p12345678_23.0.0.0.0_Linux-x86-64/% ARU_DBWLM_SubPatchTrackingBug %
Note:
For HP-UX Itanium and Linux on IBM System z platforms, the last two rows in the previous example should not be added to the
patch_list_gihome.txt
file. -
Run the OPatch command to check if enough free space is available in the Grid home:
% $ORACLE_HOME/OPatch/opatch prereq CheckSystemSpace -phBaseFile /tmp/patch_list_gihome.txt
-
-
In the Oracle software home, as the software home user:
-
Create file
/tmp/patch_list_dbhome.txt
with the patch content in the location where you have unzipped the patch. For example, if the patch isp12345678_23.0.0.0.0_Linux-x86-64
::% cat /tmp/patch_list_dbhome.txt <patch-location>/p12345678_23.0.0.0.0_Linux-x86-64/% ARU_Database_SubPatchTrackingBug % <Patch-location>/p12345678_23.0.0.0.0_Linux-x86-64/% ARU_OCW_SubPatchTrackingBug %
-
Run the OPatch command to check if enough free space is available in the Oracle home:
% $ORACLE_HOME/OPatch/opatch prereq CheckSystemSpace -phBaseFile /tmp/patch_list_dbhome.txt
-
The command output reports pass and fail messages in response to the system space availability:
-
If OPatch reports
Prereq "checkSystemSpace" failed
, then the required amount of space is not available, so you must free up space on the system. -
If OPatch reports
Prereq "checkSystemSpace" passed
, then no action is needed. Proceed with patch installation.
Parent topic: OPatchAuto Maintenance for Oracle Data Guard
Update Software on Databases with Oracle Data Guard Using OPatchAuto
After any patch conflicts are resolved, you can proceed with updating your software manually using OPatchAuto.
Oracle recommends that you use the latest OPatch and OPatchAuto version for your Oracle software release.
Be aware of the following critical restrictions:
- The database RU must be applied to the Data Guard standby using OPatch.
- After applying the patch, do not start
datapatch
to apply post-patch SQL actions for the database RU on the Data Guard standby environment. Ifdatapatch
is run on a standby instead of the primary, then datapatch issues an error when it tries to call theSYS.DBMS_QOPATCH
interface. For more details about this error, see My Oracle Support document 1599479.1. -
Datapatch must be started only on the Primary database, and only after all the databases (Data Guard Primary and Standby) are patched, and patch deployment of the database RU is complete for the setup.
Follow these steps for a an Oracle Database environment deployed with Oracle Data Guard:
-
Disable REDO transport on the Primary database.
-
If Data Guard Broker is in place, then you must use
DGMGRL
. For example:DGMGRL> connect / Connected. DGMGRL> show database verbose plb_prm Database Name: plb_prm Role: PRIMARY Enabled: YES Intended State: ONLINE Instance(s): plb Properties: InitialConnectIdentifier = 'plb_prm_dgmgrl' .. . Current status for "plb_prm": SUCCESS DGMGRL> edit database plb_prm set state='LOG-TRANSPORT-OFF'; Succeeded.
-
If Data Guard Broker is not used, then use SQL
alter system set
. For example:SQL> alter system set log_archive_dest_state_X=defer scope=both sid='*'
-
-
Shut down the standby database, all listeners, and all processes associated with the Oracle home standby site. For example:
$ lsnrctl stop lsnrplb LSNRCTL for Linux: Version 10.2.0.4.0 - Production on 04-FEB-2010 08:41:29 Copyright (c) 1991, 2007, Oracle. All rights reserved. Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=<host>)(PORT=1666))) The command completed successfully $ sqlplus / as sysdba SQL*Plus: Release 10.2.0.4.0 - Production on Thu Feb 4 08:42:02 2010 Copyright (c) 1982, 2007, Oracle. All Rights Reserved. Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production With the Partitioning, OLAP, Data Mining and Real Application Testing options SQL> shutdown immediate ORA-01109: database not open Database dismounted. ORACLE instance shut down.
-
Set your current directory to the directory where the patch is located and then run the OPatchAuto utility by entering the following commands,where
<patchnumber>
is the eight-digit number of the patch,<version>
is the release of the Oracle software for which the patch is provided, and<platform>
is the operating system platform for which the patch can be applied.unzip p<patchnumber>_<version>_<platform>.zip cd p<patchnumber>_<version>_<platform> opatch apply
For example:
unzip p12345678_23.0.0.0.0_Linux-x86-64.zip cd p12345678_23.0.0.0.0_Linux-x86-64 opatch apply
Wait for the patch update to complete successfully. After the patch update is complete, start the standby site to mount and restart the listeners only. Do not restart managed recovery.Note:
If the standby is an Oracle RAC environment, then you repeat the patch application across all nodes.If there are errors, refer to "Known Issues"
Note:
Do not apply any postupgrade changes to the standby Oracle home. Those changes must be performed using the REDO transport (catchpatch.sql
, and so on) run against the standby RDBMS itself later. - Start the primary site, and re-enable log shipping to the standby.
- At the standby site, start the MRP (managed recovery). RDBMS changes implemented
in the Primary Site through
catpatch
,catbundle
andcatcpu
are now applied to the standby.Caution:
You must perform this step immediately after upgrading the Oracle Database binaries on the Standby Database. This step ensures that the Data Dictionary (CATPROC
) version matches the version of the database binaries. If the data dictionary does not match (for example, if you upgrade the Standby database first and perform a role change on the standby before you upgrade the Primary), it is possible for you to run into severe problems. for more information , see Mixed Oracle Version support with Data Guard Redo Transport Services (Doc ID 785347.1). -
Set your current directory to the directory where the patch storage is located and then run the OPatch utility by entering the following commands,where
<patchnumber>
is the eight-digit number of the patch,<version>
is the release of the Oracle software for which the patch is provided, and<platform>
is the operating system platform for which the patch can be applied.unzip p<patchnumber>_<version>_<platform>.zip cd p<patchnumber>_<version>_<platform> opatch apply
For example:
unzip p12345678_23.0.0.0.0_Linux-x86-64.zip cd p12345678_23.0.0.0.0_Linux-x86-64 opatch apply
Wait for the patch update to complete successfully.
If there are errors, refer to "Known Issues"
-
If you are using Data Guard Broker with Oracle Data Guard, then to avoid Data Guard Broker from starting the MRP automatically, change the state to state=APPLY-OFF. For example:
DGMGRL> EDIT DATABASE 'plb_prm' SET STATE='APPLY-OFF';
-
Shut down the primary database, all listeners, and all processes associated with the Oracle home standby site. For example:
$ lsnrctl stop lsnrplb LSNRCTL for Linux: Version 10.2.0.4.0 - Production on 04-FEB-2010 08:41:29 Copyright (c) 1991, 2007, Oracle. All rights reserved. Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=<host>)(PORT=1666))) The command completed successfully $ sqlplus / as sysdba SQL*Plus: Release 10.2.0.4.0 - Production on Thu Feb 4 08:42:02 2010 Copyright (c) 1982, 2007, Oracle. All Rights Reserved. Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production With the Partitioning, OLAP, Data Mining and Real Application Testing options SQL> shutdown immediate ORA-01109: database not open Database dismounted. ORACLE instance shut down.
For an Oracle RAC primary:
$ srvctl stop listener -n <host> -l lsnrplb_<host> $ srvctl stop listener -n <host> -l lsnrplb_<host> $ srvctl stop database -d plb
-
Unzip the patch into the primary database patch storage location.
Set your current directory to the directory where the patch is located and then run the OPatch utility by entering the following commands,where
<patchnumber>
is the eight-digit number of the patch,<version>
is the release of the Oracle software for which the patch is provided, and<platform>
is the operating system platform for which the patch can be applied.unzip p<patchnumber>_<version>_<platform>.zip cd p<patchnumber>_<version>_<platform> opatch apply
For example:
unzip p12345678_23.0.0.0.0_Linux-x86-64.zip cd p12345678_23.0.0.0.0_Linux-x86-64 opatch apply
Wait for the patch update to complete successfully.
If there are errors, refer to "Known Issues"
-
Upgrade and patch the RDBMS and dictionary objects.
In an Oracle RAC environment, you perform this task from one instance only, with the other instances shut down and not running.
- After the patch is installed successfully, if you obtained patch conflict resolution interim patches after checking for patch conflicts, then apply them now.
-
To reestablish the Oracle Data Guard environment on the primary site. start the listeners.
In an Oracle RAC environment, you reestablish Oracle Data Guard on the primary site one instance only, while the remaining cluster instances are down and not running.
-
Force the primary site to register its services to the listener:
$ sqlplus / as sysdba SQL> alter system register;
-
Re-enable Oracle Data Guard on the Standby.
-
In a single instance Oracle Data Guard deployment, disable restricted session to allow end user connectivity.
SQL> alter system disable restricted session;
-
In an Oracle RAC Oracle Data Guard deployment, restart the primary site and all of its instances:
$ srvctl stop database -d plb $ srvctl start database -d plb
If there are additional Oracle RAC services used to connect the database then restart those services. For example:
$ srvctl start service -d plb
-
-
Re-enable log shipping to the Standby Site.
When you re-enable log-shipping to the standby, the RDBMS changes made through running
catupgrade
.catbundle
andcatcpu
can be applied to the standby.-
If you are using Data Guard Broker, then connect and update the state to
state=ONLINE
. For example:DGMGRL> edit database plb_prm set state='ONLINE';
-
After installing the patches needed, complete these steps:
- Load modified SQL files into the database, as explained in "Load Modified SQL Files into the Database" .
- Upgrade Oracle Recovery Manager Catalog, as explained in "Upgrade Oracle Recovery Manager Catalog" .
- Check bug fixes that may change an existing optimizer execution plan, as explained in Managing "installed but disabled" bug fixes in Database Release Updates using DBMS_OPTIM_BUNDLE (Doc ID 2147007.1).
If there are errors, refer to "Known Issues"
Parent topic: OPatchAuto Maintenance for Oracle Data Guard
Load Modified SQL Files into the Database
When you use OPatch to perform database maintenance, you must run the
datapatch
tool manually so that the tool can load modified SQL files
into the database.
Datapatch is the patching tool that completes the post-patch SQL actions for RDBMS patches, such as running scripts to load modified SQL files into the database registry. Datapatch identifies the postinstallation steps required after the database is updated, and applies and removes or rolls back SQL changes in the database as required. Unlike a maintenance operation with OPatchAuto, which calls Datapatch automatically to complete post-patch actions after the new binary patch is installed and the database is restarted, you must run Datapatch manually after running OPatch.
For more information about Datapatch, see:
- Datapatch: Database 12c or later Post Patch SQL Automation (Doc ID 1585822.1)
- Datapatch User Guide (Doc ID 2680521.1)
-
For your databases running on the same Oracle home in the multitenant environment being patched, run the
datapatch
tool. In this example, we rundatapatch
with the-sanity_checks
option:% sqlplus /nolog SQL> Connect / as sysdba SQL> startup SQL> alter pluggable database all open; SQL> quit % cd $ORACLE_HOME/OPatch % ./datapatch -sanity_checks % ./datapatch -verbose
Oracle highly recommends that you run
datapatch
with the-sanity_checks
option. When started with this option,datapatch
runs a series of environment and database checks to validate if conditions are optimal for patching. Results are shown on screen with severity and recommendations for potential actions you can take. For more information about this feature, see:Datapatch User Guide (Doc ID 2680521.1)
Oracle also recommends that you run
datapatch
on all pluggable databases (PDBs) in the multitenant environment at the same time. However, you can choose to rundatapatch
on individual pluggable databases. If you choose to do this, then datapatch is run only on the multitenant container database (CDB) and opened pluggable databases (PDBs). You then are required to update the PDBs that are not updated at this time by using thealter pluggable database
statement, and running thedatapatch
tool again at a later time to complete post-patch SQL actions on those PDBs. See:Multitenant Unplug/Plug Best Practices (Doc ID 1935365.1)
The
datapatch
utility runs apply scripts to load the modified SQL files into the database. An entry is added to thedba_registry_sqlpatch
view, recording the patch application. -
In the
dba_registry_sqlpatch
view, verify that the Status for theAPPLY
isSUCCESS
. For any other status, see:Troubleshooting Assistant:12c Datapatch Issues (Doc ID 2335899.2)
-
After datapatch completes, check its output to see if it has reported any errors. The output of datapatch contains log file locations for the patches installed. You can find all the relevant log files of that particular datapatch process in the same directory as
sqlpatch_invocation.log
. Check the initial lines of the output for "Log file for this invocation:"
Parent topic: OPatchAuto Maintenance for Oracle Data Guard
Upgrade Oracle Recovery Manager Catalog
If you are using the Oracle Recovery Manager, then the catalog needs to be upgraded.
The UPGRADE CATALOG
command must be entered twice to confirm the
upgrade.
Enter the following commands:
$ rman catalog username/password@alias
RMAN> UPGRADE CATALOG;
RMAN> UPGRADE CATALOG;
RMAN> EXIT;
Parent topic: OPatchAuto Maintenance for Oracle Data Guard
Known Issues
Learn how to find if an issue you have encountered while running OPatch is a known issue.
For information about known OPatch issues, see:
Primary Note For OPatch (Doc ID 293369.1)
For issues documented after the release of the Release Update (RU) or patch version that you have installed, review the README for the Release Update (RU) or patch version that you have installed.
Parent topic: OPatchAuto Maintenance for Oracle Data Guard
Documentation Accessibility
For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.
Access to Oracle Support
Oracle customer access to and use of Oracle support services will be pursuant to the terms and conditions specified in their Oracle order for the applicable services.
Parent topic: OPatchAuto Maintenance for Oracle Data Guard
Oracle Database Oracle Database with Oracle Data Guard Maintenance with OPatchAuto, Release 23ai and Later Releases
G15079-01