COMPATIBLE parameter

I want to know the impact of COMPATIBLE parameter on the database.
I have 2 database of versions on different machines.
COMPATIBLE parameter = 9.2.0.1 in one database and COMPATIBLE=10.2..0.3.0 in another.
Are both database enviornments different?
How are they dependant on COMAPTIBLE parameter?
Yachendra

COMPATIBLE parameter allow you to use some new features of the version, you should have a look into the corresponding docs.
Take care, if you are allowed to set the parameter to a higher value, you cannot modify the value to a lower value.
Nicolas.

Similar Messages

Oracle 9.2.0.7 vs Oracle 10.2.3 with COMPATIBLE parameter set to 9.2.0.7

Hi,
First off, I am NOT an oracle DBA (or even a DBA!), so please excuse my ignorance or errors contained within this post.
My client is currently planning to upgrade their 9.2.0.7 database server to 10.2.3. Reading through the oracle upgrade documentation, I came accross the compatible parameter, and further more you can set it to 9.2.0.7. I realise that by setting this, many new features introduced in Oracle 10g will not be available - however getting of the unsupported 9.2.0.7 platform is priority.
Can someone please advise what are the differences between a real 9.2.0.7 database server versus a 10.2.3 (with 9.2.0.7 compatible) server. By setting this will it guarantee sql scripts and external applications continue to work after the upgrade? I.e the list of compatibility issues detailed in the oracle database upgrade guide, will these issues be made irrelevant by this setting?
Your expert knowledge is appreciated.
Regards,
Shan

When upgrading from 9i to 10g the compatible parameter should be set to 9.2.0. All of the new feature will only be available when the parameter is set to 10.0.0 or higher and the instance restarted.
Once an instance has been restarted with a compaticble value of 10.0.0 it can never be set back to 9.x.
Why do you think the upgrade is required if you still want to use the features of 9.2.0.7?

When to change COMPATIBLE parameter while upgrading to Oracle 11G

We are planning to upgrade from Oracle 10.2.0.4 on AIX to Oracle 11.2.0.2 soon.
While reading oracle upgrade documents and from oracle upgrade blog, it is mentioned that once we change compatible parameter,
we will not be able to catdwgrd.sql to downgrade.
However, if we don't change compatible parameter after an upgrade, all the testing efforts during upgrade process wont be complete
as we may need to do another round of testing after changing this value.
So what is the best time for changing this compatible parameter? 1 week or 2 weeks after upgrade?
We are considering catdwgrd.sql as our option to fallback if something goes wrong.
Thank You
Sarayu

Hi,
It's a difficult question. If your applications are validated with 11gR2, if your OS is certified to work with Oracle 11gR2, if you adjusted the requirements etc. it will work. Will it work 100% well ? Maybe not but downgrading is really an extreme solution. 11gR2 is a fully supported version and anyway you will obtain efficient support from Oracle if you encountered a bug etc.
If you have doubts change when you are sure every critical activity/charge you expect went well for example. We cannot know if it will be after 1 week or 2 weeks : it's up to you.
Be sure you check what Tom says about the COMPATIBLE parameter (it's interesting to know exactly what it covers, it does not cover the optimizer features etc.) : http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:485421569569
Best regards
Phil

11gRel2 DBCA - using compatible parameter 10.2.0.3.0 results in ORA-00201

Hi guys,
Following is the scenario:
1. Oracle DB Binaries: 11.2.0.2.2
2. Using dbca to create General Purpose Database and then modify initialization parameter "COMPATIBLE from 11.2.0.0.0 to 10.2.0.3.0" in the "All Initialization Parameters" window.
So, when I finally start installing database, I get following error during the install:
ORA-00201: control file version 11.2.0.0.0 incompatible with ORACLE version 10.2.0.3.0
ORA-00202: control file: '/u01/app/oracle/cfgtoollogs/dbca/infpp1/tempControl.clt'
IGNORE OR ABORT...
Now you might ask why i am doing this. Actually I want to install fresh 11grel2. database with lower compatible parameter. IMPORT DP custom schemas into this database making sure compatible is set to 10.2.0.3.0. Then run database with such settings for a week and finally change compatible parameter to 11.2.0.0.0
Any thoughts where i am going wrong? as the default template seems not accepting what i am interested to do.
regards,
Anjum

It is not clear why you need to have the compatible parameter set to 10.2.0.3 for the import - it will work perfectly fine with the default value (11.2.0.2) of the compatible parameter. As you have experienced, once you set this parameter, it cannot be changed to a lower value
http://docs.oracle.com/cd/E11882_01/server.112/e23633/intro.htm#CEGJDHGI
HTH
Srini

Mismatch between COMPATIBLE Parameter and Oracle Version

Hi,
If the ORACLE version is say 11g but the compatible parameter in init.ora is say 9.2.0 or 8.1.7 what will be the effect on the database?
Will the database behave as like 11g or of the lower version?
If we alter the init.ora to the new version for compatible paremeter will it affect DB rebooting?
This is an interview question and i could not answer.
Please let me know the answers.

If the ORACLE version is say 11g but the compatible parameter in init.ora is say 9.2.0 or 8.1.7 what will be the effect on the database?
Will the database behave as like 11g or of the lower version?
If we alter the init.ora to the new version for compatible paremeter will it affect DB rebooting?
This is an interview question and i could not answer.Here, database created in 11gR2, if try to set lower compatibility it wont be allowed, Below is example.
Check this article of TKyte.
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:485421569569
Init.ora Parameter "COMPATIBLE" Reference Note [ID 30699.1]
SQL> show parameter compatible
NAME                                 TYPE        VALUE
compatible                           string      11.2.0.0.0
SQL> alter system set compatible='10.2.0' scope=spfile;
System altered.
SQL> shut immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
Total System Global Area 778387456 bytes
Fixed Size                  1374808 bytes
Variable Size             276825512 bytes
Database Buffers          494927872 bytes
Redo Buffers                5259264 bytes
ORA-00201: control file version 11.2.0.0.0 incompatible with ORACLE version
10.2.0.0.0
ORA-00202: control file: 'C:\ORACLE\ORADATA\ORCL\CONTROL01.CTL'
SQL>SID3
     Newbie
Handle:      SID3
Status Level:      Newbie
Registered:      Sep 27, 2006
Total Posts:      493
Total Questions:      68 (56 unresolved)
Name      Amritansu Ray
Close the thread if answered, Keep the forum clean.
Edited by: CKPT on Feb 15, 2012 9:54 PM

No Compatible parameter when creating 8i Repository

Hi, When I try to create the new repository (using RAU) I get an error, in ckrau61,script cktabs: "ORA-00406 Compatible parameter needs to be 8.1.0.0 or greater". It seems that I need a statement like: "Alter system set compatible='"8.1.0.0.0' scope=?????;"
What should the scope be and where does the statement go?
Thanks for your help. Martin

OK, I found it. It is a statement in the init***.ora files. There doesn't seem to be a scope clause. Why the instructions are not in the upgrade directions is anybody's guess.

Set COMPATIBLE parameter in 11.2 rdbms to 10.2.0.4?

OS: Windoze 2003/2008 x64 bit
Oracle 11.2 - 64bit
The situation is that some vendor supplied software is only "certified" for Oracle version 10.2.0.4 and the question is that if we install 11.2 and set the COMPATIBLE parameter to 10.2.0.4 will that software work without issues?
Any suggestions/criticism/ideas/experiences/links welcome.
Thx.
:)

My recommendation would be as follows given that all 10gR2 and older versions go into desupport mode August 1.
Tell the vendor they will either support those versions Oracle supports or they will immediately lose your business.
And if they do not give you a letter telling you they will support the move (and I don't mean with compatible set to something obsolete) then vote with your money and go to their competitor. One of the biggest mistakes companies make (and I see this everywhere) is not forcing vendors to sign a statement saying they will keep current with the versions of the Oracle database that Oracle fully supports. That is one of the reasons we have dinosaurs roaming these forums asking questions about 8.1.7 and earlier versions. It is inexcusable and we, the customers, should not let these cheap and lazy vendors get away with it.

COMPATIBLE parameter question

Our company makes an application which needs the COMPATIBLE parameter set to 10.2.0.1.0 . But our client says its db's COMPATIBLE parameter is set 10.2.0.3.0 . The only application that is going to run in this server will be our application. Do we have to ask the client to change the COMPATIBLE parameter to 10.2.0.1.0 or let it remain as 10.2.0.3.0?

On 10g the parameter COMPATIBLE cannot be downgraded, as once datafiles are open, they register this information on their headers.
In this particular case there is no conflict with the versions, as you are talking about the same functional version with different maintenances:
The first three digits refer to the major version and the functionality, meanwhile the last two digits refer to the DB and OS maintenance (bugs), but you are talking about the same version, 10.2.0.
~ Madrid

11gr2 database compatible parameter

I have a 11g r2 database and the compatible parameter was originally set to 11.2.0.0.0. I did an alter system set compatible='10.2.0.4' scope=spfiile;
Now when I try to start the database, it says control file version 11.2.0.0.0 incompatible with ORACLE version.
When I do a startup nomount and try to alter system set compatible='11.2.0.0.0' scope=spfile, I get ORA-32012: SPFILE format is inconsistent with value of COMPATIBLE parameter.
I also tried doing a create pfile from spfile and it gives me the same error. Is there anyway to fix this?
On another note, the reason why I tried this was because I tried installing Grid Control 10.2.0.3 using an existing database with this 11gr2 database. It doesn't let me proceed saying the database must be 10.2 or higher. It seems to not like my 11gr2 database version so that's why I tried changing the compatible parameter. Anyway to get around this?
Thanks for your help.

sb92075 wrote:
alter system set compatible='11.2.0.0.0' scope=spfile
I also tried doing a create pfile from spfile
As for shutdown abort and create the spfile, Why are you trying to CREATE SPFILE???????
it can't find the spfile in the dbs directory because I'm using ASM.Please make up your mind.
Either spfile exists or it does not.
Are you having a problem with the ASM instance or "normal" (OLTP?) instance?
Too bad CUT & PASTE are broken for you!Why the hostility? It was a typo. I was creating a pfile, not spfile.
Let me clarify. I am using ASM for this "normal" 11gr2 instance, so my spfile is located in a diskgroup called +DATA. When you shutdown the database and try to create a pfile from spfile, it looks for the spfile in the default directory under $ORACLE_HOME/dbs. So since I'm using ASM, my spfile is not located in this directory and oracle can't find the file.
Anyways, after some googling I answered my own question. I had to use create pfile from spfile='+DATA/emrep/spfileemrep.ora';
Thanks anyways...
But any direction on installing Grid Control using a 11gr2 existing database for the repository is appreciated.

Oracle Database "Compatible" Parameter - Understanding

Heloo,
Please reply on my below points related to "Compatible" parameter:
1.If we are running 10.2.0.4 on a site and the initialization parameter setting is 10.2.0.3.0 then what BAD impacts it can give on Database. Its our online banking LIVE environment.
2.Can we go back to 10.2.0.3.0 from 10.2.0.4.0?

Hi;
1.If we are running 10.2.0.4 on a site and the initialization parameter setting is 10.2.0.3.0 then what BAD impacts it can give on Database. Its our online banking LIVE environment.You are working on same level 10g, if you move your database to 9i to 10g or 10g to 11g than i belive you can look your question answer. But for your issue i belive its not neccessary
2.Can we go back to 10.2.0.3.0 from 10.2.0.4.0?Yes you can. Please see:
Downgrade from 10.2.0.4 to 10.2.0.3
Downgrade from 10.2.0.4 to 10.2.0.3
Regard
Helios

Rolling back compatible parameter to test?

I had just upgraded my instance from 9.2.0.4 -> 9.2.0.8 and received a complaint from my users about the behaviour of a certain query (it was returning no rows where before it didn't). One of the things I wanted to try doing was to temporarily roll back the instance compatible parameter to 9.2.0.4 and see if that did the trick. Is this possible? Does the compatible parameter allow one to go back and forth between old versions within a release? I can understand the hesitation between going between 9.0.1 and 9.2.0.x, but I'm moving only within the 9.2.0.x range.<BR>
<BR>
I'd looked at the forums here and the 9.2 documentation on the subject, and I couldn't find specific mention of whether it was safe to do so.

Please take that query and check by running yourself. If query is not returning any row then it does not mean, upgradation caused the problem. Query might be absolutely right.
For downgrading issue, Please read chapter 5 and 7 in the following document.
http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96530/toc.htm

Difference between compatible.rdbms in asm and compatible parameter in database

Hi Gurus,
Here i have small doubt. What is the difference between compatible.rdbms and compatible parameter in database.
We are having 2 node rac on solaris. When i checked at ASM instance level i found compatible.rdbms is set to 10.1.0.0.0 and compatible.asm is 11.2.0.0.0 and compatible parameter in database is set to 11.2.0.0.0.
Please guide me will it make any difference . Or do i need to change the compatible.rdbms to higher value.
Thanks & Regards,
Venkata Poorna Prasad.S

Hi,
I think you should check this
COMPATIBLE.RDBMS :Administering ASM Disk Groups
COMPATIBLE Oracle :Introduction to the Upgrade Process for Oracle Database
HTH

Compatible parameter set too specifically will it affect my database?

Hello,
I performed an upgrade from 9 to 10.2, when setting the compatible parameter I set that to 10.2.0.5 instead of 10.2.0.
I know that according to note 830576 and the guide, that parameter should be 10.2.0 but since I can't change it, I want to know if there would be any problems with the database or the SAP system
Thanks in advance

Hello Maria,
at first you should understand what happens when you set this parameter. Please check the official documentation for a detailed explanation: http://docs.oracle.com/cd/E11882_01/server.112/e25494/create005.htm#ADMIN11112
I want to know if there would be any problems with the database or the SAP system
Running your Oracle database with a 4 digit compatible parameter is not a "problem", but maybe you are not able to perform a rollback of the 10.2.0.5 patchset without a restore anymore. That's the reason why SAP (and other vendors) recommend to set only 2-3 digits of the oracle version.
Only Oracle knows, If the current patchset 10.2.0.5 (already) changed some stuff that is incompatible with an older 10g R2 patchset.
- A new feature stores any data on disk (including data dictionary changes) that cannot be processed with your previous release.
- An existing feature behaves differently in the new environment as compared to the old environment. This type of incompatibility is classified as a language incompatibility.
You can try to lower it and restart your DB - if your database is already incompatible you will get an ORA error.
Regards
Stefan

How to change COMPATIBLE parameter while creating the database using DBCA

I have installed 10.2.01.0 on centos 4.7
Now i want to create database with COMAPTIBLE parameter 9.2.0.1
I m trying to create database through DBCA, changed the initialization parameter COMAPTIBLE to 9.2.0.1.
But gives me error
ORA-19583: conversation termintated to error
ORA-19870: error reading backup peice /opt/oracle/assistants/dbca/templates/Seed_Database.dfb
ORA-00600: internal error code,arguments: [krbrckhr_compressed],[opt/oracle/assistants/dbca/templates/Seed_Database.dfb],[29],[30],[11420],[],[],[]
ORA-06512: at "SYS.X$DBMS_BACKUP_RESTORE", line 5149
ORA-06512: at line 16
if i dont change the value of COMPATIBLE parameter then its running perfactly...
But i have to set compatible parameter as 9.2.0.1....
Can anybody tell me how to create database using 10g R2- 10.2.0.1.0 with compatible parameter 9.2.0.1

Thank you for your response.
I have tried that opting.
After creating the database with COMAPTIBLE parameter 10.2.0.1.0 changed that parameter in init.ora file to 9.2.0 and start the database.
But at that time getting
ORA-00201: contorl file version 10.2.01.0 incompatible with ORACLE version 9.2.0.0
ORA-00202: control file '/opt/oracle/oradata/ORCL/control01.ctl'

Triggers - 00406 error (COMPATIBLE parameter)

I created a DDL - level trigger =
'create trigger prev_drop
before drop or truncate on kd.schema...'
which prevents anyone from droppping or truncating tables owned by the user 'kd'
with names starting from 'led'.
Upon compilation of the same i get the error
'ORA-00406 COMPATIBLE parameter needs to be string or greater'
Can anyone help me with this error.
null

Are you asking how to determine what parameters are in 10.2.0.3 that were not in 9.2.0.7?
I've not seen any documentation on this so my instinct would be a database link and then a variation on the following query:
set pagesize 35
set linesize 150
col NAME format a30
col VALUE format a20
col DESCRIPTION format a60
set pause on
set pause 'Hit enter to continue'
SELECT x.ksppinm NAME, y.ksppstvl VALUE, ksppdesc DESCRIPTION
FROM x$ksppi x, x$ksppcv y
WHERE x.inst_id = userenv('Instance')
AND y.inst_id = userenv('Instance')
AND x.indx = y.indx
AND SUBSTR(x.ksppinm,1,1) ^= '_'
ORDER BY 1;for undocumented parameters and just a straight MINUS set query from gv$parameter for those that are documented.

COMPATIBLE parameter

Similar Messages

Maybe you are looking for