In the newer releases of Oracle database you may see components with status
OPTION OFF
in the database’s registry. But what happens to components with OPTION OFF
status during upgrade? Will those stay on the old release?
What happens to components with OPTION OFF
status during upgrade?
You may have a quick look into your DBA_REGISTRY
(or CDB_REGISTRY
). I used the check_components.sql
script.
COMP_ID COMP_NAME SCHEMA STATUS VERSION
-------- ---------------------------------- ------------ ---------- ------------
CATALOG Oracle Database Catalog Views SYS VALID 12.1.0.2.0
CATJAVA Oracle Database Java Packages SYS VALID 12.1.0.2.0
CATPROC Oracle Database Packages and Types SYS VALID 12.1.0.2.0
JAVAVM JServer JAVA Virtual Machine SYS VALID 12.1.0.2.0
OLS Oracle Label Security LBACSYS VALID 12.1.0.2.0
OWM Oracle Workspace Manager WMSYS VALID 12.1.0.2.0
RAC Oracle Real Application Clusters SYS OPTION OFF 12.1.0.2.0
XDB Oracle XML Database XDB VALID 12.1.0.2.0
XML Oracle XDK SYS VALID 12.1.0.2.0
You see that the RAC component has the status OPTION OFF
. Its version is 12.1.0.2
.
Component version after an upgrade
After you completed a database upgrade the component status is still OPTION OFF
– but the version number has changed:
COMP_ID COMP_NAME SCHEMA STATUS VERSION
-------- ---------------------------------- ------------ ---------- ------------
CATALOG Oracle Database Catalog Views SYS VALID 12.2.0.1.0
CATJAVA Oracle Database Java Packages SYS VALID 12.2.0.1.0
CATPROC Oracle Database Packages and Types SYS VALID 12.2.0.1.0
JAVAVM JServer JAVA Virtual Machine SYS VALID 12.2.0.1.0
OLS Oracle Label Security LBACSYS VALID 12.2.0.1.0
OWM Oracle Workspace Manager WMSYS VALID 12.2.0.1.0
RAC Oracle Real Application Clusters SYS OPTION OFF 12.2.0.1.0
XDB Oracle XML Database XDB VALID 12.2.0.1.0
XML Oracle XDK SYS VALID 12.2.0.1.0
As a result the RAC component has been upgraded – even though the component has an OPTION OFF
status. Every installed component with OPTION OFF
will be upgraded.
Hence for clarification we will add a sentence to the documentation:
Components supported for upgrades to the target release but have a status of OPTION OFF prior to the upgrade – they will still get upgraded. After the upgrade, these version #s will be updated but status will remain OPTION OFF.
–Mike
Thanks Mike, I. Am looking for Same information
EXECUTE dbms_registry.loading(‘RAC’,’Oracle Real Application Clusters’,’dbms_clustdb.validate’);
@?/rdbms/admin/utlrp
This will make VALID.
RAC Oracle Real Application Clusters SYS OPTION OFF 12.2.0.1.0
-Akshay Rastogi
thanx , you solved my issue
Thanks – and happy to read this!
Cheers,
Mike
Following doc can be referred for this.
Oracle Real Application Clusters Component Showing “OPTION OFF” after upgrade to 12.1 in Real Application Cluster(RAC) environment (Doc ID 2494637.1)
Hi Mike
I just have now an issue by updating a SE 19.8 to 19.10
The Patchset was wrongly prepared without the Patchset to 19.10.
Now I update before from 12.2.0.1 to 19.8 / all okay
Than from 19.8 to 19.10 only show Oracle Server upgraded to 19.10, all other remains 19.8
Installing same Patchset on a 12.2.0.1 all is upgraded to 19.10
Any clues in this?
thanks in advance
Uwe
Hi Uwe,
you only need to run “$ORACLE_HOME/OPatch/datapatch -verbose” – 19.8.0 to 19.10.0 is not an upgrade but only a patch.
Cheers,
Mike
Hi Mike
I have a database with RAC component in “OPTION OFF”, but the database is not in RAC, it’s a single instance (19c version). As part of the cleaning activity, we would like to remove from the registry the RAC component as is not necessary.
What would be the process without affecting the current single installation?
Thanks in advance
Hi Gerardo,
all non-RAC databases have RAC “OPTION OFF”. No need to worry – it does only mean that the views exist. But nothing else. It does no consume any extra time during patching or other issues.
Thanks
Mike
Ok Mike thanks for your comments.
But is there any way to remove the “Oracle Real Application Clusters” from the register?
I’ve been researching but without success.
Hi Gerardo,
there is no way to get rid of it (except for an unsupported “delete” on REGISTRY$).
THanks
Mike