----
3. When lowering the value of COMPATIBLE:
- You cannot start the database with lower compatibility, unless restoring from a backup. This is because datafiles contain COMPATIBLE information in their headers. If the parameter is increased and the database is then restarted, the datafile headers will be updated to the higher release. If then you decide to lower the parameter, this will fail with ORA-201/ORA-202.
- A default value is considered lower than a specific patchset value for the setting of the COMPATIBLE parameter. E.g. 10.2.0 is considered lower than 10.2.0.1, 10.2.0.2 etc.
-----
PURPOSE
This document aims to explain the circumstances when you may receive the below errors and what to consider in such cases:
- ORA-201: control file version <num> incompatible with Oracle version <num>
- ORA-202: control file: <name>
TROUBLESHOOTING STEPS
Getting ORA-201 and ORA-202 is directly connected to the COMPATIBLE initialization parameter:
- either you are trying to set COMPATIBLE to a wrong value
- or an incompatible operation is performed with regards to the current setting of COMPATIBLE
Significance and use of COMPATIBLE parameter:
- COMPATIBLE allows you to use a new release of Oracle, while at the same time guaranteeing backward compatibility with an earlier release. This is helpful if it becomes necessary to revert to the earlier release.
- It specifies the release with which Oracle needs to keep compatibility, at the same time permitting you to use some of the advantages of a newer release. Trying to use the new specific features which require compatibility set to the higher release will return errors.
Some requirements and restrictions that will help you to avoid ORA-201/ORA-202:
1. At upgrade/downgrade:
- For upgrade from 9.2.0.x to 11g it is mandatory to set the COMPATIBLE parameter to at least 10.1.0. After the upgrade has been completed successfully, it can be further increased accordingly if necessary.
- For upgrade from 10.1.0.x or 10.2.0.x to 11g you can leave the COMPATIBLE parameter set to its current value until the upgrade has been completed successfully.
- Downgrades from 11g to 9iR2 are not supported. This is because in the upgrade process the compatible parameter is set to a minimum 10.1.0. This prevents downgrades. For additional information, see
Note 388604.1 - ORA-00201 while downgrading from 10gR2 to 10gR1 or 9iR2
2. At database creation:
- For 11.2, the default value of the COMPATIBLE parameter is 11.2.0. The minimum value is 10.0.0.
- For 11.1, the default value of the COMPATIBLE parameter is 11.1.0. The minimum value is 10.0.0.
- For 10.2, the default value of the COMPATIBLE parameter is 10.2.0. The minimum value is 9.2.0.
- For 10.1, the default value of the COMPATIBLE parameter is 10.0.0. The minimum value is 9.2.0.
- For 9.2, the default value of the COMPATIBLE parameter is 8.1.0. The range of values is between 8.1.0 to the current release.
NOTE:
For 10.1 - 11.2, if you create an Oracle Database using the default value, you can immediately use all the new features in this release, and you can never downgrade the database.
Note that a new database can in fact never be downgraded because you can only downgrade to the last version you actually upgraded from.
For 10.1 - 11.2, if you create an Oracle Database using the default value, you can immediately use all the new features in this release, and you can never downgrade the database.
Note that a new database can in fact never be downgraded because you can only downgrade to the last version you actually upgraded from.
3. When lowering the value of COMPATIBLE:
- You cannot start the database with lower compatibility, unless restoring from a backup. This is because datafiles contain COMPATIBLE information in their headers. If the parameter is increased and the database is then restarted, the datafile headers will be updated to the higher release. If then you decide to lower the parameter, this will fail with ORA-201/ORA-202.
- A default value is considered lower than a specific patchset value for the setting of the COMPATIBLE parameter. E.g. 10.2.0 is considered lower than 10.2.0.1, 10.2.0.2 etc.
What to do if you get ORA-201/ORA-202
NOTE:
As with all destructive actions, depending on the solution you will consider from below, Oracle Corporation strongly advises taking a FULL COLD BACKUP of the database before these actions are performed.
As with all destructive actions, depending on the solution you will consider from below, Oracle Corporation strongly advises taking a FULL COLD BACKUP of the database before these actions are performed.
- Set the COMPATIBLE initialization parameter to an appropriate value.
- The impossibility to lower COMPATIBLE in some cases should not be confused with the ability to downgrade a database. It is possible to 'downgrade' a database but only as far as the compatible value setting. That is, if the db has been operating with compatible=9.2.0, you can downgrade from 10.x to 9.2.0.1.0. If the db was operating with compatible=10.1.0, you can downgrade to 10.1.0.2.0 (initial 10g Release). Outside of these restrictions you must use export/import to downgrade.
- Another option, if you need the COMPATIBLE setting lowered, you can do a point-in-time recovery to a time before the compatibility was advanced.
- Recreate the control files to make them compatible with the needed release. There is a problem at controlfile level when the error message does not contain version numbers: "control file version incompatible with Oracle version" . This may indicate that the controlfile is corrupt. This may also help when no backup is available
Other observations
- to avoid the errors in RAC the instances must have the COMPATIBLE parameter set to the same value
- to avoid the errors in standby database, this parameter must have the same value on both the primary and standby databases
4. If Controlfile is corrupted, check ORA-00227, ORA-00202: BRING UP INSTANCE AFTER MACHINE CRASH (Doc ID 1072762.6)