8 Downgrading Oracle Database to an Earlier Release
For supported releases of Oracle Database, you can downgrade a database to the release from which you last upgraded.
For example, if you recently upgraded your Oracle Database 12c release 1 (12.1.0.2( to release 19c, and you did not change the compatible initialization parameter to 19.1.0, then you can downgrade to release 12.1.0.2.
- Supported Releases for Downgrading Oracle Database
You can downgrade both major releases and release update or patchset releases, based on the original Oracle Database release from which the database was upgraded. - Check for Incompatibilities When Downgrading Oracle Database
To see if the database has incompatibilities that can prevent you from downgrading, check the compatibility level of your database. - Perform a Full Backup Before Downgrading Oracle Database
Oracle strongly recommends that you perform a full backup of your new Oracle Database release before you downgrade to a supported earlier release. - Performing Required Predowngrade Steps for Oracle Database
Complete the required preparation steps described here before you downgrade Oracle Database to the earlier release from which you upgraded. - Using Scripts to Downgrade a CDB or Non-CDB Oracle Database
To automate downgrades, starting in Oracle Database 19c, Oracle provides thedbdowngrade
utility script. When necessary, you can also continue to runcatdwgrd.sql
manually, as in previous releases. - About Downgrades and Invalid Objects with Component Status OPTION OFF
Downgrades from later release Oracle Database Standard Edition to Oracle Database 12c Standard Edition with CDB and PDBS contain later release invalid objects after the downgrade. - Downgrading a Single Pluggable Oracle Database (PDB)
If you are downgrading Oracle Database, then you can downgrade one PDB without downgrading the whole CDB. - Downgrading PDBs That Contain Oracle Application Express
Use this procedure to avoid INVALID OBJECTS OWNED BY APEX_050000 errors when you downgrade PDBs that contain Oracle Application Express. - Post-Downgrade Tasks for Oracle Database Downgrades
After you downgrade your Oracle Database release, you can be required to complete additional tasks, due to changes that affect compatibility, components, and supported protocols. - Troubleshooting the Downgrade of Oracle Database
Use this troubleshooting information to address issues that may occur when downgrading Oracle Database.
Supported Releases for Downgrading Oracle Database
You can downgrade both major releases and release update or patchset releases, based on the original Oracle Database release from which the database was upgraded.
Releases Supported for Downgrades
You can downgrade a non-CDB Oracle Database from Oracle Database 19c to Oracle Database 18c, Oracle Database 12c, and to Oracle Database 11g release 11.2.0.4.
You can downgrade a PDB or CDB to Oracle Database 18c, Oracle Database 12c Release 12.2, and Oracle Database 12c Release 12.1.0.2.
Note:
Starting with Oracle Database 12c, Release 1 (12.1), non-CDB architecture is deprecated. It can be desupported in a future release.
The following table provides additional information about releases supported for downgrading. When using this table, also read about compatibility in "Checking for Incompatibilities When Downgrading Oracle Database."
Table 8-1 Supported Releases and Editions for Downgrading
Oracle Database Release or Edition | Downgradable (Yes/No) | Notes |
---|---|---|
18 |
Yes |
No additional information at this time. |
12.2.0.1 and 12.1.0.2 |
Yes |
You cannot downgrade a database after you set the compatible initialization parameter to 12.1.0.2. You can downgrade a non-CDB from 19 to 18, or 12.2 to 12.1.0.2, or 11.2.0.4 (all supported upgrade releases). Install the latest Release Update, Release Revision, bundle patch or patch set update (BP or PSU) before you downgrade a CDB, or before you unplug and downgrade a PDB. Patches are available for download on My Oracle Support. Refer to My Oracle Support note 756671.1 to obtain the latest patch set. You cannot downgrade to releases earlier than the minimum compatibility setting for the new Oracle Database release. |
Oracle Enterprise Manager |
No |
If you downgrade to an earlier supported release, then you must reconfigure Oracle Enterprise Manager controls. Before you start your upgrade, you must use the |
Oracle Database Express Edition |
No |
You cannot downgrade a database that is upgraded from Oracle Database Express Edition. |
Recommendations to Review Before Downgrading
The following recommendations for earlier supported releases affect downgrading for Oracle Database:
-
Multitenant architecture provides architecture features for a multitenant container database (CDB), and pluggable databases (PDBs). If you are upgrading to multitenant architecture, and you set the compatible initialization parameter to the highest level after upgrading to this release, then you cannot downgrade the database after an upgrade.
-
This release contains a new object privilege,
READ
, in addition toSELECT
. After you downgrade, note the following implications of this object privilege:-
If you have the
SELECT
andREAD
object privileges, then theREAD
privilege is removed. -
If you previously only had the
READ
object privilege, then theREAD
object privilege is transformed into theSELECT
object privilege.
Refer to Oracle Database Security Guide for more information about the READ and SELECT object privileges.
-
-
If Oracle XML DB is not installed in the database that you upgrade, then during a downgrade, Oracle XML DB is uninstalled. For example, if you did not install Oracle XML DB with Oracle Database 11g Release 2 (11.2), then Oracle XML DB is installed with Oracle Database 12c. If you downgrade the database, then Oracle XML DB is uninstalled as part of the downgrade. Oracle XML DB is included by default with Oracle Database 12c release 1 (12.1), and later releases.
-
During upgrade to Oracle Database 12c, the Database (DB) Control repository is removed. If you downgrade to an earlier release, then you must reconfigure the Database (DB) Control to use it after the downgrade.
-
Downgrade is not supported for Oracle Enterprise Manager. If you downgrade to an earlier supported release, then you must reconfigure Oracle Enterprise Manager controls.
Check for Incompatibilities When Downgrading Oracle Database
To see if the database has incompatibilities that can prevent you from downgrading, check the compatibility level of your database.
If you have updated the COMPATIBLE
parameter to set the
compatibility level of your Oracle Database release to the current release, then you are
not able to downgrade to an earlier release. This issue occurs because new releases have
changes to the Data Dictionary, and can have other feature changes that prevent
downgrades.
To check the COMPATIBLE
parameter setting for your database
before you downgrade, enter the following command:
SQL> SELECT name, value, description FROM v$parameter WHERE name =
‘compatible’;
Note:
For Oracle ASM disk groups, if you changed the compatible.asm
parameter after the upgrade to the upgraded release value, then when you downgrade
to the earlier release, you cannot mount your Oracle ASM disk groups. The value for
compatible.asm
sets the minimum Oracle ASM release that can
mount a disk group.
As part of your downgrade, you must create a new disk group to your downgraded release level, and restore data to that downgraded compatibility ASM disk group.
See Also:
Oracle Automatic Storage Management Administrator's Guide for information about Oracle ASM disk group compatibility
Parent topic: Downgrading Oracle Database to an Earlier Release
Perform a Full Backup Before Downgrading Oracle Database
Oracle strongly recommends that you perform a full backup of your new Oracle Database release before you downgrade to a supported earlier release.
See Also:
Oracle Database Backup and Recovery User's Guide for information about performing RMAN backups
Parent topic: Downgrading Oracle Database to an Earlier Release
Performing Required Predowngrade Steps for Oracle Database
Complete the required preparation steps described here before you downgrade Oracle Database to the earlier release from which you upgraded.
Before you start a downgrade, you must resolve incompatibilities between database releases. For example, determine if you must disable components in the database before you start the downgrade.
-
If you have enabled Oracle Database Vault on your database, then disable Oracle Database Vault before downgrading the database.
Use DBA_DV_STATUS to find out if Oracle Database Vault is enabled:
SQL> SELECT * FROM DBA_DV_STATUS;
If the output is TRUE, then Oracle Database Vault is enabled, so you must disable it.
On multitenant architecture Oracle Database systems, use
CDB_DV_STATUS
onCDB$ROOT
to find out the Oracle Database Vault status on all PDBs plugged in to the CDB:SQL> SELECT * FROM CDB_DV_STATUS;
-
If you have enabled Unified Auditing, then you can choose to back up and purge the unified audit trail:
-
Find if unified audit records exist.
SQL> SELECT COUNT(*) FROM UNIFIED_AUDIT_TRAIL;
-
Back up the existing audit data to a table. For example:
SQL> CREATE TABLE UA_DATA AS (SELECT * FROM UNIFIED_AUDIT_TRAIL);
-
Clean up the audit trail.
EXEC DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL(audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIED, use_last_arch_timestamp => FALSE);
-
-
Before downgrade, ensure that the target Oracle home for the downgraded database contains the version of the time zone file that your database is using.
To find which time zone file version your database is currently using, query
V$TIMEZONE_FILE
using the following command:SQL> select * from V$TIMEZONE_FILE;
For example:
If the query returns
timezlrg_20.dat
in the columnV$TIMEZONE_FILE.FILENAME
, then check if the file is present in the target Oracle Home:Linux and Unix
$ORACLE_HOME/oracore/zoneinfo/timezlrg_20.dat
Windows
%ORACLE_HOME%\oracore\zoneinfo\timezlrg_20.dat
If the required time zone file is missing from the target Oracle home, then do one of the following:
-
If you installed the current version of the time zone file as a patch, and you still know the patch number, then use the same patch number to download the corresponding time zone file for the target release from the My Oracle Support website.
-
Locate the correct patch by using the My Oracle Support website patch search function. Enter the following search criteria: "Product is 'Oracle Database'", "Release is 'target release'", and "Description contains 'DST'".
-
If you cannot locate the patch on the My Oracle Support website, then log a service request with Oracle Support.
After you find and download the required patch, install it in the target Oracle home.
-
-
If you created objects based on fixed objects, then drop these objects to avoid possible ORA-00600 errors. You can recreate these objects after the downgrade.
-
If you have Oracle Enterprise Manager configured in your database, then drop the Enterprise Manager user:
DROP USER sysman CASCADE;
Note:
After you drop the Enterprise Manager user, you can find thatMGMT*
synonyms are invalid. You must reconfigure Oracle Enterprise Manager to use any Oracle Enterprise Manager controls in the downgraded database.
Related Topics
Parent topic: Downgrading Oracle Database to an Earlier Release
Using Scripts to Downgrade a CDB or Non-CDB Oracle Database
To automate downgrades, starting in Oracle Database 19c, Oracle provides the dbdowngrade
utility script. When necessary, you can also continue to run catdwgrd.sql
manually, as in previous releases.
- Using Dbdowngrade to Downgrade CDB and Non-CDB Oracle Databases
To downgrade Oracle Database to an earlier supported major release, or to an earlier release update, Oracle recommends that you run the downgrade scriptdbdowngrade
. - Downgrading a CDB or Non-CDB Oracle Database Manually with catdwgrd.sql
You can run the manualcatdwgrd.sql
script for downgrades of Oracle Database to an earlier supported major release, or an earlier release update, where you either prefer to run a manual script, or you want to avoid excessive thread issues.
Parent topic: Downgrading Oracle Database to an Earlier Release
Using Dbdowngrade to Downgrade CDB and Non-CDB Oracle Databases
To downgrade Oracle Database to an earlier supported major release, or to an earlier release update, Oracle recommends that you run the downgrade script dbdowngrade
.
Starting with Oracle Database 19c, Oracle provides the Downgrade Utility script dbdowngrade
. When you use the dbdowngrade utility, it sets appropriate values for the downgrade, and simplifies how you start a downgrade. Specifically, it ensures that the underlying calls to catcon.pl
use recommended values, so that potential errors due to excessive threads being spawned are reduced. This feature is especially of value for downgrades of multitenant architecture (CDB) databases. When the potential of excessive threads exists, you can continue the downgrade by running the catdwgrd.sql
script manually, as in previous releases.
The dbdowngrade
shell command is located in the file path $ORACLE_HOME/bin
on Linux and Unix, and %ORACLE_HOME%\bin
on Microsoft Windows based systems. If you are downgrading a CDB, then you can provide the inclusion list as argument to the script.
When you downgrade multitenant architecture databases (CDBs), the dbdowngrade
script has two behaviors, depending on whether you use an inclusion list.
-
Without an inclusion list. The downgrade runs on all the containers that are open in the CDB (PDB and CDB).
Run the downgrade without an inclusion list when you want to downgrade the entire CDB. In this scenario, all open containers are downgraded. You must open all the PDBs in the CDB manually before you start the
dbdowngrade
script. -
With an inclusion list. The downgrade runs only on the PDBs within the inclusion list, and CDB$ROOT is not downgraded during the downgrade operation.
Run the downgrade with an inclusion list when you want to downgrade only the set of PDBs listed in the inclusion list. In this scenario, where you want to use unplug and plug upgrades, only the set of PDBs that you list in the inclusion list are downgraded. The CDB and the PDBs that are not on the inclusion list remain upgraded to the later release.
Prerequisites:
-
If you are downgrading from Oracle Database 19c to Oracle Database 18c, Oracle Database 12.2, or Oracle Database 12.1, then you can downgrade all databases in a multitenant container database (CDB), or one pluggable database (PDB) within a CDB. Oracle Database releases earlier than Oracle Database 12c did not use multitenant architecture.
- If you are downgrading without an inclusion list, then you must open all PDB containers before you run the
dbdowngrade
script.
As a result of running the dbdowngrade
script, the utility runs catdwgrd
and catcon.pl
. These scripts perform the downgrade, using the recommended values for the release to which you are downgrading. The log files produced by the downgrade scripts are placed under the first directory found of one of these three options, in order:
-
The Oracle base home identified by the
orabasehome
command -
The Oracle base home identified by the
orabase
command -
The Oracle home identified by the
oracle_home
command
$ $ORACLE_HOME/bin/orabasehome
/u01/app/oracle/product/19.0.0/dbhome_1
In this example, the $ORACLE_BASE directory is /u01/app/oracle/product/19.0.0/dbhome_1
, and the logs are located in /u01/app/oracle/product/19.0.0/dbhome_1/cfgtoollogs/downgrade
. In the directory, the log files are prefixed with the string catdwgrd
.
Note:
-
Read-write Oracle homes: the commands
orabaseconfig
andorabasehome
both return the environment setting for ORACLE_HOME. -
Read-only Oracle homes: the command
orabaseconfig
returns the read-only path configuration for the Oracle base in the path$ORACLE_BASE/homes
.
Downgrading a CDB or Non-CDB Oracle Database Manually with catdwgrd.sql
You can run the manual catdwgrd.sql
script for downgrades of
Oracle Database to an earlier supported major release, or an earlier release update, where
you either prefer to run a manual script, or you want to avoid excessive thread issues.
If you are downgrading from Oracle Database 19c to Oracle Database 18c, Oracle Database 12.2, or Oracle Database 12.1, then you can downgrade all databases in a multitenant container database (CDB), or one pluggable database (PDB) within a CDB. Oracle Database releases earlier than Oracle Database 12c did not use multitenant architecture.
Note:
Starting with Oracle Database 12c release 1 (12.1), non-CDB architecture is deprecated. It can be desupported in a future release.
At the completion of this procedure, your database is downgraded.
About Downgrades and Invalid Objects with Component Status OPTION OFF
Downgrades from later release Oracle Database Standard Edition to Oracle Database 12c Standard Edition with CDB and PDBS contain later release invalid objects after the downgrade.
With downgrades from later release Oracle Database releases to Oracle Database Release 12c (12.2 or 12.1), it is expected behavior to find later release invalid objects in the downgraded database, where the Oracle Database Release 12c database had these objects set to FALSE. This problem does not exist with downgrades to Oracle Database Release 18c (18.1.0) and later Oracle Database releases.
For example:
During a downgrade from Oracle Database 19c Standard Edition to Oracle Database 12c Release 2 (12.2.0.1) Standard Edition, you have OLAP and Spatial components upgraded to the 19c release versions, though they are set to FALSE. After the downgrade, the OLAP and Spatial components are still not available, but they are not reloaded into the 12.2.0.1 release. You then see this result in the DBA registry, where you have later release objects listed in your 12.2 registry:
OLAP Analytic Workspace OPTION OFF 19.1.0
Oracle OLAP API OPTION OFF 19.1.0
This result is expected behavior in downgrades from Oracle Database 18c and later to Oracle Database 12c. The reason that this behavior is expected is because the option setting for these options in Standard Edition databases is FALSE. During the upgrade, all options are upgraded, even though they are set to FALSE
. During the run of catrelod.sql
, the reload scripts do not run to replace these objects with the earlier release versions. As a result, downgrading back to Standard Edition leaves many OLAP and Spatial objects at their later release versions.
Parent topic: Downgrading Oracle Database to an Earlier Release
Downgrading a Single Pluggable Oracle Database (PDB)
If you are downgrading Oracle Database, then you can downgrade one PDB without downgrading the whole CDB.
In Oracle Database releases later than Oracle Database 12c release 2 (12.2), you can downgrade individual PDBs. For example, you can unplug a PDB from an upgraded CDB, downgrade the PDB, and then plug it in to an earlier release CDB, or you can convert the PDB database to a standalone database.
Downgrade the PDB
In this procedure example, you downgrade the PDB to release 12.1.0.2:
-
Start up the PDB in DOWNGRADE mode. The CDB can be in normal mode when you do this.
SQL> alter pluggable database CDB1_PDB1 open downgrade;
-
Downgrade the PDB, either by using the
dbdowngrade
utility, or by runningcatdwgrd
manually, usingcatcon.pl
.In each of these options, the PDB that you are downgrading is
PDB1
.-
Downgrading with
dbdowngrade
utility.Downgrade the PDB using the dbdowngrade script as follows:
cd $ORACLE_HOME/bin ./dbdowngrade -c 'PDB1'
-
Manually downgrading with
catdwgrd
, usingcatcon.p.
Run
catdwgrd
as follows:$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -d $ORACLE_HOME/rdbms/admin -n 1 -l <output directory> -e -b catdwgrd -c 'PDB1' catdwgrd.sql
In the example,
catdwgrd
is run withcatcon.pl
. The-d
parameter tellscatcon.pl
where to findcatdwgrd
. The-l
parameter specifies the output directory for log files, instead of writing to therdbms/admin
directory). You must use the-r
parameter to run the two scripts together at the same time.The log files for the downgrade are placed in the Oracle base home (the Oracle base identified by the commands
orabasehome
, ororabase
, or the Oracle home identified by the commandoracle_home
, in that order.
-
-
Close the PDB.
Unplug the PDB from the CDB
In this step you unplug the downgraded PDB from the release 12.2.0.1 CDB:
-
Connect to the upgraded CDB.
-
Close the PDB that you want to unplug.
SQL> alter pluggable database PDB1 close;
-
Unplug the downgraded 12.1.0.2 PDB, replacing the variable
path
with the path on your system:SQL> alter pluggable database PDB1 unplug into 'path/pdb1.xml';
You receive the following response when the unplug is completed:
Pluggable database altered
Plug in the Downgraded 12.1.0.2 PDB
In this step you plug the downgraded 12.1.0.2 PDB into the 12.1.0.2 CDB. To do this, you must create the PDB in this CDB. The following example shows how to create a pluggable database called PDB1:
-
Connect to the 12.1.0.2 CDB.
-
Plug in the 12.1.0.2 PDB.
SQL> create pluggable database PDB1 using 'path/pdb1.xml';
This command returns
Pluggable database created
. -
Open the PDB in upgrade mode:
SQL> alter pluggable database PDB1 open upgrade;
-
Connect to the PDB:
SQL> alter session set container=PDB1;
-
Run
catrelod
in the PDB:SQL> @$ORACLE_HOME/rdbms/admin/catrelod.sql
The
catrelod.sql
script reloads the appropriate version for each of the database components in the downgraded database. -
Run
utlrp
in the PDB:SQL> @$ORACLE_HOME/rdbms/admin/utlrp.sql
The
utlrp.sql
script recompiles all existing PL/SQL modules that were previously in anINVALID
state, such as packages, procedures, types, and so on.
Parent topic: Downgrading Oracle Database to an Earlier Release
Downgrading PDBs That Contain Oracle Application Express
Use this procedure to avoid INVALID OBJECTS OWNED BY APEX_050000 errors when you downgrade PDBs that contain Oracle Application Express.
After you downgrade the PDB to an earlier release, enter a SQL statement similar to the following to drop the Oracle Application Express user:
$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -b drop_apex5
-c 'PDB1' -- --x'drop user apex_050000 cascade'
In this example, the PDB name is 'PDB1'
.
Parent topic: Downgrading Oracle Database to an Earlier Release
Post-Downgrade Tasks for Oracle Database Downgrades
After you downgrade your Oracle Database release, you can be required to complete additional tasks, due to changes that affect compatibility, components, and supported protocols.
- Oracle XML DB Authentication Recommendations for an Oracle Database Downgrade
Upgrades from releases earlier than 12.1 result in digest authentication being disabled. - Reapply Release Update and Other Patches After Downgrade
After the downgrade is run, andcatrelod.sql
completes successfully, if you installed new patches in your original Oracle home after the upgrade, but before the downgrade, then ensure that you apply any patches that you installed. - Re-enabling Oracle Database Vault after Downgrading Oracle Database
You must do this if you are instructed during the downgrade to disable Oracle Database Vault. - Restoring the Configuration for Oracle Clusterware
To restore the configuration, you must restore the release from which you upgraded. - Restoring Oracle Enterprise Manager after Downgrading Oracle Database
The restore task described in this section is required only if you are performing a downgrade, and Oracle Enterprise Manager is configured on the host. - Restoring Oracle Application Express to the Earlier Release
After a downgrade, if you upgraded Oracle Application Express at the same time as you upgraded Oracle Database, then you must complete steps to revert to the earlier Oracle Application Express release. - Gathering Dictionary Statistics After Downgrading
To help to assure good performance after you downgrade, use this procedure to gather dictionary statistics. - Regathering Fixed Object Statistics After Downgrading
After the downgrade, run representative workloads on Oracle Database, and regather fixed object statistics. - Regathering Stale CBO Statistics After Downgrade
Oracle recommends that you regather Oracle Cost-Based Optimizer (CBO) statistics after completing an Oracle Database downgrade.
Parent topic: Downgrading Oracle Database to an Earlier Release
Oracle XML DB Authentication Recommendations for an Oracle Database Downgrade
Upgrades from releases earlier than 12.1 result in digest authentication being disabled.
If you downgrade to a release that is earlier than Oracle Database 12c, in which digest authentication is not supported, digest authentication is disabled and made unavailable as an authentication choice. This affects HTTP authentication for Oracle XML DB Repository. If you did not take advantage of digest authentication and instead used the default configuration, then no further actions are necessary.
Parent topic: Post-Downgrade Tasks for Oracle Database Downgrades
Reapply Release Update and Other Patches After Downgrade
After the downgrade is run, and catrelod.sql
completes successfully, if you installed new patches in your original Oracle home after the upgrade, but before the downgrade, then ensure that you apply any patches that you installed.
If you installed new patches, then run the datapatch
tool to apply
those patches to the downgraded database. If you did not change the binaries and files
in your Oracle Home after the upgrade, then there is no need to run
datapatch
after running catrelod.sql
. However, if
you are in any doubt about whether new patches are installed, then run
datapatch
. There is no safety concern that prevents you from
running datapatch
as many times as you require to be certain that
patches are applied to the database.
Parent topic: Post-Downgrade Tasks for Oracle Database Downgrades
Re-enabling Oracle Database Vault after Downgrading Oracle Database
You must do this if you are instructed during the downgrade to disable Oracle Database Vault.
If you use Oracle Database Vault, then you may have been instructed to disable it before downgrading your database. To use Oracle Database Vault after downgrading, you must re-enable it.
See Also:
Oracle Database Vault Administrator's Guide for the procedure to re-enable Oracle Database Vault
Parent topic: Post-Downgrade Tasks for Oracle Database Downgrades
Restoring the Configuration for Oracle Clusterware
To restore the configuration, you must restore the release from which you upgraded.
You can restore the Oracle Clusterware configuration to the state it was in before the Oracle Clusterware upgrade. Any configuration changes that you have performed during or after the new Oracle Database upgrade process are removed, and cannot be recovered.
Parent topic: Post-Downgrade Tasks for Oracle Database Downgrades
Restoring Oracle Enterprise Manager after Downgrading Oracle Database
The restore task described in this section is required only if you are performing a downgrade, and Oracle Enterprise Manager is configured on the host.
To restore Oracle Enterprise Manager, you first run Oracle Enterprise Manager configuration assistant (EMCA), and then you run the emdwgrd
utility.
- Requirements for Restoring Oracle Enterprise Manager After Downgrading
You must complete these requirements before you upgrade to be able to restore Oracle Enterprise Manager after a downgrade to a release earlier than 12.1 - Running EMCA to Restore Oracle Enterprise Manager After Downgrading
Review these topics and select your restoration scenario to restore Oracle Enterprise Manager after a downgrade. - Running the emdwgrd utility to restore Enterprise Manager Database Control
You can restore the Oracle Enterprise Manager Database Control and data by using theemdwgrd
utility after you runemca -restore
.
Parent topic: Post-Downgrade Tasks for Oracle Database Downgrades
Requirements for Restoring Oracle Enterprise Manager After Downgrading
You must complete these requirements before you upgrade to be able to restore Oracle Enterprise Manager after a downgrade to a release earlier than 12.1
The following must be true to use emca -restore
to restore Oracle Enterprise Manager to its previous state:
-
Before the upgrade, you saved a backup of your Oracle Enterprise Manager configuration files and data
-
You run the
emca
binary located in the new Oracle Database release home for this procedure
On Oracle Clusterware systems, to restore Oracle Enterprise Manager on an Oracle RAC database, you must have the database registered using srvctl
before you run emca -restore
. You must run emca -restore
from the ORACLE_HOME/bin
directory of the earlier Oracle Database release to which the database is being downgraded.
Run the emca -restore
command with the appropriate options to restore Oracle Enterprise Manager Database Control or Grid Control to the old Oracle home.
Specify different emca
options, depending on whether the database you want to downgrade is a single-instance database, an Oracle RAC database, or an Oracle ASM database.
Running EMCA to Restore Oracle Enterprise Manager After Downgrading
Review these topics and select your restoration scenario to restore Oracle Enterprise Manager after a downgrade.
- Running emca on a Single-Instance Oracle Database Without Oracle ASM
Use Enterprise Manager Configuration Assistant (emca
) to manage your database. - Running EMCA on an Oracle RAC Database Without Oracle ASM
Use Enterprise Manager Configuration Assistant (emca
) to manage your database: - Running EMCA on a Single-Instance Oracle ASM Instance
Use Enterprise Manager Configuration Assistant (emca
) to manage your database and storage. - Running emca on an Oracle ASM on Oracle RAC Instance
Use Enterprise Manager Configuration Assistant (emca
) to manage your database and storage. - Running emca on a Single-Instance Oracle Database With Oracle ASM
Use Enterprise Manager Configuration Assistant (emca
) to manage your database and storage. - Running emca on an Oracle RAC Database and Oracle ASM Instance
Use Enterprise Manager Configuration Assistant (emca
) to manage your database and storage.
Running emca on a Single-Instance Oracle Database Without Oracle ASM
Use Enterprise Manager Configuration Assistant (emca
) to manage your database.
Use this command to run Enterprise Manager Configuration Assistant.
ORACLE_HOME/bin/emca -restore db
You are prompted to enter the following information:
-
Oracle home for the database that you want to restore
-
Database SID
-
Listener port number
Running EMCA on an Oracle RAC Database Without Oracle ASM
Use Enterprise Manager Configuration Assistant (emca
) to manage your database:
Use this procedure to run Enterprise Manager Configuration Assistant:
ORACLE_HOME/bin/emca -restore db -cluster
You are prompted to enter the following information:
-
Oracle home for the database that you want to restore
-
Database unique name
-
Listener port number
Running EMCA on a Single-Instance Oracle ASM Instance
Use Enterprise Manager Configuration Assistant (emca
) to manage your database and storage.
Use this command to run Enterprise Manager Configuration Assistant.
ORACLE_HOME/bin/emca -restore asm
You are prompted to enter the following information:
-
Oracle home for the database that you want to restore
-
Oracle ASM port
-
Oracle ASM SID
Running emca on an Oracle ASM on Oracle RAC Instance
Use Enterprise Manager Configuration Assistant (emca
) to manage your database and storage.
Use this command to run Enterprise Manager Configuration Assistant.
ORACLE_HOME/bin/emca -restore asm -cluster
You are prompted to enter the following information:
-
Oracle home for the database that you want to restore
-
Oracle ASM port
Running emca on a Single-Instance Oracle Database With Oracle ASM
Use Enterprise Manager Configuration Assistant (emca
) to manage your database and storage.
Use this command to run Enterprise Manager Configuration Assistant.
ORACLE_HOME/bin/emca -restore db_asm
You are prompted to enter the following information:
-
Oracle home for the Oracle Database that you want to restore
-
Database SID
-
Listener port number
-
Oracle ASM port
-
Oracle ASM home
-
Oracle ASM SID [+ASM]
Running emca on an Oracle RAC Database and Oracle ASM Instance
Use Enterprise Manager Configuration Assistant (emca
) to manage your database and storage.
Use this command to run Enterprise Manager Configuration Assistant:
ORACLE_HOME/bin/emca -restore db_asm -cluster
You are prompted to enter the following information:
-
Oracle home for the database that you want to restore
-
Database unique name
-
Listener port number
-
Oracle ASM port
-
Oracle ASM Oracle home
-
Oracle ASM SID [+ASM]
The output of emca
varies according to the options that you specify and the values that you enter at the prompts. In Oracle RAC environments, you must repeat this step on all Oracle RAC cluster member nodes.
You must now run the emdwgrd
utility to restore Oracle Enterprise Manager Database Control and data.
Running the emdwgrd utility to restore Enterprise Manager Database Control
You can restore the Oracle Enterprise Manager Database Control and data by
using the emdwgrd
utility after you run emca
-restore
.
To use emdwgrd
, you must do the following:
-
Set ORACLE_HOME and other environment variables to point to the Oracle home from which the upgrade originally took place.
-
Run the
emdwgrd
utility from the new release Oracle Database Oracle home.
The following procedure is for Linux and Unix. To run it on Windows, substitute
emdwgrd.bat
for emdwgrd
.
-
Set ORACLE_HOME to the Oracle home from which the database upgrade originally took place.
-
Set ORACLE_SID to the SID of the database that was upgraded and then downgraded.
-
Set PATH, LD_LIBRARY_PATH and SHLIB_PATH to point to the Oracle home from which the database upgrade originally took place.
-
Go to the new Oracle Database release Oracle home:
cd $ORACLE_HOME/bin
-
Run
emdwgrd
using one of the following procedures:-
For a single-instance database, run the following command, where
SID
is the SID of the database that was upgraded and then downgraded andsave_directory
is the path to the storage location you chose when saving your database control files and data:emdwgrd -restore -sid SID -path save_directory -tempTablespace TEMP
-
For an Oracle RAC database, remote copy is required across the cluster nodes. Define an environment variable to indicate which remote copy is configured. For example:
setenv EM_REMCP /usr/bin/scp
Then, run emdwgrd —restore with the following options:
emdwgrd -restore -tempTablespace TEMP -cluster -sid SID_OldHome -path save_directory
If the Oracle home is on a shared device, then add -shared to the
emdwgrd
command options.
-
-
Enter the SYS and SYSMAN passwords when prompted by
emdwgrd
. -
When
emdwgrd
completes, Oracle Enterprise Manager Database Control is downgraded to the old Oracle home.
Restoring Oracle Application Express to the Earlier Release
After a downgrade, if you upgraded Oracle Application Express at the same time as you upgraded Oracle Database, then you must complete steps to revert to the earlier Oracle Application Express release.
To complete the downgrade of Oracle Application Express after a database downgrade, complete all the steps listed in Oracle Application Express Installation Guide to revert your Oracle Application Express release to the earlier release. The steps to revert are different, depending on whether your architecture is a Non-CDB or a multitenant architecture (CDB) Oracle Database.
Note:
You only need to complete these steps if you upgraded Oracle Application Express at the same time that you upgraded the database.
Related Topics
Parent topic: Post-Downgrade Tasks for Oracle Database Downgrades
Gathering Dictionary Statistics After Downgrading
To help to assure good performance after you downgrade, use this procedure to gather dictionary statistics.
Oracle recommends that you gather dictionary statistics after downgrading the database, so that the statistics are collected for the downgraded release Data Dictionary tables.
Note:
After a downgrade process, be aware that the the data dictionary can have changes that persist in the downgraded dictionary. These changes are insignificant. The downgraded data dictionary is functionally equivalent to an earlier release data dictionary.
-
Non-CDB Oracle Database: Oracle recommends that you use the
DBMS_STATS.GATHER_DICTIONARY_STATS
procedure to gather these statistics. For example, enter the following SQL statement:SQL> EXEC DBMS_STATS.GATHER_DICTIONARY_STATS;
-
CDB (multitenant architecture) Oracle Database: Oracle recommends that you use
catcon
to gather Data Dictionary statistics across the entire multitenant architecture.To gather dictionary statistics for all PDBs in a container database, use the following syntax:
$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -l /tmp -b gatherstats -- --x"exec dbms_stats.gather_dictionary_stats"
To gather dictionary statistics on a particular PDB, use syntax similar to the following:
$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -l /tmp -c 'SALES1' -b gatherstats -- --x"exec dbms_stats.gather_dictionary_stats"
In the preceding example the
-c SALES1
option specifies a PDB inclusion list for the command that you run, specifying the database namedSALES1
. The option-b gatherstats
specifies the base name for the logs. The option--x
specifies the SQL command that you want to execute. The SQL command itself is inside the quotation marks.
Related Topics
Parent topic: Post-Downgrade Tasks for Oracle Database Downgrades
Regathering Fixed Object Statistics After Downgrading
After the downgrade, run representative workloads on Oracle Database, and regather fixed object statistics.
Fixed objects are the X$ tables and their indexes. V$ performance views are defined through X$ tables. After you downgrade, regather fixed object statistics to ensure that the optimizer for the restored database can generate good execution plans. These execution plans can improve database performance. Failing to obtain representative statistics can lead to suboptimal execution plans, which can cause performance problems
Gather fixed objects statistics by using the DBMS_STATS.GATHER_FIXED_OBJECTS_STATS
PL/SQL procedure. DBMS_STATS.GATHER_FIXED_OBJECTS_STATS
also displays recommendations for removing all hidden or underscore parameters and events from init.ora
and SPFILE
.
To gather statistics for fixed objects, run the following PL/SQL procedure:
SQL> execute dbms_stats.gather_fixed_objects_stats;
See Also:
Oracle Database PL/SQL Packages and Types Reference for more information about using the GATHER_FIXED_OBJECTS_STATS
procedure
Parent topic: Post-Downgrade Tasks for Oracle Database Downgrades
Regathering Stale CBO Statistics After Downgrade
Oracle recommends that you regather Oracle Cost-Based Optimizer (CBO) statistics after completing an Oracle Database downgrade.
When you upgrade Oracle Database and gather new CBO statistics, the upgraded database has new database statistics. The upgraded database also can include new histogram types. For this reason, when you downgrade the database, the statistics that you collected for the new release can be different from the previous release. This issue is applicable both to data dictionary tables, and to regular user tables.
Regather stale statistics either by using GATHER_DATABASE_STATS, or by using gather commands that you typically use to update stale statistics in the dictionary and application schemas.
For example:
-
Non-CDB Oracle Database: To regather statistics, Oracle recommends that you use the
GATHER_DATABASE_STATS
procedure, with the option'GATHER STALE'
. For example:SQL> execute dbms_stats.gather_database_stats(options=>'GATHER STALE');
-
CDB (multitenant architecture) Oracle Database: to regather Data Dictionary statistics across the entire multitenant architecture, Oracle recommends that you use
catcon
.To regather stale dictionary statistics for all PDBs in a container database, use the following syntax:
$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -l /tmp -b gatherstats -- --x"exec dbms_stats.gather_database_stats(options=>'GATHER STALE')"
To gather dictionary statistics on a particular PDB, use syntax similar to the following:
$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -l /tmp -c 'SALES1' -b gatherstats -- --x"exec dbms_stats.gather_database_stats(options=>'GATHER STALE')"
In the preceding example, the
-c SALES1
option specifies a PDB inclusion list for the command that you run, specifying the database namedSALES1
. The option-b gatherstats
specifies the base name for the logs. The option--x
specifies the SQL command that you want to execute. The SQL command itself is inside the quotation marks.
Related Topics
Parent topic: Post-Downgrade Tasks for Oracle Database Downgrades
Troubleshooting the Downgrade of Oracle Database
Use this troubleshooting information to address issues that may occur when downgrading Oracle Database.
This section contains known errors that may occur during downgrades, and workarounds to address those errors.
- Errors Downgrading Oracle Database Components with catdwgrd.sql Script
Use this section to troubleshoot errors when you run thecatdwgrd.sql
script during a downgrade, such asORA-20001
: Downgrade cannot proceed. - Oracle Multimedia Downgrade and imrelod.sql Script Error
Review if you encounter ORA-20000: Oracle ORDIM component in registry is status: DOWNGRADED. - Oracle Database Vault and dvrelod.sql Script Error
Review if you encounter ORA-31011: XML parsing failed. - Downgrading Oracle Grid Infrastructure (Oracle Restart) After Successful or Failed Upgrade
To downgrade Oracle Restart, you must deconfigure and then reinstall Oracle Grid Infrastructure. You can then add back the databases and services. - Oracle ACFS and Oracle Grid Infrastructure Downgrades to 11g Release 2 (11.2)
You must runacfsroot install
before you attempt to start the software stack. - Database Links Passwords After Downgrading Oracle Database 11g Release 1 (11.1)
Reset the passwords for any database links that were created in releases 11.2 or 12.1.
Parent topic: Downgrading Oracle Database to an Earlier Release
Errors Downgrading Oracle Database Components with catdwgrd.sql Script
Use this section to troubleshoot errors when you run the catdwgrd.sql
script during a downgrade, such as ORA-20001
: Downgrade cannot proceed.
The catdwgrd.sql
script downgrades all Oracle Database components in the database to the major release from which you originally upgraded. This script must run before the Data Dictionary can be downgraded. If you encounter any problems when you run the script, then correct the causes of the problems, and rerun the script.
Errors you can see include ORA-39709
: incomplete component downgrade; string downgrade aborted, and ORA-06512
. When these errors occur, downgrades cannot proceed.
-
Cause: One or more components that must be downgraded before proceeding with the Data Dictionary downgrade did not downgrade.
-
Action: Review the log files to determine what errors occurred before the
catdwgrd.sql
script halted, and the downgrade was stopped.
Review these examples to understand how to correct this issue.
Errors typically describe what you must do to fix the issue that is preventing the downgrade to complete. Follow the instructions in the error message. After you have fixed the cause of the error, rerun the catdwgrd.sql
script.
For example, If the CDB downgrade fails during the downgrade of CDB$ROOT due to a check, then follow the instructions in the error message to fix the condition error. After you fix the error, rerun catdwgrd.sql
with catcon.pl
. Use the -c
option to run the command with the inclusion list 'CDB$ROOT PDB1'
. Use the -r
option to run the command first on the PDB, and then on CDB$ROOT. For example:
$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -d $ORACLE_HOME/rdbms/admin -e -b catdwgrd -l /scratch/rac/downgradeLogs -c 'CDB$ROOT, PDB1, PDB2' -r catdwgrd.sql
Example 8-1 ORA-20001 Error Due To ORA-06512
Your downgrade stops. When you review the log files, you find that catdwgrd.sql
terminates on this error:
DECLARE * ERROR at line 1: ORA-20001: Downgrade cannot proceed -
Unified Audit Trail data exists. Please clean up the data first
using DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL. ORA-06512: at line 65
ORA-06512: at line 42
You must purge the unified audit trial on CDB$ROOT
and on all PDBs.
-
Look for the presence of unified audit trails:
SQL> SELECT COUNT(*) FROM UNIFIED_AUDIT_TRAIL; COUNT(*) ---------- 4538
-
Purge the audit trail. on the CDB.
For example, where the audit trail type is
DBMS_AUDIT.MGMT.AUDIT
:EXEC DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL DBMS_AUDIT_MGMT.AUDIT
-
Run
catdwngrd.sql
onCDB$ROOT
. If PDBs still have unified audit data, then the script fails with ORA20001:62 execute immediate 63 'select count(*) from audsys.'||'"'||tab_name||'"' into no_rows; 64 65 -- If audit trail has some data, raise the application error 66 IF no_rows > 0 THEN 67 RAISE_APPLICATION_ERROR(-20001, ErrMsg); 68 END IF; 69 END IF; 70 END IF; 71 EXCEPTION 72 WHEN NO_DATA_FOUND THEN 73 NULL; 74 WHEN OTHERS THEN 75 RAISE; 76 END; 77 / DECLARE * ERROR at line 1: ORA-20001: Downgrade cannot proceed - Unified Audit Trail data exists.Please clean up the data first using DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL. ORA-06512: at line 75
-
Connect to individual PDBs, and find if they have unified audit trails. Clear the unified audit trail for all PDBs. For example, The PDB named PDB1 has unified audit trails:
ALTER SESSION SET container = PDB1; SQL> SELECT COUNT(*) FROM UNIFIED_AUDIT_TRAIL; COUNT(*) ---------- 1330
-
Identify the unified audit trails:
SQL> CREATE TABLE UA_DATA AS (SELECT * FROM UNIFIED_AUDIT_TRAIL);
-
Purge the audit trails.
In this example, the audit trail type is
DBMS_AUDIT_MGMT.AAUDIT_TRAIL_UNIFIED
, theUSE_LAST_ARCH_TIMESTAMP
value is set toFALSE
, so that all audit records are deleted, without considering last archive timestamp, and theCONTAINER
value is set toDBMS_AUDIT_MGMT.CONTAINER_ALL
, so that audit records on all PDBs are purged.BEGIN DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL( AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIED, USE_LAST_ARCH_TIMESTAMP => FALSE, CONTAINER => DBMS_AUDIT_MGMT.CONTAINER_ALL END; /
-
Rerun
catdwngrd.sql
at the PDB and CDB level. For example:$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -c 'CDB$ROOT,PDB1' -d $ORACLE_HOME/rdbms/admin -e -b catdwgrd -l /u01/oracle/product/19.0.0/downgrade_logs -r catdwgrd.sql
-
Repeat the process of finding and purging audit trails and run
catdwgrd.sql
until the script completes successfully on the CDB and PDBs, and you no longer seeORA-20001
errors in logs
Related Topics
Parent topic: Troubleshooting the Downgrade of Oracle Database
Oracle Multimedia Downgrade and imrelod.sql Script Error
Review if you encounter ORA-20000: Oracle ORDIM component in registry is status: DOWNGRADED.
When downgrading Oracle Database from release 12.1 to release 11.2.0.2, an error may be raised from the imrelod.sql
script, which is included with release 11.2.0.2.
ORA-20000: Oracle ORDIM component in registry is status: DOWNGRADED. Oracle ORDIM must be installed and valid prior to Oracle Multimedia upgrade, downgrade, or patch.
-
Cause The
imrelod.sql
script raises this error because it does not know the status of ORDIM. -
Action No action. You can ignore this error.
Parent topic: Troubleshooting the Downgrade of Oracle Database
Oracle Database Vault and dvrelod.sql Script Error
Review if you encounter ORA-31011: XML parsing failed.
When downgrading Oracle Database from release 12.1 to release 11.2.0.3, databases that use Oracle Database Vault may encounter the following error, which is a result of the dvrelod.sql
script that is included with release 11.2.0.3:
ORA-31011: XML parsing failed; Oracle Database Vault downgrade to release 11.2.0.3
-
Cause The
dvrelod.sql
script does not know the status of XML parsing.Action No action. You can ignore this message.
Parent topic: Troubleshooting the Downgrade of Oracle Database
Downgrading Oracle Grid Infrastructure (Oracle Restart) After Successful or Failed Upgrade
To downgrade Oracle Restart, you must deconfigure and then reinstall Oracle Grid Infrastructure. You can then add back the databases and services.
Oracle ACFS and Oracle Grid Infrastructure Downgrades to 11g Release 2 (11.2)
You must run acfsroot install
before you attempt to start the software stack.
If you use Oracle ASM Cluster File System (Oracle ACFS), and you upgrade to Oracle Grid Infrastructure 12c, either for a cluster or for an Oracle Restart standalone server, and you choose to downgrade to Oracle Grid Infrastructure 11g Release 2 (11.2), then before you attempt to start the release 11.2 software stack, you must run the command acfsroot install
from the release 11.2 Oracle Grid Infrastructure Oracle home (Grid home).
Parent topic: Troubleshooting the Downgrade of Oracle Database
Database Links Passwords After Downgrading Oracle Database 11g Release 1 (11.1)
Reset the passwords for any database links that were created in releases 11.2 or 12.1.
After downgrading to Oracle Database release 11.1, you are required to reset the passwords for any database links that were created in releases 11.2 or 12.1.
- ORA-00600 Errors with Database Links Passwords After Downgrading to Oracle Database 11.1 Release 1
This error can occur if you do not reset the database link password. - Using Oracle Data Pump Export to Create a Dump File Containing All Existing Database Links
Before performing the downgrade, use this Oracle Data Pump export procedure to create a dump file that contains all the existing database links.
Parent topic: Troubleshooting the Downgrade of Oracle Database
ORA-00600 Errors with Database Links Passwords After Downgrading to Oracle Database 11.1 Release 1
This error can occur if you do not reset the database link password.
ORA-00600: [kzdlk_zt2 err], [18446744073709551601]
To reset the password for the database link after downgrading to release 11.1, use
the ALTER DATABASE LINK
command to change the password
back to the original password by specifying the original password in the
IDENTIFIED BY
clause.
To create new database links while running Oracle Database release 11.2 or 12.1 that
do not have this password issue, contact Oracle support for information about how to use
the IDENTIFIED BY VALUES
clause of the CREATE
DATABASE LINK
command.
Using Oracle Data Pump Export to Create a Dump File Containing All Existing Database Links
Before performing the downgrade, use this Oracle Data Pump export procedure to create a dump file that contains all the existing database links.
The dump file you create includes any newly-created database links. The procedure uses the FULL=Y and INCLUDE=DB_LINK parameters with the expdp
command.
-
Log in to SQL*Plus.
For example:
sqlplus system/manager
-
Drop the dump directory in case one exists.
For example:
SQL> DROP DIRECTORY dpump_dir; SQL> CREATE DIRECTORY dpump_dir AS '/location_to_write_datapump_dump_file';
-
Export the database links.
For example:
$ expdp system/manager FULL=Y directory=dpump_dir dumpfile=saved_dblinks.dmp INCLUDE=DB_LINK;
-
After the downgrade, if any of the downgraded database links are not working properly, then drop these links, and import them from the dump file:
$ impdp system/manager directory=dpump_dir dumpfile=saved_dblinks.dmp;
For example, if you find that links are showing the internal error ORA-00600, then dropping and importing the links from the dump file should cause those links to work as intended.