Oracle Upgrade issue
I had upgraded oracle databases from 10.2.0.3 to 10.2.0.4. Everything completed correctly. Prior to the upgrade the compatibilty parameter was set to 10.2.0.2. I needed to put back some 'custom' parameters and at the same time changed the compatibily parameter to 10.2.0.
When bringing up the database i received the following error:
ORA-00201: control file version 10.2.0.2.0 incompatible with ORACLE version
10.2.0.0.0 ORA-00202: control file:
I put back the compatibility to 10.2.0.2 and it came up fine. Any idea as to why this error occurred?
When bringing up the database i received the following error:
ORA-00201: control file version 10.2.0.2.0 incompatible with ORACLE version
10.2.0.0.0 ORA-00202: control file:
I put back the compatibility to 10.2.0.2 and it came up fine. Any idea as to why this error occurred?
10.2.0.
is not a legal Oracle version
is not a legal Oracle version
ASKER
The compatible parameter in our production databases is set to: '10.2.0', which based on documentation is valid.
I was upgrading an existing database from 10.2.0.3 to 10.2.0.4. The database prior to the upgrade had compatible set to 10.2.0.2. Afterwards, in order to gain the functionality of the new version, changed it to 10.2.0 That's when the error occurred.
I was upgrading an existing database from 10.2.0.3 to 10.2.0.4. The database prior to the upgrade had compatible set to 10.2.0.2. Afterwards, in order to gain the functionality of the new version, changed it to 10.2.0 That's when the error occurred.
10.2.0 is less than 10.2.0.2. As stated already, you cannot go backward. To get all the functionality possible, compatible should be set to the database version, 10.2.0.4.
ASKER
Ok.. then why in our production envirnment is 10.2.0 working when the version is 10.2.0.3... just a little confused. thanks!
Did you change your it from 10.2.0.2 to 10.2.0 in production?
>>then why in our production envirnment is 10.2.0 working when the version is 10.2.0.3..
Likely because it was 10.2.0 when you created your database, or either it was previously an even earlier version (8i or 9i perhaps) that was also upgraded and set to 10.2.0
Just because it runs with 10.2.0 in production is irrelevant, what is relevant is that you _changed_ a later version to 10.2.0.
The use of the compatible parameter is clear, it directs Oracle to or not to make use of certain features as well as _disk structures_ based on compatibility, so by definition moving _backwards_ is a problem, just like trying to open a 10.2.0.4 database with a 10.1.0 binary is also a problem.
Likely because it was 10.2.0 when you created your database, or either it was previously an even earlier version (8i or 9i perhaps) that was also upgraded and set to 10.2.0
Just because it runs with 10.2.0 in production is irrelevant, what is relevant is that you _changed_ a later version to 10.2.0.
The use of the compatible parameter is clear, it directs Oracle to or not to make use of certain features as well as _disk structures_ based on compatibility, so by definition moving _backwards_ is a problem, just like trying to open a 10.2.0.4 database with a 10.1.0 binary is also a problem.
ASKER
Regarding production... yes it was an earlier version 9i, that was upgraded to 10g. I apparently misunderstood the setting. I was understood it that 10.2.0 would apply to all versions and not that it would be 'downgraded' version. So, bottom-line, change it to 10.2.0.4 to match the version that is running to get use of any new features...
I typically never set it except at database creation, or major version upgrade. Not during patches, so I recommend you leave it as it was.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Mr. johnsone is absolutly correct.
This parameter is set only when you expect version conflicts
with some components and would like the installation to
function like the version you mention.
But I do not have evidence you need something like this.
There are more then 300 init parameters, but we change only a couple of them
and do major changes when we need to change the behavior of the DB.
This parameter is set only when you expect version conflicts
with some components and would like the installation to
function like the version you mention.
But I do not have evidence you need something like this.
There are more then 300 init parameters, but we change only a couple of them
and do major changes when we need to change the behavior of the DB.
ASKER
thank you
The compatibility param controls what Oracle can not only support in the instance, but also what it writes to disk, and it is the disk that is important in this case, it tracks it in the control file as well. Once the database is created, you cannot go backwards because Oracle might have written structures to disk that are incompatibile.
You can move it forward, but not backwards, without an export and import.